+1 There is not a single developer on the planet who couldn't spend 30 minutes filling in the documentation in the code productively.

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

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.