90 Hour Weeks?

Aswerty wrote: »

What sort of hours/overtime do the rest of you deem acceptable?

I don't really have a hard number for that. Most of mainland Europe seems to have 39 hours as a line in the sand, though that's an average over a period, not a cut-off like airline pilots have.

And have you worked in an environment where you had to put in long hours.

Yes, I've done the 90-hour week thing.

If so, why did you do it?

Deadlines for a major demo in a startup where I'd been promised equity and was the tech lead. So it was my design and a chunk of the company was mine (or so I thought at the time).

And would you do it again?

Immediately after the demo, the promise of equity went the way of all verbal contracts. More fool me, but the lesson was learned. Would I do it again? Would I ****. It's a stupid practice, caused by deadlines that people shouldn't have committed to in the first place, and it causes more problems than it solves.

Yes, there's the flexibility thing, if something catches fire putting it out is kindof the job description, but that's why the EU regs on working hours per week are based on an average over a period, there's more than enough wiggle room there.

Trojan wrote: »

I think actual 90 hour weeks are quite rare.

I'd hope so. The last time I did one (that demo I mentioned), I was doing back-to-back stints of between 20 and 30 hours for about a calendar week. It was stupid, it was unpleasant, and I never want to go through that again.

Do I sound like I'm a little bitter about the entire experience? Rats, because I was trying to sound as bitter as a bag of old limes sucked through a tennis player's jockstrap.

I *really* think that practice is amongst the worst problems we have as an industry.

The harder we crowd business for time, the more efficient it becomes. The more well-paid leisure workmen get, the greater become their wants. These wants soon become needs. Well-managed business pays high wages and sells at low prices. Its workmen have the leisure to enjoy life and the wherewithal with which to finance that enjoyment.

The industry of this country could not long exist if factories generally went back to the ten hour day, because the people would not have the time to consume the goods produced.

Just as the eight hour day opened our way to prosperity, so the five day week will open our way to a still greater prosperity.

In the old days, before we had management and power, a man had to work through a long day in order to get a bare living. Now the long day would retard both production and consumption.

It is high time to rid ourselves of the notion that leisure for workmen is either 'lost time' or a class privilege.

The five day week is not the ultimate, and neither is the eight hour day. It is enough to manage what we are equipped to manage and to let the future take care of itself. It will anyway. That is its habit. But probably the next move will be in the direction of shortening the day rather than the week.

That long-forgotten pinko commie hippie was the highly unsuccessful businessman Henry Ford, who introduced both the 8-hour day and the 5-day week, speaking in October 1926. You'd imagine we'd have moved forward since then, wouldn't you? (And we may well need to, as Charles Stross was writing about recently).

It doesn't apply as much too exclusively physical intensive work, but for a software developer, who is ONLY really living in thought processes all day, the work day should not be 8.5/9 hours. It's my opinion that that is wasteful because the day ends up being as long as any other work day but the brain just can't concentrate on abstractions and concepts for an hour on end, there will be a lot of waste in that hour and the waste-to-productive ratio goes up as each hour passes. I think 5 hours max should be the work day of a developer.

I did 60 odd hour weeks for a period of about 2 months once for one of the bigger tech companies in Dublin that are notorious for long hours. At the time you sort of get into a groove and it becomes natural, the thought of doing it again though makes me want to poke my eyes out. We did a smaller release after that went in with more normal hours but motivation was at a low after that. Also I definitely felt I had a sense of entitlement to put my feet up a little, which is far from healthy as the job wasn't done yet.

That said we got paid an hourly rate for overtime unlike a lot of smaller companies, and since I hadn't been working in Ireland for a few months that year I had built up a load of tax credits. I ended up earning a fair chunk of cash from doing it.

90 hours for any period of time is beyond ridiculous if you are on a contract and you are being paid to work 35-37.5 on average then you are working a second job for free essentially with none of the "benefits" of that.

I haven't worked more than 45 hours in at least 7-8 years. Long hours are a symptom of bad management, planning and estimating. Sprints are usually 2-3 weeks, it is not too difficult to estimate 2-3 weeks worth of development work. There are daily standups to weed out problems quickly. If the team end up doing 50+ hour weeks then something is seriously wrong.

Sparks wrote: »

