1 yr. ago • 94%

The Worst Programmer I Know

dannorth.net The Worst Programmer I Know

The great thing about measuring developer productivity is that you can quickly identify the bad programmers. I want to tell you about the worst programmer I know, and why I fought to keep him in the team.

TechNews @radiation.party [HN] The Worst Programmer

Hacker News @derp.foo The Worst Programmer

48 comments

I don't like this story. The outcome is only accidentally good and what the author seems to miss entirely is the elephant in the room: A crass failure to communicate with the developers. If you try to establish something like KPIs (not commenting on if that is good or bad here) you need to talk to the team and get them on board. If you treat them like lab rats and try to measure individual performance from the outside that is an obvious fail. In the end, where they state that they "quietly" dropped it, indicates that the real lesson was not learned.

Uh, and a dilbert comic.

70
- Permanently Deleted
  
  21
- Uh, and a dilbert comic.
  
  ?
  
  1
  
  Scott Adams is a raving lunatic.
  
  Here's a resonable summary: https://rationalwiki.org/wiki/Scott_Adams
  
  You can also check out his blog directly.
  
  4
  
  https://www.npr.org/2023/02/26/1159580425/newspapers-have-dropped-the-dilbert-comic-strip-after-a-racist-rant-by-its-creat
  
  Enjoy
  
  2
Story points and velocity always felt to me like a flawed metric. It encourages volume of work, and discourages quality of work. The worse your code is, the more stories and tasks you can create to fix it, and the higher your velocity. It's a bit of a shame that it's used so widely as a measurement of work completed, and I wish a better means of measuring productivity would become more popular instead.

38
- It's not flawed. Nobody should get rewarded or encouraged by story points. It's solely a planning metric and not a metric of productivity.
  
  28
  
  I guess the flaw is that it's (almost) never used only for planning and is often used as a metric of productivity, from my experience. It becomes a competition to see who can check off the most story points, and velocity is often used to compare developers against each other.
  
  6
- Story points are meant to have a shared understanding about complexity during the planning phase. There where never meant (and do not fit) for either capacy planning or to measure the throughput.
  
  If your PO is using this he or she is either not well informed and/or uses this as a tool to create toxic pressure.
  
  7
Darn. I went into that article hoping to hear a hillarious article about some coder who insisted on using only his self-written buggy bubble sort implementation rather than the sort methods in the standard library or who they couldn't get to quit deleting necessary features from the codebase.

Good story even so.

32
- Have you heard about JDSL?
  
  18
  
  There's no way this is real. Completely insane.
  
  4
  
  ....What The Fuck.....I...I can't
  
  3
  
  What the actual fuck. It's a made up story I'm sure.
  
  1
Not sure why this post doesn't have a ton of comments. It illustrates the fundamental problem with KPIs and performance measurement. When it comes to measuring human production with digital tools, because the binary measure is so restrictive, it leaves out a universe of values and information that is just ignored as a result. And this very often has dramatic consequences.

29
- Posts tend to generate a lot of comments by:
  
  being funny, spurring people to try to be funnier (usually failing); or,
  
  by being interactive, spurring people to answer a prompt in the premise of the post; or,
  
  by being controversial, spurring people to argue.
  
  This isn't particularly funny or interactive. And it's not very controversial either; I think most programmers will agree with this premise.
  
  19
  
  Did my best with #3 but I continue to suspect most of the people in these fediverses are very young and therefore inexperienced.
  
  I've stated an opinion that aligns with what I've read in the hacker news discussion and the responses are aggressive.
  
  Cargo cult is strong here. No discussions will form while the ditto heads carry the majority.
  
  -3
- Myopic decision-making is a standard human fault. The problem is that some Deciders have wildly disproportionate effects on everyone else. (i.e. leadership roles across business and government)
  
  We can’t fix individual ignorance and prejudice to a level that will resolve the issue, so maybe we need to invest our efforts in forcibly distributing power to make sure one person (or a small group) can’t unilaterally ruin thousands or millions of lives.
  
  8
- Most experienced developers already agree with you
  
  8
And here i am, striving to become like tim in my professional life ( + being tech lead ). People like that are undervalued assets in any team

11
This is too simplistic in the opposite direction.

What is with the team that Tim is only pairing.

Are they constantly hiring? Are the hires bad?

If Tim unable to transfer his knowledge, basically holding their hand, making bad hires look worth keeping...he's actually hurting the company.

If Tim is not increasing their solo performance then something is wrong.

-8
- You misread that entire thing. It's not that the team was bad, or that there was any significant turnover. Nor is Tim unable to transfer his knowledge, since that's not the point of what he does.
  
  He's a sounding board. A sober voice asking the right questions when you've got your head down hyperfocused on a problem. Someone to talk to just to make sure you're on the right track, even though you were pretty sure anyways. The team would still perform without him, but he improves their quality and performance just by standing in for the duck and actually asking the right questions. It's a very subtle, very delicate job. Not everyone can do it. That's why they keep Tim on the team.
  
  14
  
  I understand the justification.
  
  I am not convinced.
  
  There is zero evidence that the team performs better or worse since at no point did Tim stop being Tim. There is no base line.
  
  If Tim had tried to pick up some points and the result was the rest of the team stumbling, that would be one thing. Tim didn't, he kept doing his own thing because his team lead is afraid of Tim.
  
  Tim should be fired.
  
  -5
- It just sounds like Tim was no longer a developer and should have a manager title, as he was training and teaching and on boarding all the time.
  
  If his title was no longer developer, because he wasn't doing any development on his own, said metrics wouldn't apply to him anymore, and the issue would be resolved in a reasonable way.
  
  9
  
  That was a common sentiment on the hacker news discussion on this story.
  
  I don't disagree.
  
  2
- You never heard of pair programming?
  
  With juniors Tim would pretty much be training them and nudging them on to write better code.
  
  With seniors, like the short article says, it's more a sparring match, trying to find the best solution. You also find a lot of edge cases when someone else works with you together.
  
  I haven't been in a company yet where they have a full time floating position for pair programming, but if it's a senior doing it I can see how it's very beneficial for product quality.
  
  6
  
  Tim should be fired for insubordinate and his lead should be fired for protecting him.
  
  I get that every shit developer thinks they a Tim or aspires to be one but Tim is a lazy developer doing the fun parts without producing.
  
  Everyone here is assuming Tim is something because you've told he is by the lead.
  
  It's troubling.
  
  -11

You've viewed 48 comments.