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



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


Posted 2017-04-21T15:18:48.697

Reputation: 4 358


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 2017-04-22T10:21:39.330

123Leave early and stay 30 minutes longer the next day.usr 2017-04-22T15:40:28.917

11I 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 2017-04-24T08:02:17.077

8“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 2017-04-24T09:11:16.287

1which will lead to me losing time Yes, but I find it very hard to believe that you lose that same amount (30 minutes) next day. Get to work ;-)Jan Doggen 2017-04-24T12:28:56.110

6If 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 2017-04-24T21:13:14.443

You're lucky. My problem as a young programmer was that my brain would get into a really high gear around 5pm when the phone and the interruptions stopped, so I would get going, work, look up eventually, and it would be 8pm. I don't claim that anything productive generally happened during that time, quite oten the opposite, but it may, just may, have meant that I learnt my trade a little faster. There's always some busy-work that needs going instead: your timesheet, tidy the workspace, answer some pending questions, plan the next days' work, ...EJP 2017-04-25T09:36:36.683

2Prevent losing context by writing the failing(!) unit tests of the next problem first. The next morning those tests will show you what you were working on. These test will be more readable than any half finished code.Erno de Weerd 2017-04-25T10:20:05.723

Can't you just go home?Ares 2017-04-27T04:49:38.870

@usr Should be like that but in a lot of companies its not possible.marxin 2017-04-27T11:38:00.533

“As a developer [...] if I start coding the very start of a task I know that I will struggle to continue it the next day” Well, before doing the programming part you are going to do the development/program structuring part, right? A developer is the person who solves the problem and then (optionally) codes, to the contrary of a programmer that just takes instruction on what solution has to be realized and does it (which is also a non-trivial task). So grab your pencil, a notebook and draw out the whole structure of your program/class/whatever you have to implement.Andrea Lazzarotto 2017-04-27T12:39:53.507



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


Posted 2017-04-21T15:18:48.697

Reputation: 3 583

332+1 There is not a single developer on the planet who couldn't spend 30 minutes filling in the documentation in the code productively.Wesley Long 2017-04-21T16:24:09.157

38The second point really should be the first! Towards the end of the day, I tend to look at the to-do list I made in the morning/last night. Usually, there's a small item that keeps getting bumped.corsiKa 2017-04-21T17:26:56.747

2@corsiKa and I find the third point most helpful. When leaving the desk, I sketch tasks for the next 8 hour period of coding. This both helps me "let off" the job, and to very quickly start doing work in the morning. Otherwise, the first hour in the morning is wasted in waking up.Vorac 2017-04-21T17:30:26.607

So very very very much this. There is always something to do. Having the time to do it is a blessing; make the most of it!Lightness Races in Orbit 2017-04-21T18:06:58.983

Even if it's just browsing Bugzilla and getting yourself re-acquainted with the state of the current release, or mentally updating yourself with the broader development plan.Lightness Races in Orbit 2017-04-21T18:07:35.510

182You left off "Visit Stack Exchange to collaborate with others in your field."Omegacron 2017-04-21T19:52:21.693

1Update your tickets in your ticketing system! (Jira, etc)SethWhite 2017-04-21T20:14:17.787

6While this list is a useful inspiration there is a risk of finding low-value work just to fill the time. If you normally wouldn't have done something (e.g. document) why only do it if you have accidental spare time?! Makes no sense. Either the work is of value and should be done, or not.usr 2017-04-22T15:41:38.430

1Also, try to reduce those 500 years of technical debt.angarg12 2017-04-22T21:30:55.027

21"start the backup" does not belong on the list. Backups is not something that you only do when you happen to have some time left over. It is something which needs to happen automatically regardless of whether anybody is paying attention to it or not.kasperd 2017-04-23T00:27:50.963

2Depending on your organization's culture, leaving early to beat traffic home could be an option.MooseBoys 2017-04-23T00:59:19.080

1I'd like to also throw in any "required" training or compliance videos your company has.Kimberly W 2017-04-23T01:54:12.193

@kasperd Unfortunately it does not for everyone. For laptops, we have to at least plug in the backup disk, then we can theoretically wait for it to start automatically. People tend to forget, until they are finally thinking they are done with the day. Same goes for usr. Yes, You should theoretically have done most of this already, but let's be honest, we run behind everything all day. The idea of the answer was more or less "You are NOT done when you think you are done."skymningen 2017-04-24T08:50:47.643

1@usr No, not really. In fact, that's the whole premise of the question - it's less efficient to start a big, high value task in those 30 minutes than to complete a shorter task with a lower value. You must also consider the costs, not just the value of the end product - you're optimising for "profit", not "income". If you actually had 8 hours of productive workday ahead of you, a 30m task would carry an opportunity cost (since you could have been doing the higher valued task instead), but the same isn't true when you only have thirty minutes. And that's not even considering motivation :)Luaan 2017-04-24T08:55:58.053

Update any software that's out-of-dateuser2023861 2017-04-24T15:07:39.957

