An eight hour work day doesn’t mean eight hours of coding

Categories Development

One of the most important factors to take into consideration when setting deadlines is that, for a programmer, an eight hour work day doesn’t actually mean eight hours of coding.
This is a mistake that a lot of project managers make when setting deadlines for tasks. Even worse, this is a mistake that many programmers make when they estimate future work, thus perpetuating the project managers evil deadline strategy.

If you are just a programmer in a normal team, and depending on chosen technologies and organizational overhead, at least a quarter of your day will be filled with non-code-producing activities. If you are a tech lead, even more of your time will be lost in administrative tasks or programmer assistance.

What non-code producing activities am I talking about? Well just think about it!

* Reading your emails. Sounds like a 5 minute job right? Wrong. It takes one or two minutes on average to read an email. What if you receive 70 emails? 20 are spam. You still have 50 to read. It takes you 100 minutes. You answer 10 of them. You just lost 2 hours of your time.
* Reading issues. I suppose you have an incident tracker. You can loose an hour just by reading incidents, setting priority, thinking about fixes, etc.
* Helping your peers. You can’t say no to a peer that needs your assistance. Especially if you are tech or component lead. Scratch off two more hours.
* Why not have a meeting or two. Necessary. Scratch two more hours.

The list can go on, but I’ll stop here.

The point is this. Next time you set a programmer’s deadline or you ask him for an estimation think about the fact that “an eight hour work day doesn’t mean eight hours of coding”.

4 thoughts on “An eight hour work day doesn’t mean eight hours of coding

  1. This is exactly how my days go too – and you’re right about the part where you have to help coworkers since you’re most likely working on the same goals. If management knows what they are doing, they will plan and assign the roles in such a way that there is little downtime. If I’m spending a big part of my time helping a colleague on a regular basis, then the colleague may end up pulling down the whole team.

  2. Working in a support/development role I can agree with this completely. I get to work at 8 o’clock and there are days where it can take till well past 10 to just get to actually reading my email. Replying to them can take most of the day if im not careful. If I could actual sit and spend 50 % of my time on programming and product development I would be lucky

  3. it’s important to let a client know that too because if you say you charge 50$ an hour for coding updates and you tell the client it’ll be ready in a couple of days they might think you are going to charge for 2x8x50 for the job! (I speak from experience)

Leave a Reply

Your email address will not be published. Required fields are marked *