The Worst Programmer I Know (2023)

Measuring story points or lines of code is kind of the opposite of productivity. This encourages developers to do as much meaningless work as possible. I'd want a developer to make a task simpler or use an existing tool which means less time writing code. The value of them saving that work from knowing another way is high but hard to measure.

What you want is measuring business outcomes but those are hard to attribute to a particular developer.

I think unfortunately we're left with our subjective judgement here. I think we'd do better admitting to ourselves that we can't measure this than to pretend we have some sort of science here.

productivity metrics aren’t entirely worthless. if I come into a team, for instance, and I see they have 1 PR mapped to roughly every 1 jira ticket, and I see a guy on a 3 person team that’s got 70% of the PR’s in a year, that isn’t a clueless piece of info. he’s probably the lead. not always, and people game stuff like this, but it is a data point you can make note of.

I experienced the "bad ending" of this productivity metric trickle down: OKR. This startup wanted not just team-based 3-month review Objective Key Result but also individual one, and on top of it, tied stock option to OKR. It was a robotics startup so very cross-domain teams (Software, Hardware, Embedded, DevOps, HW design, HW testing, HW maintenance etc etc).

The result? Developers became lonely islands. There were no "Tim" anymore. When I (Software Integrator) encountered an issue, that I just couldn't figure out but had a hunch it must be a deep-rooted issue, went to the expert (control/kinematics) for feedback. The answer I got was "I'm sorry I really want to help you but my OKR deadline is very close, and I simply don't have time". He could've probably fixed it in a day or less, but it ended up taking 2 weeks.

The problem turned out to be quite deep: inside layer upon layer of C++ mega monorepo, I found that boost library and a custom kinematics library had implicit struct copy and the different libraries (more than two) used different order for representing translation & rotation (xyz, rpy, Euler, Quaternion) and all of the ordering of each components were different. Somehow over 2 years of operation nobody got troubled by this until our new team had to use it.

Afaik I reported it to the Software team, but again, because OKR, nothing was done about it.

A much healthier situation, to me, is one where Tim does stories like everybody else, and when people need help they ask the group and whoever is the best at that thing helps them -- or whoever hasn't helped in a while.

Surely there are easier stories for those who need the most help, and Tim should be taking on the hardest stories by himself?

Or if you really do have an insanely lopsided team where everyone is straight out of school with no experience, and a single super-senior dev, then... shouldn't they just be a special kind of team lead who is expected to mentor full-time and not be subject to metrics?

The post here is not a good example at all of metrics failing to capture work. In reality, it is surfacing the fact that either Tim's job title and metric are totally wrong for him individually, or else that Tim is failing to contribute the hardest code, and the team is failing to distribute the "helping" workload. In both cases, the metric is working as intended, and it is surfacing something very important than needs to be fixed. (Remember, "fire Tim" is not the only possible action you can take because of a metric.)

As a very experienced programmer, I'm sure that I could increase the productivity of other programmers by pairing with them all day. However, is that actually the best and most productive use of my time? In my estimation, I think that overall team productivity would be maximized if I spent approximately 20% of my time pairing with others and 80% on individual contributions. (That's a rough estimate; it could be 25/75 or 30/70.) The article said that Tim was "patient", but perhaps he was too patient, wasting a lot of his time that could be spent accomplishing other things.

The best best teams I've been on, Tim's helpfulness osmoses onto other people, and instead of Tim always being the one, the process goes like this:

1. Dev gets stuck

2. Dev attempts to unstick self for appropriate amount of time given problem and probability of self-unsticking given resources (e.g. some stuff is easier to search for internally, or dismantle and go piece by piece)

3. Dev announces "hey I'm blocked on XYZ thing"

4. Whoever knows the most about that topic (not always Tim, but often Tim) puts that as like their highest priority thing, and almost always jumps in right away to help (unless they're like ignoring chat cus they're in the zone)

Works great especially if you do #4 at some break time (like say lunch or standup), and everyone has enough things to work on that they can do their own internal CPU pipelining and work on other stuff until someone has time to help unstick them

Every team is different, but software development needs the time and space for individual work just as much as group work. A small team who needs a dedicated person for pairing, who also doesn't (or won't) do any IC work, is a huge red flag.

It’s so difficult to quantify the value of “support” but they’re indispensable. I have yet to really find a sensible way to quantify it. It’s ultimately just something that you need to trust leaders to get right.

- # LoC added, changed, removed

- number of points earned in a sprint, when those points aren’t quantitatively indicative of business value, and they never are

- number of on or off-the-clock hours schmoozing with others to solidify relationships with the business and “play the game”

- number of times they “sound like good developers / intelligent people” in meetings or presentations

- number of weeks they spent on really complex problems they worked to solve when they could have provided more incremental value earlier much more quickly

- number of solutions they provided the company quickly while leaving many times more LoC to maintain

- number of hours they spent honing code, formatting, updating to the latest versions but doing so for their own edification and preferences rather than focusing on the team and the business and what would help them