Yeah, that's not actually true. At least not in good courses. Not because they teach them; but because they're not oblivious to them, they deliberately ignore them because commercial requirements are bull**** as far as things-to-base-your-syllabus-on go for undergraduate courses (if you're offering an industrial course on tool X, that's another thing entirely).
You want to run an undergrad course in CS/CENG as a general course, not some industrial prep thing because by the time your first graduate's emerged from four years of work, commercial requirements can have changed utterly. If my course had used commercial requirements as a basis, I'd have emerged knowing how to make WAP pages and code in Delphi. Instead, I learn how stuff works from the IDE down to the silicon and I've learnt every new trend since in days or weeks.


This is true; but it's equally true that nothing in life is safe and risk-free. If the "safe" option involves 60+ hours a week for entry-level wages, I'd take the risk.

Still wouldn't ****ing hurt for a uni to even introduce the concept of source control though.

The Corinthian wrote: »

the common end result, which is a developer who can be very talented and knowledgeable on an academic level, but still needs a lot of hand-holding in a commercial environment for the first few months.

It's tempting to say "yes, and?"
Everyone seems to think a computing undergrad course should produce someone who can then be given a professional role running a project and be able to hit the ground running on day one.

Why, exactly? We don't do that with solicitors, barristers, doctors, or any other kind of engineer (seriously, no civil engineering grad is ever going to build a bridge solo - apart from the obvious, it'd be illegal because you need to be chartered to sign off on things like that and we don't charter engineers until after they've been working in the field for a few years).

The point of an undergrad degree is to learn the basics, the fundamentals - we expect new grads to need some hand-holding (a lot actually) in their first role or first few years.
You come out of that 4-year degree course knowing APIs and the college has failed you. You come out of it knowing what an API is and what it should and shouldn't do, and that's the desired outcome.

That said, yes, some things should be taught more widely (like source control, like staging, like alternatives to OOP - sorry folks, OOP is useful but turns out the research that said it was the best way was wrong and flawed - and like ideas like unit tests and how things like code review are actually better than them in some ways and why we still need them and so on (as opposed to learning how to use xUnit libraries).

By commercial, I don't even mean source control, but even basic stuff like unit testing, or what a staging environment was.

Yes, but you know as well as I do that you can't just teach unit testing or staging, you have to teach what unit tests are really used for (hint; not TDD), what they're bad at, what they're good at and so on.
(And yes, that really does need to be more widely taught).

Sparks wrote: »

It's tempting to say "yes, and?"
Everyone seems to think a computing undergrad course should produce someone who can then be given a professional role running a project and be able to hit the ground running on day one.

It's a wider discussion but the role of education is blurry at the moment. There is an increasing cohort of people who feel education should be tailored towards employers' needs more than anything. I think it should be tailored towards equipping people to be adaptable because an employer can go bust or decamp. It is not specific to computer science or information technology but also afflicts second level.

Sparks wrote: »

Why, exactly? We don't do that with solicitors, barristers, doctors, or any other kind of engineer (seriously, no civil engineering grad is ever going to build a bridge solo - apart from the obvious, it'd be illegal because you need to be chartered to sign off on things like that and we don't charter engineers until after they've been working in the field for a few years).

One of the things I think compsci has done is taken on board some of the hierarchical labels from other areas - currently scientist/engineer are two - without some of the rigors applied to those labels elsewhere.

Against that, there seems to be a move to devalue the skills inherent in development, in programming. When you have the pr head for the new computing curriculum in the UK suggesting you can pick up coding in two days...that does give a sense of it's easy, therefore not worth as much money as [what I do regardless of what that is].

This is a wider debate on whether the industry, and the tasks it fulfills, should be operating on a basis of relying on people working 80-90 hours sufficiently frequently that it's perceived as a feature of the job in question. My view is that it shouldn't and the reason it happens, again, is that the effort is not adequately valued. In certain respects, it almost comes across as a hazing ritual.

Sparks wrote: »

The point of an undergrad degree is to learn the basics, the fundamentals - we expect new grads to need some hand-holding (a lot actually) in their first role or first few years.

In my view, people need hand holding to some extent in every new job; it's just the type of hand holding changes over time. The other issue is the IT industry is sufficiently vast that no undergrad degree is going to cover all of it in any major depth any more plus, if we teach people programming languages rather than problem solving, adaptability can be an issue.

Sparks wrote: »

