I seem to be alone in this, but I actually do about 25-30 hours of actual programming work each week. And that's sit-down-and-concentrate-and-build-shit work. I'm pretty ruthless about declining extraneous meetings and I keep my door closed most of the time.<p>I think it's reasonable to have 25% of a 40-hour week be for meetings, helping other people, eating lunch, sitting in on interviews, and learning/trying out new things.<p>And yeah, 25-30 hours is probably a maximum, and it needs to be done in three-hour chunks at a minimum. As a manager you can <i>easily</i> destroy that by allowing an environment where a solid three-hour block of time never happens for a dev.
I both agree and disagree with the premise that programming is a creative process. Donald Knuth calls programming “an aesthetic experience much like composing poetry or painting.” The most creative work can be done when it's not clear if something will work or not, that is it might fail, and it requires the ambition of a mad scientist to succeed. The individual programmer must have autonomy and not be micro-managed or ruled by a committee, otherwise they will resort to being creative in ways that are petty and insignificant, like naming conventions, syntax formatting, arbitrary rules, etc.<p>99% of programming jobs are not creative jobs. Most problems aren't that unique, and most programmers work within well-established boundaries and frameworks. Step out of line or take unconventional risks, and you may find yourself unemployed. This is not necessary bad, it brings stability, but also stagnation (it is why enterprise IT culture is so soul-draining, from first-hand experience). Not only enterprise but many startups operate this way. There is overwhelming cognitive bias towards doing what other people are doing, which will only lead to the same results.
A: you hire young one that have no idea what they're doing and jump into problems both feet without thinking a path ahead<p>and for every programmer claims to work that much, you also get two of them complaining on the costant shit the overworked one produces and have to fix strange bug half their time<p>eventually the software becomes a mess of tangled issues and advancement grinds to an halt irregardless of amount of time spent
The "IPO-ing will make me exceedingly wealthy" scenario is certainly one way to get an 60-80 hour work week.<p>The other is to be in a business that the employee is passionate about for intrinsic reasons. If the employee is a "true believer" in the company's mission, that can be a motivator to go above and beyond.<p>Using technology and/or techniques that the employee is interested in learning can be a useful driver. Someone who wants to learn machine learning, for instance, will put in the extra hours if they're given a chance to do it at work while working on a project. Granted it's not a way to get 80 hours from an expert in the field.<p>Another is to give an employee a great degree of freedom or responsibility in a particular role, and emphasize its importance to the company. Giving a programmer absolute technical authority over a critical project, with high visibility, can motivate them to go hell for leather for a few months.<p>Ultimately I think working 60-80 hour weeks over the long term, for any reason, will cause burnout. But you can get some short-term boosts if you align the employee's passions with your business needs.
My first programming job (actually, just my first job) was technically a 40 hour/week job, but in the employee handbook it said something along the lines of: "The <company name> day is typically regarded as 8AM to 8PM." They didn't pay very well either. Brian is right, I totally hated my job, hated my boss, hated pretty much the entire company, and quit in 5 months. I was pretty disappointed. I'm still cautious about getting back into the industry. I'm at school now, not studying anything CS related.
Answer:<p>Be in America where employees are close to slaves, and people are scared of losing their job, so you can force them to do these kinds of atrocious things.<p>My brother lived and worked in North America for 7 years before returning to Australia. He'd been in Australia for a few months when I asked what the biggest change was. He didn't say no snow, he didn't say driving on the wrong side of the road, food or attitudes.<p>He said in North America people are scared of and slaves to their jobs because of Health Care, student loans and debt in general, where-as in Australia employers are thankful to employees, and nobody is scared of their job.<p>I think it's a powerful statement when it's the most noticeable difference after 7 years.
If an employer is expecting this, they are setting themselves up for failure.<p>> No programmers really work 60-80 hours a week, especially in a 5 day span<p>There are cases when we are required to deliver athletic/marathon-like performance and it can be achieved for a shorter timespan<p>I have worked on multiple occasions, 14-16 hours per day to achieve 98-100 "productive" hrs per week, working 120 hrs a week for 3-4 weeks. I know it was productive, because I installed time-tracker and used a personal notepad too to track my time. I was invisible to my family, sleeping just 4-5 hours a day and sometimes I could not sleep after the first week. Also note, doing this as a freelancer I was getting paid for all that extra time - and I have a premium price attached for quicker results. I would not recommend doing this if you are being paid peanuts or being paid regular rates because that opens up a world of abusive managers/biz-owners.
When I really like the work that I am doing and there are some real challenges, I can get up to 6 hours of work done before I have to take a break for a few hours. Not every day, but 2-3 days out of 5. It means that there is no point in making an appearance before 10 am or working past 4 pm. But when I am really smoking I can put in another 2-4 productive hours in the evening after 7 pm or so.<p>Of course, few employers understand this kind of work pattern, and most of them prefer having a developer spend more time in the office, even though it results in less productive work getting done. This is often enforced by people who are unable to correctly assess technical skills or the outcomes of technical work. Since they have no clue who is competent and whether any of the work output is usable, they compensate by forcing people to spend more time doing useless activities that they can assess. Like sitting at a desk, having meetings, raising an issue and setting up a meeting of stakeholders to discuss how to solve that issue. Many of us have to work in environments where these enforcers create a lot of churn to make it seem like the enforcer is a valuable member of the team.<p>I suspect that there are more such useless people in the workforce nowadays because companies no longer try to hire good competent people who will work for one company their entire career. As a result, there is nobody in the company long enough to identify and get rid of incompetents while at the same time, the truly skilled people give up and find a new opportunity every 2 to 3 years.<p>By the way, the incompetents that I talk about are not skilled developers who make a mistake or two, or who get stuck in ratholes solving the wrong problem. I am referring to the people that are weeded out with fizzbuzz. Unfortunately there is no fizzbuzz for project managers, business analysts and a whole range of other support roles, including managers.<p>So my take on how to get developers to work at a high level of productivity is to make the environment excellent. Get rid of the people who waste other people's time. Cut way back on meetings and replace them with a good ticket system and some people who make sure that tickets are properly sized with clear requirements including context and acceptance criteria. This pretty much means a mature Agile shop. Focus on all the stuff around the developers and make sure that the retrospectives are as brutally honest as possible, and follow through on fixing problems that are brought up in the retrospectives.
I think it follows from Brian's point that only founders may ever put in that much work, maybe very early employees; as he said, the trick is to be painting your own house...<p>Having said that, I completely agree that long hours are overrated and maybe unhealthy. Burnout will follow. Everyone has to recover. Such long stints can only be kept up for so long!
This sounds true to me, but it would take a very uncommon executive to put it into practice. MBA types won't do a thing without quantitative data behind it and attempts to measure real productivity in creative fields usually turn into meaningless self-fulfilling prophecies. I wonder what it would take to break the dogma of the 40-hour week?
Still trying to apply manufacturing or construction work practices to IT in 2017.<p>The people of talent and intelligence, like poets and writers, work due to their own vision and inner values to make money as a by-product of their chosen occupation.<p>Coding factories would inevitable fail like any other kind of a manual labor sweatshops.<p>To make intelligent people do their best (intelligence implies that this is the only way they approach any task) is to motivate them for the cause. Any kind of naive manipulation, primitive deceptive practices and employee-morale bullshitting would surely fail with reasonable smart people.<p>There is an economic law - a forced labor is not productive and it produces a lowest quality crap the whole system could get away with. That's why communism failed.
I find the numbers somewhat off compared to how it is where I work. We are a small team mostly working remotely.<p>I would estimate that my team puts in (per person) on average about 5-6 hours per day writing code. About 2 hours go to emails, daily meetings, demos and architecture discussions etc.<p>I have very few interruptions during the day and usually 1-2 meetings pre-scheduled that are 30 min in duration each.<p>My phone is usually on silent for all notifications except calls and I turn off email as well when I need to focus. I take a short 5 min break every 45 min or so. I avoid HN/Facebook etc during the work day.<p>There is very little stress, we work towards a defined goal and have daily updates on the progress and what everyone focuses on. Deadlines are very rare.
Fully agree on the office hours aspect of it, but not necessarily on the "you can't get your best work done by someone else's specification" aspect. Either I'm missing some point, or this sounds rather egocentric to me. What is "good work"? Beautiful code? Difficult code? Or is it code that is actually of utility? I'd argue the third. If your code isn't doing anyone else any good (and hopefully enough people to make it a viable business and thus "work". And if your code is supposed to help anyone else, you have to build it to someone else's specifications, implicitly or explicitly.
I somewhat agree with the author, but I have some comments.<p>I do agree that programming is a creative profession and that creative "energy" is limited to just a few hours per day/week.<p>However, most programming doesn't require constant creative insights. Even if you have to be creative (IE thinking of fancy features/implementations or something yourself) the most time is spent actually writing code.<p>I tend to think of something (requiring intense creative energy), planning what I'll be doing and when my creative energy is lower or I have plenty of planned work, I actually execute these plans. Writing code based on earlier made plans requires little creative energy usually. Additionally, the "executing" phase usually takes many times longer than planning.<p>For me, for a 40 hour work week, about 8 goes into planning, 24 goes into actual programming and 8 goes into useless meetings/e-mails/blablabla. Then I have creative energy to spare on my side projects for about 20h/week.<p>Tbh, I did spent a lot of time figuring out how to optimise workflow privately and professionally, figuring out why sometimes I could get stuff done and sometimes I couldn't. A separation of "creative time" and "doing time" helped a lot.
That how I would maximize developer productivity (but NOT working hours) if I owned a company:<p>- Let them work at home, at <i>any</i> time they want. Just reserve some hours for meetings or stand-ups if you want. Don't control the hours, control that the tasks are progressing.<p>- Open source parts of the codebase, let the developers own some modules or components on their github accounts. This way the quality of the code will be a personal matter to them.<p>- If shit goes down or hard deadlines approach (this happens) pay overtime and do a post-mortem analysis of what happened but DON'T turn that into a blame fest just cold analysis because most often than not its random factors of life (downtime for family or health reasons, whatever) and of coding not being a hard science (that external library that looked so sweet turned a minefield for example ) the real causes. Anybody trying to do that in the postmortem should be called out.<p>- If the last point happens too much, fire the manager/lead/CTO (normal programmers should be fired too sometimes but only when their performance is substandard and this is sometimes that will be easy to see day by day).
Brain Knapp is so on the money here.<p>So, if attendance is your key metric the best way to get them to attend 60-80 hours a week is pay them by the hour, plus allow them to "work from home" half the time.
To answer the actual question:<p>1. Pay your programmers per hour, and pay them very well. For example many people who are paid $200/hour would work 80 hours per week.<p>2. Provide free taxis or have easy public transportation to their homes.<p>3. Offer to pay for their children's daycare if they work extra hours.<p>4. Provide free food delivery from nearby restaurants.
Agreed to a point, but there's also several hours a day of non-programming that just has to get done which never features in these SV conversations. Dealing with network guys to get the firewall exceptions you need, getting the DBA to actually do the indexes you asked for, endless ticket updates, meetings, more meetings, timesheets, checking the contractor's deliverables, production issues, interuptions etc. etc. Then add understaffing, UAC policies, sanfus and shifting requirements. So sure, 3 or 4 hours in the programming zone easily becomes a 55hr week.
Early in my career, I worked at a few different businesses where management expected us to work 12+ hour days. Mostly web development & design.<p>We did it, but the secret was that we didn't spend all of that time actually heads-down, working. (Surprise.)<p>We were in the office for 12+ hours (sometimes until 3am, having client calls and presentations at midnight), but how much of that time were we actually getting creative, productive work done? Maybe half.<p>And here's the problem:
The hard part was, I was managing projects, and I had developers putting in 12+ hour days against my budgets, when I knew that maybe 6 of those hours were actually productive work time. Everything went over budget, across the board, for everyone's projects. At least on paper.<p>'Moral' of the story: you can require people to work whatever time frames you want. And if you pay well enough, people will do it. (At least until they burn out, or find a more prestigious/higher-paying job.) But it's a waste of everyone's time and money, and it creates more problems than its solves.<p>Worst of all, you're creating an environment where the culture of working 12+ hours is nothing but theatre. You spend half your time creating and carefully cultivating an artifice, just to meet management's expectations... which they know are unrealistic. Talk about being unproductive.
This article also leaves out:<p>- waiting for compiles<p>- waiting for the CI server to finish running tests<p>- waiting for network transfers<p>- waiting for VMs to spin up<p>- waiting for slow algorithms to process data<p>- et cetera<p>Even if it were physically and mentally possible to problem-solve 16 hours a day, we are still not at the point where our processes and machines can keep up with us, and we probably never will be. The dev-test cycle in itself is very time-consuming and repetitive. I don't know any way of solving this that doesn't involve spending even more time writing a lot of unit tests.
Good article but disagree with one of the main arguments that programming is creative work.<p>Maybe 10% of programming is the creative part,if you're not building artificial intelligence, but for instance consumer apps or UI.<p>20% is reading the technology API doc to understand how it works, 50% is writing the code down and the rest is bug fixing, so not so much creativity.
Quote: "No programmers really work 60-80 hours a week, especially in a 5 day span."<p>Wow -- this person doesn't know about hackers (granted that it's a term with multiple definitions). The problem with hackers is not getting them to work, it's getting them to stop.<p>A true hacker will work on a project far beyond any practical termination point, perpetually thinking of ways to improve the code in ways that meet private aesthetic goals unrecognizable to others and having no bearing on earthly considerations.<p>Programmers that quit after eight hours and go home may fit well into a corporate culture, but they're not the kind of programming addicts about whom legends are born.<p>Poets have a saying that poems are never finished, they're abandoned. It's the same with programming, but only if you're a hacker.<p>p.s. found the original quote:<p>"A poem is never finished; it is only abandoned." -- Paul Valéry
Steve Blank has a nice article about this: <a href="https://steveblank.com/2016/09/07/working-hard-is-not-the-same-as-working-smart/" rel="nofollow">https://steveblank.com/2016/09/07/working-hard-is-not-the-sa...</a><p>“Our team knows this isn’t a 9-5 company. We stay as long as it takes to get the job done.”<p>...the front door of the company opened – and a first trickle of employees left. I asked, “Are these your VPs and senior managers?” He nodded looking surprised and kept watching. Then after another 10-minute pause, a stream of employees poured out of the building like ants emptying the nest. Rahul’s jaw dropped and then tightened. Within a half-hour the parking lot was empty.
Work or sitting at their desk? (or staying in office doing 'stuff'). From my experience and some studies knowledge workers peak at around 30-35 hours a week.<p>Astonishingly still many client CEOs ask me how they can make their developers work more, marketing also works 60h they claim.
20 hours sounds right. I don't think I could gain more actual productivity forced by someone even myself to work long hours. Often time, when it feels right, the code just spills itself like charm, and after that my brain just turned south for distractions.
Question itself strikes me as only slightly better than "How do you make workers indentured servants?"<p>Thankfully the article itself proposes the questioner reconsider the realities of programming work.
Few can do real programming work over 30h a week. If you force people, you'll get fake work. Specific individuals can work more, by themselves (challenge, pride, try to show whatever, etc.), but are the exception. And of course, that effort level can not be sustained forever.
I wouldn't trust the creative work of someone who does over 35 hours a week. Creative problem solving requires the ability to switch into a relaxed state at will, and I haven't yet met anyone who can do it while under pressure to work 60 hours a week or more.
Do people who work like that actually get valued by their employers? To me it seems like they'd be treated as expendable and easy to push around - not a valued trait for promotion.
I'm curious — are there any companies who have their programmers work ~4 hours a day? How does the work output compare to more traditional companies?
> No programmers really work 60-80 hours a week, especially in a 5 day span. That is a 12-16 hour day, 5 days a week.<p>Who works only 5 days a week? Saturday... sure take the day, but many of us end up working Sundays to get everything ready for Monday mornings. Making sure all the issues are prepared, reports for the past week have been written, all of our tasks for the week are defined and prioritized... 8-10 hours a day, 6 days a week... seems common to me.