Are your programmers working by the sweat of their brows or just lazy?

When people do physical work, it is easy to assess how hard they work. You can see how they move, sweat. The results of their work are also visible: the brick wall is growing, the hole in the ground is getting bigger. To endorse and reward for hard work is a fundamental human instinct, one of the reasons we like strength sports so much. But when it comes to managing creative or technical employees, this instinctive perception of hard physical work becomes a problem. Effective knowledge workers are often not like people who work hard.

In 2004, I worked as a junior developer in a large team in the billing and services department of a cable television company. Like all large systems, this consisted of several relatively independent components, which were worked on by individual employees or small groups. Digital and analog TV systems were almost completely separated from each other, each of them had its own team.

The analog TV team deployed their system to an earlier version of Microsoft BizTalk. Four of our guys and the team from Microsoft developed the system and launched it. It seemed that they all worked hard. They often stayed in the workplace at night and on weekends. They threw their affairs to help with problems at work, often crowded around the same table, putting forward suggestions about what might be wrong and how to fix it. They were constantly doing something, and at one glance it was clear to them that we have a solid team that is working hard.

The digital TV team was very different. The code was mostly written by one guy, let's call him Dave. I was a junior MOT developer on the team. At first I hardly understood the code. In the most important places there were no lengthy procedures; instead, many small classes and methods a few lines long were used. Some of my colleagues complained that Dave was too confusing. But he took me under his wing and offered to read several books on object-oriented programming. He told me about design patterns, the principles of SOLID and unit testing. Soon I began to delve into the code, and the more I worked on it, the more I liked its elegant design. He functioned correctly and just did his job. Making changes to the code was also relatively easy, so the new functions were connected rather painlessly. The use of unit tests meant that few bugs reached production ...
')
As a result, from the outside it was not too similar that we work hard. I went home at 5:30, never worked on weekends, we didn’t crowd for hours around each other’s tables, suggesting what went wrong with fallen systems. It must have seemed to people that our work is much simpler than the work of the analog TV team. In truth, the requirements for us were very similar, we just had better written and implemented software and better support infrastructure, especially unit tests.

The authorities have announced that they want to raise wages, based on performance indicators. When it was my turn to speak with the boss, he explained that it would be fair if those people work very hard and our team seems not to be so worried about the company, especially when compared with the heroes who sacrificed their evenings and weekends.

The story of the cable company is a special case, because there it was possible to compare the consequences of good and bad software and the behavior of the team. Most companies will fail to find such a comparison. If a person works hard, works late and on weekends, he doesn't have time all the time, it's hard to say whether he really does a very difficult job or just makes a lot of mistakes. If you cannot hire two or more competing teams to solve the same problem (and who will do this?), You will not be able to find out for sure. Conversely, how about a guy who sits in a corner, working from 9 to 5, and seems to be sitting on the Internet for a long time? Does he have a lot of experience in writing stable, reliable code, or is his work easier than others? If you look from the outside, the first works very hard, and the second does not. Hard work is good, laziness is bad, right?

I would say that hard work often indicates mistakes. It is difficult to develop good software, if you are under pressure and constantly interfere. Overtime work is often not so good. Sometimes, to solve a complex problem, it’s best to stop thinking about it, go for a walk, or even have a good sleep, to give your subconscious mind everything. One of my favorite books is A Mathematician's Apology G.Kh. Hardy (GH Hardy), one of the leading British mathematicians of the 20th century. In it, he describes his daily routine: four hours of work in the morning, watching cricket in the afternoon. He says that doing heavy mental work for more than four hours a day is pointless and unproductive.

I would advise managers to judge people by results, by working software, and not by how hard they work. Contrary to intuition, it is sometimes better not to sit with the developers, because then you can get a more complete picture of your products, which will not depend on ordinary / intuitive indicators. Remote work is especially beneficial; You can evaluate your employees by the amount of work done, eliminating the need to lazily look at how they sit at the tables for 8 hours a day, crawling around in integrated development environments, or "helpfully" crowding around, offering "useful" ideas.