Let’s Take This Thing Apart

My garbage disposal stopped working recently. I turned it on and could hear only the strained hum of the motor, so naturally I proceeded straight to the internet. I usually do that to see what others think of a situation, though my guess was that something was jamming up the works and preventing the motor from spinning. I went and got a sturdy piece of wood from the scrap pile in my work room and tried to force the disposal to turn, but no dice. That was a few days ago.

Tonight, I decided I’d had enough of using a strainer to gather up food debris and throw it away every day or two. When I had trouble finding work out of college during the dot-com bubble burst, I scraped by and lived in a tiny studio apartment in Chicago with no garbage disposal and one of those freezers that would frost over with ice. I care to repeat nothing of that experience. So I killed the power to the disposal at the circuit breaker and started popping off the plumbing and electrical connections. I hauled the thing down to my basement and set to work on it. As I dealt with the tedious flat-head screw removal and O-ring jockeying involved, my mind began to wander a bit.

One thing that ran through my head was that it had never occurred to me to call someone about this problem, and I started to wonder why not. I’ve never taken apart a garbage disposal before, and I don’t have the extra PVC pipe laying around to hook up as a replacement for the disposal in a worst-case scenario. If I had failed, there would have been no kitchen sink until I succeeded (which would be at least a few days, since I’m at work tomorrow and then taking a brief trip out of town). What’s my deal that I’d just say, “well, let’s start popping screws off and see what happens?”

What I realized is this: I think this mindset is at the core of the engineering mind and drives at what makes programmers successful (and/or driven workaholics). There’s a desire to deconstruct and to understand the core functionality of things. There’s a desire to look at things logically and to understand the procedures for disassembling and reassembling them. There’s a desire to know how the world works, and furthermore there’s a bit of underlying confidence. When it come to operating in that world, you’ll figure something out.

It’s my opinion that when you look at code, it’s important to think that way as well. Why is this framework call slow? Well, let’s disassemble it and find out. Is this method call necessary? Let’s delete it and see what breaks. Can we improve the structure here? Let’s roll up our sleeves and start refactoring. My attitude toward my garbage disposal is the same as my attitude toward code, and I think it’s a decent operating paradigm. Rather than calling in someone when I hit a snag, I use it as a learning opportunity, put in some extra hours, get it done and improve my capabilities. I did that tonight. I’d chiseled out a stuck piece of plastic and hooked everything up for a working disposal by 1 AM. I do things like that with code all the time (often at similar hours).

Of course, there’s a dark side to this. If while working on my plumbing I bend a supply line and somehow cause a leak back behind the drywall, I have pretty big problems. If I have to cut off water to the house and then go to work, it might be “get a hotel room and call a contractor” time. If you don’t know when you’re outgunned by life, you run the risk of going from confident and inquisitive to foolish or at least a bit reckless. I’ve probably crossed that line a few times, particularly in code when I decide I have no use for some legacy namespace and I’ll just rewrite the whole thing myself over the weekend. But I think that, on the whole, if you take the “let’s pull this thing apart and see where it leads us” approach to programming, you’ll probably have a pretty successful career.