←back to thread

25 points llll_lllllll_l | 1 comments | | HN request time: 0s | 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
techfeathers ◴[] No.42205155[source]
I think part of this is you have to know yourself. I imagine there are some people out there who can really sort of discipline themselves into doing a good job - through checklists or really good review processes.

Personally I do everything in my power not to be disciplined. I intentionally make my first draft terrible. I almost make it my goal to write bad code instead of good code(. I’m an SRE not a full time developer for what it’s worth)

And then I sort of find adversarial ways to circle around the solution. Write tests etc. I don’t know how to describe it but I never want a close eye or “discipline” to be the solution to the problem. Use tools for linting/schema validation/testing and trust them and when they don’t catch something evolve them.

It’s funny you say “rarely, but sometimes I have bad weeks”. Whereas I approach it the opposite. Sure every once in a while I have a good week where I don’t make many mistakes. But I approach my work like making mistakes is the rule, not the exception. And lean into it.

And I will say it would be crazy of me to say that in all this time I haven’t developed a pretty good eye. I certainly catch a lot of things people with less experience don’t, and my first drafts are much better now then they were earlier in my career. But I don’t rely on that experience, because I’m fallible.

replies(1): >>42205782 #
llll_lllllll_l ◴[] No.42205782[source]
oh, that's a good pov! thanks. it makes sense to consider making mistakes the rule and work from there
replies(1): >>42208244 #
1. comprev ◴[] No.42208244[source]
Which is where TDD can really help.

Write tests first and keep revising your code - making plenty of mistakes along the way - until the tests are green.

The quicker the test failure feedback loop, the quicker you'll fix the mistakes :)