Inspired by this question: What to do about "stopping point syndrome"?

I often find myself a half hour away from knocking-off time having just wrapped up a component of my work, and facing a "next piece" that is going to take more than half an hour. (That's happening right now, as a matter of fact. Hence my surfing stackexchange during business hours!)

What do you do? Launch into the new piece knowing you'll have to stop in the middle? Set it aside and twiddle your thumbs until the clock runs out?

  • @Closer: How is this off topic?
    – TheLQ
    Commented Dec 10, 2010 at 21:36
  • @TheLQ, this isnt related to programming, and could just as easily apply to any job. Commented Dec 10, 2010 at 21:47
  • 1
    @GrandmasterB - but wouldn't you expect answers in the context of being a programmer? A painter may start cleaning brushes, not very helpful.
    – JeffO
    Commented Dec 10, 2010 at 22:08
  • @Jeff, I'd expect the question to ask something related to programming. This is just too vague. But hey, thats why it takes 5 votes to close. Commented Dec 10, 2010 at 22:15
  • Isn't this just the same as the stopping point question?
    – Matt Ellen
    Commented Dec 10, 2010 at 23:14

5 Answers 5


There is also something to be said for where in your schedule are you at this point. For example, on a Friday afternoon I may pick quite a different option than I would on a Tuesday or Wednesday where I know I'm coming back the next day to pick it up. At the same time, starting on something can carry some initial tasks, e.g. updating the bug tracking software or creating a branch in source control, that can be good to get out of the way earlier rather than later.

There are likely to be some administrative things,e.g. time sheets, reflections on what got done and didn't get done, that may be worth spending that half-hour that may end up taking a bit more time than you think if you enjoy things like reflecting on how your week has gone. "Life moves pretty fast. If you don't stop and look around once in a while, you could miss it." as Ferris Bueller said some 24 years ago now is something else to point out here.


Start working on the next piece.

When it's time to wrap up, find a logical place to stop (the last line of code, perhaps), save your work, write a brief note reminding yourself where you are and what you need to do next, leave it on your keyboard and go home.


Find a simple task you can do that does take a half hour or less. Update some documentation, refactor a test or two, fiddle with your dev environment config, or shoot off a few emails.

Basically, there are always dozens of tasks I put off because the big stuff takes priority. But I know they'll never happen if I don't make a little time for them.


How important is the clock to your employer?

The simple answer may be to sometimes start the new task and see it through, finishing late as a result, but sometimes just leave early. So long as you're averaging out right, and getting work done on time, starting/leaving at exactly the right time shouldn't be an issue - though there are probably core hours when you are expected to be there and available to answer questions etc.

The problem is, of course, that not all employers will see it this way.

Even if no-one is watching the clock, it's probably a good idea to watch your hours yourself, though - keep yourself from sliding down a slippery slope to trouble without noticing.


I keep a list of non-urgent tasks (update this wiki page, refactor this class, write some basic unit tests for this other tasks, do code reviews for X Y and Z...), with associated ballpark estimates. When I don't want to leave yet because it's rush hour but don't want to start on my next task because then I'll be there until the next morning, I just pull things off of this list until traffic dies down.

In my biased opinion, everyone should have such a list - it helps avoid lost time due to trying to dig up something to work on.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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