Slashdot Mirror
Can People Really Program 80+ Hours a Week?
ibn_khaldun asks: "A question in light of the EA controversy. I'm an academic researcher who does his own programming -- I have to eat what I kill. In my 35 years of coding experience, any time I try to work on a complex program for more than, say, 60 hours a week (coding, not just showing up) for a couple weeks at a time, I'm just asking for trouble: I generate buggy code and debugging it only makes it buggier. Numerous studies in other fields (law firms, hospitals) have shown that mistakes rise exponentially after anyone works about 50 hours per week (don't think about this if you go to the emergency room at 3 a.m.)." Are these rational working conditions? (More below.)
"Does EA sprinkle magic pixie dust on their serfs to get around this problem, or is the work so trivial that it can be done while pathologically sleep deprived, or are the PHB's so technically challenged they don't realize what is going on? This whole 'death march' mentality seems absolutely crazy to me as a programmer, but appears to be common. Honestly, can someone enlighten me as to how these 80+ hour weeks ever accomplish anything?"
How else do they manage to keep their software so secure?
To answer your question: Amphetamine
Not since Slashdot debuted.
Even if you were to assume that my productivity were to go down 10% for every hour over 50 I worked, I'd still be *somewhat* productive at hour 80. Of course it's not linear like that, but if something's *got* to get done, then it's got to get done, whether I'm tired or not.
And I find that I do have hours of clarity even at the end of a long period of work. So If I get that good hour or 2 at 70 hours, I would have missed it if I'd gone home/to sleep at 60 hours.
I don't think anyone can work 14 hours a day, 7 days a week. You need some time to refresh,recycle,renew. What's a reasonable amount of time to recuperate? I think one day always seems to do it for me. I've never had to pull crazy hours like that more than a few weeks in a row, and we always found a way to take off 24 consecutive hours each week. That was what made it work.
It also helps TREMENDOUSLY to work in a cool place with cool people. If you respect everyone around, and they're all busting ass, you'll find it's EASY to do the same, and hard to let anyone else down. I knew guys who would feel guilty about going home to see their kids when crunch was on.
Is that a healthy culture? Probably not. But we did get plenty of work done, and that's I think what you were asking.
Nothing great was ever achieved without enthusiasm
I suspect most of the programmers working 80+ hours a week spend at least half of it not actively writing a line of code, be it meetings, waiting for some script to finish or reading slashdot.
For those that dont know, here for about this 'EA controversy':
http://www.livejournal.com/users/ea_spouse/
Even things that are not-quite-so mentally demanding such as electrical work become very difficult once a certain point is reached. For me, it's at about 65 hours/week.
Ok, which wire goes where now!
The previous has been a secret message to my comrades.
I called in Well today because I went in to work on Saturday. I never would have considered that at my old job but I'm finally starting to realise that if I restrict myself to 40 hour weeks I get a lot more done and I have more time to take care of important things like household chores and family stuff.
But debugging that's a bit easier - just send your assistant to find out which wires are hot :)
A fine is a tax you pay for doing wrong and a tax is a fine you pay for doing all right.
I do more coke so I can work more hours so I can make more money so I can do more coke.
500GB of disk, 5TB of transfer, $5.95/mo
I think its important to note that not everyone pulling 80 hour work weeks at EA is a programmer. There are a ton of 3d artists there too. And honestly, as a 3d artist myself I can say: plenty does get done in those extra hours. Its not all neccesarily good. But since "ok looking" art is a bit more subjective than a hard and fast bug, its easy to say the 80+ hour work week is more productive than the 50 hour when it comes to the artists I would immagine. For managers at least...
Isn't it possible that the quality of work after some point is so bad that it actually takes as much or more time to fix it as it did to do it in the first place? If that's the case, it's not just diminishing returns - it's negative returns.
"Prefiero morir de pie que vivir siempre arrodillado!"
The Pointy Haired Bosses want to be seen to be doing everything in their power to get the job done, on time and on budget. They see that things are falling behind schedule. What's the instinctive reaction when you're falling behind? Jack up the pace. That means making people work longer and longer hours to try to catch up.
They don't know, or don't care because the Powers That Be don't know, that this is counter productive. They don't know, or don't care, that they're more likely to fall even further behind schedule this way than if the people on the job just do regular hours.
By pushing their people beyond reasonable limits, their bosses can pat them on the back and say, "Well, you did your best, but it wasn't good enough. Obviously we need to check our scheduling better next time." There are no control groups to demonstrate that it was the overscheduling that caused the rampant deadline misses, the excessive bugs, etc.
Some crunch time is fine -- if you're close to being finished, and you have a hard deadline, crunching can get the job done when nothing else can. It's overdoing it that kills you. If I were a manager, I'd be erring on the side of too little crunch time -- not too much. And I'd probably be sacked because the perception would be that I hadn't done everything I could to finish the project on time.
Damned if you do, damned if you don't. The only solution is education, and that ain't gonna happen if those that need educating don't know that they need educating.
If you have tenure, you don't have to kill in order to eat. If the professor you're working for has tenure, he doesn't need you to kill in order to eat.
The reason people work 80+ hour weeks is because if the project doesn't ship on a certain date (and this is particularly prevalent in the games industry, in which payment is often contingent upon meeting milestones), they don't eat.
"OK, so why not set the milestones a little more properly -- so that you're not forced into such a situation to begin with?", I hear you cry.
If you're a game studio, and you demand sane milestones, the publishing house won't sign the contract. And that means you don't even get into the buffet line, let alone eat.
In academic terms: Nobody has tenure. And unless he was willing to sign his firstborn away as part of a contract that guarantees delivery of either a Nobel prize or a $500M IPO out of your research within six months, your professor doesn't even get to apply for the grant money.
"Even if you were to assume that my productivity were to go down 10% for every hour over 50 I worked, I'd still be *somewhat* productive at hour 80. Of course it's not linear like that, but if something's *got* to get done, then it's got to get done, whether I'm tired or not."
You're making the faulty assumption that negative work never occurs. However, it is not at all rare that a mistake made in one minute can later require ten minutes of time to correct.
At a certain point, the productivity of an individual reaches the point where the mistakes they make during an hour will take more than an hour to correct. Since errors in coding aren't fatal, the problem probably won't arise after fifty hours a week, but it seems possible and even likely that it will arise after sixty hours a week.
Although this may not apply as much to EA, it applies a lot in most the rest of computing. EA makes games, and games are mostly just a get-it-out-the-door type of product. You test for errors, make sure it's clean, then sell it. However, anything that will need to be upgraded to a newer version at some point will need to have clean, maintainable code. For that sort of material, I think you will, overall, start getting negative returns after about sixty hours a week. As far as games go, though, you really might not hit the point until after seventy or eighty hours.
Yes i think so. I find that overworking mainly reduces my capacity to see the big picture. To understand the implications of each change I make.
If the code is well architected, then my return past 40 hours does not diminish so quickly. But chances are if they are asking you to work past 48 hours, your management lacks management abilities, and are askin you to make up for their shortcomings.
I've coded, on average, 70 hours a week, for the last six years. This has been on my own project, which is coming along nicely (after about a dozen complete rewrites, language changes, and overhauls).
:)
What are you working on- Duke Nukem Forever?
Urge to post... fading... fading... RISING!... fading... fading... gone.
$17/hr. That's what they expect to pay for artwork done in 80-110 hour weeks. On the plus side- that many hours means you're pulling down $100,000 a year....
I say that's not much left after you're done paying for your divorce lawyer and your triple heart bypass when you reach forty...
I did the death marches, the crazy overtime, and the stress before, and you know what? I'd rather be paid half as much but stay 10 times more healthy and happy in my family. And yes, it does pay the bills and the mortgage, as long as you plan your spendings reasonably and you don't live on credit like most Americans do.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
I've coded, on average, 70 hours a week, for the last six years. This has been on my own project, which is coming along nicely (after about a dozen complete rewrites, language changes, and overhauls).
:)
Stop posting on Slashdot Broussard, and get back to finishing Duke Nuken Forever for petes sake - you've had long enough.
Regards,
Your Investors.
"Hey! Unless this is a nude love-in, get the hell off my property!!"
I think this issue depends on one's emotion state as much as the "work" load. I've been extremely productive on some fun, challenging assignments that made me want to spend every waking moment thinking about the problem. But if the problem (or associated people) are unpleasant/unworthy, then productivity goes to crap in no time. I think some of this is related to what Mihaly Csikszentmihalyi calls "flow" (an introduction to the idea) in his book Flow: The Psychology of Optimal Experience.
Two wrongs don't make a right, but three lefts do.
Yes, it's possible to work for 80 hrs a week, or even more. However, you need to define "work" here. Would you define reading/replying to emails as work? Would you define attending meetings as work? Believe me, these small numbers add up to take away a sizeable portion of your workday and your energy.
/. as time wasted. It's also an integral part of the process of coding. Hence, i do claim that one can "work" for 80 arse a weak.
If you're talking about pure coding, IMHO, coding is not a tap that can be turned on and off at will. One needs to "get into the flow" to get some real coding done, and this doesn't happen easily (at least for me). I'll often spend hours tinkering around with stuff, browsing some site, but won't for the death of me, be able to finish writing a simple class or stored procedure. Maybe, i'll keep getting stuck, maybe i'll be too distracted, maybe i'll decide to read some documentation instead. Then, suddenly, everything will start happening smoothly and i'll complete a day's work in a couple of hours.
I don't know if it works the same way for others, but i really feel that one cannot just keep coding continuously all day. At the same time, i will also not consider the interstitial time spent tinkering around and writing comments in
This matches my experience. I (and the teams I've worked on) can work long overtime (60 to 80 hours) for a few weeks... maybe even a month or two rarely.
But continually? Or to even attempt to pull one of these months every quarter? I can't do it. The people I know who think they can do it can't do it either.
We always ended up making bad mistakes that took a lot of time to clean up. We missed obvious architectural improvements that could have saved us days of work. We overwrote code and trashed data! :)
The point is that someone who is very tired will make a lot of basic mistakes that waste a lot of time. Someone who is well-rested and thinking clearly will be much more efficient. Work can progress smoothly and somehow you will be able to work calmly, not dealing with crisis after crisis, like the 80 hour teams do.
Agile Artisans
This is absolutely true. The lead programmer on my current project works at least 60 hours every week (and has for years) and more than that about half of the time. He's in at 6:30am and usually leaves around 6:30 or 7:00pm and he NEVER takes lunch breaks. Towards the end of the week, any problem that he "solves" quickly usually requires at least a day or more to re-fix later on. Unfortunately, his seniority makes him almost untouchable when reporting problems like this to senior management who see him as "dedicated and just as productive as everyone else". What they don't seem to notice is that he needs to work about 25-30% more hours per week than the rest of the staff just to produce adequate (not great) code.
Does anyone have any recommendations on how to present something like this to management in a convincing manner?
HTH, HAND.
Hmmm... let me fix that. *logs on to Wikipedia*
Done!
Prior to my current position I was a Cost/Schedule Engineer with a construction firm. There have been numerous studies on labor productivity versus hours per week worked and they all point to an optimum long term weekly rate of around 50 hours in the building trades.
For short term gains (read: less than two weeks), 60 or 72 hours can give you a boost, but after abour 3 weeks you actually would have been farther along chugging at 50 hours per week than at 72. After a week or two of 72 hour weeks productivity is in the toilet.
Also, safety problems increase, attendance problems arise, etc. etc.
No construction site in the world would consider working those hours long term since it is so counterproductive.
I dare say that when you have a severe case of the stupids is the best time to test.
You are much more likely to do the same stupid shit your users will do.
Make notes. Make automated tests. Fix it when you are fresh.
--Phillip
Can you say BIRTH TAX
Resign.
- learn to swim.
Dammit, people, the reason the PHBs can get away with this sh1t is that they know that even if you have the self-respect to refuse they can easily replace you with someone that doesn't value self and family enough to say no.
I know that folks in the US have been trained from birth to believe that worker solidarity = communism = ultimate evil, but those whose comments can be summed up as "stop yer whining and get back to work" miss the damn point. I want to work to live, not live to work. When there are enough workers willing to whore themselves out, it makes it impossible for the non-whores to expect fair treatment.
If the developer community would stop putting up with it, the PHBs wouldn't be able to require it anymore.
" You can work 80 hours in a week,"
Why, yes, I can.
My computer, unfortunately cannot. It starts making a lot of dumb mistakes during an extended days work.
So do my pencils and pens. It a damn equipment problem, I can do it, really.
A few years ago, I worked as a contractor for a certain large company. This company is notorious for driving people too hard, so I had reservations about working there.
... - life's just too short for this sort of rubbish, and IMHO anyone who thinks it's appropriate really needs to adjust their thinking.
When my contract was handed to me for signing, the default "max 8 hrs x 5 days per week" clause had been removed. I asked about that, as that clause generally serves as protection for both my customer (they don't get slugged for huge dollars and can plan their cash flow accordingly) and me (I get to see my family). The company replied that it was normal practice for them to remove any such clauses.
A few weeks in, and most of the people around me were working 18 hour days regularly (I started right around crunch time). I made a policy decision as follows:
- I'd work up to 14 hours a day
- once I'd worked 60 hours a week, I'd go home
Remember I was a contractor; I didn't feel any personal or professional commitment towards a management group that had put into place these sorts of work practices, and it was quite obvious to anyone working there that the long hours being worked were leading to mistakes that led to additional hours being worked to fix them.
Anyway, as expected, I got confronted pretty quickly about my perceived slacking off. My response was that I hadn't signed up for a lifestyle change; I was after income, pure and simple. Being close to Xmas, I was quite happy to work a few extra hours, pocket some extra cash and thus fund a nicer holiday, but that was the extent of the sacrifice I was prepared to make for the cause.
I pretty much had them over a barrel at that point; there was no time to train someone to replace me, and I'd made it abundantly clear what my motivations were and that they were essentially non-negotiable.
My personal lack of commitment was discussed in front of the rest of my workmates, by my boss, at the next team meeting. I took it on myself to respond, outlining my reasons for working as I did and that I didn't regard limiting myself to 60 hour weeks as being a lack of commitment - I said I thought it showed a lack of planning, and left it at that. When I finished, you could have heard a pin drop...
A few days prior to Xmas, my boss didn't turn up. This was strange, given that he worked huge hours himself, but not unexpected since pretty much everyone was quite ill at that point due to tiredness and shared (airborne) diseases. When he didn't turn up the next few days either, someone called his house and there was no answer. Eventually a relative of his went to his house and found he'd hung himself in the bedroom.
I've got no doubt at all that his death was 90%+ due to overwork, possibly exacerbated by my taking a somewhat defiant stance in public several days earlier. He'd lived alone and worked huge hours for the past several years, so there was no real possibility for other issues to have caused his suicide.
After a few months' thought, and subsequent discussions with my fellow workmates at that place, I decided that what had happened had been pretty grim but ultimately good things had come out of it. Work practices in that particular group had changed quite dramatically in the following few months; the new boss had put caps on the number of hours worked each day and each week, and re-introduced paid overtime for full time employees. Although several people had left (the turnover in that group ran close to 80% per year), those that were still there were now working in a way they felt was personally and professionally sustainable.
Having several of them call me up to thank me for taking a stance in a very awkward environment certainly helped me personally, although my "stance" was totally selfish.
Since then, I simply refuse to work in "death march" situations. I find the whole idea totally absurd; the end result is that a crappier product is shipped slightly sooner, but people's lives are affected too much for the trade-off to be worthwhile. I've seen two deaths (one described above), several bitter divorces, people leaving the industry, middle-of-the-office screaming matches,
I remember one major coding crunch at the small software company I used to work for: We were preparing a significant set of enhancements to our core product, while at the same time working on bringing to market a major new product. The two projects shared giant chunks of code and logic, so it wasn't completely off the wall, but it was still clear that we were going to have an awfully long, hard slog ahead of us.
As a kind of non-overtime overtime incentive pay, management set up a deal to pay a bonus at the end of the project, based on hours worked above a certain point, with all kinds of complicated sliding averages and whatnot. My office-mate and I crunched the numbers, and realized that in order to get any appreciable bonus at the end of the project, we would basically have to commit to 60 hour weeks for the indefinite future.
Well, you know, neither of us were exactly in our twenties any more. I had a wife and a brand new house and a 45 minute each way (non rush hour) commute; and while I still felt spry and nimble, I no longer felt immortal and god-like, even with the help of Mountain Dew and m&ms. I was in my mid-to-upper thirties. I decided that, while I was still capable of working arbitrarily many hours in a week for short bursts during an emergency, there was no way that my health would stand up to 55 to 60 hour work weeks every week, indefinitely. Both my office-mate and I decided not to bother signing up for the bonus program.
<irony> (A couple of years later, I fell ill with a chronic and incurable medical condition which has left me essentially unable to perform any work at all; so I suppose I needn't have bothered being so careful).</irony>
In fact, much to management's chagrin, only one member of our small programming staff -- call him "X" -- actually decided to commit to their schedule.
Determined to get a decent bonus for his troubles, X threw himself into it, working 60 and 65 hour weeks. In the meantime, my office-mate and I upped our hours, too, but to a lesser extent: 55 hours one week, 52 the next; and so forth.
The weeks wore on, and we inched along towards our various goals. X was doing his usual fine work, but he was looking more and more haggard (we were all a bit worse for wear, actually). His code got a little sloppier at times.
And then one morning, he committed a bunch of working code to the wrong place, and instantly wiped out about 20% of our company's source code repository.
Did we have backups? Yes, we had backups; but still, it took three or four of us much of the day to both restore everything and to verify that everything was correct. The final tally was, roughly, at least one full man-day flushed down the drain in fifteen seconds due to nothing more than pure exhaustion.
Eventually, the crush passed, of course. It is probably a coincidence that X left the company shortly thereafter, although he came back a year later or so. He's a very good programmer, but some of the code he wrote during that crunch -- especially later on -- was, shall we say, sub-optimal.
"Speed" code tends to be poorly documanted and maddeningly squirrely. I've tried to use code written by a serious gak head, and it turned out to be easier to just rewrite it from scratch.
If a job's not worth doing, it's not worth doing right.
But what if management always see's this guy there at his desk and yourself as the one leaving early and coming in later?
All of the sudden it does affect you because the PHB's look at yourself as the slacker.
That is the problem.
Image is everything in corporate America and politics comes in and the guys who appear to work harder are the ones always heard.
http://saveie6.com/
An interesting footnote on this whole "hours of time coding" issue...
The world's largest privately held software company is a company called SAS in North Carolina. Their software is basically an environment for doing statistical analysis. Regression, multiple regression, correlation, wilcoxon rank tests, and a slew of other things I haven't got to yet. But the important part is, if you were going to do a study to figure out the "optimal" amount of time to work, and consider not just productivity from the programmer, but all sorts of correlated variables (will someone work 80 hours/week for 10 years? How much will it cost to recruit and train a newbie when someone burns out?) then you would probably use a program like SAS to analyze the data. This is a company that has plenty of computer science and statistics Ph.D.'s on staff.
Their conclusion? 35 hours per week. Keeps the productivity high, the turn over low, and the company growing at double digit rates nearly every year (or maybe it has been every year).
Something to think about during your next interview cycle.
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
We were the company that coined the term Internet Time. How did we do it, by sleeping at the office and working close to 120 hours a week. Was it healthy? No. Was it smart? Probably not. Did we produce a good product? You tell me. We wrote Netscape Navigator 1.0 in less than 6 months time. (Please don't confuse it with Navigator 3 & 4, which was a very different team) But there was a catch. We had all written a browser before. We were not trying to dream up a new product completely from scratch. We had a good idea from the start of what we wanted to build. Those set of circumstances don't happen very often. If I was tasked with building a new product that had never been attempted before, I would never try and work that many hours. Good design does not coexist well with exhaustion. There are plenty of other reasons not to work crazy hours as well, one of them is "having a life"... :lou
There are good ones around, but they seem to be fewer and fewer in number.
Contemplate the fact that more and more software is being done like this, and be afraid, very afraid. The next time you get on a commercial airline flight, imagine that the software for their in-flight systems might have been produced that way. If you used an electronic voting machine, think about the fact that the software for the machine you used was probably produced that way.
Is this sustainable? Of course not. But the folks making these kinds of decisions figure they'll have their bonus and be long gone before anyone has to pay the consequences.
-- The pinhead celt
Physically there is a mental exhaustion limit, and no matter how much caffiene or other substances you pump into your body, your brain will just quit.
Sure, you can work for 80 hours a week. However, during that time your brain is burning chemicals. Sleep is required to regenerate the loss. Sleep deprivation/mental over-work is similar to any other mind altering state. You think you're doing fine and being just as productive, however in reality your performance gets worse and worse. And yes, when your brain reaches its limit IT WILL SHUT YOU DOWN! Passing out is usually the main result.
BTW, that's also not really good for the rest of your body, considering your brain is the regulator.
Doing long hours for short durations aren't bad. But the longer the period of time, the more self -defeating it becomes.
~X~
~X~
I would guess you're in a situation of working too many hours that you cannot get out of, and you are envious of the previous poster's situation. I am guessing you want out but seem stuck.
You have found the need to put the poster down personally proving you disagree with what he says. The difference between attacking the poster instead of his story tells me you don't want this type of story to be told. You are in an unfortunate situation. I don't envy you.
You will have a hard time getting the independence you want, until you see the truth in the previous story instead of fighting against it. By fighting against it you are helping to keep your self in an undesirable situation.
From your bitter comment, I don't expect to receive an answer -- what's better is no answer, but that you do some serious thinking instead. I hope you get things straightened out because it's never fun to be in a bad situation.
Whew! How do you feel now? :)
A long time ago I talked about this subject with my brother, at the time a pilot in the Strategic Air Command. I was working with a group of people who were acutely interested in precisely same question as the poster--is ther a point at which extra hours != additional useful code? As it happens, the question has been extensively studied, and answered, by the U.S. military.
There is a long-established relationship between the ability to handle abstraction (such as OOP) and the ability to do spatial reasoning. The U.S. Air Force, in the 1950s and 1960s, did a lot of research in the relationship between sleep deprivation and spatial reasoning--they were alarmed about the accident rate of aircrews after very long missions. If you're at the controls of a KC-10 tanker, a slight touch with your fingers will affect the rate at which the aircraft wheel bogies forty feet beneath you and a hundred feet back will descend to the ground. If you're sleepy and groggy, you're much more likely to misjudge your altitude or your rate of descent. Hit the runway a bit too hard, or a bit too early, and the landing gear can collapse--and you and your crew will disappear into a ball of flames.
The result? The Air Force instituted something called "mandatory crew rest"--you fly X hours, and you must get at least eight hours of sleep (in addition to debriefing, flight planning, etc.). No matter if there is a global crisis and you are rarin' to fly, if you haven't had your mandatory rest, you stay in your bunk until you do.
So what does that mean for us?
As I wrote above, there is a strong relationship between abstract reasoning and spatial reasoning. The U.S.A.F. has proved that sleep deprivation diminishes your ability to do spatial reasoning; ergo, sleep deprivation diminishes your ability to do abstract reasoning. Based on twenty-plus years in the business, that makes sense: time and again I've seen programmers try to pull all-nighters to finish up a project, only to fall further behind because they wrote gibberish all night long.
But wait, there's more...
Sleep deprivation isn't the only issue: dehydration will also affect your ability to do spatial reasoning (trivia fact: baseball batting averages are lower in the second half of a daytime doubleheader; because the players have been out in the hot sun, baking under dark-colored baseball caps. They get dehydrated, which limits their ability to hit a curveball.)
Bottom line:
Wanna be an effective project leader? Send people home at a reasonable time; provide bottled water or spring water; and discourage (or at least don't encourage) coffee or other caffeine-based sleep substitutes. Do not run a death march project in order to look macho; and be prepared to fend off the Guys in Ties who think a death march atmosphere is necessary.
Sigh--I'm drinking WAY too much coffee these days....
I think there is a very important distinction to make in this case: code head written by a speed freak is quite different from a non-addict with a mild dose of amphetamine as a coding/study aid.
...but what the hell is the point of thise post? I guess it's: if you're ever starting some sort of rehab work program for ex-software developers addicted to various drugs to go with opium. :P
Though code written by a speed freak is indeed quite fucked in the brain. Code written by stoners isn't horrible, though the overall system designs is usually either ingenius or downright retarded. If I had to pick some drug for a coder to be addicted to, I think I'd pick orally administered opiates- especially if the poor schmuck had to work 50-80+ hours a week. Opium has a long history of being used by people who did more work than they'd like to in a week, while staying sane and relatively healthy. Drunks code like shit- both alcoholics and a non-alkie coding whilst drunk.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Their conclusion? 35 hours per week. Keeps the productivity high, the turn over low, and the company growing at double digit rates nearly every year (or maybe it has been every year).
Something to think about during your next interview cycle.
Something to think about when libertarians/conservatives claim Europe is hopelessly behind in competitiveness. We get the same amount done AND we have much more pleasant lives.
Being bitter is drinking poison and hoping someone else will die
And why does coffee get a pass?
Admittedly amphetamines have their downsides, and some big ones especially with frequent use, but lets not kid ourselves, caffiene isn't exactly brussle sprouts.
Hacking your body chemistry is just like anything else, it can achieve the desired effect, or it can miss wildly. Often it involves trade offs.
I dunno about you but I sleep better, and feel all around better starting about 4 days after I quit a caffination cycle (usually I quit caffiene about the time I start to feel groggy in the morning).
Of course I eventually have a few nights where I am up too late (often involving the weekly poker game these days), and end up needing to see joe in the morning.
I make no illusions though. I am not pretending that joe is health food. Its drugs, pleasant, sweet smelling, black as as a steers ass on a moonless prairy night, tasty drugs. Definitly in the top five of non-medicinal drugs ever. (though if I ever get glaucoma and pot becomes medicinal, it will make it to 4 - and with the amount of time I spend in front of pc monitors, there is a fair chance)
"I opened my eyes, and everything went dark again"
You should do a more indepth study on this. I volunteer to be guinea pig, for free.
Oddly enough, I went throgh a period where I found coding after a couple of drinks or joints actually helped produce better code.
It was during a period where (modesty aside) I was maturing from "someone who could program well"[1] to a "good programmer"[2]. I've always been unusually aware of my own thought processes (as I suspect many programmers/hackers/martial artists/meditators/etc are), and I've noticed that good programmers all seem to go through a stage where they stop programming with their left-brain[3] and start more right-brain-thinking[4].
During this time I discovered that, as long as I already understood the problem fully, a couple of drinks (or joints) seemed to help me internalise the "rules" of a language, and spend more time on the actual creative side of programming - solving tasks without spending the whole time thinking about syntax or grammar.
Of course, some of the code was still pretty squirrely (what a wonderful word), but I do remember on several occasions waking up in the morning, running over my code again to check for bugs, and actually being blown away by how elegant some bits were - I hadn't thought I was capable of writing code like that at that point in my education. I remember one time finding a solution to a problem in linear time that I hadn't even realised sober could be done in less than exponential time, and it quite freaked me out for a while afterwards.
Even now (several years and several languages afterwards), I find coming back to a problem after a drink or toke can sometimes help you see "alternative" ways of solving it, often wildly different to how you'd normally go about it...
Fotonotes:Everything in moderation, including moderation itself