Hacker News Reader

>I'd love to see some research on 20-hour weeks, incidentally. The productivity curve is definitely non-intuitive.

I think you'd find that you'd get useful ideas for work. I think most of the time spent in software is NOT the bashing the keys to make the code. It's spent thinking about what to write, and spending time going down the wrong path.

I at least have a certain clarity when I'm rested that gives me the solution to last night's problems.

I know more than a few people who could do with understanding what you just said.

Very true.

Incidentally, that feeds into one thing that I found about 20-hour weeks when I tried them: in many ways they're harder than doing an 80-hour week, because you've got to be so disciplined about always doing the most effective thing in the most effective way.

Often that also means going "what's scaring the crap out of me? Right, let's do that", again and again.

> "What's scaring the crap out of me? Right, let's do that."

I love this. I think this is going to be my new motto.

"I continue to be amazed at the number of people who don't get the whole "after 40-50 hours, you're less productive" thing."

Yes, it is a stubborn remnant of the industrial era, where the more time was spent producing widgets, the more widgets were produced.

Software is a completely different animal (that's why I love it)

It's probably more a consequence of framing compensation as "$/hr". But on the other hand compensation based purely on performance doesn't work well either because it can feel unfair to workers particularly those can't control the input for their output.

[ For example, I've worked with a radiology department where the hospital requires technologists to meet performance metrics based purely on scans/hour or they are sent home early before their shift is complete. This would seem to be more directly performance based, but the problem is that the rest of the hospital fails to do pre-scan screening questionaires correctly and doesn't get patients to the scanners on time. It's extremely demoralizing to the staff and more importantly it leaves very expensive hardware sitting around doing absolutely nothing. And the most talented staff actively avoid doing complex proceedures because they take longer. The "bean counters" somehow don't care about the big picture--expensive hardware is left unused and patient care suffers--hardware purchases and staffing are managed by different administrators and overall things are just... not holistically integrated. Anyway... it's complicated. ]

It's not that different. The original research into productivity is from that era, and that's where the 50 hour max came from.

Yes, you can keep making widgets, but you need a new shift of people to do so. That would be an interesting thing for software to explore — a night shift that came in and hacked on your code overnight. Like pair programming, only not.

I read an article from the early 2K's about Oracle developing its 10g database line. It had development teams strategically positioned through the globe so that development could continue 24 hours/day.

I never saw a followup article about the effect on the database quality or issues around handing off a code base from team-to-team multiple times a day. I also have to wonder if Oracle still develops its software that way.

Judging by the quality of some of the code I had a chance to look at (not the DB), the software was probably a bloated mess :-)

That said, continuous development seems to work for open source projects, though typically each module has an owner and other people submit change requests, people don;t just overwrite other developer's code indiscriminately.

I know of several financial companies that do that, with software developers on the East Coast, in Europe, and in India.

I bet that happens already...sounds like just the kind of thing we could look at empirically on public version control systems.

I respectfully disagree, software is very different.

Typically, developer's output is (unfortunately) measured by the lines of code written. More often than not, it should be measured by how _few_ lines were written to achieve the desired functionality (including maintainability and scalability, etc)

What is so different about software is that you can get from point A to point B (say, write a custom order processing system) in a thousand different ways (overwhelming choice of technology stacks, architectures, etc). But only a couple of solutions would be optimal for the problem at hand. And there are so many factors which influence all the decisions.

Another difference: code is just a description of what it does. There is no way to accurately predict performance, for example

And don't even get me started on ever-changing requirements ("I know we wanted a 2 story building, but how hard would it be to add 20 more floors?"). You don't change the widget design while on a production line.

I think its more likely that programming is in its 'artisanal age' moving toward its 'industrial revolution' quite quickly.

Right now it takes skilled craftspeople to design and build good working code - just as a few hundred years ago it took a master woodworker to create a fine chair or bench or bed. There was a million ways to make a join, a million materials to use (woods, glues, metals, etc), and it took a lot of skill to purposefully decide which tools and materials would best fit the job at hand.

This is where software engineering is today.

Look at wood working today:

There are still extraordinarily skilled craftsmen doing work that is miles ahead of what any machine could produce. Real pieces of artwork, in addition to functional pieces of furniture. But the vast majority of woodworking is done by automation (be that machines or laborers)

That is likely the future of software engineering.

Because what most people/businesses need out of software is exactly what they need of furniture - they need it to be 'good enough' and to not have to spend a lot of resources fussing over it.

With SaaS and thousands of pre-packaged solutions, entire industries are beginning to flip over

How long ago was it that to have a website a company would need a webmaster and some developers?

How long ago was it that to run email, FTP, website, etc you would need to purchase hardware, and employees to manage that hardware and software?

Hell even personal websites - you no longer need to know a word of any programming language in order to spin up your very own website, you can even get 'good enough' layouts from the provided templates.

Lets not forget that building websites was (and is) a very real and very lucrative field. It was overtaken by millions of amatuer kids who learned a little html and css and sold websites for a fraction of the cost of hiring professionals. And it worked because businesses want something 'good enough'

I;ve said this before but the same thing has/is happened to many other respected fields:

Photography

travel agent

Technical support (call centers, geek squad, etc)

I don't really see how software is any different from any other trade. You solve enough major problems until you get to a point where 'good enough' is easily accomplished by automation or laymen. Seems to me that this change is already occurring.

I don't know about this. All the "scary things that are going to happen to programmers" happened 20 years ago, and we're still here.

Remember all those CASE tools that replaced the need to write programs? You just describe the problem and out comes the software. Business People can do it. (But you still need to describe the problem in the exact level of detail as the program your tool outputs, and now you have to do it using that funky tool).

Remember when all our jobs got offshored to India to be done for $10/hour? They seem to have come back, along with all the $10/hour guys over there who could actually do the work (and who are all now getting paid market wages over here). Over the years, that happened to all the "offshore" there is, and today you really don't want to have your product built by the remaining offshore guys who can't command more than $50/hour.

Costs of running a software business did in fact go down from $1M/year in server and licensing to $5/month for a Digital Ocean slice, but the actual work of writing software still requires programming computers. And that is still hard, and hard to find people who can do.

So we're still here. My money is on us still being here ten years from now.

Not sure I agree.

The key difference is you need a carpenter to make chairs, but you need an engineer to make a chair factory.

You need a software developer to make software, but you need a software developer to make a software factory.

This also means there's a pyramid is place. The software devs have built a website builder? Okay, so the kids take over that part. But your website builder startup is now more successful. He needs to add some features, some big data, some better tools, advertisement. So he needs... more software developers.

Outside the website builder, other things are getting easier too. So people are building things on top of those things. Everyone's got a phone with GPS and internet now, and computing power is cheap, as is storage, so there's an Uber, there's an AirBnb, there's all sorts of things that are built on top of previously difficult things.

It's software developers all the way down.

Under good conditions one can easily work 70 hours/week and stay productive. But traditional open-office sweatshop with 2 hour commute does not work that way.

The research contradicts you, and if you're going by your intuition you're likely wrong, even about your own performance.

It's exactly your sort of thinking that means the industry keeps working the way it is

While I totally believe the research is right, and see the same results and draw the same conclusions for myself, I don't think the research can tell anything about one individual.

The way studies work is to measure the average of a large group. Most people I assume (I don't have data to back that up) work in jobs that do not have what jkot meant with "good conditions". So the research finds that _on average_ longer work hours do not result in more work done, and that is good advice for every employer.

For a motivated individual or small group that can be different, so I believe such personal accounts and would not tell them they are wrong. I can totally see how founders, special personalities, people with what I call the "perfect job" can work much longer than 40 hours without being wrong about their own performance.

The wrong thing is only to expect that from others or to create an environment that makes others believe it would be true for them too.

Covered at least in part in http://ericdodds.com/research-and-the-realities-of-time-work... - including perception vs reality of productivity in crunch time. He has a graph on that:

http://ericdodds.com/wp-content/uploads/2015/06/graphing-per...

It's possible that some special individuals can work longer hours than average without productivity loss. However, without hard data to prove you're one of those individuals, given the above, it may be inadvisable to simply assume you are...

In addition to this, for every "capable of working more than 40 hours" worker, there's another "incapable of being productive more than 40 hours" worker. That's the joy with averages.

So look around you - of the 20 people who are working late hours with you and believe they are still productive, 10 of them are wildly unproductive, quite possibly to the point of contributing disproportionally negative productivity due to writing bugs.

Is the additional 400 man-hours of productive work worth those 400-800 man-hours spent debugging problems which could have been avoided?

Not really, problem is that most people define "work" as sitting behind computer.

Again, no - the original research was into people working in a huge range of ways -- heavy industry, outdoor occupations, clerical work etc.

If you mean "I can socialise and network and that counts as work", I don't think that's what comes over in your original post.

Ford built tenements for his factory workers so they would live close to work, and he originated some of the research that 50+ hour weeks are damaging to productivity.

Define "good conditions", it's a judgement of value, based on subjective perception.

I find it quite hard to work 70 hours/week even if my work is very well organized (my main productivity drain) and I'm working at home, with my own setup in an environment I crafted for being distraction-free and really comfortable.

I can work for at most a week at the pace of 70 hours/week, after that I know I'll really drop my productivity even when I'm liking what I'm doing and truly motivated...

That's my personal experience after my first 9 years in the industry, having worked on open plan offices, team-rooms offices and at home for a couple of years.

Someone once said that "the weight of evidence for an extraordinary claim must be proportioned to its strangeness". Where's yours?

Being overtired can have 1 positive effect: you get out of your own head and come up with creative solutions that you wouldn't have dreamed up otherwise. Works for me sometimes.

Not a positive effect. Creative solutions are one thing, but the best creative solutions come when you are thinking clearly, not overtired and just trying anything.