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

Code quality only matters in context (2019)

adamtornhill.com

Post reply on HN
Print view View original

71–78 of 78 posts

Re: Code quality only matters in context (2019)

#71

Post by gabereiser »

closeparen wrote: post #68
defen wrote: post #19

Earlier quoted context omitted.

> I was let go once for having too many commits in a PR. You were fired for having too many commits in a PR? That seems like an extreme overreaction unless there's more to the story.

The fundamental performance complaint you can make about a developer is that their PRs are bad… whether that’s too little/too late, too many problems, or too unwieldy to reasonably review. You don’t fire someone over one incident. But if someone declines to internalize the feedback and continues to make PRs that are very far from acceptable or even reviewable, yes that is grounds for termination.

I agree. A volume of commits to get to a workable/reviewable PR is in relation to the code quality and ease of change of the codebase. If I made 20 some odd commits to get to a good working PR (which you compare with develop, or main, or whatnot) you only see the complete change view, not the individual.

I think it’s something to discuss. Why did it take so many commits? Is our testing broken? Is our runtime broken? Or is it the fact that we programmed in a lot of hard coded values that only work on the codebase owners machine? Hmmmm…

Re: Code quality only matters in context (2019)

#72

Post by defen »

closeparen wrote: post #68
defen wrote: post #19

Earlier quoted context omitted.

> I was let go once for having too many commits in a PR. You were fired for having too many commits in a PR? That seems like an extreme overreaction unless there's more to the story.

The fundamental performance complaint you can make about a developer is that their PRs are bad… whether that’s too little/too late, too many problems, or too unwieldy to reasonably review. You don’t fire someone over one incident. But if someone declines to internalize the feedback and continues to make PRs that are very far from acceptable or even reviewable, yes that is grounds for termination.

> You don’t fire someone over one incident. But if someone declines to internalize the feedback and continues to make PRs that are very far from acceptable or even reviewable, yes that is grounds for termination.

I agree; it's just that the way OP phrased it ("I was let go once for having too many commits in a PR", emphasis mine) made it seem like it was just one incident. Unless it was something completely egregious like a 50-commit PR to make a one-line change, I don't see how firing is a reasonable response. Which is why I want to hear the rest of the story :)

Re: Code quality only matters in context (2019)

#73

Post by hinkley »

dhzhzjsbevs wrote: post #58
mbrodersen wrote: post #57

Earlier quoted context omitted.

Agree. Do the same with meetings. How expensive is this meeting? If the meeting takes an hour then the cost of the meeting is the sum of the hour rate of the people participating. Then ask if the meeting will generate enough additional revenue to pay for itself?

How do you quantify the revenue generated from coordination, alignment, transparency and any intrinsic motivation gained by including people in the decision making process? I agree a lot of meetings are pointless and not everyone present needs wants or maybe even should be there but I'm struggling to understand the quantifying you're supposedly able to do.

A couple years ago someone wanted to switch us off of Saucelabs because it was Expensive. I don't know how many 4-10 person meetings we had about it but it was a farce, and eventually I called them out on how many $5-10k meetings we'd had in order to try to save $25k a year.

The opportunity cost in these situations is usually harder to quantify. But for me it was distracting from cloud infrastructure work that had price charts associated with it, and contracts that also had dollar values associated with deadlines.

I think what annoyed me the most was that I had to point all of this stuff out to finally shut it down. Were were in a transitional period and people were trying to evaluate every sacred cow at the same time. That sounds like progress to some but like a recipe for burnout to me.

Re: Code quality only matters in context (2019)

#74

Post by mbrodersen »

solveit wrote: post #64
dhzhzjsbevs wrote: post #58

Earlier quoted context omitted.

How do you quantify the revenue generated from coordination, alignment, transparency and any intrinsic motivation gained by including people in the decision making process? I agree a lot of meetings are pointless and not everyone present needs wants or maybe even should be there but I'm struggling to understand the quantifying you're supposedly able to do.

Most of the time this quantifying is impossible as you say. But sometimes half a dozen well-paid professionals do spend two hours discussing the colour of a bike shed.

Heh in a lot of companies that’s what is happening most of the time.

Re: Code quality only matters in context (2019)

#75

Post by mbrodersen »

hinkley wrote: post #73
dhzhzjsbevs wrote: post #58

Earlier quoted context omitted.

How do you quantify the revenue generated from coordination, alignment, transparency and any intrinsic motivation gained by including people in the decision making process? I agree a lot of meetings are pointless and not everyone present needs wants or maybe even should be there but I'm struggling to understand the quantifying you're supposedly able to do.

A couple years ago someone wanted to switch us off of Saucelabs because it was Expensive. I don't know how many 4-10 person meetings we had about it but it was a farce, and eventually I called them out on how many $5-10k meetings we'd had in order to try to save $25k a year. The opportunity cost in these situations is usually harder to quantify. But for me it was distracting from cloud infrastructure work that had pr…

Yep it is crazy. Most employees have no idea how their work impacts the cash flow and revenues of the company they work for.

Re: Code quality only matters in context (2019)

#76

Post by dhzhzjsbevs »

mbrodersen wrote: post #75
hinkley wrote: post #73

Earlier quoted context omitted.

A couple years ago someone wanted to switch us off of Saucelabs because it was Expensive. I don't know how many 4-10 person meetings we had about it but it was a farce, and eventually I called them out on how many $5-10k meetings we'd had in order to try to save $25k a year. The opportunity cost in these situations is usually harder to quantify. But for me it was distracting from cloud infrastructure work that had pr…

Yep it is crazy. Most employees have no idea how their work impacts the cash flow and revenues of the company they work for.

Any ideas on how to train people in thos area?

Re: Code quality only matters in context (2019)

#77

Post by dhzhzjsbevs »

mbrodersen wrote: post #70
dhzhzjsbevs wrote: post #58

Earlier quoted context omitted.

How do you quantify the revenue generated from coordination, alignment, transparency and any intrinsic motivation gained by including people in the decision making process? I agree a lot of meetings are pointless and not everyone present needs wants or maybe even should be there but I'm struggling to understand the quantifying you're supposedly able to do.

Does the meeting move a revenue generating project forward or solve a customer issue? If not then it is 100% cost. BS feel good ideas like “coordination”, “alignment”, “transparency” and pretending to include people in the decision process has zero value unless it results in progress on revenue generating projects. The more people you include in a decision the slower you make progress. The sooner you make progress th…

I've recently started being include in some meetings I didn't realise were happening. It's night and day between the crapshoot planning was before hand. Now when I suggest solutions it's based on what the company needs instead of what I think is best for a given problem. Those things don't align more than you'd think.

Re: Code quality only matters in context (2019)

#78

Post by mbrodersen »

dhzhzjsbevs wrote: post #76
mbrodersen wrote: post #75

Earlier quoted context omitted.

Yep it is crazy. Most employees have no idea how their work impacts the cash flow and revenues of the company they work for.

Any ideas on how to train people in thos area?

Ask people how they think their work contribute to the cash flow of the company. Ask them to consider what impact them not working would have on the cash flow. If their salary is greater than the income their work generate, then their work is actually not beneficial to the company. If they interrupt people who do have a positive impact on cash flow (unnecessary meetings) then it is even worse.
Post reply on HN