Live data from Hacker News

The worst programmer I know

dannorth.net

131–140 of 668 posts

Re: The worst programmer I know

#131

Earlier quoted context omitted.

Maybe, or maybe human endeavour is more complex than individual efforts.

It's tough, but what I've seen is low performers weigh the team down. They constantly ask for the high performer's time, and if we give them bug tickets, new feature work, they constantly stumble and always report status as blocked. They don't add value. They can't get to the finish line with anything. It's not a kind thing to point out, but trying to angle it as "oh there's this other benefit you're just not seeing"…

You've turned the story round from "Tim MacKinnon is a good programmer and asset to the team which the simple metrics were not tracking" into the strawman "defend people who cant do their jobs and are not an asset to the team by claiming that they are nice people".

Re: The worst programmer I know

#132

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.

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.

100 lines of integration tests are worth a lot more than 100 lines of unit tests, so it's not a simple matter of counting LoC.

Also, solving the same problem with less code is a lot more valuable than many think. Not only are there fewer code paths to test, the system probably has fewer unnecessary constraints and edge cases to consider. How do you account for negative LoC?

Re: The worst programmer I know

#133

Earlier quoted context omitted.

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…

> Management can't, at scale, consider such factors. Why not? Peer feedback is a prime component of most performance/rewards discussions at companies. Work outside of points is certainly not a new concept. A manager's job is to distill this information amongst others to their own management chain at the right time. > We don't have the counterfactual where Bob didn't ask the questions, and Alice did great anyways. Bob…

It isn't wrong, it's right; because pontification of things (in a vacuum) yields no results. I cannot sell my customers Bob's ideas. All I can sell them is software that does something. The people that can do this without needing Bobs around are the people that will be rewarded.

Re: The worst programmer I know

#134

I worked at a company for a couple years where you had to produce 10 points a week or you got pipped. Didn't matter if you were a jr or sr. I worked on a few teams there and you could immediately tell how the teams measured points by the stress level of the developers. Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week…

> Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week.

So in the short term, the company benefited, yeah? They got more work out of the same people than they would have if they didn't apply the pressure.

Reminds me of an old boss I had who would flat-out say that to get a project done we would "hire someone and burn them out" - he planned to only get six months of useful work out of someone, and if they were stupid enough to stick around for high stress and low pay, that's just a benefit to the company.

(I didn't last very long there either)

Re: The worst programmer I know

#135
post #14
post #8

Earlier quoted context omitted.

"Hey, boss who can fire me, I just thought you should know that we on the team have started keeping metrics. I want you to know that your 'times you made the only girl on the team uncomfortable with a sexist joke' metric is unusually high this month, and your 'unblocked the team by speeding up an external request' metric is 0 for this month, down from 3 times last month" Let me know if you find any downsides. Anyway,…

The logical conclusion to that argument is that we should do away with the lot of them.

In many workplaces middle management has already been automated. Algorithms manage Uber drivers. Algorithms manage Amazon warehouse employees.

These companies are even more stratified than before with the lumpenproletariat doing human-mechanized tasks while executives program their lives using software we write in exchange for the unbridled luxuries like the chance to own a roof over our head one day.

It's not exactly the future I wanted.

Re: The worst programmer I know

#137
post #36

Earlier quoted context omitted.

I've written several 100ks LOC/year at points in my career- but exclusively when working on new projects. When maintaining projects I might go a week at a time without writing any code solo, or I might spend a week trying to _reduce_ LOC.

My problem in my last role when I read large Pull Requests is that they tended to be way more complicated than they should have been but because they worked and I couldn't single out a small number of specific problems, I had no choice but to approve. Still, I knew it would slow us down in the medium and long term but this bloat is completely invisible to management. It has become taboo to say things like "This code…

"You don't need to add an external dependency for that" "You're violating separation of concerns"

I've found that kind of feedback to be useful actually. And when giving similar feedback it is received better with a small change in wording to make it more about the code and not the person. Even if that is the intention the wording does matter. For example:

"An external dependency isn't needed here, try implementing with XYZ instead." "Split this function into x and y for better separation of concerns"

Removing the "you" removes some resistance to receiving the message .

Re: The worst programmer I know

#138

Reminds me of an anecdote about Bell Labs. Someone calculated who the most productive employees were (based on things like patents received), and found that many of them would eat lunch with the same person. That person wasn't individually very productive, but he would always ask thoughtful, compelling questions that in turn made his coworkers measurably more productive.

For all a lot of people dump on Scrum Masters and Agile Coaches . . . this is part of who the good ones are supposed to be.

Re: The worst programmer I know

#139

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…

> I tend to think that the dev who can churn out thousands of lines isn't thinking deeply enough about the long term direction of the project; all the code they're writing is essentially throwaway code. This is a strong statement. There are both people who are writing throwaway code and people who are writing essential code that match the description. And one will never get to be the latter part without going through…

> one will never get to be the latter part without going through a phase where they are doing the first.

The parent comment doesn't contest this. I think it's about the throwaway code author being valued more than the other.

Re: The worst programmer I know

#140
post #68

Earlier quoted context omitted.

My problem in my last role when I read large Pull Requests is that they tended to be way more complicated than they should have been but because they worked and I couldn't single out a small number of specific problems, I had no choice but to approve. Still, I knew it would slow us down in the medium and long term but this bloat is completely invisible to management. It has become taboo to say things like "This code…

I sometimes use my job title as a higher level senior or lead to say vulnerable things like: "This change is hard for me to read and understand" or "This is a large PR, and it may be difficult for me to schedule time to review it. Can it be split up into a series?" I also configure linters and code quality tools to automatically flag some of the more egregious problems.

> "This change is hard for me to read and understand"

Believe it or not, I consulted at one place where the manager decided I was the problem because I was consistently assessing problem code and team processes in similar ways. She asserted that "everyone else understood", even when they plainly didn't understand but where just going through the motions.

Said manager had a number of other issues as well. Worst gig I can recall having in the last couple of decades.

Post reply on HN