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)?
Ask HN: How can I consistently deliver high-quality work with minimal issues?
1–10 of 42 posts
Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?
#2Personally 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.
Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?
#3All kinds of things can go wrong when programming. Sometimes you don't have control over them. Very often you can't reliably predict them. You get better at knowing yourself and what to watch out for with experience, but even the most experienced programmers run into unexpected issues. And have bad days or weeks.
Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?
#4I 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 devel…
Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?
#5Four bad moments in five years? You should tell us your secret. All kinds of things can go wrong when programming. Sometimes you don't have control over them. Very often you can't reliably predict them. You get better at knowing yourself and what to watch out for with experience, but even the most experienced programmers run into unexpected issues. And have bad days or weeks.
Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?
#6An actual strategy: track all of the blockers. You say that your sprints "go wrong" but that isn't a helpful observation. If you track why it goes wrong - write down the start and end time any time you get stuck, blocked, confused, waiting on others, dealing with unforeseen issues, "tech debt", etc.
This is not a failure, it's a vital signal! The time spent on blockers are literally what's standing between you and consistency. Address them head on with empirical data. You should be able to estimate the risk for any new change based on how much time you wasted in the past working on that subsystem. It's a clear choice. Slog through the problems again and deliver inconsistent results - or fix it and deliver consistently.
You do have to be selective - don't just fiddle with the code until it's pretty - fix only the observed problems that stand in the way of delivery. "Make the change easy, then make the easy change" - Kent Beck.
Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?
#7People habitually run at 90-110% capacity and then wonder why they do bad work.
Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?
#8Lots of options, some of them require swallowing your pride and putting effort in.
Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?
#9During the day I copy-paste every JIRA link I work on there, related class names, APIs, fragments of code I worked on that were particularly tricky, test cases, stacktraces I encountered, useful SQLs, urls to webpages with solutions to problems I had, short descriptions of these problems and my discoveries about them. It's not very verbose, usually it's less than 1 screen worth of notes per day (excluding the stacktraces ;)).
At the end of the work day I save that file as date_short_description.txt - for example 20241121_exception_when_logging.txt.
When I encounter a problem giving me dejavu - the first thing I do is grep in that folder for exceptions, lines in stacktrace, class names, related keywords, etc.
After a few years working at the same company it's surprisingly helpful. I started doing this at my first job after working there for over 2 years and experiencing the "I could swear I dealt with this problem before, but can't rememeber how".
Another tip that is probably personal is - I tend to fall into this habit of "do a very small change, compile, check tests" loop that feels good but is suboptimal if testing/compiling takes a long time. So I try to notice if I fall into that trap and stop myself. It's not the worst thing in the world, but it's wasting time (and giving me an excuse to procrastinate cause "it's compiling").
Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?
#10- Try to get stuff tested earlier (see point 1)
- if things can get be tested, write tests while working on the code
- split a feature up in chunks and develop parts
- take your time. Pressure of failing sprints (whatever that might actually be caused by) does not help. Smaller changes help with getting others to respect your time too. Everyone is happy when stuff works :), even if its incomplete