When a project has a tight deadline, it requires the entire team to be 100% focused on delivery; in those cases, delivery time is by far more important than quality. There's an old saying: 9 moms can’t make a baby in 1 month. Therefore, does working more hours on a daily basis actually increase productivity for engineers?
When building software, developers have certain periods of the day when they're most productive; most of them are night owls, so that is why it is common to see them arriving late in the morning and leaving the office late at night. Sometimes they tend to continue to work from home because developers believe that the solution to developers-block is to get out of the office and change the scenery.
I know CEO's want engineers to stay in the office as long as possible, but staying longer at the office won't affect productivity. The reason is because in between those periods of high productivity, developers go into stand by mode, a mode where new ideas simply don't come to mind.
Writing code isn’t a recipe; it's not as easy as sitting down, selecting the right music, reading requirements and making them “magically” work. There’s a lot of constraints when implementing new features: where is the code going to live, should I write the code from scratch, should I find a library someone else has written -- the possibilities to solve a programming challenge are endless.
Every developer will at one point understand what they have to do and develop a roadmap to follow, but after several hours of coding, they'll inevitably hit a roadblock: an unexpected obstacle that was not accounted for when they originally planned the day.
We luckily now have tons of online content such as stack overflow where many common issues have been resolved, and if there’s not one to fulfill your needs, you can post your question and wait for other developers to help out. But even with these tools in place, developers will encounter issues no one else has experience and they will have to somehow get it resolved before moving forward.
This happens to all of the best developers: you reach a point where you're stuck. You spend all of the day focused, fixated on this problem -- it could take hours, days, or perhaps even a week. And all the while, you have "the boss" breathing down your neck asking, "Hey, I haven't seen any progress in the project management tool”. It's extremely difficult for "the boss" to understand that you're constantly working on solving the problem in your head while you sleep, while you eat, or while you go out for a walk. Even if you take a step away from the problem and work on a separate task, it's difficult to devote your brain power to this separate task as you're still focused on the main problem at hand.
When a developer has reached this state, they are like zombies; you can ask questions or even take them out for a walk (beer), but they will definitely continue to have part of their brains working on how to solve that problem.
We recently worked on a project where we migrated servers. We have developed a comprehensive checklist of 'things to do for a migration' that has come from years of experience, which should result in a flawless migration process; however, last month we faced errors that we had never encountered before.
We scheduled our downtime period for 5 hours (starting at midnight so that we would not affect the majority of our users). By the time we were 50% complete with the migration, the process crashed, forcing us to start over and extend our downtime an additional 2 hours.
After a sleepless night, morning came and we opened the door of our website to users once again; as you can imagine, we were working like zombies and by noon, many bugs and errors were found. We lost attention to details and obviously every minor update we intended to perform took longer than expected -- exactly what happens when a zombie developer has been fighting with an uncommon issue.
An experienced developer has been heavily exposed to these challenges while a young coder has not. The different technologies a developer has used in the past will make him stronger when issues are present and working as a team will help to fix these type of issues faster.
People in this industry who have not experienced this feeling don’t understand how to manage developers -- that’s one of the reasons many techies sometimes do not connect with their managers. A few years ago I had the opportunity to lead a project where some of the stakeholders were new to this field; it took me longer than usual to make them trust the work of the team and to help them understand that developers are more productive and effective when they're not micromanaged.
Sometimes it's best to just let the developer be and figure out the problem without any distractions. If you interrupt their workflow with meetings and progress reports, then you'll interrupt their flow, leading to longer development time.
I invite managers who have never coded to learn the basics of coding in just one language. It will help you understand what the “Zombie developer” feels when the code you're writing does not work, and you’ll feel the relief and satisfaction that developers feel when they finally find the solution.