2I would like to suggest adding additional testing to the list. If you finish a new version of your program, and you have time left over, try to think of the dumbest thing you think the dumbest possible user of your program could do, and make sure that won't break it. If your program still works, think of something even dumber, and try it. If you can't find any new bugs by dumbing it down, start thinking of crazy things instead of dumb things, and get crazier with each successful test. You'll likely either discover a bug before you ship, or find your program is more robust than you thought.Justin Time 2017-04-24T16:40:13.127

@JustinTime I prefer to not do testing when I would not have enough time left to think about solutions. If you find something, you might easily end up in overtime.skymningen 2017-04-25T06:57:21.657

@WesleyLong the code IS the comments! ;)paqogomez 2017-04-25T20:01:43.343

2@paqogomez - OMG, did you honestly jump into The Workplace just to drop that one? I'm honored. :)Wesley Long 2017-04-25T20:06:29.870

@skymningen That's a good point. I was kinda thinking of just testing until time's up, and leaving a note for yourself or coworkers if you find something, though, instead of actually trying to fix anything you find right then.Justin Time 2017-04-27T16:47:28.750


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.

Kate Gregory

Posted 2017-04-21T15:18:48.697

Reputation: 95 749

18+1 on this! Also works great for other writing (essays, stories, ...) and other things that have a long completion time -- leaving a "cliffhanger" makes you want to return to it and finish, which is a great way to start your day.KlaymenDK 2017-04-21T19:06:53.147

4This is also true if you have to make changes to existing code. Since modifying existing code can be more difficult, starting to dip into it and structuring what sort of changes you want to make can be helpful. And if you realize you'll have some tricky decisions to make, then great! You'll iterate over that in your mind off-and-on that evening and the next morning and hopefully come to some great conclusions you might not have without casually thinking about it during your down-time.Ellesedil 2017-04-21T20:02:28.863

for want of 30 minutes, i could easily find something professional to do online regarding sites like this one or journals. and i could easily spend 30 minutes sizing up and planning the next coding project, and even writing a line or two of code. there are also personal/workplace things to do at the "water cooler" with the peeps you work most closely with. 30 minutes will disappear quickly.robert bristow-johnson 2017-04-21T20:08:37.410

8+1 One of my wife's mantra's for her (writing) clients is "park on a downhill slope". (She learned that from Ken Skier.)Ethan Bolker 2017-04-22T13:31:27.550

3As a developer, I'm taking this idea one step further. I make a code change that makes the code break when I try to compile it. The tool will remind me the next day where I left the things, instead of me trying to search for the file or running git status to find it outIgor Soloydenko 2017-04-22T20:16:05.157


This technique in described in Robert Cialdini's recent book "Pre-suasion" on page 89 in reference to the Zeigarnik effect. The anecdote that he relates (though as I just mentioned this is backed up by research) is he had a friend who was also a writer whom he found very productive. Her technique was to never stop writing for the day at the end of a paragraph or a thought. This was presented more as a way to avoid procrastination which is arguably more related to the Ovsiankina effect.

Derek Elkins 2017-04-22T22:47:49.253

While it might work for some people, I don't like this solution because it will inevitably lead to me continuing to think about filling in what I started on and off for the following 15+ hours when I'm nominally not working, i.e. taking work home with me. I'm fortunate enough not to be working in a situation that requires physical presence or fixed hours, but the same definitely applies - having an unfinished, in-progress task that's going to block other work or bitrot if not finished seriously cuts into my ability to get the work out of my mind and do/enjoy other things.R.. 2017-04-23T21:23:46.237

5Are you reporting what happens to you when you do this, or what you think happens? Because I always wanted to get to a stopping point so that I could leave work behind when it was over. To my surprise I found that stopping abruptly and just walking away - I work at home so I just leave documents open and the laptop up - made it simpler to change gears and forget work until it was work time again. As I said at the top of the answer, this feels counter intuitive. What happens for most people is not what most people would predict happens.Kate Gregory 2017-04-23T22:51:01.493


I first came across this mentioned by Paul Halmos in his "How to Write Mathematics" (end of section 7): “A good technique, to help the steadiness of your rate of production, is to stop each day by priming the pump for the next day. What will you begin with tomorrow? […] It’s surprising how well you can fool yourself that way; the pump-priming technique is enough to overcome the natural human inertia against creative work.”

ShreevatsaR 2017-04-24T04:59:34.700

2That's what some programmers use ToDo mark in code for. Write your plans here and continue later.La Mi 2017-04-24T08:28:43.373

