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.

• llll_lllllll_l

  last Thursday at 8:35 PM

  Good advice, really. love it. Maybe I can try harder to control these issues. One challenge with this is finding a way to talk about it without it sounding like I'm just complaining all the time

  • perrygeo

    last Friday at 12:46 AM

    I've definitely been that guy complaining about all the unnecessary friction. What I've learned is that you have to be selective; take note of the flaws when you find them, but put them aside and focus on the things that directly impact current work on your plate. "I'm going to refactor this class in order to add X with less risk" is an easier sell compared to "I'm going to put development on hold while I refactor all the things for some reason."

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.

• llll_lllllll_l

  last Thursday at 4:13 PM

  oh, that's a good pov! thanks. it makes sense to consider making mistakes the rule and work from there

  • comprev

    last Thursday at 8:24 PM

    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 :)

Not a solution for all of your problems, but it does help me with debugging stuff faster: I have a directory on the desktop called "scratchpad" in which every day I create a new txt file.

During 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").

• llll_lllllll_l

  last Thursday at 8:19 PM

  I've been working with js stuff so compiling is not a big deal, sometimes on the frontend there are a lot of steps to test something, though, I def feel the procrastinate call

  Interesting idea of keeping the daily log. I thought about but feels like a lot of work. Today I keep a "gotchas" list with some of these stuff, which is someway similar

  • ajuc

    last Thursday at 9:24 PM

    The key to do the log is to open the new file in notepad++/whatever in the morning and keep it open. When you do stuff you copy-paste the interesting parts anyway, so just paste it there as well. It's almost zero overhead.

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.

• llll_lllllll_l

  last Thursday at 8:32 PM

  Interesting point, but unfortunately not possible in all code bases. You know the drill, old code base, tight deadlines. But I can see the point, and I'll advocate to that for sure!

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.

• nasmorn

  last Thursday at 7:05 PM

  Today I tested a feature in production that integrates with another system where I fetch how much to delay our data feed for some customers. I kinda remembered we were talking about the delay being an extra 5s but the numbers I got from their prod service amounted to an extra 30s. I flagged it up and it turned out all the other people on the team for the other service simply never checked that they actually input the correct data. Luckily they now have time until tomorrow to fix it.

• llll_lllllll_l

  last Thursday at 8:24 PM

  This makes sense. It's just like, sometimes is really hard to see how to keep improving on the quality besides failing and learning with it.

A big part of this is QA flagging the bugs. Humans make mistakes, and testing is there to catch them. The goal is not to ship the bugs to the customer, not to never make mistakes.

This does not mean that there is nothing you can do to prevent bugs, but try to let go of the idea that bugs should never reach QA. That's what they're there for, and if you add another layer of QA between your work and them, you've basically doubled the work done without improving anything that gets shipped to the customer. And all for the sake of your ego to never have a sprint go wrong.

It's great to have bugs because they become your next sprint.

My advise is to get out of the sprint ecosystem pressure if possible you need time and space to make/fix bugs. The focus should be on the overall deadline not a two week package. Trying to align with that creates issues.

The other is to pick a stack that you can pivot with.

- ship faster, more incremental changes.

- 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

• llll_lllllll_l

  last Thursday at 8:20 PM

  Good list! Yah, stuff working is always better

Small pieces of software incrementally delivered is the key.

Never ship a big feature at once

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

• llll_lllllll_l

  last Thursday at 4:15 PM

  haha, yeah perhaps I removed some examples from my counting. I see your point, we dont know what we dont know

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

• llll_lllllll_l

  last Thursday at 8:38 PM

  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

  • adamhp

    last Friday at 4:50 PM

    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.

I like to write down any mistakes I make or see myself make, since I don't always have a QA team, but I'm not exactly trying to prevent the mistake.

I think of the thoughts in my head like LLM output. I don't expect it to be right every time, my job is to make it useful without relying on it.

If I make a mistake, I don't just think "I'll do better next time" I think "Why was that even possible".

Sounds like you're already doing great if this only happens occasionally!

Is it better than raw claude computer use like in this proof of concept?

https://www.reddit.com/r/singularity/comments/1glmle0/claude...

I'm sure that video is full of hallucinations, but it could be an interesting thing to benchmark the whole system just against a prompt with something like that.

Remove the small errors to stay focused on the big ones. Use typed languages, linters, unit tests and the like.

Don’t trust your future self to remember anything. Not that the logic needs updating in multiple places (single source of truth!), not the steps of a process (scripts!), and not what you need to do (lists and flight checks!)

When something goes wrong, treat it as a learning experience and set up a countermeasure. Mistakes shouldn’t happen twice.

Keep ahead of the industry, keep up with blogs and industry influencers for trends, new APIs, patterns, etc; write tests, look at others’ code, practice good coding patterns, always ask a lead/senior to do some pairing when you’re struggling (that’s what I did to help a lot of other developers in my career), ask for feedback/temperature check during 1-on-1s.

Lots of options, some of them require swallowing your pride and putting effort in.

• llll_lllllll_l

  last Thursday at 8:22 PM

  About asking feedback, what would be good points to ask exactly? I didnt have good experiences with feedbacks in my career, usually they were too vague.

Daily scrums, code reviews, and close collaboration should lessen or keep mistakes at bay. I think working closely with the team and having someone to check your work, anticipate missteps early, and provide guidance helps. We can't expect to sit alone and release something great. It's a team sport.

Do whatever QA is doing to find your bugs before they find them. Then spend 20% of the time to automate 80% of that work. That might be unit testing, it might be selenium, it might be some different linter settings, but keep the focus on bang for the buck stuff.

No 1 thing you need is seriousness to do high quality work. No need for any checklists, keep working until its 100%

You have to love what you do, otherwise you won't care in the long term.

Once you figure out that the rest is trivial.

Have more slack/free time. That’s basically it. Anything else is a patch that will fail once you go over capacity.

People habitually run at 90-110% capacity and then wonder why they do bad work.

• llll_lllllll_l

  last Thursday at 8:15 PM

  Yes, interestingly enough, these bad times usually come along with tight deadlines.

1. If the work is actually hard, your software will have bugs along the way.

2. Big projects do not look finished until the end.

3. If you want to dominate the dojo, only fight children.

4. The creative process is messy and mostly unsuccessful. Assembly lines are neat and predictable…

…the sprint model comes out of consulting where the goal is to do the same thing that’s been done before.

5. QA’s job is to find bugs. They are part of your team. They are not your opponents.

Good luck.

• llll_lllllll_l

  last Thursday at 8:40 PM

  > 3. If you want to dominate the dojo, only fight children.

  hahah, love it, thanks!

testing - do unit testing and system testing.

Gradually.