>If you care about the product you work on

I don't care about the products I work on. I don't own the product, I don't work for an NGO willing to change the world and the product would probably won't revolutionize the industry.

The product's only purpose is to make some people rich. And I don't care for it.

What I care about is being paid, learning, advancing my career and not being bored to death while I work.

So I do quality work because of that. I don't enjoy fixing bugs (some people do), so if I can avoid fixing bugs, I'm happier. I also try to ship as least bugs as possible and I test my code before pushing it. The code has to pass an QA cycle so I will fix my bugs if any. But if some bug is coming from production I'd rather pass on it and take on a feature instead.

So then you do care about the product you work on.

Sure. But also if all you do is fix bugs, unless they are really hard and complex ones in occasionally new domains it's probably not the best career path.

As an example fixing trivial styling, dead links, documentation, flaky tests. Work that is important and has to be done, but not something to drown yourself in. Sometimes it's also better to try to solve the root causes, like use css variables, introduce swagger or a more reliable test framework. You want the engineer who codes themselves out of the job of trivial tickets.

> it's probably not the best career path.

Which is a damn shame for our industry, fixing bugs should be a good career path.

I agree with it. There a rare subspecies of developers who enjoy fixing bugs. The more rare and obscure, the better. Maybe they derive the same kind of pleasure as a police detective solving a hard case.

I do believe they should be princely rewarded and I would hope there would be more of these people as this will allow us the people who enjoy building concentrate on it.

I believe there was a thread on HN two days ago of a guy who enjoys fixing bugs asking how he can make a business out of it. Chapeau to him!

Bug fixing is fun and easy. You just need a good test suite.

I agree, but I do think that's kind of an imaginary enemy. I don't know that anyone said "All I do exclusively all year is fix trivial bugs in hacky or minimal ways". Probably what anyone does is a bit of this, a bit of new code writing, and a bit of new feature stuff.

That's essentially what I do. Sometimes bugs are quite mentally demanding to resolve, but a couple weeks of that begins to get really draining, so I try and move onto something more on the implementation side for a bit.

fixing bugs is more important than trivial stuff like swagger, css variables, or adding new test frameworks. Function over form

But isn't having no bugs to begin with better then fixing them later?

The argument was that you'll have less bugs if you use these technologies after all. And I have to agree wrt styling inconsistencies and css variables at least. They're extremely good at standardizing design without getting in the way of the developer

Honest question - have you ever worked on a codebase with 0 bugs? I don't think that's feasibly. What you're asking for is an infallible god-like programmer.

You will always have bugs. The best engineers can solve the hardest bugs

It's feasible to create no bugs with formal specification and formal verification. For example, with Lean 4, one can add a proof for each array-access-by-index that the index is within the bound of the associated array. Every aspect of the codebase can be subject to formal proofs that are verified by the compiler. See also CompCert and Sel4.

Honest question - How did you get from "less bugs" to "0 bugs"?

Maybe because there’s a bug in your statements. You use “no bugs” and “less bugs” to describe the same point.

CSS variables, test frameworks, are good tools for catching bugs -- but at the end of the day the goal is that the code should work and be easily maintainable. Best practices help you do that, but theres many instances of a code base full of bugs that has to be maintained and improved over time. Developers who turn up their nose at "fixing bugs" are of no use to a business. These ideas are great when starting a new codebase but thats not the situation a developer is going to be in most of the time in practice. And if you follow every best practice there will still be bugs that need to get fixed.

You're arguing with a straw man then. Their argument was that only solving bugs is an issue, because you should be taking preventative measures so they're occurring less frequently.

If the bugs are all your doing, I agree. But many times the developers working on a project are maintaining code that was written years ago before they even joined the company, by other devs that had totally different incentives.