Thursday, December 12, 2013

Are Your Programmers Working Hard, Or Are They Lazy?

When people are doing a physical task, it’s easy to assess how hard they are working. You can see the physical movement, the sweat. You also see the result of their work: the brick wall rising, the hole in the ground getting bigger. Recognising and rewarding hard work is a pretty fundamental human instinct, it is one of the reasons we find endurance sports so fascinating. This instinctive appreciation of physical hard work is a problem when it comes to managing creative-technical employees. Effective knowledge workers often don’t look like they are working very hard.

Back in 2004, I was a junior developer working in a large team on a cable TV company’s billing and provisioning system. Like all large systems it was made up of a number of relatively independent components, with different individuals or small teams looking after them. The analogue TV and digital TV provisioning systems were almost entirely separate, with a different team looking after each.

The analogue TV team had decided to base their system around an early version of Microsoft Biztalk. There were four of our guys and a team from Microsoft developing it and running it in production. They all appeared to work really hard. They would often be seen working into the night and at weekends. Everyone would drop what they were doing to help with production issues, often crowding around a single guy at a desk, offering suggestions about what could be wrong, or how to fix something. There was constant activity, and anyone could see, just by looking that, not only did everyone pull together as a team, but they were all working really really hard.

The digital TV provisioning team was very different. The code had been mostly written by a single guy, let’s call him Dave. I was a junior maintenance developer on the team. Initially I had a great deal of trouble understanding the code. There wasn’t one long procedure somewhere where all the stuff happened, instead there were lots of small classes and methods with just a few lines of code. Several of my colleagues complained that Dave made things overcomplicated. But Dave took me under his wing and suggested that I read a few books on object oriented programming. He taught me about design patterns, the SOLID principles, and unit testing. Soon the code started to make sense, and the more I worked on it the more I came to appreciated its elegant design. It didn’t go wrong in production, just hummed away doing its job. It was relatively easy to make changes to the code too, so implementing new features was often quite painless. The unit tests meant that few bugs made it into production.

The result of all this was that it didn’t look like we were working very hard at all. I went home at 5.30pm, I never worked weekends, we didn’t spend hours crowded around each other’s desks throwing out guesses about what could be wrong with some failing production system. From the outside it must have looked like we’d been given a far easier task than the analogue TV guys. In truth, the requirements were very similar, we just had better designed and implemented software, and better supporting infrastructure, especially the unit tests.

Management announced that they were going to give out pay rises based on performance. When it was my turn to talk to the boss, he explained that it was only fair that the pay increases went to the people who worked really hard, and that our team just didn’t seem to care so much about the company, not compared to the heroes who gave up their evenings and weekends.

The cable company was a rare laboratory, you could observe a direct comparison between the effects of good and bad software design and team behaviour. Most organisations don’t provide such a comparison. It’s very hard to tell if that guy sweating away, working late nights and weekends, constantly fire-fighting, is showing great commitment to making a really really complex system work, or is just failing. Unless you can afford to have two or more competing teams solving the same problem, and c’mon, who would do that, you will never know. Conversely, what about the guy sitting in the corner who works 9 to 5, and seems to spend a lot of time reading the internet? Is he just very proficient at writing stable reliable code, or is his job just easier than everyone else’s? To the casual observer, the first chap is working really hard, the second one isn’t. Hard work is good, laziness is bad, surely?

I would submit that the appearance of hard work is often an indication of failure. Software development often isn’t done well in a pressurised, interrupt driven, environment. It’s often not a good idea to work long hours. Sometimes the best way of solving a difficult problem is to stop thinking about it, go for a walk, or even better, get a good night’s sleep and let your subconscious solve it. One of my favourite books is A Mathematician’s Apology by G. H. Hardy, one of the leading British mathematicians of the 20th century. In it he describes his daily routine: four hours work in the morning followed by an afternoon of watching cricket. He says that it’s pointless and unproductive to do hard mental work for more than four hours a day.

