How much is a programmer worth?

This is a question for companies that want to hire talent in the development field, as well as for all of us programmers who want to know how much we are worth.

Well, to price something, we need to differentiate characteristics that make one good more or less valuable than another. When we talk about the work of a professional, which is not a good, but produces goods with their work, we could then think that the productive capacity of that professional makes their work more or less valuable.

We are talking about productivity, which in the language of IT is something like the amount of functional, performant, bug-free (or with the smallest possible number of bugs) software that a developer is capable of delivering.

Okay, we have entered common sense territory. A good programmer delivers more quality software than a mediocre programmer or a bad programmer. However, how do we validate what makes a good programmer? How do we measure the productivity of people given that each project/system/software has different characteristics and complexities?

The market has been trying to do this for years without success. Have you heard of function points? Measuring performance by lines of code written? All of these attempts were daydreams that led absolutely nowhere.

If I write much more code per hour, does that make me a more productive programmer... And if that code could generate the same result and be written in half the lines of code because someone smarter used a more intelligent solution?

And if my incredible performance of delivering code quickly delivers bugs in production? What is the cost of that? What is then the value of my productivity and the ROI (Return on Investment) that I am producing with my code? Measuring the performance of a programmer is therefore not a trivial task. How do we know how much more productive programmer A is compared to programmer B? Or, how many times more productive is a spectacular developer than a mediocre developer? If programmer A receives more complex tasks than programmer B and makes fewer deliveries, is he worse or better than programmer B? And how do we measure the level of complexity of two different tasks?

Joel Spolsky (if you don't know who he is, take a look here - https://en.wikipedia.org/wiki/Joel_Spolsky) had an interesting insight. He tabulated data from Professor Stanley Eisenstat (https://cpsc.yale.edu/people/stanley-eisenstat), a professor at Yale who for years taught the CS 323 discipline, which consisted basically of about five major programming assignments, each taking about two weeks.

The assignments were relatively complex algorithms for an undergraduate student - implementing a compression algorithm, implementing a Unix command line shell, and so on.

Each semester he received various complaints from students about the complexity of the assignments. The projections of effort to solve the assignments were so disparate that he decided to start measuring and tabulating the performance of each of the students. He began asking each of the students to report how much time they spent on each of the assignments and collected this data for years.

The way Professor Eisenstat grades his students is also completely mathematical - it is a formula based on how many automated tests the code was able to pass. That's it, nothing more. No feelings or extra points!

What is wonderful about this dataset is that it is an absurdly controlled study (same assignments), with a relatively controlled audience (Yale undergraduate students), with an objective metric (grade) being repeated for years on end (the assignments have been the same since 1980!).

Here are some tables compiled by Spolsky in the book "Smart and Get Things Done" (https://amzn.to/31IhgQp):

Ok, we clearly have an impressive variation among students. Look, for example, at the relationship between the lowest hours produced in COMPRESS00, Min of 11.58, to Max of 77!!!

You may argue that the developer who delivered the work the fastest did not pass all tests and is not necessarily the one with the best grade. And you are completely right in this analysis. Therefore, let's borrow one more table compiled by Spolsky, which only considers the first quartile (25%) of students with the best grades:

Data from the implementation of project COMPRESS01 (which is an implementation of a compression algorithm known as Ziv-Lempel-Welch) from students who took the class in 2001 is shown in the graph below:

Some interesting observations:

The standard deviation is huge! The quality of the produced code has no relation to the time spent. Going back to the motivation of this post, can we then say that an excellent programmer is 5 to 10 times more productive than a "bad" programmer and that they are worth 5 to 10 times more?

Can I then hire 5 "average" programmers for the price of 1 and get the same productivity result? The objective, quick, and concise answer is NO! There are several explanations for this:

1. Small teams have much higher average productivity than large teams. The complexity of interaction between human beings increases exponentially. So the smaller the team and the more "smart" it is, the better.
2. If you want to delay a project that is already delayed, hire more programmers for that project (quote from "The Mythical Man-Month" - https://amzn.to/3fI3ceF, if you haven't read it yet, read it. It's mandatory reading for anyone in the IT market).
3. If you are a company, you do not have infinite time to deliver your product with quality.
4. If you are a startup, you have even less time!

In summary, if you want to deliver quality software quickly and with a better overall cost, form a small team of legendary programmers. The effort of interaction between them and future maintenance will be much lower than any other variation.

And finally, a curiosity, do you know how many programmers WhatsApp had when it was sold to Facebook for $19 billion dollars? At the time of the sale, to support its base of 450 million users, WhatsApp maintained a team of 35 engineers.