Hacker News Reader

Comment by jakub_g | Hacker News Reader

Semi-related: "there-must-be-an-eslint-rule"-fetishism.

Some developers seemingly can't live in a world where certain constructs can be used sometimes in the code, and others at other times, depending what is more appropriate in a given context. If they think construct B is superior over A, they will put in place an eslint rule that forbids A and always forces you to use B.

In some cases it happens that B is clearly superior because A is known to be broken for reasons x,y,z, then I'm okay with this.

But sometimes those kind of rules are taken out of nowhere for no good reason, just a personal preference, or with a fake reason like this blog shows (certain construct is only better at certain times, but not always).

View on HN

I got a lot more relaxed about hard and fast rules around the same time I really started having some success growing plants. I couldn't tell you which order it happened in. Organic systems can't be controlled, they can only be guided. And at the end of the day, while the software itself is inorganic, it is and continues to be created by a bunch of meat sacks, flapping their meat at each other to communicate. If you have an evolving system created by organic creatures, it is going to behave organically itself.

I will say it's a little weird the ways in which some people think they've found a 'gotcha' and instead what's happened is that they're thinking 3 moves ahead and you're thinking 6.

ETA: What happens in plants is that I can walk down a street, and see dying trees that the owners think are healthy, and mostly healthy trees that the owner thinks are dying (when just a few strategic cuts would give them another 30 years). Sometimes you can read the sad story of decline in the dying ones, a repeating cycle of waiting too long to do preventative care, and overreaction leaving scars that never fully heal. Getting either tree owner to act is often like talking to a wall. Basically the same problem happens in software.

Very interesting take. I think I also noticed a change in my thought processes around coding when I started gardening.

You can never defeat the weeds; so you have to be vigilant and pull the early before they drop seed.

I find the same practice also works well in code: consistent "weed pulling" to keep things tidy.

If you get a big enough piece of land, you find you can’t pull all the weeds the moment you see them. You have to focus on the nasty ones. Some of the others will take care of themselves, and some are easier to pull at other stages of life. some you absolutely can’t let go to seed. Others have their uses and it’s a matter of weighing whether the “tech debt” later or sweating your ass off now feels like a worse fate.

But even the more innocuous ones can eventually block access to things, or become a hazard, and you have to clear them from the main areas in order to get anything done, or to see the nastier weeds hiding behind or under them.

been there. Worst offender I've seen is an eslint rule that forces you to not mutate the object you're creating with reduce() because mutation is bad. So now you're doing object spreading and went from an O(n) algorithm to an O(n^2) algorithm. Wonderful.

There is a lot of unquestioned dogma going around in this industry.

lol, and then you add an exception for spreading: /* eslint-disable react/jsx-props-no-spreading */

Why not just use a for loop?

I have pretty much gone back to for loops for anything besides the simplest map()'s. You can get reduce() to do some pretty cool things that always need more lines of comments to explain than a for loop and some variables.

I agree. If your reduce requires mutation, then you almost certainly shouldn't be using reduce.

There's an eslint rule forbidding for loops too.

is that an airbnb eslint rule?

no wonder their website is so slow!

Ugh tell me about it. My large enterprise company has been piling these on lately. You also get blocked from checking in any ignore eslint statements unless you ask some review board that meets once a week with a month long waiting list. I know all jobs are balance of productivity and bookkeeping, but all these CI checks are really starting to make me consider switching jobs.

I keep trying to tell people that the metrics knife is sharpened on both sides. The only way to be absolutely, categorically sure of your trajectory is if your velocity is 0. And that is, as they say, a "divide by zero error".

These rules and tools go in to fix a hurt caused by making mistakes, and somewhere it gets twisted away from "not making the same dumb mistakes repeatedly" to "never make any mistakes", which slows things down until you eventually make the chiefest of mistakes for a capitalist venture: never shipping.

Two of my better bosses pointed out that only people who risk nothing avoid making mistakes. One of those thought that "perfect estimates" meant you were over as often as you were under (the old accuracy vs precision argument). You can't achieve anything without taking some risks, and 'boring company' only works in a few niche markets, that don't pay well.

  > These rules and tools go in to fix a hurt caused by making mistakes, and somewhere it gets twisted away from "not making the same dumb mistakes repeatedly" to "never make any mistakes" (except for the chiefest of mistakes for a capitalist venture: never shipping).

tools cant really prevent mistakes anyways, because people will always find a way to "get the job done anyway" by working around them... the end result in many cases is actually... more mistakes!

at some point you have to hire people you can trust, no tool or process can fix that!

If the people working with tools like ESLint or TypeScript don't appreciate what they're doing for them, then yeah they'll work around them.

I guess you need to teach people like that how they can work with the tools to get things done, with higher quality results.

For my part I very much appreciate that ESLint and TypeScript can help me write better code, they're helpful and consistent reminders. I understand that I should use ===, I understand I should check for null, but without the tools I won't remember to do it in 100% of the cases I should.

A common thing seems to be that the reasoning behind the rule is missing. I have personally seen single return recommended for C# code, when the original reasoning for it is manual memory management.

Reply on news.ycombinator.com