Experience does not matter
Did you know that for all the years of the software development industry, there has not been a strong connection between work experience and code quality and employee productivity?
In 1968, a study of the productivity of programmers was conducted ( source ), which showed that the ratio of the best and worst programmers was:
These figures in different variations have already seen everything. But the fact that the study was conducted on programmers who had an average of 7 years of development experience with minor deviations, no one knows.
')
Similar studies were repeated by other groups of scientists for 30 years:
They also showed the difference between the worst and the best at times (although of course less than 25 times). And also showed no relationship between productivity and work experience.
Since 1968, literally everything has improved in development: languages, frameworks, tools, and also programming have now been taught for several years in high school. Nevertheless, the productivity of programmers was different at times 30 years ago, and it is different today.
This suggests that there is some X-factor, not related to experience, which distinguishes a good programmer from a bad one. At the moment there is no consensus on what the factor is. Some say that it is the ability to plan their work and “see” the structure of the code before the code is written. Others say that the most productive programmers are those who can quickly produce a visible result. My personal observations suggest that those who can read the code write the code best.
If we discard the ethical side of the issue, then we must dismiss all low-productive programmers, regardless of experience. Seriously, given the facts above, you can recruit a small team of relatively inexpensive, but highly productive, programmers. And it will be many times more profitable than keeping a staff of experienced professionals.
Another conclusion that contradicts logic a little, but is often met in practice: the programmer will not become more productive, having received years of experience. The only way to improve the productivity and quality of code for programmers is to conduct targeted education and training.
Last but not least, we need to strongly revise the method of hiring programmers. Instead of dropping out by keywords in a resume and logic tasks, candidates need to write code, preferably in “laboratory” conditions, so that they can track productivity and quality.
We must understand that productivity is not the same as efficiency. In the modern world, where the complexity of technology grows faster than people manage to study technology, where any problem has more than one solution, where most of the code is already written, it’s not the programmer’s productivity that comes to the fore, but the ability to find and combine ready-made solutions, as well as the ability to come up with a non-standard solution. But the larger the project, the more important the productivity and quality of the code, and, the more important, the selection and training of the team.
In 1968, a study of the productivity of programmers was conducted ( source ), which showed that the ratio of the best and worst programmers was:
- 20: 1 on the time of writing code
- 25: 1 on debugging time code
- 10: 1 on the speed of the program
- 5: 1 by volume code
These figures in different variations have already seen everything. But the fact that the study was conducted on programmers who had an average of 7 years of development experience with minor deviations, no one knows.
')
But it was a long time ago and in the study a lot of mistakes ...
Similar studies were repeated by other groups of scientists for 30 years:
Research list
- Curtis, Bill. 1981 "Substantiating Programmer Variability." Proceedings of the IEEE 69, no. 7: 846.
- Mills, Harlan D. 1983 . Software Productivity. Boston, Mass .: Little, Brown.
- DeMarco, Tom, and Timothy Lister. 1985 . "Programmer Performance and the Effects of the Workplace." Proceedings of the 8th International Conference on Software Engineering. Washington, DC: IEEE Computer Society Press, 268-72.
- Curtis, Bill, et al. 1986 “Software Psychology: The Need for an Interdisciplinary Program.” Proceedings of the IEEE 74, no. 8: 1092-1106.
- Card, David N. 1987 . "A Software Technology Evaluation Program." Information and Software Technology 29, no. 6 (July / August): 291-300.
- Boehm, Barry W., and Philip N. Papaccio. 1988 “Understanding and Controlling Software Costs.” IEEE Transactions on Software Engineering SE-14, no. 10 (October): 1462-77.
- Valett, J., and FE McGarry. 1989 . "Summary of Software Measurement Experiments in the Software Engineering Laboratory." Journal of Systems 9, no. 2 (February): 137-48.
- Boehm, Barry, et al, 2000 . Software Cost Estimation with Cocomo II, Boston, Mass .: Addison Wesley, 2000.
They also showed the difference between the worst and the best at times (although of course less than 25 times). And also showed no relationship between productivity and work experience.
What does it mean?
Since 1968, literally everything has improved in development: languages, frameworks, tools, and also programming have now been taught for several years in high school. Nevertheless, the productivity of programmers was different at times 30 years ago, and it is different today.
This suggests that there is some X-factor, not related to experience, which distinguishes a good programmer from a bad one. At the moment there is no consensus on what the factor is. Some say that it is the ability to plan their work and “see” the structure of the code before the code is written. Others say that the most productive programmers are those who can quickly produce a visible result. My personal observations suggest that those who can read the code write the code best.
And now what i can do?
If we discard the ethical side of the issue, then we must dismiss all low-productive programmers, regardless of experience. Seriously, given the facts above, you can recruit a small team of relatively inexpensive, but highly productive, programmers. And it will be many times more profitable than keeping a staff of experienced professionals.
Another conclusion that contradicts logic a little, but is often met in practice: the programmer will not become more productive, having received years of experience. The only way to improve the productivity and quality of code for programmers is to conduct targeted education and training.
Last but not least, we need to strongly revise the method of hiring programmers. Instead of dropping out by keywords in a resume and logic tasks, candidates need to write code, preferably in “laboratory” conditions, so that they can track productivity and quality.
Conclusion
We must understand that productivity is not the same as efficiency. In the modern world, where the complexity of technology grows faster than people manage to study technology, where any problem has more than one solution, where most of the code is already written, it’s not the programmer’s productivity that comes to the fore, but the ability to find and combine ready-made solutions, as well as the ability to come up with a non-standard solution. But the larger the project, the more important the productivity and quality of the code, and, the more important, the selection and training of the team.
Source: https://habr.com/ru/post/209646/
All Articles