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

321–330 of 668 posts

Re: The worst programmer I know

#321

Post by Gibbon1 »

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…

Friends of mine worked at a place were they got a rock star programmer that churned out thousands of lines of code a week. And they eventually found themselves relegated to the role of cleaning up the mess. So they all quit.

Edit: Take rock stars 3000 lines of code a week and divide by one rock star + six experienced developers now doing nothing but bug fixes and it doesn't seem so super.

Re: The worst programmer I know

#322

Post by liquidpele »

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…

Have juniors plan out work first in design doc form and broken up into small deliverables. Helps to catch things early when they start down a rabbit hole.

Re: The worst programmer I know

#323

Post by manicennui »

88913527 wrote: post #106
mynameisvlad wrote: post #93

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…

Quickly shipping a thousand lines of buggy code that you then spend the next month fixing (by writing thousands more lines of code) is a good way to fool everyone into thinking you are productive.

Re: The worst programmer I know

#324

Post by manicennui »

EVa5I7bHFq9mnYK wrote: post #122
mynameisvlad wrote: post #93

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.

Nonsense. Most people write pretty useless unit tests. Gotta get that test "coverage" high though!

Re: The worst programmer I know

#325

Post by adolph »

bitwize wrote: post #272
adolph wrote: post #166

Earlier quoted context omitted.

> 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 This sounds like an improvement over the opposite, a code base that is rarely touched and uses eol frameworks. Software is a living thing and if you don’t act as a ruthless gardener you wind up a museum curator with 1990s DEC hardware running in the 2010’s. The right…

Hey, if the 1990s DEC hardware still works, and it'd be more expensive to change it... There are PDP-11s running nuclear plants today with support contracts to keep them running until 2050. PDP-11s.

That is a great example. By not taking account of risk on the front end by embracing change, the system gets progressively more expensive to maintain (extended support contracts) and the risk of eventual inevitable change grows higher. Further, the system becomes progressively less valuable compared with newer systems.

Re: The worst programmer I know

#326

Post by wonderwonder »

crazygringo wrote: post #287
wonderwonder wrote: post #104

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…

> ...or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers. But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns. I'm not saying this was a good workplace, it doesn't sound like it at all. But to me, it sounds li…

OP here. You are right, but the minimum point totals eliminates any benefits that can be achieved from scrum, it forces engineers to incentivize survival over project momentum. If a story is really a 3 pointer but I know that if I close 2 3 point stories in a week then I am pipped, suddenly those 3 point stories are 5 point stories.

On the teams that played fair, it was a mix of sr. and jr. and the sr. measuring that story at a 3 meant the jr. was working the weekend. Over and over again.

Note: On the happy team, we had almost no supervision, not even a scrum master. We just looked out for each other. That 3 point story often suddenly became an 8 as the end of the week approached and no one blinked. That team incidentally was the only one that consistently got good reviews from management.

Re: The worst programmer I know

#327

Post by ResearchCode »

tengwar2 wrote: post #238
marcosdumay wrote: post #37

Earlier quoted context omitted.

It sucked being that person back then too. The idea of measuring everything and acting on the numbers you can get is from the 19th century. Managers have been doing that same kind of practice since then, with the same kind of result (it's a very reliable result), without a change.

Acting on the numbers you get is not intrinsically a problem: it's what the action is. Looking at how fast stories, function points or whatever get closed is important for planning what you can get done in a given time, and that can be crucial for project management and managing customer expectations. It's not acquiring the information which is a problem; it's not using the metrics which is the problem. The problem i…

Those are not important at all, or the top software projects would be using them. Linux kernel is doing fine without the velocity point story tickets. Agile "planning" which is used in worse software projects is snake oil.

Re: The worst programmer I know

#328

Post by liquidpele »

ChrisMarshallNY wrote: post #270
tnel77 wrote: post #268

Earlier quoted context omitted.

In my experience, the best raises are from getting a new job. What were raises like for your engineers that stuck around for 10-20 years?

Not very good. These were highly skilled engineers that could easily have commanded better salaries, elsewhere. That meant they stayed for other reasons. I wonder what those reasons could be?

… So you let them enjoy work but fucked them on salary?

Re: The worst programmer I know

#329

Post by volkk »

nine_zeros wrote: post #91
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

> 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 The clickbait is made so that this document can be shared with a future shitty manager. If you send them a link titled "The Worst Manager" - I assure you their first reaction will be to figure out how to get rid of you. Managers are the bane of this industry and sadl…

a manager that truly relies on story points as a direct metric of productivity wouldn't be reading blogs like this in the first place to make themselves better. the article is preaching to the choir of engineers and at a minimum half way decent managers nodding and upvoting. the ones that truly need to read this and embody it will never see it

Re: The worst programmer I know

#330

Post by wonderwonder »

vegetablepotpie wrote: post #311
crazygringo wrote: post #287

Earlier quoted context omitted.

> ...or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers. But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns. I'm not saying this was a good workplace, it doesn't sound like it at all. But to me, it sounds li…

I think what the GP means by “gaming” the system is that the teams did all the technical activities of scrum without providing much or any business value. The issue with scrum or any process that involves estimating is that every software project will inevitably have some risky element or difficult to estimate task that is essential to the execution of the project. Scrum will incentivize teams to avoid the essential…

"every software project will inevitably have some risky element or difficult to estimate task"

You are exactly right here. At this company though, that risk on a personal level could mean a pip. So the happy teams inflated the story points massively to ensure that any or no risk was accounted for and they survived to code another day.

Post reply on HN