Live data from Hacker News

"Any time you have worked long hours, it is a sign of a broken process."

programmers.stackexchange.com

11–20 of 172 posts

Re: "Any time you have worked long hours, it is a sign of a broken process."

#11
post #5

I'm curious how efficient most coders are even in an 8 hour work day. I find that I can only log about 4 - 5 hours a day (on average) of solid coding time (or marketing/business work). This is because I limit myself to an 8 hour work day, but of course there are breaks and inevitable down time.

Our startup team of 10 has kept pretty strict time logs for the past 3 years. We have an official policy of 40 hour work weeks, but yeah, no developers are able to have that much productive time. Usually we see about 25-30 hours of solid development time, 5 hours of meeting/admin time, and 5 hours of lunches/coffee/break time.

Re: "Any time you have worked long hours, it is a sign of a broken process."

#12
post #7

It's nice that LinkedIn has a great process: regression testing and the like, but what if you work in an environment where you can't afford to test every single little thing, and where business models, let alone requirements change constantly (ie. a startup)? What if a competitor just launched a feature that will put you out of business if you don't implement the same thing in 48 hours? What if there is a mission-cri…

Those sound like outliers and they happen. I think he was getting at chronic long work days.

However, I'd like to make a few points.

regression tests should be baked in from the start, especially easy at a startup starting from fresh.

Features that can be implemented in 48 hours have no business being in the way of your success.

Mission critical bugs are a symptom of a broken process. They happen, but shouldn't be pathological.

Yes, and that culture stinks. Luckily for software developers at this point in time we have MANY options and don't have to be subject to shitty working conditions.

Re: "Any time you have worked long hours, it is a sign of a broken process."

#14
post #7

It's nice that LinkedIn has a great process: regression testing and the like, but what if you work in an environment where you can't afford to test every single little thing, and where business models, let alone requirements change constantly (ie. a startup)? What if a competitor just launched a feature that will put you out of business if you don't implement the same thing in 48 hours? What if there is a mission-cri…

If your company is put out of business by a feature from a competitor you can not copy it within 48 hours, you do not have a business.

Re: "Any time you have worked long hours, it is a sign of a broken process."

#15
post #10

Long hours are not always because of a broken process, or death march deadlines. Many times when I have worked long hours, it was because I was really into the problem I was trying to solve, and didn't want to quit.

Yes, precisely. This only applies if you were forced to work the long hours, as opposed to doing it because you felt like it.

Re: "Any time you have worked long hours, it is a sign of a broken process."

#16
post #10

Long hours are not always because of a broken process, or death march deadlines. Many times when I have worked long hours, it was because I was really into the problem I was trying to solve, and didn't want to quit.

Same here. Any time you are working a difficult problem, especially one that is difficult because of its complexity, you have to keep a lot of context in your head. In that situation, keep going as long as you can and are still making progress. This is the same problem, but in a more extreme context, as the "getting back on track" problem caused by interruptions that was discussed in Peopleware, and frequently since.

Re: "Any time you have worked long hours, it is a sign of a broken process."

#17
post #7

It's nice that LinkedIn has a great process: regression testing and the like, but what if you work in an environment where you can't afford to test every single little thing, and where business models, let alone requirements change constantly (ie. a startup)? What if a competitor just launched a feature that will put you out of business if you don't implement the same thing in 48 hours? What if there is a mission-cri…

What if a competitor just launched a feature that will put you out of business if you don't implement the same thing in 48 hours?

Even if we stretched the 48 hours to 48 days, I am pretty sure this has never happened.

Re: "Any time you have worked long hours, it is a sign of a broken process."

#20
post #5

I'm curious how efficient most coders are even in an 8 hour work day. I find that I can only log about 4 - 5 hours a day (on average) of solid coding time (or marketing/business work). This is because I limit myself to an 8 hour work day, but of course there are breaks and inevitable down time.

I think 37Signals is completely accurate with their assessment of working time. It mirrors your take of a maximum of 4-5 hour blocks that can effectively considered "productive work".
Post reply on HN