Hacker News Reader

Comment by code_biologist | Hacker News Reader

It really annoys me that whenever I argue for "don't write bugs" as a quality practice, people immediately respond with all sorts of justifications why that's not possible. Of course it's not. But that doesn't mean we can't improve.

We spend time and money on CI, linting systems, sprint retros — so the allergy to "think more carefully about what you wrote" surprises me.

View on HN

There's a big difference between "Analyse your mistakes so you're less likely to repeat them." and "Don't make mistakes."

The first sounds like sensible advice. The second sounds like a completely unrealistic thing that would only be said by someone who doesn't understand fallibility, or humans.

I think it is the opposite. The reason we spend time and money on linting or CI is because we know people write bugs. If "don't write bugs" was an option we wouldn't need to spend that time and money. Good engineering practices should make systems that are resistant to human error.

There is no allergy. The advice given is as basic as it gets. That’s what people already have been doing for years and decades. It’s comically insufficient. what else can be done? How do we deal with the reality of mistakes?

Bug journals, code reviews, prioritizing fixes, tooling support, enough sleep and enough time! If you give me time, then I come up with more and more failure modes, checks, analysis, improved design, better tests. Who pays for that?

People are lazy and would rather pay out the ass for a way out of their problems than actually change. Becoming a better programmer is difficult. Spending money on CI is easy.

Maybe a slight rephrasing, "don't write stupid bugs"; there's a lot of small mistakes that people can make that can be solved by enforcing stricter rules, e.g. forcing the use of `===` in languages like Javascript and PHP to enforce the developer to think better about data types used.

Using linters, formatters, and IDE tools have taught me a lot of easily overlooked issues in those languages.

"Don't write bugs" implies it is possible to write substantial code with no bugs, which isn't true (despite what this guy says).

You should say "try really hard not to write bugs" which is what you actually mean.

"Don't write bugs" means opportunity cost and that's generally bad for business.

If bugs are business problems, figure out why and deal with the business problems. Maybe that means avoiding bugs but maybe otherwise changing the business makes more sense.

Reply on news.ycombinator.com