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

Question

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 ?"

Answer 1

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.)

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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!

Answer 6

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...")

Answer 7

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...

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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

Make your code a little bit better.

Answer 14

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.

Answer 15

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.

Answer 16

As i understand these 30 minutes are left after all the clerical / administrative duties.

In my experience, i use this time to note my train of thoughts and future functionality i plan. in most descriptive way possible

Answer 17

1. Documentation There is not a project in the world which doesn't need better documentation, or updated documentation.
2. Natural stopping points. I prefer to stop here, since things are clean. For me, it's for morale, energy and organization.
3. Reading. There's always some useful tip/trick to read and understand, or some technique which you need to try out, so that you can use it efficiency in your later work. There's the problem that the first time you use a new technique, you will be slower. This is the time to burn to get through that.