The Worst Programmer I Know (2023)

What i like the most is how it describes the more senior engineers in my team.

Don't forget about the type of software. Something really specialized or algorithm heavy (science or math heavy) might be harder to do solo than a CRUD app.

I had a sort of similar situation. I was one of two senior developers at a company making utility software for Windows and Mac in the late '90s and early 2000's. The other senior developer was the owner and CEO of the company and had to spend most of his time doing owner/CEO things so was only able to spend maybe one day a week developing.

The way we organized most of our Windows programs is that I'd write a non-GUI core that implemented all the underlying system level stuff we needed, and then the junior developers would write a nice Windows GUI that used that core. If the product needed anything like a VxD, a filesystem hook, an LSP, or any other Windows kernel extension I'd write that too.

We were profitable and there would be profit sharing bonuses quarterly (I think...might have been monthly but that doesn't significantly change what follows). The owner was always tinkering with how to decide how much profit sharing each person got.

One scheme, which he was sure was going to be great, was to take the total amount available for profit sharing for a quarter and divide that by the number of employees. Call that amount "1 share". So if there were N employees there were N shares available.

He wanted those shares to be allocated so that 25% of the employees got 2 shares, 50% got 1 share, and 25% got 0 shares. Who is in what group would be determined by a company wide vote.

Ballots were distributed that listed all N employees in alphabetical order, and we were told to write a 2 next to N/4 names, a 1 next to N/2 names, and write a zero next to the remaining N/2 names.

For each person their numbers from all the ballots were totaled, and the 1/4 with the highest totals got 2 shares, the 1/4 with the lowest totals got 0 shares, and everyone else got 1 share.

In addition, the people with the 8 highest votes would be put on a committee that would advise the owner on the direction of the company.

The owner's expectation when he launched this was that I would be the top vote getter nearly every time, and would always be in the top 8 so be on the committee of 8 which he was planning for me to run.

I ended up not being in the the top 8. I wasn't even in the top 25%. I don't remember for sure, but it was either somewhere in the bottom half of the 1 share group or it was in the 0 share group.

The reason was simple. Although I wrote the core functionality of all our products my role was not really visible to people other than other developers. It was the junior developers who wrote the GUIs. It was the junior developers who did most of the interaction with the testers. When a test found a bug they'd report it to the junior developer who was, to the testers, the face of the project. If the bug turned out to be in code the junior developer would let me know.

So every developer put me down for 2 on their ballot, but to everyone else I was just some guy in development doing some unknown work so I didn't get many votes from anyone else.

At least the owner immediately recognized that this profit sharing scheme was flawed and dropped it. Since he reacted so quickly I didn't gloat too much over the fact that this was exactly what I told him was going to happen when he first proposed this scheme.

(Some gloating was necessary because the owner and I had been best friends since we met in college about 15 years earlier, and the obligation to rip on your best friend when they do something stupid after you told them it would not work is stronger than the rule that you shouldn't tell your boss "I told you so!").

It is not absurd. From manager's point of view, when they are deciding to let someone go or promote them, they often need some arguments. And since software is invisible, it is often hard to just say straight away who is over/underperforming and why you think so apart from a "vibe" you are having. Measuring some relevant metrics can strengthen your argument and/or your overview of the situation.

I don't think that the blog makes a compelling argument why measuring productivity is bad per se. It makes a compelling argument that metrics should not be interpreted blindly, but the metrics in this case identified a guy that was doing something unusual, and the managers managed to interpret why this is the case. But if it was an IC that is supposed to deliver, or if you did not want "Tim" to spend his time coaching people, this could still have been valuable info.

Both "trivially" and "fixed" are doing an incredible amount of heavy lifting here.