Programmers are not bricklayers, they are writers

[[134795]]

If you have 10 programmers, the best one is probably at least 5 times better than the worst one. This is absolutely not bullshit.

We define "better" as working faster, producing fewer bugs, and having more readable, logical, and maintainable code.

Programmers are not bricklayers, but they are often treated as bricklayers. (I am not discriminating against these professions)

"Why do I need a senior programmer when I can hire two junior programmers for the same salary?"

"It takes one programmer three months to complete this function, so we only need to add two more and it can be done in one month."

Why is the above idea ridiculous? Because we don’t have a simple and effective way to measure programmer productivity. If we can’t measure something, we ignore it.

Let me ask you this: Would you rather have two novices take care of your baby, fix your car, and do a lumbar puncture, or would you rather have one veteran?

Relevant research shows that the productivity of the best programmers can be up to 28 times higher than that of the worst programmers. However, the cost of spending on these best programmers is definitely not that much, so they are the most cost-effective "special products" in the software field. ——ROBERT GLASS, "FACTS AND FALLACIES OF SOFTWARE ENGINEERING"

If you must make a comparison, programmers are more like writers.

Some writers write things that sell for millions, while some writers write things that are so boring that they can only be used as fuel!

But they both produced a book, so they are both writers, but unless you read their books, you would not know the difference between them.

Programming managers have long recognized that there is a huge difference in productivity between good and bad programmers. But the actual measured data still surprises us all. In the study, Sackman, Erickson and Grant wanted to measure the performance of a group of experienced programmers. The results showed that the ratio of the best and worst productivity was about 10:1 on average, and the ratio of programming speed in particular was an astonishing 5:1! - FRED BROOKS, "THE MYTHICAL MAN-MONTH"

Let me tell you a true story. (The names have been changed.)

A software company needed to implement a new module in their signature product. Mr Lousy happened to be free, so he was given the task and asked to start working immediately!

After four months of tinkering, Mr. Cha finally finished. The QA team found a lot of bugs and inconsistencies and reported them back to Mr. Cha. Mr. Cha spent another two weeks fixing the bugs based on the reports and finally released a new version! Those damn annoying bugs really racked Mr. Cha's brains.

Test and fix, repeat this cycle two or three times.

Users are already looking forward to this new module. Sales has also signed up some new customers. You can imagine how stressful it was to get this module out and integrate it into the next version. But, fortunately, it worked! Let's celebrate with champagne!

Oh, no, the new module is still full of bugs. The public's eyes are always sharp, and customers are always particularly good at finding some bugs that have never been found before. So they contact technical support. The technical support team then finds out what went wrong, whether the customer doesn't know how to operate the function, or they made a mistake, or it's just a bug, a bug that can be reproduced. ... Then the technical support team submits a bug report. So, Mr. Cha is in trouble - I mean, even if he is working on another project, he can only put down everything he is doing at this time to solve these troubles.

(This does not involve the maintainability, logic and documentation of the code - because there will definitely be others who will improve the code in the future)

But, well, what can I say… it seems that some bugs are beyond Mr. Cha’s ability and he can’t fix them at all. In addition, new bugs keep appearing and no one knows whether they are really new or they have existed before but have not been discovered. Technical support is getting annoyed. And sales is getting more and more annoyed because new customers are saying that this module is too unreliable and they want to cancel the contract!

Finally, the boss had to ask Mr Rockstar (the good man) to take a look at the code.

Mr. Nice didn't want to clean up Mr. Bad's mess. Many of the structures didn't make sense to him. He suggested rewriting the code, estimating that it would take about a month. He then started working and finished the module just a few days later than originally estimated (he was Mr. Nice, not Mr. Perfect). Everything worked as expected except for some minor errors found by the QA team. The QA team was silently worried: if all programmers were like him, then they would be useless. Mr. Bad thought Mr. Nice was arrogantly mocking him, but his opinion was irrelevant to Mr. Nice.

The improved module was released quickly. Everyone was happy because it finally worked. Hooray!

Now it’s time to pop the champagne and celebrate!

But at this time, everyone seemed to have forgotten that Mr. Good successfully completed the task that Mr. Bad had failed to complete in seven or eight months in just about a month.

This shows the huge difference in productivity levels between these two developers - they are performing the exact same task.

By writing leaner but more functional code, by writing code that is less buggy and easier to maintain, a good developer can reduce the workload of QA, colleagues, and management, and increase the productivity of everyone around them. This is why data such as 28 times productivity that are obtained from studies are possible, and may even be underestimated if you look at the big picture. - PHIL HAACK, "10 DEVELOPERS FOR THE PRICE OF ONE"

So, what's the worst thing that could happen in this story?

Mr. Good eventually noticed that he was much more efficient than Mr. Bad: he could easily identify bad code. But despite this, he was sure that his salary was about the same as Mr. Bad. He expressed dissatisfaction and even resolutely left. So your development team lost a pillar of efficiency.

Even if he doesn't leave, what will he think when faced with the overtime of the entire team due to release/project delays? Leaving is inevitable, it's just a matter of time.

And if you are really unlucky and mention another person to replace the good gentleman, but unfortunately it turns out to be another bad gentleman, then I can only light a candle for you silently.

So why do we always tend to ignore this fact?

Because it is much easier to ignore than to correct the problem - at least to some extent, it is true. And no one wants to be the villain who informs on his colleague and become the reason for him to lose his job: because maybe the colleague has parents to support and children to feed; maybe he just bought a new house and has to pay the mortgage every month - most importantly, it is really difficult to measure the productivity of developers unless you let them do the same task to compare, just like the story above.

So I've been thinking about this: how do you measure developer productivity? I'm jealous of people in sales because they get paid based on performance. I have some ideas (still immature) that can help you separate the good from the bad. I also have some ideas about how to identify, attract, and retain good developers.

Who I am and why I'm telling you these truths

I've been working as a full-time developer for over 10 years. I made my first commercial product (a game) back in 1989. It didn't make me a lot of money, but it felt really good (I was only 16). A few years later, I sold one of the game ideas and it ended up being released on Nintendo consoles (among other formats)! I can tell you from experience that it's a great feeling to see something you came up with (including the name) finally appear in stores.

In 2008, I applied for a non-technical position at a technology-driven company. I wanted to understand how the business generally operates, all the non-technical processes that happen in the business, including sales. Although my technical skills were helpful in my job search, they were no longer a critical component of the job.

I no longer program for a living (well, at the time), but I often tinker with new technologies on side projects. For me, reading a good book is both stimulating and relaxing at the same time.

In my current role, I often come across people who misunderstand concepts or lack the basic knowledge of development, which can have a huge impact in their position (usually CxOs).

Many CxOs treat developers as bricklayers and rigidly calculate their work efficiency. However, here, I would like to reiterate this "writer theory". Developers are intellectual workers, OK?

Original English text: Your Developers Aren't Bricklayers, They're Writers