DevOps Zone is brought to you in partnership with:

Mike Hadlow is a Brighton, UK based developer, blogger and author of a number of open source frameworks and applications. Mike is a DZone MVB and is not an employee of DZone and has posted 88 posts at DZone. You can read more from them at their website. View Full User Profile

Are your programmers working hard, or are they lazy?

  • submit to reddit

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. Recognizing 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.

Published at DZone with permission of Mike Hadlow, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Gaurav Abbi replied on Tue, 2013/12/17 - 8:30am

very true, it is really difficult sometimes to convince colleagues about the simplicity of the design and proper use of OO principles. I have seen instances where some developers take pride in writing complex code and sometimes working overnight. 

Ws King replied on Tue, 2013/12/17 - 8:40am

Great post!!  I'm tweeting this, I know (quite) a few people that could learn from this.

Greg Brown replied on Tue, 2013/12/17 - 5:40pm

A guy I used to work with a while back had a t-shirt or sign that said "the trouble with doing something right the first time is that no one realizes how difficult it was". Over the years, I have realized how true it is. I tend to put a lot of up-front design into the projects I work on. This usually makes execution go much more smoothly, which unfortunately gives the appearance that the task was easy.

Alexander Kriegisch replied on Wed, 2013/12/18 - 8:00am

This is what I have been preaching to all my teams as a Scrum coach for years: "You are not lazy enough." I explain to them that good developers should maximise the work not done by finding smart, creative ways for solving problems, automating tests etc. Anything else is just unprofessional. When I started my carreer as a developer long ago, what fascinated me about software development was that I could automate boring tasks and - once done correctly - I could just forget about them and concentrate on the next intriguing problem.

Neil Murphy replied on Wed, 2013/12/18 - 8:09am

I agree with the article and the comments so far made .  I am a project manager now but started life asa programmer when Cobol (and even assembler) were the norm and IBM mainframes the place to be - how things change :)

This comment especially strikes a chord " This usually makes execution go much more smoothly, which unfortunately gives the appearance that the task was easy."

I ran a project a few years ago for division of a large company.  another division of the same company had another project also by us doing similar things. Our head of development would visit each project once per week, for my project he would spend 10 minutes talking finances and progress then 20 minutes just chatting.  then he would spend several hours trying to resolve the problems of the other project.

I had a great team which gelled really well, we worked very effectively with our customer and we delivered  on time and budget.  the other project eventually delivered but with cost overruns, large numbers of defects etc and had much burn out.

Some time later I was back in our office and mentioned this project during a conversation with some colleagues and was told 'oh yeah, you had the easy project didn't you'. I nearly had  fir because the team had delivered a solution to a complex problem very effectively by good working practice, but the other team had screwed up and had to work like idiots, so it was assumed their job was harder.

Sometimes perception is everything.  At least my boss knew the truth and everyone got the credit fmr him.

Enrique Tron replied on Wed, 2013/12/18 - 8:21am

So true, I learn it the hard way also... a development team where I was working always were 'commited' until 2.00 am, I really never understand it, as I have the same work load and leave at 6.00.... that's what I called the hamster syndrome.... all day running (in a wheel), but not even 1 inch of advance....

Stephen Hosking replied on Wed, 2013/12/18 - 5:06pm

I've learned this lessons the hard way, as I've seen other programmers who appeared to be more "hard working" be rewarded for what looked to me to be unnecessary drama.

If you see yourself as the "quiet achiever" then you will sometimes be noticed for your accomplishments, but often not, so it is up to you to tell management what a good job you've done. Also, if you see a difficult task ahead, then tell them that it is going to be difficult and why, rather than going about it quietly and hoping that someone will notice. If the difficult problem blows up in your face then your explanations will only sound like "excuses".

Araceli Mercado replied on Wed, 2013/12/18 - 8:36pm

 As my grandfather used to say: The lazy and the stingy walk twiace the same road.

The point is they want to see you running, even if it is running as that dumb bear in the cartoons.

Tayo Koleosho replied on Thu, 2013/12/19 - 9:42am

When I first saw the title, I was prepared to gripe about how the lazy developers usually find the easiest, leanest way to go about a task. Astute observations here

Lund Wolfe replied on Sun, 2014/01/05 - 2:06am

If you are good at it, you make it look easy.  If you enjoy it, you make it look fun.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.