Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Worst Programmer I Know (2023)

dannorth.net

Post reply on HN
Print view View original

331–340 of 385 posts

Re: The Worst Programmer I Know (2023)

#331

Post by red-iron-pine »

paradox460 wrote: post #181
OnionBlender wrote: post #108

Earlier quoted context omitted.

I had a director that was obsessed with github enterprise stats. He forbid people from squashing commits and told people to commit every day, even if you're in the middle of something. This was so that he could see who was writing the most code. One of our interns was close to the end of his term and this director wanted to hire him. He thought the intern was amazing based on the amount of code he wrote. The problem…

Reminds me of a manager and a QA I once knew. QA was a nice guy, but a terrible QA. Would fail stories on the most arbitrary guidelines. Story is about changing the font size on the home page? He'd fail it because he wasn't able to log in (he tested while the auth service was undergoing planned maintenance). Manager loved this guy, and pushed him through several promotions. Eventually other employees got tired of bei…

people get promoted based upon their ability to conform to management culture, and their ability to deliver outcomes; in most places the former is far more important than the latter but not always

Re: The Worst Programmer I Know (2023)

#332

Post by Yoric »

NitpickLawyer wrote: post #308
Yoric wrote: post #303

Earlier quoted context omitted.

We're talking about vibe coding, not just AI-assisted coding. Do you put this in production without review?

Oh, my bad, and TIL. I thought vibe coding is the trendy way of saying you're using LLM based code in tools like aider/cline/cursor/windsurf... edit: So I did a quick google, apparently it's this: > Vibe coding is an AI-dependent programming technique where a person describes a problem in a few sentences as a prompt to a large language model (LLM) tuned for coding. The LLM generates software, shifting the programmer’…

Well, when Karpathy introduced it, I seem to recall he claimed that he didn't look at the code, just put it in production.

But it's entirely possible that there may be several definitions around by now.

Re: The Worst Programmer I Know (2023)

#333

Post by mystified5016 »

ryandrake wrote: post #56
JohnMakin wrote: post #9

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…

I'm actually shocked that Tim, himself, knowing the metric exists and was going to be used in firing decisions, did not attach himself to all these tickets in the first place. Talk about a lack of self-preservation. Everywhere I've seen that measures performance by some metric, everyone instinctively tries to pump that metric all by themselves. No other motivation required.

I consider myself a Tim here. My value is not primarily in my individual contributions, but how I eleveate the rest of the team.

If my manager demanded this type of bean counting, I'd just take my talents elsewhere. I'm not interested in that kind of game. I'd take the severance and go find a new team to make better.

Re: The Worst Programmer I Know (2023)

#334

Post by xdavidliu »

red-iron-pine wrote: post #331
paradox460 wrote: post #181

Earlier quoted context omitted.

Reminds me of a manager and a QA I once knew. QA was a nice guy, but a terrible QA. Would fail stories on the most arbitrary guidelines. Story is about changing the font size on the home page? He'd fail it because he wasn't able to log in (he tested while the auth service was undergoing planned maintenance). Manager loved this guy, and pushed him through several promotions. Eventually other employees got tired of bei…

people get promoted based upon their ability to conform to management culture, and their ability to deliver outcomes; in most places the former is far more important than the latter but not always

the former is often easier to measure than the latter, and the latter is often only measurable when superficial.

Re: The Worst Programmer I Know (2023)

#335

Post by xdavidliu »

suzzer99 wrote: post #107
morsecodist wrote: post #94

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.

> The second you try to measure it, the wave function collapses, and you've fundamentally altered the thing you were trying to measure.

Related to Goodhart's law: "When a measure becomes a target, it ceases to be a good measure".

I'm wondering if this is only true if the act of measurement is transparent (so that the people being measured can game them). If the act is opaque enough such that the form of the metric cannot easily be guessed SEO-style, then maybe wave function collapse can still be avoided?

Re: The Worst Programmer I Know (2023)

#336

Post by lapcat »

motorest wrote: post #329
lapcat wrote: post #89

Earlier quoted context omitted.

> I don't think your opinion is educated, or based on any experience working on a functioning team, let alone a high-functioning one. That's an incredible assumption about me. What is your empirical justification for such an insulting claim? > Any team working on non-trivial projects does stumble upon critical bugs that are hard to catch or features that are faster to roll out if a subject matter expert sits down wit…

> That's an incredible assumption about me. Not really. You introduce yourself to the world by the statements and opinions you express. Advocating for firing everyone in a hypothetical team because of a hypothetical scenario where hypothetical team members help each other out is a business card of your level of experience, expertise and awareness.

> Advocating for firing everyone in a hypothetical team because of a hypothetical scenario where hypothetical team members help each other out

That's not the hypothetical scenario described. Rather, the hypothetical scenario is that all of the other engineers are in constant need of babysitting by the one adult in the room, Tim. There was no indication given that, other than Tim, team members are helping out "each other", or that anyone else is helping Tim. If the team members are peers, then why is Tim disproportionately pairing, 100% of his time?

Re: The Worst Programmer I Know (2023)

#337

Post by natnatenathan »

JohnMakin wrote: post #9

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…

Tim's problem is that he has a bad manager. One of a manager's core jobs is to communicate upwards the value that each team member is providing (or not providing). His job was to ensure that Tim's contribution were reflected and visible.

Re: The Worst Programmer I Know (2023)

#338

Post by rurp »

I worked at a company with very similar performance metrics and it was as counter-productive as you would expect. The surprising thing is that the management wasn't that bad overall but they worshiped at the altar of data and metrics for everything. That works great for some things, but not everything.

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.

Re: The Worst Programmer I Know (2023)

#339

Post by rpmisms »

milesrout wrote: post #296
rpmisms wrote: post #248

Earlier quoted context omitted.

My dangerous opinion is that the purpose of a company is to provide a living for its employees.

That isn't dangerous, just ignorant.

It's not ignorant, it's a different perspective on priorities that is outside your orthodoxy.

Re: The Worst Programmer I Know (2023)

#340

Post by OnionBlender »

mx_03 wrote: post #242
OnionBlender wrote: post #108

Earlier quoted context omitted.

I had a director that was obsessed with github enterprise stats. He forbid people from squashing commits and told people to commit every day, even if you're in the middle of something. This was so that he could see who was writing the most code. One of our interns was close to the end of his term and this director wanted to hire him. He thought the intern was amazing based on the amount of code he wrote. The problem…

> The problem was that this intern was bad, so we had him write unit tests. Please tell me you assigned this person a "increase code coverage" task and not "I wrote a new feature, write the unit tests for it" task

Yes, it was an "increase code coverage" task. The same director wanted 100% code coverage so I had the intern write tests for existing code that didn't have many tests.
Post reply on HN