Live data from Hacker News

The worst programmer I know

dannorth.net

311–320 of 668 posts

Re: The worst programmer I know

#311

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…

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 work and guide them towards work that is easier to estimate.

Certainly having a good product owner can mitigate this because she can do the work of identifying and breaking down the intractable to something more actionable.

But in that case you’re depending on the people on the team to make good choices. Smart people can do that regardless of the development process they’re using. It’s unclear what value scrum brings to teams at all. It doesn’t make bad teams work any better and it restricts how smart teams can operate.

One thing that scrum does give is it provides management metrics they can use to measure performance.

Re: The worst programmer I know

#312

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 guess some interesting anecdotes have resulted in the post, but the message of the article itself doesn't seem to share anything particularly new or enlightening.

Enough commenters here on HN are disagreeing with the article's conclusion that I think we can infer this is not a point everyone here agrees on, and the article was needed after all...

Re: The worst programmer I know

#313

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…

You’re missing the point, it’s not about scrum it’s about making the work look like it’s way more than it is to pad the metric.

Re: The worst programmer I know

#314

This is also why the most hilarious anti-feature of Jira, supposedly a tool to manage agile teams, is how every ticket has one person assigned to it. If you do sufficient pairing, the person assigned to a ticket is completely useless. Also why performance measurement from the outside of a team is always going to be dubious. Every team knows their best performers, and their lowest performers. The number of points aren…

> supposedly a tool to manage agile teams, is how every ticket has one person assigned to it.

It's whoever owns the issue. You can make it an epic and assign particular sub-tasks to team members if it's a teamwork.

Re: The worst programmer I know

#315

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…

>E.g. would it be at the top if the title was "Don't measure performance by story points"? TBH it's a non-zero chance here on HN. "Don't measure by story points" is still preaching to the choir to a community like this after all. >I guess some interesting anecdotes have resulted in the post, but the message of the article itself doesn't seem to share anything particularly new or enlightening. 1. Lucky 10k. Especially…

Agreed, but also: enough people are disagreeing with the moral of the story that I think we can no longer assume anything in the article is preaching to the choir.

Re: The worst programmer I know

#316

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…

Depends on the company and management. Google codifies this role to some extent as Tech Lead, which is an engineer expected to act as a force multiplier and mentor more than an individual contributor. It doesn't always work as designed (ok, maybe rarely works as designed), and TLs can get too bogged down in cat herding, planning, and bike shedding to actually work as an engineer. But at least the spirit of the role i…

The TL role is a little restrictive IMHO. I’ve worked with very junior people who have a very effective ability to pair and improve others’ effectiveness. Perhaps as they learn they also teach.

Re: The worst programmer I know

#317

This is also why the most hilarious anti-feature of Jira, supposedly a tool to manage agile teams, is how every ticket has one person assigned to it. If you do sufficient pairing, the person assigned to a ticket is completely useless. Also why performance measurement from the outside of a team is always going to be dubious. Every team knows their best performers, and their lowest performers. The number of points aren…

[deleted]

Re: The worst programmer I know

#318

Earlier quoted context omitted.

If your leadership is tossing these incredibly valuable engineers aside, then it's time for you to toss that leadership out. You can do that by leaving, or talking to management about this, or unionizing. It's crazy to me tech workers aren't unionizing anyway.

[flagged]

Unions may be different in your part of the world. In America, it's one of the only ways for blue collar or other production-oriented workers to have any degree of leverage at the negotiation table. We are treated like cattle in the workplace, and though unions come with their fair share of problems (due to it being yet another leadership structure to work within), the idea of workers holding power as a group is essential, because it reflects reality. None of that VC money is getting a return without workers to do the work. Most places in America are not unionized, but the ones that do pay better than other work in the area, even after union dues.

I see it as very much a union-by-union thing, much like you would an employer.

Now, some programmers may be able to negotiate good terms for themselves, but the vast majority of that stage is simply how silver your tongue is. Why should you be paid better because you got a better charisma roll with the interviewer? I would want my coworkers to be paid the same as me for the same experience. A senior with 10 years in the field, naturally, would be paid much more.

It's strange you say developers can negotiate, when there've been quite a few layoffs as of late and we see plenty of stories of people having trouble staying in tech. Which is it? The only thing that can give you credible sway is learning rarer or more in-demand skills, and putting together projects that show you understand how to use them. And for how long will that last? A union is a lot harder to fight than an individual.

But yes, there are bad unions. If they're as bad as your alleged blue collar friends say, let's name them! Sometimes their politics or dues or seniority system sucks. Those systems deserve to be put on blast.

But strangely, no unions listed in your comment as bad.

Re: The worst programmer I know

#319
post #314

This is also why the most hilarious anti-feature of Jira, supposedly a tool to manage agile teams, is how every ticket has one person assigned to it. If you do sufficient pairing, the person assigned to a ticket is completely useless. Also why performance measurement from the outside of a team is always going to be dubious. Every team knows their best performers, and their lowest performers. The number of points aren…

> supposedly a tool to manage agile teams, is how every ticket has one person assigned to it. It's whoever owns the issue. You can make it an epic and assign particular sub-tasks to team members if it's a teamwork.

And if there’s pairing on a sub-task…?

Re: The worst programmer I know

#320

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…

The ironic thing is that may have generated exactly the outcomes management wanted. I’ve worked at places where it was more important for management to know what to expect than to achieve raw productivity towards a goal. The people who were estimating in good faith may have assumed that management was acting in good faith. Whereas a lot of projects are created aspirationally or have artificially short deadlines to “m…

[deleted]
Post reply on HN