Live data from Hacker News

The worst programmer I know

dannorth.net

121–130 of 668 posts

Re: The worst programmer I know

#121
DORA seems ok as a big company framework, where different teams of similar sizes can be roughly compared using the scores, and the CIO or CFO can have some satisfaction about being able to avoid spending money on non-producers, without engineers feeling like they're being individually spied upon. Without this accountability, engineering managers may let non-performers coast for a variety of reasons.

For small companies, engineering managers & direngs should be aware enough through working with the team members individually & through PR review who is performing and who isn't, and not need to deploy metrics.

Re: The worst programmer I know

#122

Earlier quoted context omitted.

Because it's a bogus argument. The productive person doesn't need a paper weight at lunch to act as a shower thought generator. Management can get it wrong sometimes, but in broad strokes, they're right.

Define "productive". Because lins of code churned out is not and has never been a good measure of productivity. That "shower thought generator" might very well be more productive than the person they're sitting next to churning out tens of thousands of lines of unmaintainable code if their shower thoughts are causing people to find better ways to solve a problem. Which is basically the entire point of the article.

why? most code is not some complex algorithm where 100 lines of code can take years of genius work to figure out. Unit tests, for example, have near linear proportionality between LOC and utility. Same for comments, same for standard business logic.

Re: The worst programmer I know

#123
post #61

> He would not crowd them or railroad them, but let them take the time to learn whilst carefully crafting moments of insight and learning, often as Socratic questions, what ifs, how elses. I do not like people who do this. just tell me the answer. this is such a gigantic waste of everyone's time. you figured something out months/years ago, great for you. give it to me NOW, so I can get on with my day. if we BOTH run…

Quite simply, no. You're not going to learn from being handed an answer on a silver platter. You'll implement it, get on with your day, and not at all think about why the answer is what it is.

> You'll implement it, get on with your day, and not at all think about why the answer is what it is.

this is an incorrect assumption. some people (like me) have an analytical mind. if I am given an answer, I will usually reverse it back to the question, so that I understand how it came about. or I will ask follow up questions until I have that understanding.

all this method is doing is forcing multiple people to go through the discovery process, when all that should be needed is for one person to do so. its a waste of business resources. person A can share with person B, then person B can go on to make their own discoveries. we dont need to force every employee to discover EVERYTHING on their own. thats just a huge waste of time. it would be like forcing everyone to discover Pythagorean theorem on their own, instead of giving them that tool and letting them use it to create other stuff.

Re: The worst programmer I know

#124
I wish I could pair program more. I have so much knowledge to give other members of my team. Domain knowledge, programming knowledge, common pitfalls, etc. You get a code review pass at the time of writing the code, and it means you have more opportunity to change things for the better. Once it's written there's not much appetite for drastically changing working code during code review unless there's a really good reason.

But it's usually contained to someone like a junior calling me up and saying "can you help me?". The answer is always "yes of course!" and I share as much as I possibly can. But it ends there.

I just want to sit down and show them things. Teach them in a way that makes things "click" the way I found they clicked with me. But I don't think management really values this approach. We get siloes of knowledge and then when someone leaves it's all hands on deck to transfer that knowledge.

I'm often brought onto projects as a firefighter because I'm seen as productive. But I think the more important thing for the team would be to have me upskill everyone else below me. But for whatever reason, it's hard to get that point across to management. I can see myself in a few people and that they have potential, they just need encouragement.

Re: The worst programmer I know

#125
post #2

I sometimes wonder if developers should do an end run around all this bullshit and come up with and start measuring management productivity metrics. I dont see a downside to doing this.

How would coming up with good metrics for "management" be any easier than coming up with good metrics for "programming"? At least programming has some verifiable realities that can be witnessed objectively by multiple observers. Not that such things are often used on "metrics", but they could be. The quality of someone's management is hard to assess from outside, much less objectively verify. Has your manager increas…

That's exactly my point. Managers who protested the use of metrics on them would inadvertently undermine the argument for using them on developers.

Measuring is an aggressive act intended to invoke control that has a veneer of innocence.

That said I'm now wondering if there wouldn't be some metrics which might prove useful to workers either way.

Re: The worst programmer I know

#126

Earlier quoted context omitted.

Define "productive". Because lins of code churned out is not and has never been a good measure of productivity. That "shower thought generator" might very well be more productive than the person they're sitting next to churning out tens of thousands of lines of unmaintainable code if their shower thoughts are causing people to find better ways to solve a problem. Which is basically the entire point of the article.

It's more about measuring outcomes. We have a goal, did we meet the goal. There are many paths to the goal, so measuring things like lines of code is incorrect. But so is measuring Bob's ability to ask Alice a good question. Management can't, at scale, consider such factors. We don't have the counterfactual where Bob didn't ask the questions, and Alice did great anyways. Performance reviews would become even more sub…

The part that's often missed is the future outcome, when someone returns to this code to fix a bug or add a new feature. I believe it's incumbent upon those of us with some experience to ensure maintainability is part of the considerations.

Re: The worst programmer I know

#127

It sucks being that person today because everything is about optics and that person will get purged. I know from experience. Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently wr…

The saddest thing is that some bosses want throwaway code. I had a short stint once in a company where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion. He would hire a 5000 LoC per week hero on the spot.

It depends on “when” along the timeline of the project.

If we don’t know if anyone will want the product, the quality of the product is less valuable than validation of product market fit.

Later, I care much more about avoiding accidental complexity and having a great technical foundation.

Re: The worst programmer I know

#128
post #38
post #25

Earlier quoted context omitted.

It might be from the great book The Idea Factory by Jon Gertner (p 135). 'In the midst of Shannon’s career, some lawyers in the patent department at Bell Labs decided to study whether there was an organizing principle that could explain why certain individuals at the Labs were more productive than others. They discerned only one common thread: Workers with the most patents often shared lunch or breakfast with a Bell…

The most impressive thing about this story is that they figured out the answer . They did the research, and nailed down that it was Nyquist who was was the productivity booster. It’s the exact opposite of the OP’s story, where management tried to fire the Nyquist-equivalent.

They found an answer that felt right to them. The reseachers weren't blinded to the context they were working in, and their hypothesis is essentially unfalsifiable so I would take it with a grain of salt.

Re: The worst programmer I know

#129

It is also possible if they fired this guy, and replaced him with another developer that only did points that the organization would be more productive. Without quantifying it or comparing to an alternative, this is just feel good commentary. If you deliver any value, that does not consequently make you a good business decision. You have to pit your value against your cost and the companies best alternative option. A…

Your last paragraph just said that if you hire people and tell them their earnings depend on $METRIC they will optimize said metric.

The argument here is which metric, or are metrics good for anything? [1]

[1] Except ditch digging and children. It is well known that 9 people will dig a ditch in 1/9 the time one person will, and 9 women will make a baby in 1 month instead of 9.

Re: The worst programmer I know

#130

It sucks being that person today because everything is about optics and that person will get purged. I know from experience. Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently wr…

> Managers always love a developer who can consistently write 5000+ lines per code per week

Managers love metrics. There's nothing wrong with metrics, of course. It's when metrics become targets that things fall apart.

https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

Post reply on HN