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

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!

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.

You left off "Visit Stack Exchange to collaborate with others in your field."

Update your tickets in your ticketing system! (Jira, etc)

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

Also, try to reduce those 500 years of technical debt.

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

Depending on your organization's culture, leaving early to beat traffic home could be an option.

I'd like to also throw in any "required" training or compliance videos your company has.

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

@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 :)

Update any software that's out-of-date

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

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

@WesleyLong the code IS the comments! ;)

@paqogomez - OMG, did you honestly jump into The Workplace just to drop that one? I'm honored. :)

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