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

311–320 of 385 posts

Re: The Worst Programmer I Know (2023)

#311

Post by crazygringo »

wavemode wrote: post #215
crazygringo wrote: post #205

I agree with a couple other comments here -- this is a bizarre model where one programmer does no individual work and does all the helping. A much healthier situation, to me, is one where Tim does stories like everybody else, and when people need help they ask the group and whoever is the best at that thing helps them -- or whoever hasn't helped in a while. Surely there are easier stories for those who need the most…

> shouldn't they just be a special kind of team lead who is expected to mentor full-time and not be subject to metrics? It sounds like this was precisely the situation, and the author's company did indeed take this very action, in response to seeing the data. So, what is your complaint?

No they didn't. They dropped the metrics for everyone entirely, and Tim's job title is unchanged. The article is arguing metrics are bad and shouldn't be used; I'm arguing metrics are a valuable signal and Tim should have been given a different formal role of mentor.

Re: The Worst Programmer I Know (2023)

#312

Post by crazygringo »

move-on-by wrote: post #243
crazygringo wrote: post #205

I agree with a couple other comments here -- this is a bizarre model where one programmer does no individual work and does all the helping. A much healthier situation, to me, is one where Tim does stories like everybody else, and when people need help they ask the group and whoever is the best at that thing helps them -- or whoever hasn't helped in a while. Surely there are easier stories for those who need the most…

> when people need help they ask the group and whoever is the best at that thing helps them -- or whoever hasn't helped in a while. I agree this would be healthy for an organization, but I don’t think that is often possible. In this example, the organization is clearly NOT tracking mentor activity. So, anyone who helps someone else, is getting zero recognition for it. I work with a lot of people where ‘ruthless prior…

> So, anyone who helps someone else, is getting zero recognition for it.

Where I've worked, this is what 360 peer review during performance reviews is.

If your colleagues all say you're super-helpful, that's part of what it takes to get promoted.

If your colleagues all say you're selfish and never help out, this is something that needs to be addressed immediately.

It's a metric like any other, it's just collected twice a year rather than bimonthly, and it's qualitative rather than quantitative. But it's analyzed at the same time and given lots of weight when it comes to promotions.

Re: The Worst Programmer I Know (2023)

#313

Post by johnnyanmac »

crazygringo wrote: post #205

I agree with a couple other comments here -- this is a bizarre model where one programmer does no individual work and does all the helping. A much healthier situation, to me, is one where Tim does stories like everybody else, and when people need help they ask the group and whoever is the best at that thing helps them -- or whoever hasn't helped in a while. Surely there are easier stories for those who need the most…

>this is a bizarre model where one programmer does no individual work and does all the helping.

Sounds like a lead or manager. He definitely works like a lead in spirit. Cheaper for the company to delineate it like this.

>Surely there are easier stories for those who need the most help, and Tim should be taking on the hardest stories by himself?

difficulties don't signify priorities. Maybe all the hard stories are low priority. Maybe the energy is focused on onboarding newer hires. Maybe there was a semi-looming headline and getting others' tasks done was more important than his individual module (or perhaps he was ahead of pace already).

I can see a dozen of scenarios this comes up in organically. I experienced a few of these firsthand.

Re: The Worst Programmer I Know (2023)

#314

Post by NightSquirrel »

There are 4 methods of determining developer quality: Empirical metrics which can be misleading, or gammed. Team consensus which can devolve into a popularity contest. Manager "impression" which can be manipulated with strong people skills and "impression management", or letting an AI algorithm decide who is the most productive. No evaluation system is perfect and most are very flawed which is why management is both an art and a science and those that can do it well are very rare and in very high demand and therefore often deserve the compensation they receive.

Re: The Worst Programmer I Know (2023)

#315

Post by kevincox »

NightSquirrel wrote: post #314

There are 4 methods of determining developer quality: Empirical metrics which can be misleading, or gammed. Team consensus which can devolve into a popularity contest. Manager "impression" which can be manipulated with strong people skills and "impression management", or letting an AI algorithm decide who is the most productive. No evaluation system is perfect and most are very flawed which is why management is both…

