Programmers love to work long hours! There I said it, c’mon admit it, your job/boss doesn’t make you do it, we do it to ourselves. Alright, I’ll concede, maybe not all programmers love long hours, but surely with the amount of overtime that is prevalent in this industry at least half of us must love it. Right?

I can hear the excuses already. “No, no that’s not it, we just love working with cool tech and don’t want to leave a problem unsolved. It is actually a good thing it’s what makes us awesome!“

I say – you’re not seeing the forest for the trees. Here is some perspective, you’re not doing this for yourself, you’re doing it for “the man”. Admittedly he might be a nice man, but you don’t owe him slavish commitment. Here is even more perspective, how often are you actually playing with interesting problems and cool tech and how many times are you churning out code desperately trying to get something delivered and meet some arbitrary deadline that someone has assigned to you? But hey, you’re a business savvy developer, you’re helping the company succeed, your manager has explained the financial situation to you – it has to be done, we’re relying on you. Well, unless that same manager is right there with you, entertaining you with amusing anecdotes at 2 am, his words are worthless.

Let me tell you a story that a friend once told me. It is about a brilliant developer – lets call him John.

John was a superstar, a one in a million programmer. He had an uncanny ability to understand and write code and was 20 times more productive than anyone else. One day the company got a big contract that needed a fast turn-around. The client sent a massive spec document – to everyone’s dismay. John came to the rescue, he took the spec home and noone heard from him for 3 days. When he came back to work, he looked like hell, but he had gone through the whole spec and had an outline of the solution already finished. Except for one bit which was impossible to implement, though the spec said otherwise – even the client didn’t realise this, but John picked it up. Amazing!

When I first heard that story, I was pretty impressed, my first question was, “So, where is this guy now?”. To which my friend replied – “He is dead, too much hard living!”. Too much hard coding would be more like it. Kinda takes the wind out of that story a little bit – John was in his early 30s.

Programmers take a perverse pleasure from sharing death-march war stories. Even when we do it with disgust, it is a disgust tinged with pride – daring our peers to do “better”. But it is a bit like those guys who wear their pants so low you can see ALL of their underwear or the people who take up smoking for the “trendy image”. They and their friends think it’s cool – everybody else thinks it’s stupid.

Making A Bad Situation Worse

I can see the necessity of occasionally putting in some extra effort and burning the midnight oil at work for a day or two. But when “occasionally” turns to “often”, when your boss stops thanking you profusely for your efforts and just treats it as norm, this is when we’re all in trouble. It sets bad expectations, not just for you, for the whole industry. Humans are like dogs, we’re eminently susceptible to positive and negative reinforcement. And this whole industry has been conditioned by years of death-marches to the point where it even rewards this behaviour. Every time we give-in to the long hours argument, we continue to negatively reinforce this trend.

It doesn’t help that we’re herd animals, you only need to get one person and everyone else wants to conform. Guilt comes into the equation – “we can’t leave our mates by themselves to do the hard-yards, we gotta help them”. The more people conform, the more pressure on the rest of the herd to do so until the whole team is chugging coke and eating pizza at midnight. But how do they suck even one person in, where is that famed programmer independence. We’re happy to “stick it to the man” and do whatever we want in school, but as soon as we’re in the workforce all bets are off. It is puzzling.

Interestingly, sometimes these gargantuan efforts aren’t even tracked properly, as it would make the project look bad. So they “cook the books”, as far as the client is concerned everybody is doing 40 hours a week (i.e. they get billed for 40 hours) and the project is coming in on schedule (maybe), never mind the other 40 hours that everyone on the team puts in. OK, maybe they’ll track the real effort in a “second set of books”. Accountants go to jail for these kinds of shenanigans, but our industry expects it – nay almost demands it.

The Sustainable Pace Effort

Most Agile processes talk about sustainable development pace. But, I’ve seen even self-confessed agile teams knuckle under and put in the hours, you know, for the greater good and all. They were still agile though, and don’t you dare say otherwise.

When I think about this stuff I am always reminded of lawyers. You come in as a new lawyer and you put in massive amounts of effort and time, it is the accepted way to get ahead in that industry. No developer wants to be compared to lawyers, but often the situation is similar except you’re not going to get ahead by doing a lot of overtime as a developer (unless you’re working for a big 4 consulting company and then you might as well be a lawyer :)). So, lawyer vs programmer, which one is the chump?

