Live data from Hacker News

The Worst Programmer I Know (2023)

dannorth.net

141–150 of 385 posts

Re: The Worst Programmer I Know (2023)

#141

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 again…

> the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on. I don't think this comes even close to solving the problem. This in fact makes the problem worse, because a) you admit the metric is shit and does not reflect work, b) you opt to keep the bullshit metric but instead try to manipulate it to bump the score under some scenario. That's not desirable outcome by…

> This in fact makes the problem worse, because a) you admit the metric is shit and does not reflect work

It's just like in physics: "all models are wrong, some are useful". All metrics are wrong, but some are useful when they are correctly applied.

Re: The Worst Programmer I Know (2023)

#142

The idea of measuring individual developer productivity is kind of absurd to me. I'm not saying that what we do is magic, there are just so many variables. 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 valu…

Dev productivity is like quantum mechanics. The second you try to measure it, the wave function collapses, and you've fundamentally altered the thing you were trying to measure. That said, at every place I've worked you could get a starting point idea of who the top devs were by looking at overall code commits. This Tim sensei situation may be more common than I think, but I've never run into it.

With my minor dabbling in game theory, I've considered funny angles like secret-ish internal metrics and punish those who simply game the incentives. Example: bot detections and banwaves in MMOs. Instead of instantly banning plausible bots, the company has to hide its (ever-changing) internal algo and ban in waves instead.

Basically, treating (non-)productivity like bot detection, lol.

Re: The Worst Programmer I Know (2023)

#143
This just seems like you performed a social engineering attack on your boss to keep someone on the team who was objectively performing poorly but happened to be doing something that is valued in western culture.

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.

Re: The Worst Programmer I Know (2023)

#144
post #116
post #114

Earlier quoted context omitted.

the worst programmer nowadays is the vibe coder. vibe coding is so overrated imo https://www.lycee.ai/blog/why-vibe-coding-is-overrated

I've been writing code professionally for a decade but I've never written so much code in my free time because I can just vibe code it all. I wouldn't do it at work and I probably wouldn't trust a juniors vibes as much as my own but no tools have made me feel quite so powerful.

I never tried vibe code as described in this article, but I could see where it breaks. Initially, code works. Eventually, there's a bug, and the LLM isn't able to fix it. At that stage, you're on your own with a potentially large codebase which is totally new to you.

Even on small projects, sometimes I'm tired, I just try to get the LLM do some refactoring for me or write a couple of tests. First, whatever the LLM writes, it's going to code review and I'm not submitting code that I haven't read and understood just to have colleagues complaining. Second, if the code doesn't work, it gets frustrating. For LLMs to help, I like to have a pretty clear idea of what I want, how the "right" code looks like so I can give more indications.

Re: The Worst Programmer I Know (2023)

#146

The idea of measuring individual developer productivity is kind of absurd to me. I'm not saying that what we do is magic, there are just so many variables. 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 valu…

Could a company keep a subjective poor performer on for the lifespan of the company? As in, what is the plus or minus in overall revenue or profit from this charity? What if all companies did that? Could we distribute the "burden" of the charity across all companies for a better society? My point is, I don't even know if metrics are good or bad, we may need to look at why we see each other like this. Is it so offensive to the mind of the captain of a ship that they may have a few of not the best sailors? It's a chance for them to be on a ship, go on a journey. The concept of a "free ride" appears to be a serious moral hazard for us, but I can't figure out why.

Re: The Worst Programmer I Know (2023)

#147
Counterexample: Not everything needs to be a group activity or social. If a developer of average skill can't manage to deliver a feature without the constant help from a "Tim", it says something about your code, processes, team. I've worked at places where they used pairing as a signal the team was working well together, when the reality was the code was so brittle and full of hacks it took the combined help (usually moral support) of a Tim to help support through every little change.

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.

Re: The Worst Programmer I Know (2023)

#148
post #127

Earlier quoted context omitted.

it's definitely nice for prototypes, but nothing more complex.

I used to feel that way but my perspective over the last 6 months has changed greatly. You can absolutely build very complex things in this style

show me an example of such a complex thing obtained after just writing prompts

Re: The Worst Programmer I Know (2023)

#149

The idea of measuring individual developer productivity is kind of absurd to me. I'm not saying that what we do is magic, there are just so many variables. 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 valu…

Dev productivity is like quantum mechanics. The second you try to measure it, the wave function collapses, and you've fundamentally altered the thing you were trying to measure. That said, at every place I've worked you could get a starting point idea of who the top devs were by looking at overall code commits. This Tim sensei situation may be more common than I think, but I've never run into it.

I've worked on projects where every single ounce of enthusiasm is coming out of one mediocre developer. Nobody pays attention to team dynamics like this, but they're all over the place.

Re: The Worst Programmer I Know (2023)

#150
post #143

This just seems like you performed a social engineering attack on your boss to keep someone on the team who was objectively performing poorly but happened to be doing something that is valued in western culture. 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…

This is an awfully bad reply. The person described in the essay is basically an L6 and an L5 moving to L6 at AWS. Our L6s don't write code, they build PoCs, work on designs, estimates, and scale through others. They use their experience and knowledge to scale out, and the L5s and L4s do the work.
Post reply on HN