Thursday, December 12, 2013

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.

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.

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 :).

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.

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.

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.

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

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

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.

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.

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 ;)

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.

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)

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!

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.

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.

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.

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.

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.

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.

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.

Speaking about perceptions, I was reported by a senior VP one time for reading in my cubicle. He thought I was screwing off when I was really studying an ABAP book so I could edit some SAP code. It bothered me that my manager never set the story straight.

"The code had been mostly written by a single guy, let’s call him Dave."

That's a big problem right there. Indicates poor leadership when all development for a given system is bottlenecked through a single guy.

What if Dave gets blown out a convenient airlock by HAL or is otherwise incapacitated? Sure, the source is there, but then you have to translate Dave's code into usable code. Plus, with Dave at the helm, he can be a white knight if he chooses and break and then fix the code to look like he deserves a hearty "Good job, Dave!" when in actuality he's a lazy slob making work not only for himself but others in the long run.

Great read that's applicable to many professions and not just programming, but I did think this bit of the story is interesting:

"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 point of your story is that management was clueless and didn't know the work you were doing and not the net results. I have no arguments there - the end result is likely more important than how they got there. However, management can only make decisions based on the information they receive. From managements perspective, you showed no teamwork and did not work as many hours. Why would they give you the bigger bonus?

If in fact, you were getting better results, then that should have been explained to management. Despite all the tools they have to measure employees, management these days does not always have the best understanding of the day-to-day ongoings of individual workers. If you do not promote your work, you shouldn't expect that management will know what you're up to.

I know this because I believe it is a weakness of mine. I don't like self-promotion or at least it feels awkward, but there are good ways to promote yourself and your work to your team.

Here's a few things you could have done differently:- Had weekly checkins with your team lead or manager and explain that you were learning about object oriented coding during weekly check-ins. - Told your manager about a breakthrough conversation you had with Dave or CC'd your manager on one of your conversations with Dave.- During a team meeting (stand-up, sprint planning, round table) explain the work you're doing and the benefits of this design.

At the end of the day, good management expects and appreciates communication from employees.

My theory is THIS is the primary reason why Agile was created or accepted. As a project goes forward you have to showcase a project moving forward and milestones. As a software developer from the classic waterfall model school of development, I know it sucks but the time you spend on system requirements and identifying functionality and objectives at the beginning of a project is very very important. What happens is that higher ups (VPs, Finance) need to be shown progress. I don't know how many times I've said "we've been working 3 weeks straight but identified 90% of all objects, functions, models, etc....". "Great can we see something?" Sure,here's the word documentation and flow charts etc... "No no can we see your hard work from the last 3 weeks". I don't know how many times our hardwork wasn't rewarded when most of the work was done at the beginning with documentation and identifying features. This is why it's important and helpful to have a manager or VP that once was a coder. I know I'm all over the street with this rant but for a programmer "hardwork" is relative especially when one day we'll code 24/7 for 3 days straight cause we are in a groove and then the next day we aren't feeling it. Been there done that. Very frustrating.

I completely agree. Career developer here, now a manager of a development team. I think a lot of this also stems from the perspective of the management team and the other employees. Operations mentality is always different than development mentality. I have battled this for years as every company I have worked in never knows exactly where app dev "fits" and often sticks them in weird groups like infrastructure, support, etc. In ops mentality, it's all about numbers (quantity): how many, how often, how soon... over quality.. I would often sit in staff meetings and listen to non-development staff talk about how many tickets they closed, how many servers they supported, how many users they helped, etc. Then I would say "well, I worked on one app this week". People would look at me like I was sitting around doing nothing. They did not understand that this one app was going to be used by 5000 people, provide substantial cost reduction over its lifetime and streamline the jobs of multiple departments. In like manner, I agree that if a developer is focused on how many hours they work, they have lost their focus. If one of my staff is continuously burning 60 hours a week, then I have a problem. This means they are thrashing and either have a skills deficit or are unclear in the requirements. I want my people to come in on time and leave as close to on time as possible. Development is creative work. You cannot produce logical art (as I like to call it) when you are fatigued and mentally drained.

The difference between you and the analogue TV team was that you gave "Dave" a shot (by mentoring you and referring you to good books) at explaining his point of view and why he did what he did, whereas they didn't. They'd too many incentives in keeping the dinosaurs alive, because dinosaurs were big, imposing and threatening creatures that made a better short-term appearance than the tiny, single-celled amoeba that'd finally evolve into life as we know today.Unfortunately, this is not a problem a developer can solve. This is where the management needs to choose between dinosaurs and amoebas, but most of them don't have the foresight and vision to understand that the dinosaurs' time is limited.

I'm going to guess the reason why you only see posts from the "good guys", is because the "good guys" are the only ones that care enough and are active enough to write about it. Typical "bad guys" are the ones who never read blogs like this, let alone write them. Be it because of the lack of insight or the lack of motivation, skill or other factors. It's about being engaged in your field versus not.

Je, you are so, so, so right. Scrum (what I think you're actually talking about) is Management's shared delusion that they can organize us in a way that will be more efficient. Also these:- Scrum seems to discount domain knowledge, that programmers can just be swapped in and out from any place in the code- Program/Project managers are easier to find, hire and pay. So Management tries to fix the issue of effective programmer scarcity and the true time it takes to write good software by hiring more P&P managers which spend large amounts of energy trying to show that their process is working.- Management is more comfortable micromanaging. Scrum is codified micromanagement. See daily standups.

the list goes on, but I have to move tickets around and adjust meaningless story points instead of coding.

Fantastic article -- with 30 years in the industry, as an Engineer, company founder and public and private development manager I couldn't have said it better. The fact that you had two "teams" side-by-side to compare was unique and valuable. I'm often brought in to situations and asked if I can "improve productivity" and help teams meet schedules... Sure! If you let me... Most non-technical managers want to see teams "motivated" - a code word for "working late into the evening and weekends" ... and want to "feel a sense of urgency" - or more aptly "panic". All ridiculous. It would be tough to get hired if you said, "let's reduce hours", "let's reduce interrupts and feature creep", "let's give developers time to think things out.. " --- but that is what works.

I'm a open source programer in very big company. I've contributed on one of world largest project. Every people has different way to maximizee the productivity.In my case, working for 14 hours a day maximizes my productive. It's not 2x time more than 8 hour working. It's 4~10 times more productive. My mind and body and code are merged together and my mind is on the flow and I think only problem solving even when eating, shitting and shower.However, company doesn't compensate my sacrifice enough, so I may need to start up.

Good coders aren't lazy, they're just better at choosing the path of least resistance. Whether that's working hours that aren't amenable to other people or reusing solutions for problems that need to be solved. I think this guy gets it https://blog.learnosity.com/2017/08/programmers-at-work-what-kind-of-lazy-are-you/