324

As a developer, I often get to this point where at the end of the day I finish a big task and still have approximately 30 minutes to go.

The problem is that 30 minutes are not enough time for me to code anything, and if I start coding the very start of a task I know that I will struggle to continue it the next day while losing the context and will have to re-read the code, which will lead to me losing time.

But to focus on the professional problem, I don't want to slack off at work for so much time and staying there doing nothing during 30 minutes just seems absurd.

How do I deal with the "30 minutes remaining" issue?

EDIT : To explain why it's not a duplicate, the trouble is not about "what to do when the systems are down at work ?" or "what to do when I have nothing to do?" but "what to do when you arrive close to the end of the day and don't have the time to start a new task ?"

  • 3
    Comments are not for extended discussion; this conversation has been moved to chat. Remember what comments are for: if you're trying to answer the question, please do so in an actual answer after checking that existing answers haven't covered your points already. – Lilienthal Apr 22 '17 at 10:21
  • 136
    Leave early and stay 30 minutes longer the next day. – usr Apr 22 '17 at 15:40
  • 11
    I sometimes go through all the browser tabs and decide whether to bookmark them or just close them without bookmarking. Sort of 'cleaning your desk at the end of the day'. This can take some time, especially after a bug hunting day. – Pavel Apr 24 '17 at 8:02
  • 9
    “staying there doing nothing during 30 minutes just seems absurd” — thinking that 30 minutes of downtime is a problem seems absurd to me, unless your job somehow involves saving people’s lives with every minute of effort you expend. – Paul D. Waite Apr 24 '17 at 9:11
  • 6
    If re-reading your code is that hard, then maybe you should be reading your code more often. We write code (hopefully once) but we and others read it many times. If the code is that hard to follow, you have some issues to work on, namely readability. Not saying you are a bad coder, but if reading code you worked on yesterday takes that much time, then something is wrong. – boatcoder Apr 24 '17 at 21:13

15 Answers 15

458

There are plenty of options:

  • Check (relevant) blogs/news/journals and read what's going on in your field
  • Document what you have done during the day
  • Plan what you need to do the next day/week/month
  • Get back to your mail and finally really get the information you missed while skipping through it earlier
  • Check if you have done all of the "organizational tasks", and if not, do them (Hand in your hours, send that report on your desk to whoever should read it, start the backup,...)
  • Clean your whiteboard/desk/desktop of anything that accumulated there but has lost relevance three weeks ago
  • You have done all of this? Still 30 minutes? Go back to step 1! (And, you are a magician.)
  • Comments are not for extended discussion; this conversation has been moved to chat. – Snow Sep 2 at 14:31
326

In addition to planning your day, tidying things up, and just plain leaving early (to make up for staying late other times), let me suggest something that probably seems very counter-intuitive:

Try to avoid stopping at a "natural stopping point"

You worry that if you get half an hour into a coding task, you'll find it hard to load up context when you get back to it the next day. But my experience is precisely the opposite. Say you are going to write a simple function. You know there will be some initialization, a loop to process all the X in the Y, and some cleanup. I will literally add the file to my project, declare the function, add three comments (maybe writing the for or while construct around one of them) and then -- go home.

In the morning, when you get in, you don't need to remember what you were doing or consult your notes -- it's all right there for you. Why go home with an empty file, or a blank sheet of paper, waiting for you in the morning? Instead, at least write a title or a subject line. At least write the name of the function. If you're supposed to write a document, make the folder, create an empty document with the right name, and put the title of the document at the top of the first page. Apply a style sheet.

Get started. Then leave. You may be VERY pleasantly surprised -- it is much easier to get started if you didn't stop at a natural stopping point. Launching off from these points is super easy.

