The Worst Programmer I Know (2023)

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.

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 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 ?

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.