<story><title>Ask HN: Why don&apos;t companies hire programmers for fewer hours per day?</title><text>Hello&lt;p&gt;Maybe this question doesn&amp;#x27;t properly apply to USA programmers since labor laws are a little different there, but let me try.&lt;p&gt;Rationale: we always discuss how programming makes us tired and stressed, how often we spend hours and hours per day just procrastinating or being completely unproductive while still trying to be. Also, we often discuss how programmers get paid nice salaries in comparison with most other professions. This leads me to the conclusion: I&amp;#x27;d probably be very happy to take a 25% (or more) salary cut if I had to work 25% (or more) less. I mean, 8 hours per day is a lot and it&amp;#x27;s very rare for me to have a fully productive day. If I moved to 6 hours per day, I&amp;#x27;m not even sure if I&amp;#x27;d become less productive, I&amp;#x27;d probably just spend less time chatting at the coffee room, and have a smaller chance to get burnout. Maybe a little less productive, but the company would be saving some money with me, and if they did this to other 3 people they would be able to hire another 6h&amp;#x2F;day programmer to balance things, maybe making the result even positive for them.&lt;p&gt;But, considering that no company does this, it looks like this isn&amp;#x27;t a good idea for employers. Why? Why do companies try to squeeze all the possible juice from employees instead of the alternative where they pay a little less, require a little less, and the employee becomes much more happy?&lt;p&gt;And the question to the workers: wouldn&amp;#x27;t you accept a proportional salary reduction for a proportional time-spent-inside-the-office-doing-whatever reduction?</text></story><parent_chain><item><author>Piskvorrr</author><text>Quoting TMMM as a justification for product death march? Wow.&lt;p&gt;A programmer who works 55 hours a week will produce twice as much code - but for how long? Once fatigue settles in (a few weeks in), you&amp;#x27;re back at the 40-hour productivity levels, just paying it at 55-hour rates (and organizational overhead for overtime, oooh boy!), plus burning out the developers (and organizational overhead for employee churn).&lt;p&gt;Your assumption is that 55 hour weeks are sustainable: just change this number in the spreadsheet from 40 to 55, and voila! And while we&amp;#x27;re at it, why not 80? Why not 200? Very PHB-ish, in my unhumble opinion.</text></item><item><author>dustingetz</author><text>Mythical man month says that even if longer hours have diminishing returns, the organizational overhead from adding people to the team is worse - fewer people with longer hours is the better alternative.&lt;p&gt;Here I will quote a HN post which quotes a secondary source which analyses mythical man month&lt;p&gt;&lt;i&gt;&amp;quot;From a business point of view, long hours by programmers are a key to profitability. Suppose that a programmer needs to spend 25 hours per week keeping current with new technology, getting coordinated with other programmers, contributing to documentation and thought leadership pieces, and comprehending the structures of the systems being extended. Under this assumption, a programmer who works 55 hours per week will produce twice as much code as one who works 40 hours per week. In The Mythical Man-Month, the only great book ever written on software engineering, Fred Brooks concludes that no software product should be designed by more than two people. He argues that a program designed by more than two people might be more complete but it will never be easy to understand because it will not be as consistent as something designed by fewer people. This means that if you want to follow the best practices of the industry in terms of design and architecture, the only way to improve speed to market is to have the same people working longer hours. Finally there is the common sense notion that the smaller the team the less management overhead. A product is going to get out the door much faster if it is built by 4 people working 70-hour weeks (180 productive programmer-hours per week, after subtracting for 25 hours of coordination and structure comprehension time) than if by 12 people working 40-hour weeks (the same net of 180 hours per week). The 12-person team will inevitably require additional managers and all-day meetings to stay coordinated.&lt;/i&gt;&amp;quot;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=3547965&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=3547965&lt;/a&gt;</text></item></parent_chain><comment><author>skywhopper</author><text>One of the points of TMMM is that communication and coordination overhead is a cost and a risk and that it grows exponentially in relation to the number of programmers you have. So, you won&amp;#x27;t get double the productivity out of twice as many programmers (unless they&amp;#x27;re on unrelated projects--but more projects == more overhead as well).&lt;p&gt;200 hour weeks would be quite unsustainable, indeed. Forget not sleeping, where do you get the other 32 hours?</text></comment>
<story><title>Ask HN: Why don&apos;t companies hire programmers for fewer hours per day?</title><text>Hello&lt;p&gt;Maybe this question doesn&amp;#x27;t properly apply to USA programmers since labor laws are a little different there, but let me try.&lt;p&gt;Rationale: we always discuss how programming makes us tired and stressed, how often we spend hours and hours per day just procrastinating or being completely unproductive while still trying to be. Also, we often discuss how programmers get paid nice salaries in comparison with most other professions. This leads me to the conclusion: I&amp;#x27;d probably be very happy to take a 25% (or more) salary cut if I had to work 25% (or more) less. I mean, 8 hours per day is a lot and it&amp;#x27;s very rare for me to have a fully productive day. If I moved to 6 hours per day, I&amp;#x27;m not even sure if I&amp;#x27;d become less productive, I&amp;#x27;d probably just spend less time chatting at the coffee room, and have a smaller chance to get burnout. Maybe a little less productive, but the company would be saving some money with me, and if they did this to other 3 people they would be able to hire another 6h&amp;#x2F;day programmer to balance things, maybe making the result even positive for them.&lt;p&gt;But, considering that no company does this, it looks like this isn&amp;#x27;t a good idea for employers. Why? Why do companies try to squeeze all the possible juice from employees instead of the alternative where they pay a little less, require a little less, and the employee becomes much more happy?&lt;p&gt;And the question to the workers: wouldn&amp;#x27;t you accept a proportional salary reduction for a proportional time-spent-inside-the-office-doing-whatever reduction?</text></story><parent_chain><item><author>Piskvorrr</author><text>Quoting TMMM as a justification for product death march? Wow.&lt;p&gt;A programmer who works 55 hours a week will produce twice as much code - but for how long? Once fatigue settles in (a few weeks in), you&amp;#x27;re back at the 40-hour productivity levels, just paying it at 55-hour rates (and organizational overhead for overtime, oooh boy!), plus burning out the developers (and organizational overhead for employee churn).&lt;p&gt;Your assumption is that 55 hour weeks are sustainable: just change this number in the spreadsheet from 40 to 55, and voila! And while we&amp;#x27;re at it, why not 80? Why not 200? Very PHB-ish, in my unhumble opinion.</text></item><item><author>dustingetz</author><text>Mythical man month says that even if longer hours have diminishing returns, the organizational overhead from adding people to the team is worse - fewer people with longer hours is the better alternative.&lt;p&gt;Here I will quote a HN post which quotes a secondary source which analyses mythical man month&lt;p&gt;&lt;i&gt;&amp;quot;From a business point of view, long hours by programmers are a key to profitability. Suppose that a programmer needs to spend 25 hours per week keeping current with new technology, getting coordinated with other programmers, contributing to documentation and thought leadership pieces, and comprehending the structures of the systems being extended. Under this assumption, a programmer who works 55 hours per week will produce twice as much code as one who works 40 hours per week. In The Mythical Man-Month, the only great book ever written on software engineering, Fred Brooks concludes that no software product should be designed by more than two people. He argues that a program designed by more than two people might be more complete but it will never be easy to understand because it will not be as consistent as something designed by fewer people. This means that if you want to follow the best practices of the industry in terms of design and architecture, the only way to improve speed to market is to have the same people working longer hours. Finally there is the common sense notion that the smaller the team the less management overhead. A product is going to get out the door much faster if it is built by 4 people working 70-hour weeks (180 productive programmer-hours per week, after subtracting for 25 hours of coordination and structure comprehension time) than if by 12 people working 40-hour weeks (the same net of 180 hours per week). The 12-person team will inevitably require additional managers and all-day meetings to stay coordinated.&lt;/i&gt;&amp;quot;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=3547965&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=3547965&lt;/a&gt;</text></item></parent_chain><comment><author>mannykannot</author><text>MMM is actually an important part of the answer, and it is unfortunate that it was presented this way (death marches are deprecated for their own reasons.) The right way to think of this is to consider four people each working two hours a day on the same problem. Sustained effort and focus matter.&lt;p&gt;This is most true for tasks that are more intellectually demanding, like the development of large-scale software (which is what Brooks was writing about.) The more routine a task is, the easier it is to divide it up (though that is rarely to the benefit of the worker.)</text></comment>