Studies about productivity declines when working more than 40 hours a week surface with disturbing regularity. As a developer your creativity declines, you make more mistakes, you miss existing issue etc., to the point where you’re doing more harm than good. Should I even mention the health concerns when you spend that much time engaged in the same activity (they even had rules about spending too much time at work in the Soviet Union, and those guys were all about putting in the time for the good of the people). What about diet, you can only survive on coke for so long – poor John couldn’t even make it to 40.

Can you tell that I am against long hours and death marches yet :)? Maybe one of these days I’ll tell you how I got my wake-up call, it is an interesting story. Herding cats is easy compared to getting developers to make a concerted effort in the same direction, it is something I both love and hate about our people (programmers) :). But I do wish that once in a while all the smart developers just took a stand to eliminate at least one of the truly crappy and counter-productive trends in our industry. As far as I am concerned, smart programmers don’t like to work long hours and won’t be pressured into it – there is more to life.

Image by Tattooed JJ

I am going to give it away right here in the first sentence, it’s the ability to ask for and take criticism. Yeah I know technically it’s two skills. Before you switch off and browse away to look at funny cats with bad grammar, I don’t mean the ability to say:

"Well, of course I can take criticism, I am hip, I am with-it."

It’s like asking people if they are good in bed, it’s not as if anyone is actually going to say that they are terrible. And yet most developers (most people) can’t take criticism well and even fewer know how to ask for criticism and have it be received without uncomfortable silences.

Humans don’t tend to be able to get a lot of insight into their own failings, so we need an outside opinion. Feel free to disagree with me here, but I’ll tell you this. There are dozens of things I want to learn that I think will improve my skills and make me better at what I do, but it has always been external advice into how, where and what I should tackle that has given me the biggest boost in my growth as a developer. This advice was accidental every single time, just imagine if I could achieve a little bit of repeatability here. I wonder if this is the exact same thought that the dudes who were implementing waterfall for the first time had? Rigid processes aside, taking criticism and using it constructively is especially important for developers. It is basically a matter of survival within our field. There is so much to learn and new stuff comes along at a faster rate than you’re able to “master” (when I say master, I mean become aware of) old stuff. We want our efforts to propel us forward in leaps rather than at the speed of a leisurely crawl (although there is something to be said for crawling as well, but I will get to this some other time).

So Why Are People Bad At Taking Criticism?

Well, it doesn’t really help that most people are really crap at giving constructive criticism. There is just not a lot of criticism going around, how are you supposed to get good at it if you hardly ever get a chance to practice? Plus, our primal response to criticism is confrontational, either offensive or defensive (depending on personality), goes back to the cave days.

"I've survived right? So how dare you say I am doing something wrong!".

Double plus, developers are worse at this than most, we’re ornery, we like to argue, we pick on minute details. By rejecting criticism we can immediately scratch too many itches, it’s hard to ignore for the promise of some intangible benefits at a later date.  

What About Asking For Criticism?

Remember how I said that most people are crap at giving constructive criticism? Well, they know it. They also know you’re bad at it. We’re not particularly comfortable when we’re asked to do stuff that we are no good at. So, they don’t ask you and you don’t ask them, everyone is happy (kind-of). It’s a global conspiracy that everybody buys into – easier that way. Sort of similar to how everything is overpriced 10-fold in the enterprise world (including software), but it is easier to try and get a piece of the pie rather than call the whole industry on it. And when they try to make us criticise other people, like for those crazy annual reviews that most companies have (I’ve got thoughts about them); we do our best to get it over with as quickly as we can and try to use as many words as possible to say as few constructive things as we can get away with.

What To Do

Ha, I don’t have all the answers. Just because I observe an issue and see the benefits if it were removed, doesn’t mean I know how to remove it :). I am not particularly great at taking or giving criticism, I am a lot better than I used to be, but there is a long way to go. I’ve already given one tidbit of advice that can get you on your way – practice. The one surefire way to get better at something is to keep doing it. Find some people you trust, and go crazy on each other – hopefully you’ll still be friends afterwards :).

Here is some more advice, when asking for criticism, it really helps if people don’t know you’re doing it. You need some serious communication wu-shu to pull this off, but I have seen people who were awesome at this. Unsurprisingly considering everything I said above, these people were also awesome at a lot of other things.

Last piece of advice – grow a thick skin without becoming deaf to what people are saying about you. It’s a sad life when you go around taking everything personally, but at the same time you don’t want to dismiss it. There is a saying in Russian “to coil on the moustache” (it seriously doesn’t translate well, considering it’s metaphoric nature), but it essentially means, you examine a piece of information for relevance and take it under advisement if you find it useful. So, ummm, do that.