and so many more...

I was once part of a team that had a zero-storypoints developer too, let's call him Zero. He always refused to get any stories assigned during planning, his goal was always zero. He felt responsible for delivering all the planned stories and helped the people who struggled. He often came to me and told me to help someone on a specific task, because it was too much for him to help everyone.

This was well understood by management though. Zero took a 4-6 week vacation every year, and management always pushed important releases back if Zero was not there. The team could've done it without him, and it might've been better for the team not to have Zero around for all important releases. But management was scared something could go terribly wrong without him.

I write code for others to read a lot, to explicitly teach them how to do something. This code has always been overly verbose, "decompressed" and teaches people the thought process behind a solution above being a "neat" solution. I was dragged a little reluctantly into this style, by being forced to anticipate all the ways the code may be misunderstood ahead of time -- by all the ways it was misunderstood previously. Its much less work for me to be verbose up-front, than fix misunderstandings later.

After watching and looking at some of the best systems programming code/coders -- I've come to think this is just the best way to program in general.

The latest program I wrote this way, and the quality of code is vastly higher. No abbreviations, any unusual coding practice (eg., conditional imports, using classes as namespaces rather than object templates, etc.) I noted briefly in comments to highlight it's unexpected. Any functions which are domain/app-specific have execessively long names which fully describe that step/asepct of the solution. Extensive design comments where my thinking is noted. etc.

Programs which teach their readers how to think about the solution, rather than how to understand the code -- and teach it to a "smart junior" rather than to an expert. I think this is different than literate programming, and of the maxim "code is read more than written" -- it's a specific "educational ethic": code isnt clean, or literate, or readable -- its educational.

If this is the best way for "programming in the large", then a property of programming languages follows: languages which enable the programmer to "decompress" their thoughts over many lines are preferable to ones which hinder this. This I think then explains something about the uptake of functional languages -- which resist this decompression of thoughts over lines of code. They are often sold on their conciseness -- as if a 200 line C++ ought be reduced to a 10 line F# program. This trades the wrong sort of productivity: long-lived large programs require programmers to build mental models of them far more often than they require them to add to them at-scale. A programmer self-teaches the code base more often than they write it: this isnt about reading.

This goes somewhat to the role of Tim in OP. Perhaps the right software engineering programming practice is to write code as-if you are pairing with a new programmer in the future. To verbalise everything Tim would say, already, in the code.

I'm very glad this essay turned out to take this position, because when I read the first couple paragraphs, I was ramping up to write a mean internet comment about how stupid measuring developer productivity through story points is.

A friend of mine is exactly like this Tim guy he talks abou: he spends time helping other people fix their problems, or takes extra time doing things the right way. His personal velocity suffers, but the team and the code base is greatly improved on net. He was put on a Performance Improvement Plan at one company, and told his job was at stake at another as a result. No question it's kept him at a Senior level when he should be higher at this point in his career. I sort of take it personally, because I worked with him at the company that gave him the PIP, and both he and I quit as a result.

When I see companies trying to measure developer productivity (and tying it to employment and advancement) I think about Seeing Like a State by James Scott, and the concept of legibility: imposing by force a set of rules on a complex, messy system to make it easier to steer from some office far away. Makes it very convenient to managers, and often leads to disaster.

We’re told of the hero, who goes against their managers and executives and doesn’t deliver any stories as agreed in sprints.

We’re told of the engineer who isn’t hired by Google because he can’t invert a binary tree. Everyone else piles on and decree that, yes indeed, you cannot measure developer efficiency with a Leetcode or whiteboard problem. We’re too good for that. Another engineer chimes in: “I don’t test my candidates. The best people I worked with were hired over a beer and a chat at the local pub”

We’re told of the MBAs who destroy the organisation, by introducing evil metrics, and how that the work we do are immeasurable and that the PHBs don’t understand how great we are. 10x engineers aren’t a real thing, everyone is equally productive in our digital utopia.

Meanwhile in the real world, hordes of awful engineers deliver no story points, because they in fact, do nothing and only waste time and lowers morale.

Meanwhile in the real world, each job opportunity has thousands of applicants who can barely write a for loop. Leetcode and whiteboards filter these people out effectively every day.

Meanwhile in the real world, metrics on delivery, features and bugs drive company growth and success for those companies that employ them.

To me, all these heroes, and above process people, just strike me as difficult to work with narcissists who are poor at communication. We are not special, and we do not sit above every other department in our organisation.

First: just like there can be individuals who lift up an entire team but are not ticking off tasks themselves, there can be apparently individually productive team members who slow the entire team down for any of a number of reasons. In my experience it's usually either that they are a) fast but terrible, b) have really weird coding styles that might not be bad but are very difficult for others to work with (architecture astronauts and people who barely speak the language often fall here), or c) are process bullies who try to set up the entire review system to enforce their preferences in a hardline way that suits them but delays everyone but them. Each needs to be dealt with very differently, to varying degrees of success, but my honest opinion at this stage is that no matter how productive these people seem by themselves it's mostly harmful to have them on a team. Behavioral issues in senior people tend to be really tough to adjust, and take a lot of energy from a manager that is better spent helping your top performers excel; that said, if you can get them to adjust sometimes it's worth the effort.

