Programmers are not brickwork workers, they are writers "turn"

If you have 10 programmers, the best one may be at least 5 times times better than the worst one. This is definitely not nonsense.

We define "better" this way: work faster, produce fewer bugs, and make your code more readable, logical, and maintainable.

Programmers are not brick-builders, but they are often regarded as brickwork workers. (I don't mean to discriminate against these professions)

"Why do I need a senior programmer to know that I can hire two junior for the same salary?" ”

"It takes three months for a programmer to do this, and it takes two more to get it done in one months," he added. ”

Why is it absurd to say the above idea? Because we don't have a simple and effective way to measure the productivity of programmers. Once we meet something we can't measure, we ignore it.

I ask you this way: you are willing to let two novice to take care of your baby, repair your car, give you a lumbar puncture, or would rather find a senior?

Research shows that the best programmers can produce up to 28 times times the maximum productivity of the worst programmers. But the cost of using these best programmers is certainly not so much, so they are the most affordable "specials" in the Software world.
ROBERT GLASS, "FACTS and fallacies of software ENGINEERING"

If you must compare, then the programmer is more like a writer.

Some writers write things that can be sold millions of dollars, and some writers write something boring to the end can only be used to fire!

But they all produce a book, so they are all writers. But unless you read their books, you won't know the difference between the two of them.

Programming managers have long recognized that the productivity of both good programmers and poor programmers is a bag of the day. But the actual measured results still surprise us all. In the study, Sackman, Erickson, and Grant wanted to measure the performance of a group of experienced programmers. The results show that the best and worst productivity ratios are on average about 10:1, especially the rate of programming speed is surprisingly up to 5:1!
FRED BROOKS, "The Mythical Man-Month"

Let me tell you a true story. (the name has been changed.) ）

A software company needs to implement a new module in their logo product. Mr Lousy (Mr. Poor) just had the time, so he gave the task to him and let him work immediately!

After four months of tinkering, Mr. Poor was finally finished. The QA team found that there was a lot of bugs and inconsistencies and returned the report to Mr. Poor. Mr. Poor, according to the report, took another 2 weeks to fix the bugs, and finally gave a new version! Those damned annoying bugs really brains the wrong man.

The test is then repaired, so it loops two or three times.

The user is already looking forward to this new module. The sales staff also signed some new customers. The pressure to make this module and integrate it into the next release is conceivable. But, fortunately, success! Open the champagne and celebrate!

Yes, no, the new module is still full of bugs. The eyes of the masses are always sharp, and customers are always very good at finding bugs that have never been discovered before. So they contacted technical support. Technical support team to find out what is wrong, the customer does not know how to operate the function, or they are wrong, or this is just a bug, a can reproduce the bug. ...... The technical support team then submits the error report. So, Mr. Bad tragedy,--I mean, even if he is doing another project, at this time can only put aside all the work at hand to solve these problems.

(It doesn't have to do with the maintainability, logic, and documentation of the code--because there's definitely someone else to improve the code later)

But, alas, how to say it ... There seems to be some bugs beyond the scope of Mr Poor's ability to fix them. In addition, there are new bugs that are constantly emerging, and no one knows if they are new or have been discovered before. Technical support is annoying. And sales are getting annoyed, because new customers have said the module is too unreliable, they want to cancel the contract!

Finally, the boss had to let Mr Rockstar (Mr. Good) take a look at the code.

Mr Good does not want to clean up the mess for Mr. Poor, and many structures are meaningless in his eyes. He suggested rewriting the code, which is expected to take about one months. Then he started, only a few more days before he finished the module (he was Mr. Good, not Mr. Perfect). In addition to the QA team found some small errors, everything can work as expected. The QA team was silently worried: if all the programmers were like him, they would be useless. Mr Poor thinks that Mr Good is an arrogant mockery of him, but his view is irrelevant to Mr Good.

The improved modules were released soon. Everyone is happy because they can work at last. Hail!

Now it's time for champagne to celebrate!

But at this point, it seems that everyone has forgotten that the good husband has only spent one months or so of time to successfully solve the poor Mr Bad for seven or eight months also uncertain tasks.

The huge difference between the two developers ' productivity levels is evident-they perform exactly the same task.

By writing more streamlined but more functional code, by writing less maintainable code with fewer bugs, a good developer can reduce the pressure on the QA staff, colleagues and managers to improve the productivity of everyone around them. This is why the research results from these data, such as 28 times times the productivity is possible, and may even be also reported low if you look at the overall world.
PHIL HAACK, "Ten developers for the price of one"

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

The good man finally noticed that he was much more efficient than Mr. Poor: he could easily identify bad code. But nonetheless, he is sure his salary is about the same as that of Mr Poor. He expressed dissatisfaction, and even resolutely left. Your development team has lost a powerful pillar of power.

Even if he does not leave, what will he think when facing the overtime of the whole team due to the release/project delay? It is inevitable to leave, but only in time.

And if you are really unlucky enough to mention another person to take the place of Mr. Good, but unfortunately another Mr. Bad, then I can only silently light a candle for you.

So why do we always get used to ignoring this fact?

Because neglect is much easier than correcting a problem-at least to some extent, indeed. And no one is willing to be the villain of the report, to become the reason why he lost his job: because he has Gao Tang to support, there are children starving, perhaps he just bought a new house, every month to repay the loan--most importantly, it is really difficult to measure the productivity of developers, unless you let them do the same task to do the comparison , just like the story above.

So I've been thinking about how to measure the productivity of developers. I'm jealous of sales because their pay is based on performance. I have some ideas (not yet mature) that will allow you to go to its dregs to extract its essence. I also have some ideas about how to identify, attract and retain good developers.

My identity and why I'm telling you the truth.

I have worked as a full-time developer for more than 10 years. Back in 1989 I made my first commercial product (game). Although it didn't bring me much money, it felt really good (I was only 16 years old at that time). A few years later, I sold one of the game ideas and ended up in the Nintendo game console (and other formats)! From the perspective of my experience, I can tell you that when you see what you want to come up with (including the name) eventually appearing in the store, it doesn't feel too good.

In 2008, I applied for a non-technical position in a technology-driven company. I would like to know about the general operating mode of the enterprise, including all the non-technical processes occurring in the sales enterprise. Although my technical ability is very helpful to my job search, it is no longer an important part of my job.

I'm no longer programmed to make a living (to be exact, at the time), but I often tinker with new technologies on amateur projects. For me, reading a good book is both exciting and relaxing.

In my present position, I often encounter some misconceptions or lack of basic knowledge of the development of people. And in the position they are in (usually the CXO), these basics can have a huge impact.

Many CXO will treat developers as bricks-and-mortar workers to calculate their productivity. But here, I would like to reiterate this "writer's theory" that developers are brain workers, OK?

Link: http://www.codeceo.com/article/programmer-not-bricklayers.html
English Original: Your developers aren ' t bricklayers, they ' re writers
Translation Code Agricultural Network-Xiao Feng

Programmers are not brickwork workers, they are writers "turn"