To managers I would say, judge people by results, by working software, not by how hard they appear to be working. Counter intuitively, it may be better not to sit with your developers, you may get a better idea of their output unaffected by conventional/intuitive indicators. Remote working is especially beneficial; you will have to measure your employees by their output, rather than the lazier option of watching them sitting at their desks 8 hours a day thumping away at an IDE, or ‘helpfully’ crowding around each other’s desks offering ‘useful’ suggestions.

57 comments:

lee said...

"Software development often isn’t done well in a pressurised, interrupt driven, environment."

I certainly agree, but there are many in the industry who would argue that point.

ForceCrate said...

But the problem is that you can be working smart with bad assumptions and still produce something that doesn't work correctly (or vice versa!?) In my experience this is the typical case. Did the developers on the analog project choose BizTalk or was it imposed on them? I wish I could always work in the way and with the tools that I know will be most successful. I seldom get to make that choice.

Niklas Modess said...

Yes, but the whole remote work movement is starting to change that.

I would say that a interuptive working environment is the number one cause for decreased productivity among developers.

William Payne said...

There are social aspects to any role, as well as hard, technical ones. Sometimes keeping up the appearance of working hard is just (an unspoken) part of the job specification.

Anonymous said...

Management clearly has no clue about IT which is unfortunately often the case.

Given the apparent number of defects I would say that the team working long hours should have been let go rather than getting a pay raise.

ag said...

time to make the donuts!

Anonymous said...

Reminds me of a manager I once had who expressed concern when she saw "long periods of time passing with no typing."

kk g said...

Nicely written and Truth !!!
In India , most of the companies prefers Engineer who stretch till late at night, come on weekend. If you don't follow this culture you might be told 'some people are not working hard'. Promotion or Salary hike to is directly proportional to no. of Hrs spent.
Manager would love to offload his meetings to you and himsself enjoying NBA games in cabin :).

Anonymous said...

IT is often screwed up by middle managers who don't understand how coding works, and end up micromanaging so that they can be seen as productive enough by THEIR managers.

Darrell Paul said...

Mike, can you provide some recommendations for reading on object-oriented software construction?

Bryan said...

If you're always frantically coding, then you're probably not leaving enough mental space for insight and innovation. Also, time away from a problem allows the brain to mop up and integrate the concepts. Like with a car, it's more efficient to keep your RPMs out of the red: You may get there a little later, but you'll use less fuel and do less damage along the way.

Todd M said...

absolutely love this, thanks. i need to show this to my girlfriend who cant ever tell if "im working hard or not"

JD said...

True for mentally-strenuous work, but hat about long hours for tasks that are easy but ought to be done? C'mon, it's not every day that a programmer has to reinvent the wheel!!!

Nick W said...

"Software development often isn’t done well in a pressurised, interrupt driven, environment."

Sometimes software doesn't get completed if it does have some pressure. Development is like air. It will always take up the space provided.

Anonymous said...

Working smart is no excuse for not working hard.

So your co-workers were assigned a harder task, and they worked harder to get it done in same time period as your easy task, while you spent your extra time blogging about it during work hours.

I see no reason not to reward them with higher wages.

Rob Jellinghaus said...

If the only thing you measure is how much people are sweating and swearing at their monitors, then yeah, you'll reward that behavior.

If, on the other hand, you're measuring the number of actual live site failures and tracking those back to root causes, you'll know very well exactly which code is the flakiest and causing the most problems. Then you can properly reward the people whose code actually works, and fire the people who keep breaking everything -- no matter how sweaty they are.

Kurt Cagle said...

I have been programming, designing software and managing programmers for about thirty years. Overall, from what I've seen there's a lot of truth in your rant, but there's also a few other points to keep in mind.

A significant percentage of coders are nocturnal by nature. They are slow to wake, are usually not terribly productive first thing in the morning, and are really just getting the wind behind their back about the time everyone else is packing up and going home. There's a lot of reasons for the night-owl association, some biological, but I suspect in great part it's because at night you can think and write without interruption, without having to deal with meetings and other social activities that are "required" in company culture but are non-productive from that programmer's standpoint.

