<story><title>Bring Back the 40-hour work week (March 2012)</title><url>http://www.salon.com/2012/03/14/bring_back_the_40_hour_work_week/</url></story><parent_chain><item><author>bokonist</author><text>Software is generally a winner-take-all market.  Software has zero marginal cost, so the company with the most revenue can invest the most upfront into making a better product, giving it even more revenue.  Furthermore, in most cases there is little incentive for customers to ever use the second best product in a segment.  So when building software, you not only have to meet the customers needs, you have to meet the customer needs better than any competitor.  If you produce a product that is half as good or improve the product half as quickly, you do not lose just half your revenue, you could lose all of it.&lt;p&gt;The second aspect of software development is that a developer working 40 hours a week is more productive than two developers working 20 hours a week.  With the sole developer, there less communication overhead, less management overhead, and the ratio of productive time to time learning the system and understanding the interlocking parts is higher.  This is the classic mythical man month problem.&lt;p&gt;The third aspect of software development is that directly measuring output and effort of an engineer is very difficult.  So as a proxy, managers look for signs of passion and engagement.   If you are passionate and smart, but are slow to implement some feature, management will believe the feature was simply more difficult than anticipated.  If you generally are not passionate about your work, and are slow to implement some feature, management will think you are slacking and fire you.  Creating an effective company requires creating a culture of passion and hardwork, and having one person only work part-time can decrease the morale of those putting in 40+ hours.  Asking to only work half-time betrays a lack of passion, and could be a bad career move.&lt;p&gt;So the net result of these factors is that a company must work at maximum efficiency, and maximum efficiency comes when all developers are working 40+ hours a week.  It is not in the company&apos;s interest to let you work only 20 hours a week, and it could indeed be risky if you bring the idea up with management.&lt;p&gt;I should also note that the above dynamic is not just the case in software, but in virtually all high paying jobs, from professional athlete to corporate lawyer to corporate executive.  Virtually all high paying jobs have some sort of competitive, winner take all dynamic in the market at large (the winners being the ones who get paid well), and within the company, the high paid people are the ones with specialized, hard to replace skills, that have a large ramp up time to learn effectively (learning a large code base, learning a set of legal traditions, learning how to hit a curveball, etc, etc).  Thus in order to earn the high pay you must work long hours, and you must work many productive hours on top of a base of ramping-up hours.</text></item><item><author>drewblaisdell</author><text>Perhaps this is a good thread to pose this question.&lt;p&gt;I am a front-end engineer in my early twenties. Right now, 40+ hours a week is doable and I am paid well, but I don&apos;t need all of the money I&apos;m earning. I would &lt;i&gt;gladly&lt;/i&gt; take a 50% salary cut and work ~20 hours a week.&lt;p&gt;The only problem with this is that I feel like this is a risky thing to bring up with an employer. Has anyone ever had any success getting a good part-time job or downsizing your position at a company? Every listing for part-time I see seems to be for someone with a lesser skillset.</text></item></parent_chain><comment><author>adrianhoward</author><text>&lt;i&gt;The second aspect of software development is that a developer working 40 hours a week is more productive than two developers working 20 hours a week.&lt;/i&gt;&lt;p&gt;I am unsure that this is true in all circumstances.&lt;p&gt;&lt;i&gt;So the net result of these factors is that a company must work at maximum efficiency, and maximum efficiency comes when all developers are working 40+ hours a week.&lt;/i&gt;&lt;p&gt;I know for a fact that this isn&apos;t always true - since I&apos;ve repeatedly seen teams of developers doing 45+ hour weeks become &lt;i&gt;more&lt;/i&gt; productive by every metric we had to hand by dropping their working week to 40 hours (with only about 6 hours a day of that being coding).&lt;p&gt;I talk about this in a little bit more over here before (&lt;a href=&quot;http://news.ycombinator.com/item?id=3883362&quot; rel=&quot;nofollow&quot;&gt;http://news.ycombinator.com/item?id=3883362&lt;/a&gt;)... copy/paste below.&lt;p&gt;-----&lt;p&gt;There is something deeply broken about equating hours to productivity.&lt;p&gt;It&apos;s been my experience that folk are very good at deceiving themselves about their productivity (myself included :-)&lt;p&gt;One team I worked with had a serious problem with overtime. They were putting in stupid hours and it was showing in the quality of work going out. So I ran an experiment where we all agreed to work &quot;normal&quot; hours for six weeks.&lt;p&gt;I was &quot;only&quot; working about 45 hours a week at this point, when other people on the team were regularly working 50-60. I was relatively young, didn&apos;t have any family pressure, enjoyed my work and felt very productive doing those hours. I wasn&apos;t one of the people with a &quot;problem&quot; as I saw it. We were running the experiment for the other folk on the team.&lt;p&gt;In the experiment we dropped to a 40 hours week (6 hours coding per day, 2 hours for breaks, meetings &amp;#38; lunch). After a couple of weeks adjustment my productivity went way up. I also felt a lot better in myself - generally sharper and more on the ball.&lt;p&gt;People seem to have quite a wide bad of &quot;this feels okay&quot; that subsumes the much narrower &quot;I&apos;m performing at my best&quot;.&lt;p&gt;Also people don&apos;t jump from a 35 hour week to 60 hours a week. It creeps up a few minutes at a time as pressure increases on the team. People have enough time to adjust to it being &quot;normal&quot; and don&apos;t notice the drop in productivity that goes with it.&lt;p&gt;Currently I work roughly 25-30 hours a week and am just as productive by all metrics that I have available to me as when I worked 40-50.&lt;p&gt;I would strongly urge people to experiment. Pick some metrics, try working shorter hours for a month, see what happens.&lt;p&gt;(The only caveat I would add is that with folks doing silly hours - anything over 50 I would say - there is often a couple of weeks where things go to hell as the body adjusts. On the team from the story practically everybody caught a bug and felt crap for the first week or so before productivity rose again).</text></comment>
<story><title>Bring Back the 40-hour work week (March 2012)</title><url>http://www.salon.com/2012/03/14/bring_back_the_40_hour_work_week/</url></story><parent_chain><item><author>bokonist</author><text>Software is generally a winner-take-all market.  Software has zero marginal cost, so the company with the most revenue can invest the most upfront into making a better product, giving it even more revenue.  Furthermore, in most cases there is little incentive for customers to ever use the second best product in a segment.  So when building software, you not only have to meet the customers needs, you have to meet the customer needs better than any competitor.  If you produce a product that is half as good or improve the product half as quickly, you do not lose just half your revenue, you could lose all of it.&lt;p&gt;The second aspect of software development is that a developer working 40 hours a week is more productive than two developers working 20 hours a week.  With the sole developer, there less communication overhead, less management overhead, and the ratio of productive time to time learning the system and understanding the interlocking parts is higher.  This is the classic mythical man month problem.&lt;p&gt;The third aspect of software development is that directly measuring output and effort of an engineer is very difficult.  So as a proxy, managers look for signs of passion and engagement.   If you are passionate and smart, but are slow to implement some feature, management will believe the feature was simply more difficult than anticipated.  If you generally are not passionate about your work, and are slow to implement some feature, management will think you are slacking and fire you.  Creating an effective company requires creating a culture of passion and hardwork, and having one person only work part-time can decrease the morale of those putting in 40+ hours.  Asking to only work half-time betrays a lack of passion, and could be a bad career move.&lt;p&gt;So the net result of these factors is that a company must work at maximum efficiency, and maximum efficiency comes when all developers are working 40+ hours a week.  It is not in the company&apos;s interest to let you work only 20 hours a week, and it could indeed be risky if you bring the idea up with management.&lt;p&gt;I should also note that the above dynamic is not just the case in software, but in virtually all high paying jobs, from professional athlete to corporate lawyer to corporate executive.  Virtually all high paying jobs have some sort of competitive, winner take all dynamic in the market at large (the winners being the ones who get paid well), and within the company, the high paid people are the ones with specialized, hard to replace skills, that have a large ramp up time to learn effectively (learning a large code base, learning a set of legal traditions, learning how to hit a curveball, etc, etc).  Thus in order to earn the high pay you must work long hours, and you must work many productive hours on top of a base of ramping-up hours.</text></item><item><author>drewblaisdell</author><text>Perhaps this is a good thread to pose this question.&lt;p&gt;I am a front-end engineer in my early twenties. Right now, 40+ hours a week is doable and I am paid well, but I don&apos;t need all of the money I&apos;m earning. I would &lt;i&gt;gladly&lt;/i&gt; take a 50% salary cut and work ~20 hours a week.&lt;p&gt;The only problem with this is that I feel like this is a risky thing to bring up with an employer. Has anyone ever had any success getting a good part-time job or downsizing your position at a company? Every listing for part-time I see seems to be for someone with a lesser skillset.</text></item></parent_chain><comment><author>lostnet</author><text>This is exactly what a lot of companies and managers will try to tell you.. But it is a bunch of nonsense.&lt;p&gt;An actual 40 hour a week programmer is an awful asset, if we do more than ~20 hours of work a week the rest is bad code and the shit we are to tired of thinking about to fix/automate. The ones who work 50+ hours have forgotten that things can be automated or even pondered before diving in, or that are powerless to fix the accumulating breakage of their group/project/company.&lt;p&gt;That being said, a 20 hour a week engineer who is partying the remainder probably isn&apos;t great either.&lt;p&gt;I currently work 3 days a week, but I spend about half of the remainder studying things that interest me, mostly in CS or physical sciences. A few years back, I worked 2.5 days in tech support, while finishing up my BS.&lt;p&gt;I would say live and breathe it while you are there, you should be senior/mature enough that you don&apos;t require mentoring/sponsoring to do your job, be a bit humble about your immediate &quot;importance&quot; and handle those longer term pains, and have a nice (but unapologetic) explanation for how you spend your other time.&lt;p&gt;If overall I spend less than 25-30 hours a week thinking about the field then expect to gradually feel rusty. But then CS is not a good field to mentally slow down in.</text></comment>