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

91–100 of 385 posts

Re: The Worst Programmer I Know (2023)

#91

Post by bee_rider »

grayhatter wrote: post #82
bee_rider wrote: post #59

Earlier quoted context omitted.

It seems hard for us to say, from the outside, how the deal ended up for them. They spent the experienced programmer’s time setting up a team of five. If they’d had GP train one person and work on code as well, they’d have one good new engineer and some code. Now they have five good new engineers. I mean, it depends on how long it took, how much code GP could have produced in the meantime, and how sticky the lessons…

this particular company paid way below market rate with the promise of interesting work. It without a doubt incentivizes hiring new grads where you roll the dice and hope the good ones will stay because they enjoy the job. It's very hard for them to attract experts at the salary that they're offering.

Yah. I also just wanted to make the meta point or whatever—this is your anecdote, technically there’s room for you to be wrong or right, but we don’t have any connection to the underlying reality to argue against your interpretation… so why not just go along with your story?

Re: The Worst Programmer I Know (2023)

#92

Post by lapcat »

grayhatter wrote: post #78
lapcat wrote: post #61

Earlier quoted context omitted.

> yeah, what the company should have done, is only hire experts! I did not say that, and you know it: "What the company should have done is hire you and one new grad (rather than five)". > I won't work for an MBA bean counter. I want to work for a company that's willing to invest in people. Um, IMO someone who hired a team of 5 new grads sounds like an MBA bean counter and not someone that's willing to invest in peop…

> Um, IMO someone who hired a team of 5 new grads sounds like an MBA bean counter and not someone that's willing to invest in people. It sounds like they brought in an experienced programmer (you) only because the preexisting pathological team was (predictably) failing. Nah, this was a pet project of my skip level, and I joined after he asked my boss for solutions to the delay. The manager who owned the project had a…

> they were assigned because it would have been malpractice otherwise.

I don't know understand this means.

> This was very much a team built out of the resources available, rather than intentionally selecting only new grads.

Yet your other comment says, "this particular company paid way below market rate with the promise of interesting work. It without a doubt incentivizes hiring new grads where you roll the dice and hope the good ones will stay because they enjoy the job. It's very hard for them to attract experts at the salary that they're offering." https://news.ycombinator.com/item?id=43453700

> it being an internal project, it would have been killed once it had no active development.

I'm having a hard time understanding why this project needed to exist at all.

> But taking something to the extreme to see where it fails is a useful rhetorical tool.

I disagree, and it only created unnecessary argument in this case. You ended up having to retract and clarify anyway:

> I think 5 noobs to 1 expert is fine, just like 5 to zero is bad

But the team was 5 to zero.

> just like 1 to 1 is bad.

Why?

Re: The Worst Programmer I Know (2023)

#93

Post by dmoy »

Yea the best teams I've ever been on have always had someone like Tim.

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

Re: The Worst Programmer I Know (2023)

#94

Post by morsecodist »

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

Re: The Worst Programmer I Know (2023)

#95

Post by franktankbank »

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.

Play the game and any number of management fuckends will prop themselves upon your shoulder. Unless youre into that sort of thing.. no judgment..

Re: The Worst Programmer I Know (2023)

#97

Post by mrbadguy »

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…

Well said. There’s a noticeable lack of judgement in many places these days; people think they can abdicate it to metrics and data but this is mistaken.

Re: The Worst Programmer I Know (2023)

#98

Post by tpmoney »

_fat_santa wrote: post #36

Honest Question: Are there any metrics around developer productivity that actually work? Reading stories like this and others over the years I've come to the conclusion that you simply can't measure developers productivity on a granular level, it's just about the final product. However, I would love to be proven wrong.

I don't think there are realistically any good "individual" productivity measures that work across a broad spectrum of employees, even when all of those employees are in the same role. Every team I've ever been a part of, even before being a developer has been made up of people that all contributed to the overall project in different ways. Imagine trying to measure all workers on a car assembly line by the number of screws they insert per day, or the number of welds they make per day. Anyone who's primary job on the line isn't inserting screws or making spot welds is instantly a low performer by this metric, and yet you can't assemble a complete car with only screws and welds. And it's worse I think in something like software development, where the specific way a team member contributes might be more nebulous. Very rarely do you hire someone just for their code review skills or the design capabilities. The team member that somehow always manages to recall the tiniest of details about the system that no-one else recalls from the feature work done 5 years ago is not exactly a skill you can find on a resume or even one you could build a good metric for even if you had hand tailored metrics for all employees.

And it's a hard problem to solve. I don't envy the job of anyone in management trying to figure out how to determine who (if any) of your employees is a drag on the team. Sometimes it's obvious and there are concrete problems, but other times it's just someone "everyone knows" is a drag, but without hard metrics, you're left with awful things like having employees stack rank each other.

Re: The Worst Programmer I Know (2023)

#99

Post by jrs235 »

NalNezumi wrote: post #20

Glad to hear that Tim stayed and author managed to steer the entire process towards the right direction. Which requires a listening manager. 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 (So…

100% this. Want to sacrifice team output? Have team members be concerned about individual goals. Team alignment and synchronization will be off affecting the efficiency and effectiveness of that team's performance.
Post reply on HN