Aegir shared this post on Mastodon earlier and I think it's an interesting take on something I've attributed to an ability to debug.

Fixing stuff for a living makes you really good at being wrong. Forty times a day you'll be all "Bet it's one of the outputs on this chip. Nope, well let's check the inputs, what're they connected to... okay so it's further up the line," and you get practice at dropping wrong ideas fast before you follow them down a silly rabbithole, you get to be okay with going "Well, it'll be this, unless I was wrong two steps ago and then it'll be that."

I worked with a guy once who was REALLY bad at being wrong. Like, he'd spend literally hours hilariously misaligning a single pair of flippers rather than consider that he might've used the wrong coil stop. He bloody soldered his crimp connections as well!

Being wrong is a skill and with a lot of practice you can get good at it. When you've let enough silly nonsense run through your head and dribble out your ears then it's as easy as inhaling to get a wonderful perfect beautiful boy of an idea, and in the next exhale you can toss that same idea in the trash with all your other nonsense where it belongs.

I won't toot my own horn about many thing but damn it I'm GOOD at being wrong. It's taken me YEARS to get this good at fucking up.

I learned to debug really early on in my career. My first job where I wasn't a junior, I worked on a codebase that had been maintained by someone who was always 100% sure that they were right (this isn't an exaggeration - I've genuinely never met or known someone so arrogant in my entire life), and that had resulted in so many incredibly confusing things that were an example of that "misaligning a single pair of flippers" mentality. Some people have an idea of how they're going to implement something and they will not deviate from it (or consider deviating from it), even if they meet with substantial resistance.

At the inoffensive end, this looks like reimplementing existing functionality (i.e. not stopping to think surely this must have been implemented already or not R-ing TFM), but at the terrible end, you usually end up implementing hacks in your initial idea because you didn't test/think it through sufficiently, and you didn't go back to the drawing board when you hit real problems.

There can obviously be a tonne of reasons that you might not be able to go back as far as you should, to refactor your code or approach to accommodate these realisations, but you should always at least try to learn lessons from them when you can¹. Analysing your own ideas and output and accepting when you were wrong, or could've been better, is the easiest way to improve in almost anything. I do it at work, and I do it whilst playing badminton; it probably fits most places. The ability to be constructively self-critical² gives you a toolset for self-teaching that l've found so incredibly valuable over the years, I couldn't even list the ways it's helped me if I tried.

I'm not really sure what my point is here. That toot got me thinking and I'm not sure I agree with it entirely, but a lot of it fits with me. It can't just be a matter of being wrong because I am terrible at that sometimes, but I think it depends on where I'm wrong. There's at least two people that I can't bear being wrong in front of, but I'm definitely fine being wrong in the comfort and safety of my own office. But it also can't just be a debugging ability because you need to be able to do it before real problems arise.

I should've mulled this for a few days before trying to write something.

¹ Most notably, every relational database relationship is many-to-many, given enough time. Always design systems so that converting to many-to-many would be minimally disruptive
² I don't recommend just being self-critical if you can help it