I try really hard to leave work behind at the end of the day. If I find myself thinking about work after hours, I give myself a mental correction and get back to whatever it is I’m doing. I’m not exactly a career man. But occasionally, despite my best efforts, work intrudes on my real life, and I figure that if you’re going to spend a third of every day working, you’d better bring something home besides a paycheck, and the occasional backpack full of office supplies.
I build software for a living, and while I rarely have a direct need for coding skills at home, there are a few things I’ve picked up about modern managerial philosophies that have proved handy. For example, I’ve used Lean manufacturing principles to streamline my firewood operations, with both poor and excellent results. I’ve also taken to writing a lot of documentation on my preps – APB being the main repository of same – so that I have both a record of what I’ve done, and a way to pass my work onto others, both in my family and in the broader community. What can I say? I’m a sharer.
Recently, though, my software development experience contributed to my preparedness in an unusual way. After my daughter’s onset of Type 1 diabetes, along with about a zillion other things, I realized that I needed to make sure that we had a solid procedure for dealing with power outages. Insulin is life now, and it needs to be kept cold, so continuity of refrigeration is critical. That means keeping the electrons moving, so anytime the power so much a blips here, we need to get into action and start pulling out the blackout gear.
I knew I needed to write an SOP that everyone in the family can follow – who’s to say I’ll be her when the lights go off? I sat down to write it multiple times, but I struggled with the task. I just couldn’t organize what I wanted the SOP to accomplish. I knew the various steps – pull out generator, fuel it up, plug it in – but I just couldn’t organize them for some reason. It could have been because as I wrote, I realized that some of the steps I was describing were things I didn’t know would work, like powering our backup fridge off the battery bank. Knowing that there were untested steps in the process seemed to be creating a mental block for me.
That’s when the idea of Test Driven Development popped into my head. TDD is a method of writing software where the coder writes a test before writing any code. A simple example would be a job requiring a function that multiplies two numbers and returns the results. If I needed to code this, the first thing I’d do is write a test that called the function with various numbers and checked the results. If I feed this function a 3 and a 4, it’d better return 12. The first time I run the test, it’ll fail, but that’s good – I haven’t actually written the multiplication function yet, so it has to fail. Once I see that the test fails, I then go add code to the function to make it pass. Once it passes, I move onto the next function using the same methodology. Lather, rinse, repeat, cash paycheck.
I realized that I could use the same principle to write my SOP – make each line in the SOP a testable step, and then see what happens by actually walking through the steps. If one of the steps is:
- Plug the battery bank into the generator using extension cord labeled “UPSTAIRS FRIDGE.”
then that’s something I can test. Does my kit have an extension cord so labeled? If not, I’d better make sure I fix that. Can the cord reach from the patio to the second floor? If not, get a new extension cord. And so on.
The tests themselves are being tested too, which is a little break from the TDD paradigm, but useful nonetheless. The SOP is just a list of tests, really, and it’s possible that I have them out of order, or that I missed a step. Running through the SOP will test that – if I try to start the generator before adding fuel, say, the test will (eventually) fail, so I’d need to rework the test so that it can pass.
With all this in mind, writing the SOP became a breeze. I just wrote down a list of outcomes I wanted, knowing fully that some would work and some wouldn’t. I’ll spend an afternoon going through the steps I wrote down, fix the steps that don’t work, identifying any missing supplies or gear, and refining the SOP until it makes sense.
Yeah, it’s kind of weird to treat prepping this way, but it worked. And I know how counterintuitive it is to engage in a process where the first thing that happens if you’re doing it right is failure. But once you wrap your head around it, it makes things easier. In this case, it made coming up with the SOP possible, since I couldn’t get it done any other way. I don’t like letting work intrude on my real life, but if it gets the job done, so be it.
Now I just have to remember to actually run those tests…