That said, yes, some things should be taught more widely (like source control, like staging, like alternatives to OOP - sorry folks, OOP is useful but turns out the research that said it was the best way was wrong and flawed - and like ideas like unit tests and how things like code review are actually better than them in some ways and why we still need them and so on (as opposed to learning how to use xUnit libraries).

Related: if you've a citation for the comments on OOP I'd be interested.

The Corinthian wrote: »

That's a different debate, TBH. The main point in relation to graduates is that regardless of whether they should be taught in a more vocational manner or not, they're still less attractive to employ than a developer with one or two years experience, hence more likely to end up in a situation where they have to 'pay their dues' in their first job and work silly hours.

Yes but at the other end, a lot of companies don't necessarily want to pay for long term acquired expertise either. or, more to the point, they want neither the pain of training someone up to be commercially useful, nor the cost of paying them properly when they are seriously commercially experienced.

Cake and eat it springs to mind

The Corinthian wrote: »

Indeed, and when they start their professional careers as apprentices, devils or interns, they too end up 'paying their dues' too - actually graduate developers are probably lucky in comparison, as they get paid; something that apprentice solicitors often do not and devilling barristers almost never do.

Actually, I don't see it that way and I don't agree with it. The point is, if people are working, people should be paid, regardless of whether they are an intern or not. The unpaid apprenticeships, particularly in areas like law and the media tend to mitigate against diversity and social mobility.

Suggesting devs should feel lucky is the wrong approach; the correct approach is that we should be paying the apprentices in the law and media industries. Anything else is a race to the bottom and hardly aspirational. An argument of "that's the way it's always been" or "well it never did me any harm" is not an argument.

TC wrote:

That's a different debate, TBH.

True, we may need to split this out, but it's kindof amorphous so lets leave it run for a little while till we get an idea for where to cut.

Calina wrote: »

There is an increasing cohort of people who feel education should be tailored towards employers' needs more than anything.

Yes, but those people - at least the vocal ones - are predominantly.... well, let's be polite and say they demonstrate a depraved indifference to the good of the students who are paying for the courses. Quite a few of them seem to be employers who are putting their companies' bottom lines over the good of the students, predominantly in the US where employer-employee relations seem to be trying to model themselves on the mugger-muggee relationship (seriously, at-will contracts? Feck right off mate). Okay, that's their fiduciary duty in a reductionist view, but:
(a) a longer-term view would say that they're not doing themselves any favours because they're driving down their worth in the eyes of the very people they'd most want to hire (just as an example, think of the list of companies you the reader have in your mind under "will never ever work for ever" and ask how many of them this would be true of); and
(b) it's their opinion, not ground truth, and it's deeply and often unacknowledgedly biased and that's a good reason to mostly ignore it.

without some of the rigors applied to those labels elsewhere.

I think in large part that's because we don't have those rigors in computer science or computer engineering yet, though we're (thankfully) moving that way.

Seriously - one of the more telling questions I've heard recently was "Do we have any empirical evidence to say version control is a better way to do things" and the answers were "er, it's obvious, duh!", "here's an explanation of what version control is", and "did we need to prove that?". Disturbingly, it seems that there's no actual data to prove it - and this question dates from December 2012, not 1972. There's a whole other debate in there, but it boils down to this - maths can prove 1+1=2 (for various reasons, yes that had to be proven), doctors can point to studies showing that not stabbing yourself in the head is a good thing, in short every field but ours can prove the basic fundamentals they based their field on and which the rest of us would call "common sense" (though notably those proofs often pointed out things we wouldn't have thought of at all because of that common sense blind spot and their fields improved as a result).

We can't do that yet... though we're getting better, slowly.

When you have the pr head for the new computing curriculum in the UK suggesting you can pick up coding in two days...that does give a sense of it's easy, therefore not worth as much money as [what I do regardless of what that is].

Was that not the same interview where she said she couldn't code herself?

Related: if you've a citation for the comments on OOP I'd be interested.

This is a good intro to the main paper; and this quote sums up the problem:

It turned out that code size accounted for all of the significant variation: in other words, the object-oriented metrics they looked at didn't have any actual predictive power once they normalized for the number of lines of code.

And if you haven't seen Greg Wilson's talk on this entire area yet, go watch it now, and if you have, he talks about this at the 40 minute mark.

And when you're done, go read http://neverworkintheory.org because it has a lot of odd but proven results in it. For example, the proof that code review (the deeply stodgy, almost-waterfall, IBM method from the 1970s) works better than TDD (at least within set scenarios). If you're interested in this aspect of software engineering, that site's a good week or two's worth of fun reading, and if you're interested in writing better code faster, it's where you find some of the proven ways of doing that.

Cake and eat it springs to mind

Indeed, and while it's not something you can generally say to an employer while an employee, my thoughts would be that "eat it" is a pretty succint and expressive response to that kind of proposal on multiple levels