The Worst Programmer I Know (2023)

JohnMakin · 2025-03-23T14:14:58 1742739298

Used to be bitten by stuff like this until I figured out something Tim and this author apparently didn’t - the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on. he can ask his teammates to do this and they gladly will, or, nice teammates will usually throw a “figured this out with the help of @Tim” in the ticket. goes a long way to keep “tim” on your team against obtuse velocity metrics like this.

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.

Clubber · 2025-03-23T14:18:04 1742739484

You're absolutely right, but some people just refuse to play silly games. It's odd that the manager isn't ever in the room with the team and doesn't understand his team's dynamics. Giving the benefit of the doubt, he must have been new, but any manager worth his salt will ask people on their team what the team dynamics are.

bsindcatr · 2025-03-23T14:21:39 1742739699

Some things that don’t measure whether a developer is “good”:

- # 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...

gravy · 2025-03-23T14:28:07 1742740087

It never occurred to me that a rebuttal to "not using lines of code or bugs solved because it can be gamed" is just to point out productivity is literally always gamed

croes · 2025-03-23T14:12:38 1742739158

So the real metric is the manager who knows their team and what each member brings in.

decGetAc · 2025-03-23T14:23:54 1742739834

How did the manager not know Tim didn't have tickets slated for him ? How did Tim not even pick up some (at a lower capacity) and then still helped with the remaining time ?

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 ?

mjburgess · 2025-03-23T14:22:10 1742739730

I've had some thoughts on programming practice somewhat related to Tim's role, and some on language design this morning.

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.

sehyun · 2025-03-23T14:00:18 1742738418

Discussion 2 years ago: https://news.ycombinator.com/item?id=37361947

franktankbank · 2025-03-23T13:41:36 1742737296

Sounds like Tim was the manager. What exactly was the paid for manager doing?

bluGill · 2025-03-23T14:06:04 1742738764

There are different types of managers. I'd use the term technical lead for tim. Someone needs to maneage product delivery. Someone needs to manage the backlog. Someone needs to manage the training of everyone. Someone needs to ensure people are getting setup for their next job. Someone needs to ensure everyone is paid right. Someone needs to handle it when two people don't get along. The above is a small subset of the full list - I don't know everything on the full list.

simonw · 2025-03-23T14:07:52 1742738872

Instead he would spend his day pairing with different teammates. With less experienced developers he would patiently let them drive whilst nudging them towards a solution.

That's not a management activity - that's the kind of coaching you would expect from a senior IC ("Individual Contributor" - I still hate that term.)

Generally I would expect a "manager" to have authority over other people in the company: run performance reviews, handle promotions and hiring and firing.

I think it's important for companies to provide a career structure that allows for influence, decision making and leadership roles that don't also require taking on those management tasks. Management tasks are extremely time consuming and require a substantially different set of skills from being a great team coach or force multiplier like Tim in the story.

jprosevear · 2025-03-23T14:14:58 1742739298

I would agree, but the manager probably should be in touch enough that they could see the teaming behaviour themselves.

llamaboy · 2025-03-23T14:17:28 1742739448

They did… that’s the whole premise of the article

spiderfarmer · 2025-03-23T14:08:54 1742738934

Clearly performing another under appreciated task: to act as a buffer for Tim, allowing the team to flourish even when they don’t adhere to company policy. And all other managerial stuff apart from coaching.

failrate · 2025-03-23T14:22:34 1742739754

The worst programmer I know literally could not go a day without either checking in code that did not compile or saying something creepy and sexual in a large open plan office, and we all worked together to get them fired.

eckesicle · 2025-03-23T14:18:04 1742739484

These sort of stories seem to be dime a dozen and weirdly celebrated around HN and the software engineering community.

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.

（评论） (comments)

（评论）
(comments)