Like A Girl

Pushing the conversation on gender equality.

Code Like A Girl

Three ways programming made me a better electrician

Switches for firing the traps that surround my friend’s hypothetical zombie apocalypse compound

In undergrad one of my friends switched majors from computer science to pre-dentistry because she didn’t think that programming was a truly useful skill. Sure, it could get her a job, but in the event of a zombie apocalypse or time portal accident no one would need her to build a website or compile binaries, but people would always need their teeth pulled.

At the time I thought her logic was reasonable, but I’ve recently bought my first house and in the process of fixing its myriad of problems have come to the realization that programming helps develop several transferable skills in fields where no computers are even used. Here are three examples of how I’ve used these skills in fixing electrical problems in my new house:

Anything Can be Debugged

When the project I’m working on doesn’t easily provide interactivity or print statements, like with hardware description languages on FPGAs or C/C++ code before I learned how to use gdb, I use a variation of the “wolf fence algorithm” to make it work.

Though you might not have heard of this term, you’ve likely used it. The algorithm solves the problem of how you find a lone wolf in Alaska: build a wall bisecting the state, then listen in either section for the howl. Then bisect the section with a howl again, and again and again, until you’re within biting distance.

This algorithm can be applied to figuring out why a circuit in your house isn’t providing power like it can to finding segmentation faults in your code: make one change between tests and iterate based on the result. Of course, the tricky part of debugging is often coming up with what to try next, but just as there’s a finite number of lines in your code, there’s a finite number of switches and outlets on any circuit.

The User Comes First

Budgeting time to think about how my project is going to be used before implementation saves time down the road. I’ve wasted effort by building a slew of functionality when I only needed it to do one thing well. I’ve spent days prettifying GUIs and then been frustrated when the most common action takes three button clicks instead of one.

Similarly, it’s important to think about how I’m going to live in my house before I make any changes to it. If I’m too short to reach, does it make sense to wire a switch on a ceiling light fixture as well as one on the wall? If my taller husband uses the ceiling switch, it will cause me frustration when the wall switch doesn’t turn the light on. It doesn’t make sense to add USB power to the outlet under my desk if there’s no way I’d get get on my hands and knees to use it, but it does make sense to add it to the closest outlet to my door so that I can charge my phone while I’m waiting for my ride.

Fear is the Progress Killer

I’ve worked on projects where I felt fear — what if my website has a security vulnerability and hackers take it over? What if I’m reading in the gray codes from this motor incorrectly and I make it overshoot its target? Though these were serious issues, had I attempted to guarantee that they would not happen, I never would have progressed. The same is true for electrical work. Though there is a serious risk of death if I stick your wet hand directly into a service, the consequences of messing up when a few precautions are taken are not serious enough to discourage me from trying.

If I backup my code and test in a sandbox environment, the consequences of a hacker finding my vulnerabilities are small because I can always shut down my website and try again. If I turn off the circuit I’m working on, and the consequences of mis-wiring an outlet are small because my house has more than one outlet.

I believe that these three examples are enough to qualify me as a useful member of my friend’s compound in the upcoming zombie apocalypse. Less facetiously, I think they provide an important point when it comes to deciding our educational goals.

In high school and undergrad, the humanities and social and natural sciences were sold as courses that would teach me how to think, whereas engineering, technology and business would teach me practical, specific skills. But this did not end up being my experience: programming has taught me how to think as much as the philosophy and history classes I took. We often enforce the message of learning to program in order to build a specific thing, but relatively little on the fundamentally transformative effects of thinking like a programmer.