←back to thread

Ask HN: How can I consistently deliver high-quality work with minimal issues?

25 points llll_lllllll_l | 2 comments | 21 Nov 24 14:53 UTC | HN request time: 0.401s | source

TL;DR: What are your checklists, tips, and tricks to ensure you're delivering a high-quality piece of work (whether it's a Pull Request or something equivalent in your field)?

As a full-stack developer, I've often found myself in situations where a sprint goes wrong, and a lot of bugs are flagged by QA. It's a tough spot to be in because I genuinely put in my best effort when coding, but sometimes things just don't go as planned. It could be due to a new feature, an old legacy system, or simply a rough week—it happens from time to time (not so often, I remember like 4 moments in my 5 years of experience). What advice do you have for maintaining consistent deliveries with minimal bugs (or equivalent failures in your area)?

Show context
ilaksh ◴[21 Nov 24 20:31 UTC] No.42208316[source]▶
This comment and many of the replies are ridiculous. Bugs are part of the process and so is QA. Having only a handful over a few years probably means you spent too much time trying to make it perfect. You will see fewer problems the more time you have to work on a feature or test it, but in my opinion if you consistently get to zero then that is inefficient because it delays the feedback from the user. Or it means you have a really well funded organization that can afford a lot of development time on each item but is probably wasting money.

You have the "luxury" of a QA team, unlike many developers. Take advantage of that. Don't feel bad just because you see a bug once a year (which I don't believe is accurate reporting on your part).

replies(1): >>42208394 #
1. llll_lllllll_l ◴[21 Nov 24 20:38 UTC] No.42208394[source]▶
Yah, making it clear, I def get more than a couple of bugs yearly hehe. You sound right for me, and I heard stuff like that from companies here and there. Stuff like "delivery it first, make it better later", like focusing on putting it together on front of our users besides of over engineering the right thing. This is cool, till dozens of bugs appears
replies(1): >>42215364 #
2. adamhp ◴[22 Nov 24 16:50 UTC] No.42215364[source]▶
It's the right mindset. Because code isn't the end, it's a means to an end. The end is "value". To your users. The quicker you give that to them, the better. Bugs here and there are absolutely part of the process. You are making an assumption that the least amount of bugs is "best" for your company.

It's important to consider the bigger picture here. Consider a scenario where you spend twice the amount of time delivering features, getting things perfect. Let's assume for the sake of it, that our users will "like" half the features we ship, and we'll throw out the rest. In this scenario, it's better to reduce quality to ship faster, because half of your features are going to be "thrown out" anyway.

This happens in the real world, albeit to a less extreme extent. But the point remains. That's why we have product teams that attempt to reduce the likelihood of a feature being tossed out and time being wasted. That's why we have QA teams to ensure development bugs are caught and we deliver both value and have robust systems in place.

As long as these aren't catastrophic, affects-all-users, brings-down-the-servers type of bugs, you're probably writing the optimal amount of bugs to balance the trade-off in value delivery.