I never set out to break systems, but systems frequently break around me. On the one hand this means I’m really good at debugging things, and then putting them back together better than they were before. On the other hand, it is super annoying because sometime you wish things could “just work” the way they do for other people. I have two names for this phenomenon (* yes, it is just confirmation bias in action, but this is funnier). One way I look at it is that I emit an improbability field, which causes statistics to go haywire. The other way is that I call myself an accidental QA.
Anarchy or Acceptance?
There are many of us in the technical space who tinker with things. From taking apart our pens to see what makes them click when we were in primary school, to tinkering with cars, computers, 3D printers, etc as adults. With a special mention for the “can I make this explode” days in our teen years. Tinkering is a controlled form of quality assurance, and a fantastic way of learning how things work. It gives us a sense of the internals of things, which can serve us well later on. Of course, we have to ask “why did you open that up?” If you’re like me, the usual answer is “because it stopped working”. Not “to see how it works”.
It isn’t a consistent battle. Once I have learnt the oddities of a piece of software and have set it up to work for me then Newton’s laws apply. As long as nothing changes, it should keep working! The problem with software, is that it does change. It changes in ways that we don’t expect, not always because of an action taken by an intentional actor. So, we have to go through the thought process of “is this worth the fight”. This is a very easy question to answer – if I cannot achieve my goals in any other way (up to and including “do my job” as a stated goal) then the fight is necessary. If there is another way to achieve my goal, and it has less friction, then that is a valid alternative and I will usually choose that route.
So, where’s the anarchy in that view? It is much more in line with choosing equanimity and acceptance that what is, is, and we change only that which we must. The problem is that I have spent a lot of time working as a DevOps engineer. Which means once the code is in production, it is still your problem. So, I have been paged (* no old fashioned beeper, sadly, just a really annoying phone app) into many different types of operational events. With a high enough frequency that people other than me accepted the curse of my improbability field. From database fail over events on a system where no one knew which processes needed to be restarted to pick up the new endpoint (that was the first one ever) to massive AWS Networking events and Log4Shell in the same week. By the end of these things, the anarchist in me wants to throw up her hands and say “let it burn”.
Anarchy is recognising that systems often work differently to how I anticipate, and purposefully breaking them to watch as other poor engineers have to deal with the fallout. Acceptance is seeing the issue. Recognising that perhaps I am the problem (not Taylor Swift), and shrugging my shoulders and moving on.
Neither
It isn’t really that black and white. It is a brilliantly colourful minefield of wonderful things you can break. The more you build, the more ways you will find to do it. The more interesting your life, the more edge cases you will find for the other broken things. Living in South Africa, but having wide ranging hobbies, you find edge cases really fast where people just straight up choose not to ship something to this edge of the world. Or you can break the system in other ways. I have a really simple name, it has never broken any systems. I have, however, had to remind various HR people that I should be paid please, and that I submitted all my paperwork, so it shouldn’t be that hard. Or tell people that my given name (or preferred name) and my legal name are different.
These are battles worth fighting. Much as the battle to build resilient systems is. So, when I report a bug in a piece of software, I might be the problem, PEBKAC (Problem Exists Between Keyboard And Chair) is a viable reason for the issue, I still was unable to solve it myself and will provide logs and examples to boot. The fact that a system doesn’t work the way I expect means there is probably someone else with the same issue, who doesn’t know how to ask about it. I have had colleagues decide that this makes me a very good beta user for their systems (some of them even went so far as to get me involved in UX conversations). I have also felt like I was irritating people by bugging them too much about things.
I embrace being an accidental QA as a superpower. It makes me much better at thinking about edge cases when testing and at figuring out ways to build resilient systems. It is why I know so many different debugging tricks, and why I care deeply about operational tooling. It is why I care about taking the ops out of DevOps. I am the person who will break the system, so I have invested time and energy into becoming the person who knows how to fix it. For good. Not just by turning it off forever.
When physical things break around me, that’s when I call it the improbability field. I don’t really know what to do about that one, but given that I had to replace the hot end in my 3D printer after too much debugging caused the brass nozzle to fuse to the inner workings and puny little me managed to snap it off, I guess still useful. If nothing else, I have learnt to live by the words of the Hitch-hikers Guide to the Galaxy, and I don’t panic.
Equanimity
You can tell I’ve been doing my meditation practice, because of this word. It really does come back to this. We don’t have to choose anarchy, or roll over and accept the world as it is. We can fix the things we know how to fix, and accept that the world is not the perfect shape. Sure, it is infuriating when stuff is broken. But the high you get from fixing it is pretty unbeatable too.
Pippa Hillebrand 