Seriously, if people followed some of this advise, we could improve workplace atmosphere across the board. Then maybe people could relax a little bit more at work. Of course there are already places where if people were any more relaxed they’d need business hammocks. I think I am veering off-topic a little, having a short attention span sucks. Somebody really aught to pull me up on that.

Image by lism.

I was reading Beautiful Teams the other day. In chapter 2, Scott Berkun talks about “Ugly Teams” and weighs in with an opinion on academic scores and how they tell you nothing about a persons aptitude (of course when I say “person”, in my mind that translates to – “developer” :)). I’ve heard similar opinions so many times now that I felt like I had to champion the other side of the argument. Here are some quotes:

“If we go beneath the superficial, perfect grades often mean the perfect following of someone else’s rules”

or

“They (good grades) are not good indicators of passionate, free-thinking, risk-taking minds”

or

“The tragedy of a team of perfect people is that they will all be so desperate to maintain their sense of perfection, their 4.0 in life, that when faced with the pressure of an important project their selfish drives will tear the team apart”

or

“Beautiful people are afraid of scars: they don’t have the imagination to see how beautiful scars can be”

Frankly I have to say – that is all so much bullshit. How is it that in the world of software, mediocre grades have come to be equated with creativity and flair and flashes of genius. “Oh, he is an academic underachiever you say – well that must mean he is a creative, entrepreneurial go-getter who thinks outside the box”. You see they just didn’t get the poor guy at university, it is so sad that his genius has been overlooked. What a load of rubbish, why is it that this side of the argument is never vociferously argued by people with perfect GPAs and a record of academic excellence? Sure, poor grades can be an indicator of a creative mind but they can also indicate laziness, inability to concentrate, lack of knowledge and skill, inability to complete tasks, poor interpersonal skills etc. Good grades can sometimes mean slavish obedience (rarely), but are more likely to indicate, superior knowledge, better study skills, adaptability, great teamwork skills, quicker mind etc. It is beyond me how high academics can possibly indicate lack of passion and creativity.

So you want to employ some people, you have some high academic achievers and you have some mediocre ones, who do you hire? Do consider the average Joe, those grade jockeys are just law-abiding drones, Joe is the radical who is going to revolutionise the industry, he just needs the right kind of motivation. What about motivation then? Lack of the right kind of motivation is often cited as the reason for average academic performance. If only our underachieving friends had the “right” kind of motivation, they would be brilliant. Well, it’s not as if the high achievers get their kicks out of boring lectures and worked examples. The difference is that the high achievers are able do well and motivate themselves despite the banality and minutia. So which skill is more valuable, ability to self-motivate no matter what, or passively waiting for the “right” type of motivation? Are you sure you have the “right” kind where you are?

Let’s get this one out of the way, cause it will inevitably come up. Yes, there are plenty of people in the world of software who had average (or worse) grades when they were studying, but have since “made it”. They gained kudos, money, the acceptance of their peers (either or all of those) there is no arguing this point. But that in itself is the problem, these academic underachievers who succeed have the spotlight cast upon them, because people didn’t expect it of them. They get hailed and written about – see, even the average Joe can make it. Thing is – they are the exception, not the rule. These people succeeded “despite the fact” and this is the very reason why they are interesting. People love an underdog story, makes us feel good, nobody wants to hear about the brilliant guy who lived up to his potential and made it big, as per expectations.

Rather than looking at high academic achievers as conformist drones, let me paint another picture for you. Those who get good grades are the ultimate survivors. They enter an environment, evaluate it critically to figure out what skills they need to succeed and thrive in said environment. They then put in the effort to gain and/or sharpen these skills. At this point they can apply their knowledge and skills with precision to get to the top of their environment and stay there. Excellent academic results are just a side-effect. And you know what, it’s not as if being a high achiever is black magic, all it takes is a little bit of work and practice (I am so going to cover that in a later post).

So yeah, good grades make better programmers, hell, good grades make better anything. And there is nothing that stops a high achiever from being a passionate, free-thinking, risk-taker. When faced with the pressure of an important project high achievers won’t get torn apart by their selfish desire for perfection, infact they will be better able to adapt and achieve superior results because that is what they do – evaluate their environment and figure out what is needed for them to succeed. Beautiful people (academically speaking) are not afraid of scars, but they do have the knowledge and skill to avoid the scars when they can and create superior scars when they have to. 

Image by GogDog