Mike Hadlow is a senior software developer and author of EasyNetQ and Suteki Shop. He loves history and technology and is a tech geek. Recently, Mike wrote a blog on the topics of programmer productivity, work performance, and work results. He talked about how we should think about whether programmers are working hard or lazy.
If people are doing manual labor, it's easy to see how hard they work. You will intuitively and clearly see their frequent moving steps and sweat drops. Also see the fruits of their work: brick walls that gradually rise, holes in the ground getting deeper and deeper, etc. It is a very basic human nature to observe and reward hard work, which is one of the reasons why we find endurance sports so fascinating. But this natural appreciation for hard, physical labor can be problematic for employees who manage technical creativity. Efficient knowledge workers often don't seem to work that hard.
Back in 2004, I was a junior developer working on a large team working on billing and supply systems for cable companies. Like all large systems, this system consists of a large number of relatively independent components, and different groups are responsible for the development of different components. The analog TV and digital TV supply systems are almost completely separate, developed by two different groups.
The analog TV team decided to build their system based on an early version of Microsoft Biztalk. The team consists of 4 people and a team from Microsoft to develop and run the system. They seem to work very hard, often working late into the night and working overtime on weekends. When there is a production issue, everyone on the team drops what they're doing and huddles together, offering a variety of suggestions and comments, as well as insights on how to fix the problem. You will see that everyone on this team has a strong team cohesion and they all work very hard.
Digital TV supply systems are quite different. The code of the system is almost done by a guy, let's call this guy Dave for now. I'm a junior maintenance engineer on the team. At first, I had a lot of trouble understanding the code. There are no long procedural statements in the program, on the contrary, there are a large number of small-sized classes and methods, and the code of each method is only a few lines. Several of my colleagues complained that Dave was overcomplicating things. Dave, however, suggested that I should read several books on object-oriented programming. He taught me design patterns, SOLID principles, and unit testing. Soon, the code he wrote started to make sense, and as I continued to understand the code, I became more and more aware of its elegant design. The code has no issues in production, it just keeps working silently. It's also easy to make changes to the code, so implementing new features is a snap. Unit testing means that the number of bugs that make it into the production system is miniscule.
The result is that our team doesn't seem to work as hard. I leave work at 5:30 pm every day, and I never get off work on weekends, and we don't have to gather around to guess what's causing the problems in the production system. From an outsider's point of view, what we're doing is definitely much simpler than the analog TV team. In fact, the needs of the two are very similar, except that we have developed better designed software and better supporting infrastructure, especially unit testing.
The management team announced that it would reward employees based on performance. When it was my boss's turn to talk to me, he said that it's fair to reward those who work hard, the harder the work, the bigger the reward, our team doesn't seem to care that much about the company, and it's less able to communicate with those who give up at night. On par with weekend time heroes.
What makes this cable company unique is that you can directly compare the difference between good software design and poor software design, and you can compare team behavior. Most organizers don't offer this comparison. It's hard to tell if an employee works all night, or even on weekends, frequently acting as a firefighter. This is what a complex software system must do. Unless you can get several competing teams to solve the same problem, you'll never be able to directly compare the differences in their work. Conversely, what about the guy who sits in the corner and works 9 to 5 who probably spends a lot of time surfing the web? Maybe he's very good at writing stable, reliable code, maybe his job is simpler than everyone else's. For managers who occasionally come to check, they will feel that the first type of people is working hard, and the second type is not. Working hard is good, being lazy is bad, is that true?
My take is that superficial hard work is often a sign of failure. High-stress, frequent-disruption environments often fail to develop good software. Working long hours is also not the right thing to do. Sometimes the best way to solve a problem may be to stop thinking about it, get out for a walk, or get a good night's sleep and let your subconscious mind solve the problem. One of my favorite books is A Mathematician's Apology by GH Hardy, one of the great British mathematicians of the 20th century. The book describes his day job: four hours in the morning and cricket in the afternoon. He said working more than 4 hours a day was completely pointless and unproductive for complex mental work.
What I want to say to managers is to be results-oriented, based on the results of the employee's work, based on the software that works, and don't be fooled by people's ostensible hard work. Also, it's best not to sit with your developers, you'll get better results, good results that aren't influenced by conventional, intuitive judgment. The benefits of working remotely are so many that you can only measure how well your employees are doing by output, not by whether they sit 8 hours a day staring at the IDE, or come together to come up with their own insights. measurement criteria.
Some readers commented that the article is very well written, and sometimes it is really difficult to convince colleagues of the simplicity of design and the benefits of using OO principles properly. I've seen people take pride in writing complex code and working late into the night.
Other readers said I once worked with a guy who said "the hard part about getting things right the first time is that no one realizes how complicated things can be". Over the years, I have found this statement to be very true. I now do a lot of advance design before projects start. This often makes the execution very smooth, but may make it easy for others to find it.