Hacker News Reader

Comment by hinkley | Hacker News Reader

> So “screw it, this works” seems to be an entirely justifiable methodology.

I've become more aware over the years that some developers, especially very senior ones, are under the fatally mistaken assumption that the problems start when the complaining starts, when it's closer to the truth to say that the real problems start when the complaining ends.

There can be bad developers on any team of course, but there are many developers who know or suspect what they are considering doing is wrong, and discover that asking someone about it is far more trouble than its worth. They either get yelled at or saddled with a bunch of homework because they've drawn attention to a can of worms and are being deputized to fix four things instead of the one they knew about.

Every project has problems. Even the ones that are making millionaires out of relatively new team members. If you aren't hearing about those problems, that's entirely, 100% your fault.

View on HN

> when it's closer to the truth to say that the real problems start when the complaining ends

Oh, no, when the complaining ends, the problems didn't just start, they reached the magnitude where they are unsolvable long enough ago that no one even harbors any glimmer of hope of fixing or even meaningfully mitigating them.

... yeah... that's a whole row of ice cream flavors of its own. There's depressed despair, betrayed despair (chocolate and vanilla), cold disdain (mint) and red-hots (if I think about this I will get so angry that I will do something career limiting, so I cannot think about it anymore).

I'm still trying to work out how I communicate to someone that the things I have stopped mentioning might still be bothering me, and so fixing the two things I'm actually harping on won't magically make me happy. Maybe that's just something people are supposed to work out for themselves. Mostly I seem to have figured out how to do this when three or more people are involved (basically hand all of my fodder to someone who is still engaged, and let them run with it), but not when it's one on one. Conversations with people who can't 'look at things' can be exhausting, and that seems to hold no matter which party you are.

> real problems start when the complaining ends

I really like this quote, and I'm gonna reuse it in a slightly rewritten fashion. In SE teams, indeed, the amount of complacency is directly related to the amount of increasing technical debt.

Often the complaining ends because the complainer leaves. And now you have two problems.

Not all problems have to be solved before they become an issue though.

Its often a pointless effort, especially if the problem boils down to "this architecture isn't pure enough"

You know you can acknowledge a problem and that doesn't mean you have to solve it this very instant, right? It's not a matter of either dropping everything or gaslighting people^W^W dismissing the issue as trivial. There are other choices. Many other choices.

If you don't think the problems people are bringing you have merit, then they won't bring you any problems at all, even when they have merit. Suck it up and realize that you're going to have to allocate a little bit of time on "good problems to have" (if this is our biggest problem right now, things are going very well) or you'll either introduce latency into your early warning system or shut it down entirely.

> if the problem boils down to "this architecture isn't pure enough"

Then the problem is that your coworkers think that purity is a magic shield that will protect them from all ills, which is a bigger problem. You still need to hear it, even if you don't like it.

Honestly though a lot of times when I find myself at odds with someone they try to dismiss my concerns as matters of purity when what I'm really complaining about is the smoke that's coming out of the machine (or the team's ears) because they're riding it too hard. Sharpening the saw isn't aesthetics. Preventing wear and tear isn't some white tower bullshit. It's about keeping something in the tank for the next problem we don't know we have yet. People who don't believe in burnout are doomed to create it, usually in others.

People think they’re designing a spaceship, when in reality they’re building something closer to IKEA furniture.

YAGNI applies to a lot more than most people think it does.

Targets of opportunity are problems that have a distinct value in being solved which is less than the naive cost of fixing it.

Not the actual cost of fixing it, the 'drop everything and work on it now' cost, adjusted for Murphy's law. These are often the sort of 'nice to haves' that come out to 3 months of work, which nobody is going to approve unless a customer is actively yelling in their face about it. And sometimes not even then.

Refactoring is Make the Change Easy, Then Make the Easy Change. If you don't know what your targets of opportunity are, because you have some misguided notion that you can't [have an adult conversation about the state of things](https://www.jimcollins.com/concepts/confront-the-brutal-fact...) without tender egos being hurt, then instead of moving toward any of the horizons you'll just sail in a big circle while people keep trying to get you to venture farther afield.

The problem I often see is in the evaluation of the naive cost of fixing it versus the actual probability your target of opportunity will become a legitimate design consideration. The naive cost almost always is large but the probability your target of opportunity will be necessary is often small or miniscule. It's easy to try to cover all your bases and write something in an unnecessarily flexible way when a concrete implementation would have solved the immediate requirements succinctly and very likely may not to be touched again for years (if ever again).

The point of the post isn't that all problems should be given equal credence, but that all problems should be at least acknowledged. Im the end would you rather a Jr. dev who's been working on the project for 6 months be the one who decided whether the problem is important enough to be solved or the Sr/project lead?

> They either get yelled at or saddled with a bunch of homework because they've drawn attention to a can of worms and are being deputized to fix four things instead of the one they knew about.

There is a gradient I've seen with IT workers in general, that is doing IT as a passion and doing IT for a job. Disciplining someone for not knowing enough though is a bit much.

> real problems start when the complaining ends

By this point no one cares anymore and the technical debt is beyond fixing.

I dunno. I know of a project that lingered in this spot for a couple of years before enough people who cared had left to make it a truly lost cause. But there was no leadership to speak of to motivate any of those people, and most of them left. There were points right up until the end where these people were sprinkled across enough of the organization to be a beach head for doing something, but then they lost people on two teams in as many months and from then on it is destined to be status quo. Or at least until they decide to binge on a tech stack update, hire too many people but not for long enough and end up back where they are now. From what I understand they've done that a couple times already.

Reply on news.ycombinator.com