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

201–210 of 385 posts

Re: The Worst Programmer I Know (2023)

#201

Post by jimbokun »

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

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…

This story tracks pretty closely with the Dilbert cartoon in the article. Except unintentionally.

Re: The Worst Programmer I Know (2023)

#202

Post by jimbokun »

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

> who was writing the most code There's yer problem right there. Code quantity is not correlated with value. In fact, it can be negatively correlated with value if it's buggy and laden with technical debt. Measuring productivity by lines of code produced actively discourages writing clean, maintainable, bug-free code.

I’m getting a similar sense from many of the AI “success” stories we’ve been hearing. There’s amazement about how many lines of code the AI produces in a short amount of time.

But not so much about maintaining and debugging all those lines of code once they’re created.

Re: The Worst Programmer I Know (2023)

#203

Post by jimbokun »

hamburglar wrote: post #198
__turbobrew__ wrote: post #182

Earlier quoted context omitted.

> 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 Yea, in the current place I work at we do not measure coding performance metrics, but if you look at the top commiters to the repo — by number of commits — you will see all of the people who bring the most value to the company. Even at staff eng the best engineers are still the ones…

At my last gig I spent the last year and a half as staff engineer and made almost no commits because I was constantly writing proposals, defending them to execs, doing architecture reviews, doing design consultations, and planning long term responses to large incidents. I know for a fact that I brought a ton of value to the company but it was very uncoupled to commits. I didn’t really like it because I need to code,…

Just check all of your proposals and design documents into source control, and you’ll still have plenty of commits!

Re: The Worst Programmer I Know (2023)

#204

Post by paradox460 »

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

I think just about everybody has had to deal with one or several of these guys.

Much as cancer arises and grows from natural cellular processes gone awry, this seems to be an organizational cancer, present in any company of a large enough size.

Re: The Worst Programmer I Know (2023)

#205

Post by crazygringo »

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 help, and Tim should be taking on the hardest stories by himself?

Or if you really do have an insanely lopsided team where everyone is straight out of school with no experience, and a single super-senior dev, then... shouldn't they just be a special kind of team lead who is expected to mentor full-time and not be subject to metrics?

The post here is not a good example at all of metrics failing to capture work. In reality, it is surfacing the fact that either Tim's job title and metric are totally wrong for him individually, or else that Tim is failing to contribute the hardest code, and the team is failing to distribute the "helping" workload. In both cases, the metric is working as intended, and it is surfacing something very important than needs to be fixed. (Remember, "fire Tim" is not the only possible action you can take because of a metric.)

Re: The Worst Programmer I Know (2023)

#206

Post by eek2121 »

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

> What you want is measuring business outcomes but those are hard to attribute to a particular developer. I think we could solve this by eliminating some middle tiers and putting the developers on the actual customer calls every week. Each senior developer owns at least one customer. That sort of thing. It's a completely different ball game when you are a developer on some B2B/SaaS and you are answering directly to t…

lol no, I have worked with companies that do that. Many developers have very specific personality types, and they also think in technical terms rather than customer terms. It isn’t a bad thing, it is why they are good at what they do.

The most successful companies I have worked with have a good product manager that can take customer input and work with a technical manager to balance priorities/effort. The technical manager consults the team before making decisions (such as SCRUM meetings if using that)

Issues come into play when folks start distrusting developers. When we say it will take 4 weeks or 8 weeks to implement something, there is a reason for that. We know the code. We know how much of a PITA it is to work with, and we aren’t being misleading. On the flip side, we have been trained to give conservative estimates thanks to crap management and unexpected pitfalls, so we try to understand promise and over deliver. If management could recognize this, everyone would be happy, provided they recognize that 8-week timeline is fine and they don’t promise something different to the client and trust devs to do their thing.

EDIT: Managers also tend to forget that we aren't a machine in a factory. We have good days, bad days, and everything in between. We excel with using our brains, however our brains suffer from anything between lack of sleep, depression, and other nonsense due to just plain having a bad day. I feel like it is more noticeable with us because we rely on our brains so much more than other folks in other professions do. Shoot, even random noise in an office, whether working at home or at an office, can hurt productivity.

Now I have myself missing dev work. Hoping to go back soon. Currently unemployed.

Re: The Worst Programmer I Know (2023)

#207

Post by rvba »

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…

Well, I seen a fair share of "blind" programmers who just did their (very limited) scope, perhaps they did it well... yet the whole tool just didnt work and nobody cared.

I imagine that if the guy pointed out things like this - he wasnt popular with the developmemt team, but popular with management and users.

Re: The Worst Programmer I Know (2023)

#208

Post by philjohn »

suzzer99 wrote: post #151
lolinder wrote: post #133

Earlier quoted context omitted.

> 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 works for Junior through Senior level roles, but it falls apart quickly when you have Staff+ roles in your company. Engineers in those roles still code, but they write a fraction of what they used to and that is by design—you want these people engineering entire initiatives, integrations,…

Yeah, I've always worked at non-tech companies with pretty small teams and no roles like that. But it seems like any place with Staff+ engineers should know better than to try to stack them up against more junior devs based on some metric.

Case in point, I worked with a Staff software engineer (I was also the same level) who consistently, half over half, had zero diffs to their name.

Because they were leaning more into a product archetype - which it turns out they were very suited to.

Re: The Worst Programmer I Know (2023)

#209

Post by asdf6969 »

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

I think just about everybody has had to deal with one or several of these guys.

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

Average offshore QA team.

Re: The Worst Programmer I Know (2023)

#210

Post by slowtrek »

trelane wrote: post #199
thesuperbigfrog wrote: post #168

Earlier quoted context omitted.

> Code quantity is not correlated with value. In fact, it can be negatively correlated with value if it's buggy and laden with technical debt. ** "No Code" or Nihilist Software Engineering ** No code runs faster than no code. No code has fewer bugs than no code. No code uses less memory than no code. No code is easier to understand than no code. No code is the best way to have secure and reliable applications. Write…

This is an amazing collection. Thanks for it. It's is exactly what I was needing for this slide deck on I'm writing how to improve our code.

a) Would make a great coffee table book.

b) Would make a great poster.

Post reply on HN