1In practice, I've found this very useful indeed. Instead of coding (or writing or whatever), I write notes - what the task I'm going to work on is about, general lines of thought, what must not be forgotten etc. The next day, I start with reading those notes, and usually add more to them (not just "morning is wiser than evening", but "morning and evening together are wiser than either alone), reconsider some decisions etc. Instead of having to deal with (likely relatively poor) "last night's work", I tend to improve the quality of the task, even if I stop in the middle.Luaan 2017-04-24T09:01:29.867

2Bonus: You get to start your next day like a TV drama, with "Previously on The Walking Developers..." along with a recap of where you left off the day before.loneboat 2017-04-24T13:53:16.273

2I started implementing your suggestion, and found it quite useful thus far!Mister Positive 2017-04-24T15:11:18.313


Roald Dahl used the same trick, which he learned from Hemingway (see ). I and other developers I know find it absolutely true. We look forward to coming in the next morning and jumping into the work.

Travis Wilson 2017-04-24T19:02:39.617

While I like this suggestion, I don't think it answers the question, because you've just moved the problem. If writing the initial boilerplate is the ideal way to leave a task, and it takes you 30 minutes to write the boilerplate, now you have a problem when you finish the big task one hour before. Or when you finish the big task exactly at quitting time. Unless the proposal is "you can stop at any time and it's actually fine," then this doesn't really resolve the underlying problem of how to deal when the work flow doesn't match up with the hours in the work day--it just moves it.GrandOpener 2017-04-24T22:17:31.983

2I expect the boilerplate to take far less than 30 min - maybe 1 or 2. My point is that you can and should just leave at quitting time, and that you shouldn't be casting around 30 minutes before that for a 30 minute task that will take you to a natural stopping point. You should stop away from such points, to the extent that if you just finished a big thing, best to start something to get you away from the natural stopping point. The opposite of "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" from the OPKate Gregory 2017-04-24T22:27:41.743

1I like this idea, and a good way is to leave having written a failing test. That way, you get a quick win - making the test pass - in the morning, and quickly into the flow. If you've forgotten where you were, running the tests will tell you.davidsheldon 2017-04-26T10:01:59.040

1This is actually good life advise as well. I hate jogging, but I need the exercise. How to get started - well put on your shorts, running shoes, hydrate, find the earplugs... get ready and THEN decide if you want to go jogging. It is so much easier to decide when you have done all the threshold climbing in advance.Stian Yttervik 2017-04-26T10:45:11.470

@KateGregory Personally I sometimes prepare the boilerplate, but most of the times, I just think without writing anything and perform eventually some google search about technical point. When I come the next day, I already have a clear mind about how I will do it.Walfrat 2017-04-27T12:19:28.103


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.

Philip Kendall

Posted 2017-04-21T15:18:48.697

Reputation: 32 317

Yes it's more of a "7 hours a day, no more no less" thing.sh5164 2017-04-21T15:25:10.050

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 2017-04-21T18:08:16.227

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 2017-04-21T20:08:44.473

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 2017-04-21T20:53:06.153

@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 2017-04-21T23:41:46.790

I agree 100% with @Philip but the first thing I would so is talk to the boss. Having been both a contractor and permanent both for many years I have found that most competent bosses/project managers understand this situation and will be happy for you to leave early and make the time up when it is needed. If not then just hang out on one of the "stack" sites for 30 minutes and book it on your timesheet as R&D...ElPedro 2017-04-25T21:51:29.883


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.


Posted 2017-04-21T15:18:48.697

Reputation: 7 370

The trouble with that is that in OOP, even planning can take a lot of time.sh5164 2017-04-21T15:31:21.680

2Yes, 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 2017-04-21T16:17:57.217

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 2017-04-21T16:53:56.917

What is "wire frame code comments"?Peter Mortensen 2017-04-21T22:46:35.577

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 2017-04-22T03:01:10.687


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!

Mister Positive

Posted 2017-04-21T15:18:48.697

Reputation: 40 497

5Whether doing review / answering tasks on Stack Exchange during your working hours is okay may be very company specific, I guess.Jonas Wielicki 2017-04-21T16:30:30.933

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 2017-04-22T11:29:50.740


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

Timothy Truckle

Posted 2017-04-21T15:18:48.697

Reputation: 507

2+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 2017-04-21T17:04:11.150

@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 2017-04-21T19:11:56.893

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 2017-04-24T09:07:19.587


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


Posted 2017-04-21T15:18:48.697

Reputation: 221


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.

Joe Strazzere

Posted 2017-04-21T15:18:48.697

Reputation: 207 512

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 2017-04-22T07:53:37.753

What do you need to take home if you're working from home?mayu 2017-04-26T07:25:51.173

Hopefully you will move less and less printed documents. It's not good for your back and paper sheets are notoriously hard to secure :)mayu 2017-04-28T00:28:15.440


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.


Posted 2017-04-21T15:18:48.697

Reputation: 562

1I tend to take the time and answer questions in stackOverflowSnowlockk 2017-04-21T16:01:39.727


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.


Posted 2017-04-21T15:18:48.697

Reputation: 1 156


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.

Robert Dundon

Posted 2017-04-21T15:18:48.697

Reputation: 1 462

You should just mention action items and then leave for the reader to assume. Please list them up for others take them from.Smit 2017-04-21T19:17:51.543

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 2017-04-21T20:32:26.233


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.

Count Iblis

Posted 2017-04-21T15:18:48.697

Reputation: 733


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

Make your code a little bit better.

Gray Sheep

Posted 2017-04-21T15:18:48.697

Reputation: 1 060


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.

Pieter B

Posted 2017-04-21T15:18:48.697

Reputation: 1 645


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.


Posted 2017-04-21T15:18:48.697

Reputation: 1 668

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 2017-04-23T03:47:41.987