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?

  • 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 '19 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 '19 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 '19 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 '19 at 9:42
  • 1
    As written, this is a poll. Polls don't work well in the SE Q&A format. – user53019 Jun 21 '19 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.

| improve this answer | |
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.

| improve this answer | |
  • 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 '19 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 '19 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.

| improve this answer | |
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.

| improve this answer | |
  • 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 '19 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 '19 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 '19 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 '19 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.

| improve this answer | |
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. :)

| improve this answer | |
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...

| improve this answer | |
  • 1
    Useful but wouldn't tell you where exactly in the code you'd stopped. – Robbie Dee Jun 21 '19 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 '19 at 15:20
  • That would be the ideal of course but that is somewhat optimistic... – Robbie Dee Jun 21 '19 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 '19 at 9:34

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