In fact, it's so easy that I sometimes use a variant of this to trick myself into working on something I don't want to work on. I just do the "get started" part - making the new project or empty folder or whatever. Making a file called outline and pasting in the outline from email. Downloading the spec or release notes. Finding the link to that video I need to watch. None of this really counts as working on the thing I don't want to work on, it's just the getting started stuff that would enable me to actually work on it, so I do these tasks without resistance. And then I find, when I've done them, that my resistance falls away and I'm able to do the task itself.

Try it.

  • Comments are not for extended discussion; this conversation has been moved to chat. – Snow Sep 2 at 14:31
32

I would be more than happy to see you go home and make up the 30 minutes some other day. As you say, you'll be far more productive doing this than you will trying to do 30 minutes work, losing your context overnight and trying to restart in the morning.

But I'm never a stickler for the "9 to 5" job anyway. Your employer may be more regressive stricter on this.

  • Yes it's more of a "7 hours a day, no more no less" thing. – sh5164 Apr 21 '17 at 15:25
  • Downvote because there is always a productive and fun way to fill this time (see sky's answer). Skipping out early is not applicable here. A developer isn't just coding all the time; a good developer maintains mental context of the world around them, the state of the release/product, any new issues raised on the tracker... read them! A nice soft thing to do for the last 30 mins of the day... during which you're still being paid and expected to be available for questions! – Lightness Races in Orbit Apr 21 '17 at 18:08
  • 9
    @BoundaryImposition: This entirely depends on your work environment. If working hours are dynamic (and almost every place I've been, this has been true), then every developer is keeping their own hours. Some show up 7 and leave before 4 while others show up at 11 and leave around 9. As long as everyone is putting in a full-time level of effort and getting their work done, most places won't care too much about when you leave. Some of the other things you mention, developers are likely to do in their free time anyway. So... I can't say I agree with the criticism here. – Ellesedil Apr 21 '17 at 20:08
  • 2
    @BoundaryImposition The point isn't that you can find something productive to do, it's doing the thing which adds most value to the company. The poster is an intern, they're probably not going to add much value worrying about the state of the product or answering other people's questions. – Philip Kendall Apr 21 '17 at 20:53
  • @PhilipKendall: I couldn't disagree more. That is a standard "I work here" practice and the intern is there to learn such crafts. – Lightness Races in Orbit Apr 21 '17 at 23:41
18

Practice planning and writing it down. You can't code something else up, but there is usually some planning to code that goes on and if you write it down in those 30 minutes you can read it first thing the next day and start coding. If you get through one plan, just do another one so you are prepped to dive in on a couple items instead of just one.

The level of notes on this will be dependent on you as a person and what helps you remember best, but the goal is to plan and articulate in such a way it jogs the memory of the planning and puts you right back where you were yesterday without too much loss of thought. I've seen this done in wire frame code comments, on paper, post it notes, text editors, white board pictures, etc... Find what works best for you.

  • The trouble with that is that in OOP, even planning can take a lot of time. – sh5164 Apr 21 '17 at 15:31
  • 2
    Yes, this was going to be my answer. Spend the last 30 mins making notes for what you intend to do the next day to finish it. You'll help frame the problem in your mind, and likely the subconcious will think of things later you missed at the "code face", plus it gives you the briefing you need to start the next day (plus if you are agile it may give you things to mention at the standup). – The Wandering Dev Manager Apr 21 '17 at 16:17
  • This, i spend spare time making a checklist of things left to do and upcoming as well as documenting exactly where I left off, as in the morning (or over the weekend) its very easy to forget where you stopped. – DasBeasto Apr 21 '17 at 16:53
  • What is "wire frame code comments"? – Peter Mortensen Apr 21 '17 at 22:46
  • basically the same thing that Kate Gregory articulated in detail. Not complete coding, but pieces with comments in the code stubbed for future understanding. Different people call it different things... – mutt Apr 22 '17 at 3:01
12

How to deal with the "30 minutes remaining" issue ?

This happens to me once in awhile, I suggest you use the time to your advantage.

I use these unexpected time gifts for research into new technologies, or analysis of my next task, or I answer/review questions on Stack Overflow. I learn a lot just by reviewing new questions and answers.

Don't just sit and pretend to be busy. Make good use of the time!

  • 5
    Whether doing review / answering tasks on Stack Exchange during your working hours is okay may be very company specific, I guess. – Jonas Schäfer Apr 21 '17 at 16:30
  • Of course this should apply to the highly relevant Stack Overflow projects first. You should only go to music.stackexchange if you write a tool like Sibelius. – eee Apr 22 '17 at 11:29
11

As a developer you're never done.

Even if you cannot add new functionality to your code in the time left you can (and should) refactor it:

  • improve names,
  • reduce code duplication,
  • split long methods/functions/procedures into shorter ones
  • move methods/functions/procedures to new files to apply SRP and/or same level of abstraction principle.

and other stuff like that.

Any of this tasks takes a few seconds by using your IDEs automated refactoring capabilities. And your unittest will guarantee that you did not change the applications behavior as it is currently implemented.

And in the unlikely case you broke something: checkout the last working state from your SCM...

  • 3
    +1 Taking a few minutes to think about the quality of your work (let alone actually improving it) is a very professional thing to do! In fact, it's required for professional growth. – employee-X Apr 21 '17 at 17:04
  • @jpaugh "+1 Taking a few minutes to think about the quality of your work" Thanks, but why not doing it? As written it is safe and fast. – Timothy Truckle Apr 21 '17 at 19:11
  • That's the last thing I would want to do at the end of a day. If your unit tests are perfect, and you never introduce a change that takes more than a minute or two, and you don't introduce merging issues... maybe. Just considering possible improvements (and planning for them if they seem worthwhile) seems to carry less cost to me, and seems to be just as effective in the long run. The hardest bit is overcoming the inherent brain-inertia in even considering the costs and benefits of any change. – Luaan Apr 24 '17 at 9:07
10

I maintain a "sweep list" of tasks that occur to me as I'm working on something else - tasks that are just long enough that I don't want to digress into working on them right away (or that I don't want to tackle immediately for some other reason - like "I want this commit to contain only one logical change"), but short enough that they don't merit all the overhead associated with normal projects. Whenever I encounter a task like this I scribble it down on the list with a large helping of detail - where to go, what to do, who might benefit and how long I expect it to take. Most of the things on it are corner cases too minor to get "official" resources, refactors that should be done, unit tests that should be written, etc., but things that my colleagues ask me for while I'm in the middle of something else also go on this same list (hence the "who might benefit").

When I have leftover bits of time, I go to the list and just start pulling random things. Each item is self-contained and highly predictable in terms of the amount of time it takes, making them perfect for squeezing in when I have 15 minutes before a meeting, 5 minutes after setting up for a conference call, etc. Plus, when someone is late to a meeting nothing makes them happier than "Hey, I was thinking of you so I squeezed in that feature you asked me for six months ago, isn't it lovely?" (And nothing makes me happier than not sitting there, thinking, "*&@$ meetings, never start on time...")

5

How to deal with the "30 minutes remaining" issue ?

I always devoted the last 30 minutes of each day to:

  • Cleaning up any remaining emails
  • Checking and updating my calendar
  • Prepping for the next day
  • Packing anything I needed to bring home (particularly if I was planning to do some work at home)

These are things you could consider doing if you often find yourself with 30 unscheduled minutes to spare at the end of the day.

And if I actually didn't have any worthwhile activities remaining, I'd just leave.

  • 1
    -1 because basically it's something you always do. It's not accidental time for which you had no plan. In your version: what do you do when you have done your things with an hour remaining? Because that hour is actually 30 minutes because you already have you en-of-day 30 minutes planned in. Do you also do the same chores at the end of the day if your in the middle of coding? Do you stop coding then to tidy up? – Pieter B Apr 22 '17 at 7:53
  • What do you need to take home if you're working from home? – tymtam Apr 26 '17 at 7:25
  • Hopefully you will move less and less printed documents. It's not good for your back and paper sheets are notoriously hard to secure :) – tymtam Apr 28 '17 at 0:28
2

If you are hourly, use the time to do some busy work like adding comments and general cleaning up. I typically also use these last 30 or so minutes to send emails, write reports, and fill out work logs.

If nothing else, cruise Stack Overflow and look busy.

  • 1
    I tend to take the time and answer questions in stackOverflow – Snowlockk Apr 21 '17 at 16:01
2

Do some of the tasks that there "isn't time" for

There are lots of tasks which an organisation might believe there is "no time" for, but which can create technical debt if left - testing sometimes falls into this category.

Convincing management that they need to spend money on tasks that save money at some indeterminate future time is often difficult. This time, if they complain, you can point out that you had a spare 30 minutes at the end of the day, and point out that you found X number of bugs.

Too often, developers are pressured to finish things faster and there is insufficient quality oversight.

Check that something you wrote recently is done to spec - This happened to me yesterday. I re-read part of the spec for something, and realised it wasn't quite right - spent about 20 minutes fixing that.

1

Personally, this happens to me, for about the last 15-20 minutes of the day.

What helps me is planning the next day (or week) by coming up with a few action items, etc.

  • You should just mention action items and then leave for the reader to assume. Please list them up for others take them from. – Smit Apr 21 '17 at 19:17
  • It is not a problem to cross over in the next day, not much difference if you stop at 23:50 or 0:20. Typically it's more like I need to force me to stop when I have to get up (only partially kidding here). I am somewhat shocked about how widespread rigid office hours seem to be. – eckes Apr 21 '17 at 20:32
1

You should consider splitting up your time at work in blocks that are large enough to be able to allow you to work freely within each block but which are not excessively large. You may think that arbitrarily large bocks that last as long as necessary to get some task done works well for you, but concentration does suffer after a few hours of uninterrupted work. If you enforce a break after, say 2.5 hours, then you can spit a 9 hour work day (8 hours work plus 1 hour breaks) in 3 such blocks with 20 minute coffee/lunch breaks between blocks and an additional 50 minutes exercise break.

You'll then eliminate this "last half hour problem", there is only ever going to be a last 2.5 hour block which will feel totally differently than your current last hours at work. If a task gets finished within the last block, you'll have much more energy to continue with other tasks or plan for next day. You'll have started that block with more energy and at the start of the block you'll probably know that you're going to finish ahead of time, which makes you more inclined to think positively about doing other work after the project is done.

The fact that you're now not inclined to do that is an artifact of "working until the end of a task" which drains mental energy; if you organize your work as long marathons then it's no surprise that at the end of a task you feel like a marathon runner at the finish.

1

Any software over a (not very high) complexity can be made always a little bit better.

Make your code a little bit better.

0

My job has different kinds of work. Work that needs to get done today. Work that needs to get done this week. Work that needs to get done within the next half year.

The work that needs to get done in the next half year mostly consist of small menial tasks with little "think-work". These are the things I do in the free time between bigger tasks. They're nice fillers to let your brain relax at the end of the workday.

0

Think ahead. Unless you are really right at the end of a package of work and "only have one thing left to do", switch to another task that will take you up to the end of the day before you get into the "only 30 minutes remaining" situation.

Actually, I don't really understand why "30 minutes are not enough time for me to code anything" - if you don't (or can't) break your work into pieces smaller than that, it doesn't sound a very efficient way to make progress. In fact if you used a time management technique like Pomodoro you would be breaking all your work into 30-minute pieces.

  • 2
    The Wikipedia page you linked doesn't really describe breaking down work into 30-minute pieces, but just describes arbitrarily inserting breaks when the timer rings. Is Wikipedia wrong here, and does the technique need cutting tasks in small pieces before starting to work on them? – Paŭlo Ebermann Apr 23 '17 at 3:47

protected by Lilienthal Apr 22 '17 at 10:19

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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