4

I just had a more than 2-week long vacation/business trip and I couldn't remember actually what was I working in my coding and where I stopped. Could someone recommend a best practice to solve this?

closed as too broad by gnat, Doc Brown, Bart van Ingen Schenau, user53019 Jun 21 at 11:45

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    This does not look like a Software Engineering question. TheWorkplace.SE is probably better suited (but better check if someone else has already asked such a question there before). – Doc Brown Jun 21 at 6:20
  • @DocBrown I can sense a disturbance in the field, as if millions of engineering notebooks cried out in terror and were suddenly silenced. – candied_orange Jun 21 at 8:46
  • 2
    @DocBrown Why call it Software Engineering if we don't consider Engineering traditions like an engineering notebook part of it? – candied_orange Jun 21 at 8:57
  • 2
    @candied_orange: I admit, my above comment was too terse. I actually meant "This does not look like a question specific to Software Engineering", but more like a general workplace issue". Just replace "code" by something else. – Doc Brown Jun 21 at 9:42
  • 1
    As written, this is a poll. Polls don't work well in the SE Q&A format. – user53019 Jun 21 at 11:45
8

Copious notes. Write down your thoughts, your progress, in as much detail as needed to clear your mind.

It's no different from when you do a problem analysis tracking down a bug and someone else is going to execute the fix (or yourself at some indeterminate point in the future). Write down EVERYTHING of consequence. When I do it I won't usually write in the line numbers per se as they may have changed by the time the ticket is executed, but class names, method names, etc. etc. where changes are to be made are mentioned.

And try to leave the codebase in a somewhat predictable state. Don't leave in the middle of implementing a method for example. Leave the entire method unimplemented and make a note that it's the next thing to be done.

7

The most obvious recommendation is to always stop at a point where all of the work is "done". So when you return, you start on something new instead of trying to remember where you left of.

Instead of looking at it as a vacation time, look at it as if you worked in some different part of the application. So after few weeks, you return to module you worked on few weeks or months back. To me, best solution to this are automated tests. With automated tests, I can start playing around with code. When I mess up, I can look at which test failed and see what the intention behind the code was. This allows to quickly remember what the code was meant to do and what was reasoning behind it.

  • 1
    This IMHO is the right answer. Your project is made up of lots of little parts, you should aim to finish each one before taking a significant break and moving onto the next. In other words... scrum – Liath Jun 21 at 10:45
  • I agree with this. keeping the tasks small enough that they can be done in a day or less seems to be the generally accepted practice. Having this guideline makes the problem stated a non-issue – Ivo Beckers Jun 21 at 12:08
4

How do you know where you stopped in your codes after a 2-week break?

The same way I know where I stopped after I take a bathroom break.

Notes.

You take notes, you make to do lists, you don't walk away from the 2 hours of work that it took to get an idea spun up in your brain without writing it down.

Add method names, file names, ideas worth exploring, things to check out, questions to answer.

Then go to the bathroom before you make a mess.

The process is remarkably similar when going on vacation. The only difference is how much work other people did while you were gone. Maybe talk to them before jumping right back in.

3

Personally, I leave an intentional compile error.

I write a short comment to myself in the code. Then I uncomment it.

When I get back, by force of habit I start up my IDE, build, and...hey, something's broken!

I go there, and there's my note, telling me what I was working on.

  • 2
    Not saying I never did this before by myself, but I would not recommend to make this a regular practice. If code does not compile, and you leave it that way over 2 weeks, that means you keep uncommitted or unmerged changes over the same period in your local working copy, which is seldom a good idea. – Doc Brown Jun 21 at 8:43
  • 1
    @DocBrown Nothing prevents you from pushing to a remote feature branch before you go on vacation. Just make the situation clear in the commit message. – Kyralessa Jun 21 at 10:01
  • If it really is work in progress, you'd probably want to put this in a shelfset rather than commit to a branch - even a development one. – Robbie Dee Jun 21 at 11:36
  • @RobbieDee If you're using Git, a branch is the only thing that makes sense. If you're not using Git, then...I will keep my opinions to myself. – Kyralessa Jun 21 at 16:35
1

Simple. Keep a notebook which records all work done that day and lessons learnt. Make a record every time you stop work. I use // to indicate breaks in work but do whatever suits you.

This is also a valuable tool for project management queries when they're asking why you didn't finish X, Y & Z on a given day.

For a more senior (i.e. older) developer like myself who probably has fewer years ahead than behind, it acts as a source of pride for everything you've achieved over the years. I have many of these in the loft covering different jobs and roles and like to dig them out every so often.

0

I sometimes use a counter-intuitive approach, especially over a weekend. Start on something and leave it slightly unfinished, may not compile, fail a unit test etc. When I come back, this jogs my memory sufficiently to continue working.

P.S. This approach may not work for everyone. :)

0

Do you follow AGILE ?

If you do then you can have sprints, with Kunban charts...

So it could point you out to the feature \ bug you were working on...

How it going to help OP ?

When user stories are broken down to tasks, ideally tasks should be less then a day, so when you come after 2,4,8 weeks holidays, you will work on next task assigned to you :)

Commit regularly and when come back, check commit history, it's really easy with Azure DevOPS or sourcetree...

  • 1
    Useful but wouldn't tell you where exactly in the code you'd stopped. – Robbie Dee Jun 21 at 11:34
  • @RobbieDee it actually does if your tasks are broken down into less then a day, so ideally OP will finish task they were working on before going on holidays and pick up next one when they are back. – Mathematics Jun 21 at 15:20
  • That would be the ideal of course but that is somewhat optimistic... – Robbie Dee Jun 21 at 18:02
  • @RobbieDee this is the standard way of working with Agile and it's common and works very well too – Mathematics Jun 23 at 9:34

Not the answer you're looking for? Browse other questions tagged or ask your own question.