Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The worst programmer I know

dannorth.net

Post reply on HN
Print view View original

201–210 of 668 posts

Re: The worst programmer I know

#201

Post by oytis »

Aperocky wrote: post #117

Smells fishy. Senior engineers in my knowledge and experience are all delivering on something relatively high impact while contributing massively to the team by occasional/often "pairing". I've seen rare examples who don't "pair" but just deliver by themselves. I've never seen an example where they don't deliver on anything (planning, design, architectures included) but only "pair" as their job every day.

In orthodox agile environment planning, design and architecture might not result in any "story points".

Also these activities might not always result in a lot or any artifacts. E.g. being in a meeting, making sense of messy stream of requirements and using institutional knowledge to help set the right priorities on a project or prevent team from spending months on a dead end idea might not leave any paper trail at all.

Re: The worst programmer I know

#202

Post by droopyEyelids »

jongjong wrote: post #18

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…

This is the “sorting hat” the makes sure that person ends up at the right company.

Its not fun to lose your job, but that can be better than being stuck just getting by at a company where your work isnt appreciated.

Re: The worst programmer I know

#203

Post by tomtheelder »

jader201 wrote: post #188

The moral of this article seems to just point out what we all already know, and what has already been discussed on HN countless times: don't measure performance solely by things that should never be measured in a vacuum (like story points, lines of code, etc.). Not sure why this is the #1 article on HN right now, other than maybe the (what I would consider) click-baity headline. But I wish there was an acceptable way…

I actually don’t think that’s what the author is arguing. They are arguing that certain metrics that are valuable to measure at a team level become less useful or even misleading if you zoom in too far to an individual level. Story points being a good example. Useful when talking about a team, not useful when talking about individuals. That’s a more nuanced point, and one that I definitely don’t think is obvious to everyone.

Re: The worst programmer I know

#204

Post by Philip-J-Fry »

psychphysic wrote: post #159
yjftsjthsd-h wrote: post #151

Earlier quoted context omitted.

Yes, that is what was written. Would you like to say something about it?

[flagged]

I'm rarely paired because pair programming just isn't something we do in the company outside of just helping people with their little issues. It's not an encouraged practice. There's nothing deep about it. It sounds like you're trying to insinuate something negative about me.

Re: The worst programmer I know

#206

Post by hnfong »

jongjong wrote: post #64
dharmab wrote: 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…

Somewhat unrelated, but it's true that it's sometimes hard to give a reason to reject code that has a "funny smell".

Without going into specifics, there was a case where I reviewed a PR, asking "this isn't usually how people do file operations, are you sure this is really fine?" To address my concerns, they even wrote a specific test program to "prove" that there weren't any problems with the code. I reluctantly approved the PR since I couldn't just ask them to rewrite the whole patch due to just a hunch.

Lo and behold, after a kernel upgrade and file system change, that weird piece of code caused a multi-week panic for the whole team. The extra funny thing is that the test program above made it trivial to confirm and reproduce the issue once we identified this was the cause.

Re: The worst programmer I know

#207

Post by rjbwork »

Philip-J-Fry wrote: post #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 re…

Apparently I am pretty lucky. My managers are explicitly asking me to help rescue a project AND get the dev who did most of the work upskilled and following some of our patterns from some other successful projects. It is hard to know whether they are actually taking my advice and changes to heart and integrating them into their knowledge base and mindset, or just accepting that they're being asked to make changes by me and doing them.

Mentorship is hard, regardless of management buy in :/

Re: The worst programmer I know

#208

Post by adhesive_wombat »

brundolf wrote: post #85

> You see, the reason that Tim’s productivity score was zero, was that he never signed up for any stories. Instead he would spend his day pairing with different teammates. Pretty clickbaity title. This isn't a story about a bad programmer, it's a story about a bad metric, and an even worse manager who followed it blindly

> worse manager who followed it blindly

And apparently has zero idea of the team's internal working patterns.

Re: The worst programmer I know

#209

Post by watters »

The title is a fairly harmless form of click-bait.

What the author describes is the effect on a solid senior engineer working in a terrible organizational system for a not very skilled or savvy manager.

Such managers (and directors and VPs) are common, even in the top tech companies. They may occur less frequently in those companies, but skilled, savvy managers are much rarer than excellent engineers, so the dysfunction described continues unabated in all companies.

Re: The worst programmer I know

#210

Post by Fluorescence »

kstrauser wrote: post #174
Fluorescence wrote: post #147

Earlier quoted context omitted.

Talking about flow state and estimates? The red flag just gets bigger. You are asking me to show you that Santa is not real. A "very senior dev" will not be handing out "1 hour" estimates to a product team. An hour of what? Billable hours? Wall-clock time? It's just not the right framing. You will notice a good senior dev will be incredibly cautious about any commitment and not hand out "ego estimates" like one hour.…

That sounds nightmarish. If I say 1 hour, I mean that I know exactly which knob needs to be twiddled, perhaps because I wrote it in the first place, and that there'll be a pull request ready for review an hour from now. That's clearly not always possible. Sometimes it is. If I say that it is, then I can deliver it.

Scale ruins everything but that's where you will find "very senior devs".

> Sometimes it is.

What's the worst case of the other times? These "one hour" estimates are the golden path, nothing goes wrong, minimum. It's not the average of horror shows or an amortisation all the related support work required to sustain efficient development over time. They are often too coding-focused and ignore the level of interpersonal work to agree and sign off features or to change code in collaboration with others. Talking through a demo can take more time than the code.

Post reply on HN