Live data from Hacker News

The Worst Programmer I Know (2023)

dannorth.net

341–350 of 385 posts

Re: The Worst Programmer I Know (2023)

#341
post #325

Earlier quoted context omitted.

It only appears that HackerRank/Leetcode isn’t good at filtering because you’re viewing it from your perspective, and not the perspective of the entire population that is tested. To you, the predictive power at the top tail end of the distribution is low, because you’re thinking of two strong developers Alice and Bob. Alice happens to know algorithm X and would pass the test, whereas Bob does not. But that’s not the…

> It’s absolutely fantastic at filtering the lower 95% of applicants because they will _never_ be able to pass. This is the part I disagree with. It hasn't been true for years. Anyone with the free version of ChatGPT can pass a hacker rank today. > but that doesn’t matter to the outcome of your company It does for mine, because we've hired all of the good developers that get through the process you're describing and…

> This is the part I disagree with. It hasn't been true for years. Anyone with the free version of ChatGPT can pass a hacker rank today.

It certainly still is true today. Anybody who is sufficiently motivated to cheat can pass it. It was true prior to ChatGPT, and it still remains true today. And yet they don’t. Most people completely fail these screens

> It does for mine, because we've hired all of the good developers that get through the process you're describing and it isn't enough.

Then your industry is atypical in the type of applicants that you are getting. So to accommodate you’ve had to increase your false positives to reduce false negatives. That’s completely fine if it’s what you need to do, but it’s not the typical experience for a tech company.

We also do a pair screen after the code test and we still reject around 80% who make it to that stage. How do you scale interviewing everyone if you don’t pre screen?

Re: The Worst Programmer I Know (2023)

#342

Earlier quoted context omitted.

> Some things that don’t measure whether a developer is “good”: > # LoC added, changed, removed Everyone loves to say this, and yet at every company I've worked at, the top developers just cranked out code . High quality, performant code. And at every company I've worked at, the lowest performers would take a week to write 100 lines of basic python. "Oh, but khazhoux, those 100 lines were really very complex!" No, no…

You can make massive LoC changes by reformatting everything or just adding superfluous code or changes. You can rip out a lot of code rewriting it to simplify and then losing a ton of business functionality that was used, or causing the need for a lot of business changes in process that might not be for the business’s benefit. You can, on your own or with AI, write many LoC, and maybe it provides business value, whic…

You're arguing a different point. I never said a manager should simply count the number of LOC changes as a productivity metric.

I said that good developers write a lot of code. And I'm not talking about senior developers who now do mostly advising/review/architecture work (and don't code much anymore). And sure, sometimes someone takes a long time for a critical few-line change, but that does not happen every day.

I find it exhausting, frankly, how much pushback this simple concept gets around here. It seems to be a reflection of the gigantic team sizes that are common these days, and the modern tolerance for low-output (but still highly paid!) developers. Maybe the popularization of 2-week sprints 15-20 years ago corrupted everyone into thinking that everything should take that long, minimum.

People are shockingly ok with taking 3 days to add an argparse block to a python script, or half-week to implement a single HTTP call. It's nuts!

Re: The Worst Programmer I Know (2023)

#343

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…

> The idea of measuring individual developer productivity is kind of absurd to me.

that idea is very attractive to every manager on planet earth. they seem to quickly lose their ability to maintain contact with reality and they start using metrics to track everything, rewarding those who game the metrics best.

Re: The Worst Programmer I Know (2023)

#344
post #306

Earlier quoted context omitted.

In every organization I've worked in, everyone knew who the productive and non-productive people were. Just like in school. Everyone knew who the good teachers were, and who the good students were. I don't fathom how you can work with other people and not be aware of it.

Have you ever found your opinions of things, including people’s relative worth changing over time? Perhaps as you had time to understand the context, or as time revealed the benefit of an action that wasn’t so clear initially?

Definitely.

Re: The Worst Programmer I Know (2023)

#345

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…

Dev productivity is like quantum mechanics. The second you try to measure it, the wave function collapses, and you've fundamentally altered the thing you were trying to measure. 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. This Tim sensei situation may be more common than I think, but I've never run into it.

https://en.wikipedia.org/wiki/Goodhart%27s_law says (almost) exactly this.

Re: The Worst Programmer I Know (2023)

#346

Earlier quoted context omitted.

Might it be that he’s so good everyone comes to him first and not you?

I would not hire him in my business regardless of how 'good' he thinks he is. I'm interested in people who can get work done.

I think you underestimate those who are both technically brilliant and empathetic. I sense you're at least brilliant

Re: The Worst Programmer I Know (2023)

#347

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…

Tim's problem is that he has a bad manager. One of a manager's core jobs is to communicate upwards the value that each team member is providing (or not providing). His job was to ensure that Tim's contribution were reflected and visible.

According to TFA, that's exactly what the manager did.

Re: The Worst Programmer I Know (2023)

#348
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…

Have had multiple roles running behind these guys cleaning up their messes. If I’m now ever in a position to just let them flail around (not always possible as these guys are often leads) I try to do so, if they are abusive about it, I’ll just quit. this is a major cause of burnout.

Re: The Worst Programmer I Know (2023)

#349

Earlier quoted context omitted.

> I think you might be confusing "productive" with "smart" or "easy to work with". Working in teams for most of my career, and especially when I make or lose money depending on how the team performs, I am not confusing them. At work, I am not really interested in how smart they are or how easy to work with they are, or how nice a person they are. At work I'm interested in results. I've had workers come to me and comp…

> At work, I am not really interested in how smart they are or how easy to work with they are, or how nice a person they are. At work I'm interested in results. I've had workers come to me and complain about "Bob" who has annoying habits and an abrasive personality. I defend the ones that produce results. And what if "Bob" makes it so that "Alice" who is almost as smart as him can't work effectively?

That's why being a manager is not a trivial job.

Amusing story: one day, I got a call from "Bob" who complained that our receptionist "Alice" refused to forward his phone messages to him. Apparently, this was because "Alice" didn't like "Bob". What was this, high school? So "Alice" was informed that she was taking messages for the company, and "Bob" needed those messages to perform his job. She got the message.

Re: The Worst Programmer I Know (2023)

#350

These sort of stories seem to be dime a dozen and weirdly celebrated around HN and the software engineering community. We’re told of the hero, who goes against their managers and executives and doesn’t deliver any stories as agreed in sprints. We’re told of the engineer who isn’t hired by Google because he can’t invert a binary tree. Everyone else piles on and decree that, yes indeed, you cannot measure developer eff…

> We’re told of the engineer who isn’t hired by Google because he can’t invert a binary tree.

>Meanwhile in the real world, hordes of awful engineers deliver no story points

These two seem linked; if hiring practices are bad, then you would expect to end up with many bad hired developers.

Post reply on HN