> an AI algorithm

In reality this is just some secret combination of the above metrics (assuming there are no "bugs", which there surely are).

Re: The Worst Programmer I Know (2023)

#316

Post by johnnyanmac »

Vampiero wrote: post #44
lapcat wrote: post #32

Earlier quoted context omitted.

> If you can unblock yourself by having a team member sit besides you and walk through a problem, that team member will be helping the team. I don't dispute that; hence the 20-30% pairing. But if it's the case that all day, every day there's at least one person on the team who is blocked, then you don't need a "Tim", what you really need is a new team, because that's an unacceptable level of blockage.

It's cheaper to hire 5 juniors and to give Tim a mental breakdown than it is to hire 5 Tims. Realistically though, if you really did hire 5 Tims you would deliver in 1/5th of the time and the software would actually be decent on the first iteration. It seems to me that consultancy companies actually want inexperienced developers because they can bill their inexperience to the client as they train them to become usefu…

>if you really did hire 5 Tims you would deliver in 1/5th of the time and the software would actually be decent on the first iteration.

depends on how the tims mesh. Every company thinks that hiring only experts leads to a superior product, despite software being a collaboarative effort.

>I didn't become a senior by being mentored by other people, btw. I became one because I've always loved doing what I do, and nothing more.

The good mentors I had definitely helped. If anything, they reeled me in to realizing that being a good SWE is not about solo diving into problems and expecting to come out with solutions everytime. It's to understand who owns what and who to consult when landmines inevitably come up. Even if I could solve it all by myself it just wastes time compared to a quick Slack message or a 15 minute meeting.

Re: The Worst Programmer I Know (2023)

#317

Post by johnnyanmac »

iamleppert wrote: post #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…

Most of us work in decade+ legacy code made from a lot of people who are no longer at the company. So most of the code is brittle by default. That's simply the trend that emerged from a workforce that stopped incetivizing retention.

As such, I'd argue that 80+% of your problem solving for the first few years (AKA the only years before you hop or get laid off) is in fact asking other people what the quirks of the code-base are. Maybe that is bad, but it doesn't seem like the retention culture is shifting anytime soon.

Re: The Worst Programmer I Know (2023)

#318

Post by lo_zamoyski »

linsomniac wrote: post #250
hi_hi wrote: post #221

Earlier quoted context omitted.

Reminds me of an old joke about a policeman who pulls over a poor driver. The driver complain "But I haven't been in a single accident", the reply from the policeman, "Yes, but you've caused dozens". Some people are just oblivious to the trail of destruction left in their wake.

“Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactica…

In other words, the "10x programmer".

Re: The Worst Programmer I Know (2023)

#319

Post by johnnyanmac »

snapetom wrote: post #161
andix wrote: post #131

The title should be: Why measuring developer productivity by story points is bad. I was once part of a team that had a zero-storypoints developer too, let's call him Zero. He always refused to get any stories assigned during planning, his goal was always zero. He felt responsible for delivering all the planned stories and helped the people who struggled. He often came to me and told me to help someone on a specific t…

Wouldn't Zero be a hero in disguise, then? When I hear stories about Tim or Zero, it makes sense... with the caveat of whether they are actually transferring knowledge to teammates, and whether the other team members are capable of taking over the function of Tim/Zero. If not, then Zero is just covering for low performers, and your bus factor is still a liability.

In Zero's case, it sounds more like there is knowledge transfer but there's this cult of personality from management's perspective. Almost the opposite of Tim.

It can be scary, but you gotta pass the torch at some point and accept there will be turbulence compared to Zero smoothing out the landing. That's how you get future Zeros/Tims who very likely had their own turbulence to handle.

Re: The Worst Programmer I Know (2023)

#320

Post by ignoramous »

lo_zamoyski wrote: post #318
linsomniac wrote: post #250

Earlier quoted context omitted.

“Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactica…

In other words, the "10x programmer".

Not really; as a 10x programmer, to some, improves outcomes by 10x regardless of the team members and project status, but LLM and agents built on it, may soon qualify.
Post reply on HN