Second: pair programming works great for some people, but it is terrible for others. I've measured this on teams by trial and error over fairly long periods, and unfortunately it's also the case that people don't segment neatly based on their preferences, so the obvious "let them choose" method isn't ideal. There are pairs of people who really love pair programming and desperately want to do it all the time who are almost fully 2x as productive when split apart instead (yes, including downstream bugs and follow-ons, meaning that they really are just having two people do the job of one), and there are people who hate pairing who see similar multiples by being forced into it even though they hate it. My rough intuition is that there are two independent variables here, a social factor that measures how much you enjoy pairing, and a style factor that determines how much benefit you derive from it, with the two not correlating much at all. There might even be a slight anticorrelation, because the more social people who love it have already naturally done as much knowledge sharing as is helpful, and the people who hate it are underinvested there and could use some more focus on the fact that they're part of a team.

Every system can and will be gamed, either directly or indirectly through osmosis and attrition.

The only way to win is not to play. Put people in charge that know how the pie is made, then trust them to make the right calls.

This btw is one of the major reasons why non-technical founders/managers so often fail.

There’s also folks that pair because they’re a crutch for one or two other engineers. The other engineers never improve or are let go, but softly slow down the team.

There’s also the folks that pair because their code doesn’t make sense on its own. Or they have some config files they’ve refused to check into the repo, etc.

Pairing makes them feel valuable.

At my (very large) company Scrum and SAFe is applied to all kind of projects. Even to manage organisations with highly heterogeneous responsibilities and workloads. Think of 2 people doing dev, 2 conceptional work for various larger projects, 3 are basically consultants for other orgs, 4 are data analysts and 1 is doing some spreadsheet work all day long. Now our manager had the great idea to manage us with Scrum.

Anyone that looks for the metric to find the weakest link, is the weakest one at heart.

One major problem with tools that ask crafters to do data entry to show their value is that best people are most likely to refuse. You really need to focus on tooling to help capture what’s going on without toil.

For example, if your folks are remote and they use software to aid in pairing (eg Tuple), script the system to log the tuple sessions and perhaps even capture the pairing in the commits made together.

This can be used as an input to bring visible to be best leaders in your org.

Aside: I wasn't actually fired, when I went under "review" status, whatever it was called, I lined up another job and left.

It kind of rubs me the wrong way that Tim can just fly under the radar and do whatever he wants without any paper trail or accountability while the rest of the team has to clearly convey what they are working on

I guess as someone who does a lot of the same that Tim is doing,and I bet others can resonate, I still "have to" pick up tickets and I think that's always the expectation in any job I've had as an IC. Is Tim managing his time well ?

https://medium.com/heroicpresence/the-super-chicken-study-pa...

Measuring stories/features/issues solved seems sensible to me

https://www.folklore.org/Negative_2000_Lines_Of_Code.html

I like casually hanging around and telling people what they can do better. This usually results in me seeming unlikable, since I am so often pointing out mistakes.

I doubt he never worked on any tasks though, so maybe something for him once for a while.

In short you replaced one well defined metric with an adhoc one following your bias.

You are a peon. For all you know your local improvement has a negative effect on the whole company. Listen to your boss and let the company fail fast if it has an unfit system.

Was he the cross-pollinating bee of math?

Competition within teams selects for the people who invest most time into looking as if they produced worked punishes those who are good team players.

On top of that, how do you compare a guy who produces 100k lines of unmaintainable boilerplate code versus a guy who in the same timeframe hunts down a particularly nasty and hard to fix race condition and changed 1 line in the end? Any programmer knows the latter is much more exhausting and provides lasting value, while the former might actively hurt the project down the line.

If you manage software development either you trust your team or you have to understand the program yourself and micromanage them. Best would be to trust and understand the program and only inject yourself when it is really needed.

The Jira-focused performance metrics led to a lot of short term work and fixes since everyone was heavily incentivized to get the immediate task done as quickly as possible without much long term thinking. This created an increasingly large amount of tech debt and caused some real messes. But hey, we could loudly proclaim our love of iterative innovation and data driven decision making processes!

I suppose one benefit was that it became pretty easy to get a stellar performance review since it was completely based on a few metrics that could be managed.

I love this story.

Vox Jira, Vox Dei. Make sure you're not working in a company with such kindergarden-like approach at managing people before attempting anything like that.

"Reports showed me the absolute worst programmer on my team. Did I fire him? No. I actually gave him a 20% raise.

Do you know why? He was the best programmer on my team (in disguise)."

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!").

But our AI overlords will need metrics that they can use.