Since most companies frown on people coming in at two in the afternoon and working until midnight (it's costly keeping lights on, security staff in place, and so forth), this quite frequently means that these programmers are often working two shifts, and driving themselves into the ground, because the brain does not generally turn off at 5pm.

Great coders write elegant code. They also usually write that code at 10pm in the quiet of their own homes, where no one sees all the false starts, stupid syntax error miskeys and, yes, even scratchpads as those great coders draw out their problems with pencil and paper. They only appear lazy because in general they've done all the hard work ahead of time, away from the florescent lights and company pep talks and idiot status meetings. The ones that don't, the 9-5ers, are usually just not very good coders, but they've got the appearance thing down cold.

Anonymous said...

Can you include one or two examples of what you call good design? Also, an example of what is for you a "bad" software design.

I have been around for long time, and I wonder how come I only see posts of the "good guys" saying how good they were and how "the bad guys" how bad they were, but they skip the details, I'm not talking about business private info., I mean the design details.

I don't want to think that this post is another case of "self-righteous internet people".

Anonymous said...

"Can you include one or two examples of what you call good design? Also, an example of what is for you a "bad" software design."

This is actually somewhat hard to do, because just like with observing work output, you can't take something out of context and say if it's good or bad.

There are some classic examples that seem to be frequently given as examples of this, like Plan 9, Nginx, and Redis. I've not worked on them myself, so I can't say how good they are, and software quality is such that simply reading them, you probably can't tell what it is about them that's so good, either.

But the minute you try to add a new feature to them, you'll know.

Jane Roberts said...

Good blog. Heard it before, but it bears repeating.
I've never been someone who had the stamina for copious overtime. But I'll often come to work the next day with a new idea on how to improve a design without purposely thinking about it since I left work the day before. That mathematician had the right idea. I've read that indexers also cannot concentrate on their work for more than a few hours a day.

Anonymous said...

>lee said...
>
> "Software development often isn’t done well in a pressurised, interrupt driven, environment."
>
> I certainly agree, but there are many in the industry who would argue that point."

They are called managers and we hate them.

Anonymous said...

Often times a prototype needs to be created to test the market! If this is the case, get that shit out! Don't wait until the code is perfect, just make it work with a true MVP in mind.

There's a time and place for everything, even complete hacks. ^___^

Frederick Ancheta said...

Great write-up. It can be frustrating to hear from a non-programmer that my job looks "easy". He or she never understands how I can be exhausted at the end of a work day.

Anonymous said...

I think that people have had trouble properly evaluating software developer productivity from the beginning. And this is always going to be a problem. Everything in software is hard to estimate and evaluate - just look at how hard estimating development time is.

Truthfully though, it always pays to work smarter, not harder. You need to explain things to decision makers in terms that they understand. Tell the boss its just you being efficient. Like when it comes to managing a social media page, you don't try and get all of the likes yourself, you use Facebook ads or the types of services listed at BuyLikesReviews. Trying to do everything yourself is a waste of effort and thats what should always be avoided. When you avoid problems associated with bad software project management, you're fullfilling your job the best way possible. It's the equivalent of

Luckily though, programmers are blessed with a skill that is easily transferable. If your company doesn't get it and doesn't evaluate your worth properly, there are scores of people lining up for your services who will.

@travisbarnette said...

this was fantastic. thanks.

Anonymous said...

"In truth, the requirements were very similar."
They weren't assigned a harder task, they were just organized poorly. Read the article.

Sivaram M said...

// But Dave took me under his wing and suggested that I read a few books on object oriented programming.//

Can you list what books "Dave" suggested?

Tim Hunt said...

Book recommendations:

http://pragprog.com/the-pragmatic-programmer

http://www.cc2e.com/Default.aspx

http://en.wikipedia.org/wiki/Design_Patterns_(book)

However, software development is not something you learn from books. You need to do it, and think about what you are doing so you learn. (The old, do you have 10 years experiences, or just one year's experience repeated 10 times?) The books simply introduce you to new ideas that you can use to judge your own work at a higher level.

As well as reading these books, do test-driven development. That will show you what a tangles mess some of your code is. You will find it is impossible to test an object of one class without creating seven other objects for it to interact with, which is a pain. Breaking your code into separate bits that can be tested independently will force you to write more modular and hence more maintainable code.

Wesley Archbell said...
This comment has been removed by the author.
Wesley Archbell said...

I also read the pragmatic programmer in my early days of programming and can also highly recommend it. It combines the art and science of programming into a book that just makes sense. It will teach you to apply yourself in using code in the correct manner instead of just hacking to get the job done. There will always be the impostors in the land of code. They "shine" out in clear view. Their existence will always exist but as i always say if you want to judge a person; look at his code ;)

Mike Hadlow said...

Since several people have asked, the books 'Dave' suggested I read included:

Agile Software Development, by Robert Martin. (this one made the biggest initial impression on me)

Test Driven Development, by Kent Beck. (I worked through all the examples, a brilliant book)

Design Patterns, by the gang of four. (This was the hardest to grok at the time)

All a little dated now, but probably still worth a look. At the time object-oriented software development was very new to the Microsoft eco-system, and there was almost nothing from the official sources (MSDN etc) encouraging developers to learn or use it. So although we now had a very nice OO programming language (C#), most people had come from programming VB and still took a very procedural, transaction scriptish, approach with all the problems that implies.

Robert Cowham said...

I remember working on a system in the late '80s where the project manager evaluated people on lines of code produced - so of course that's what he got!

After the first release, the team slimmed down, and a couple of good guys had a few months maintaining it, and the LOC count went from 500k->200k with more functionality...

John Reilly said...

Great insight - thanks for sharing.

Anonymous said...

What I find strange is your example of guys browsing the internet and still be considered hard at work. They should have gone one to new projects, products or change requests to work on.

Anonymous said...

From the text about short methods, I think the book might be Clean Code by Robert Martin http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 it's excellent, a lot of the better programers I work with have read it (I've read the first half, lol)

Marc Ziman said...

This really rings true Mike, good call. Ever worked on a project where you hand over your well factored code which respects SOLID to a 'busy' team who haven't read about OO, find it complicated and 'refactor' it into one or two big methods and say they are being agile? they're real busy now I can tell you!

Marcel said...

Great article.

For those who are asking about good vs bad, here's a pretty obvious example:

http://thedailywtf.com/Articles/Fixing-Delphi.aspx

Anonymous said...

which books did you read for OO design ?

Steve said...

This kind of naive, uninformed comment is exactly what this article is meant to refute. Your ignorance of how effective software developers work is showing.

Shaun Barker said...

What a great post - my own sentiments written SOLID(ly) - sorry for the pun! I as a manager was for a long time a devhead - in my mind if developers are working like crazy mad men chances are I am not doing my job right. Development needs time and space to be done right - for a tech company to ignore that is an accident waiting to happen. Please please understand that there is always a business need for the code, but the solution must also be right - they are the ultmate ying and yang.

Sebastián Fernández Quezada said...

I agree on your conclusion.

And let me add that, sometimes, It isn't an easy task to do when you try to convince a manager that hard work doesn't always means smart work.

Something very difficult to achieve for developers is focus without interruptions.

Working with http://www.codealike.com, which is a service that allows developers to track their activity while they code, we've found a lot of interruptions patterns and we're making it visible so developers (Eclipse and Visual Studio) can show it to their managers and ask them for help, using HARD DATA.

lobrien said...

This is sad for me to read, not because I think it's an exceptional story, but because it could have been written 5, 10, or 20 years ago. Our industry has done a terrible job learning how to communicate our value: the virtues of rested, thoughtful developers as opposed to "heroic" keyboard-bangers; the futility of estimation versus the benefit of incremental delivery; the value of good tools and techniques. If we focused on those issues with half the effort we spend pissing on each other's languages and paradigms, perhaps your boss's foolishness would be less common in the future.

Tom Lianza said...

There's something really fishy about this post, since it seems to paint a picture of teams of developers who are only (a) doing ops work, (b) fixing bugs, or (c) leisurely(?) adding new features.

If you had a bug-free system with few bugs to fix, wouldn't you have a nice healthy backlog of features to add? Every piece of software I've ever worked on has. In which case, wouldn't Dave be adding features all the time? And, wouldn't it be *extremely* clear to management how productive he his, based on how he was cranking through features?

The "Dave" picture seems too simplistic to be believable. Though, if he had a big backlog of features but walked out early without producing tangible output... well I'd understand management not thinking very highly of that.

Anonymous said...

It's the old clash between professionals and hackers. Which one you are depends on how you react if someone calls you a 'code-monkey'. Anger or pride? :-) Yes I know that it is sometimes possible to be both, but it seems that anyone who has read a 'Teach Yourself [blah] in 7 days' book can call themselves a developer nowadays. It's not helped by the fact that it is *still* the case that most managers of software teams seem to have been parachuted in from other parts of the company and have little experience of development.

I've worked in a place where every week I literally had to rewrite every single line of code that the long-hour crew wrote in order to stop it crashing, let alone get it to do what it should do. Don't worry, they didn't actually produce that much. Equally though, I've worked somewhere where the guy who pulled the longest hours was by far the most skilled developer there.

Companies can't ignore the enthusiasm of the geekier people. Those who are happy to forego family life, social life and other interests in order to play around with code are often more committed to the company and hopefully know the system very well. So long as they are not actively making things worse they can be very useful just for system knowledge.

So it's worth rewarding that, but such companies should be rewarding quality too. It's just much more difficult to measure.



Kissaki said...

Or shortened/reinterpreted to one sentence: If you have to work hard, your code is already in a shitty state.

Ferdinand Joseph Fernandez said...

I think it's a misnomer to call them lazy when they diligently applied software engineering in their work. They consequently just happen to have lots of free time. ;)

liebjabberings said...

This is true in EVERY field: people running around like chickens minus their top stories have AWFUL skills (not aweful), no clue what they're doing (in my case writing - but I used to do software), and they cause most of their own misery.

Alicia

alekciy said...

> he explained that it was only fair that the pay increases went
> to the people who worked really hard, and that our team just
> didn’t seem to care so much about the company

How the story ends?

Mike Hadlow said...

Hi alekciy,

Yes, that was pretty much the end of the story. I left quite soon after that. Eventually the system was shut down after an acquisition.

sinma said...

Hi, I want to translate your article to French and publish it on framablog.org. You certainly know that I can’t do it without your authorization. Do you like the idea?

Mike Hadlow said...

Hi Sinma,

I'd be very happy if you translated this blog into French. Let me have a link once it's done.

Many thanks!
Mike

Anonymous said...

hey here is the French version http://www.framablog.org/index.php/post/2013/12/28/Les-programmeurs-ne-sont-pas-des-branleurs, thx for your agreement

on behalf of Framalang team

-- goofy

William said...

Lazy Programmers are good, they create less bugs and quality code. Did I say, I am lazy?

Anonymous said...

If you believe manual work can be assessed by the sweating and the huffing and puffing, it goes to show you have not done much manual work.

The truth is that seating and huffing and puffing do not go well with any craft, and even less when power tools are involved. And bad OOP does not crush legs (at least not yours, not now).

Efficient and productive manual labour look just like gymnastics: effortless and flowing.

Lee H said...

I have often said in job interviews that I consider frequently working long hours as a mark of failure, specifically a failure of management.
'Occasionally' working long hours happens. 'Frequently' means that either I'm not managing myself properly or someone higher up isn't.
If they don't want to hire me after that statement then I'm much better off for it.

PhilHibbs said...

As Larry Wall put it, the three virtues of the great programmer are impatience, laziness, and hubris.

Brendon Wayne said...

To know if your programmers are lazy, maybe you need to check this list: http://www.21stcenturynews.com.au/6-signs-laziness/