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.

You will continually get better at not just writing the right code, but at interpreting requirements into the right code. You will learn the edges and corners where bugs will hide. And sometimes you'll write them anyways, because that's life. You'll fix it in the future.

In this trade, a lot of orgs put a lot of emphasis on "sprints" and "deliverables", but you really have to look at software development as a continuum. Optimizations and bug fixes are a part of this continuum, and any good team has space for these things in planning.

Not all teams recognize this, however, and I would recommend discussing with the other engineers on your team how you can work together to advocate for this. No sprint can be 100% features. Software requires upkeep. Bugs are a natural part of this.

Sounds to me like you need to do more testing. You should have automatic integration tests that run with your CI/CD pipeline to make sure you don't break seemingly unrelated bits, and most importantly you need to actually test the application like a real user - like QA will test it - before you merge. Writing code that works is only half the battle. You need to test it and get it ready for production before you merge. Most importantly you need a robust test suite with >90% coverage, to avoid breaking things by accident. Focus on making sure your code is stable, rather than trying to get each task done as quickly as possible.

I know this sounds like a zen koan but to be consistent, don't worry about consistency. A description of the desired outcome is not a strategy for achieving it.

An 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.

This is literally what seniority/experience means.

This is why more experienced developers get paid more — because the deliver more consistent, higher quality, less issues work.

You work more, on more projects etc. and you eventually grow. Doesn't matter at all which tricks, approaches do you use.

The best investment in you quicker growth - is to find bigger, more complex and important project to tackle, and better team.