Recently, a family friend gave my two children disc guns. The boys were thrilled; what could be possibly more fun than shooting your sibling? Our friend handed one gun to Blaine and one to Larrabee. Both found the on switch, pointed their guns at one another, and pulled their respective triggers. The guns made satisfying electronic beeping noises. The children felt the vibration of small electric motors. And, almost immediately, the guns sent foam discs flying at surprisingly high speed from their muzzles.
At least, that’s what Blaine’s gun did. Larrabee’s gun made the beeping noise. Larrabee could feel the motor whirring. But, to his great disappointment, no disc emerged from the gun. So, while Blaine could fire a steady stream of discs at his younger brother, Larrabee was completely unable to return fire. While I would have been unafraid to face a steady simultaneous barrage from both disc guns, I was now petrified; two brothers with only one disc gun between them seemed unlikely to lead to a happy, relaxing afternoon.
Fortunately, I am an engineer. True, as a computer scientist, I dealt mostly with abstractions (zeros, ones, algorithmic complexity, category theory, etc.), but as a software developer I dealt with slightly less abstract abstractions. After all, I have crafted real actual software used by real actual people. Software may be intangible, but, still, we call it software engineering, don’t we? The mere fact that the system in question was physical, rather than logical, did not dissuade me from debugging it.
By which, of course, I mean “taking it apart.”
In my defense, I started with a visual inspection. I looked into the mechanism and observed that pulling the trigger would release the bottommost disc in the magazine, but, beyond that, the system was a black box. Attempting to fire clearly released the disc, but instead of flying out the muzzle, it was sent sideways. Perhaps there was some sort of obstruction in the flight path? Nothing I could see, but it wasn’t easy to see very much. So, I demanded a screwdriver and set about the disassembly process.
My dissection revealed the workings of the weapon. There were two round objects bordering the path of the disc. The first was small and immovable; it was a guide intended to ensure that the disc went towards the muzzle. The second, larger object had ridges to grip the discs, and rotated when the trigger was pulled; it was the propulsive mechanism. And, quickly, the problem became clear: the motor was rotating the wrong way, effectively shooting the disc back into the gun. But, it was not obvious how to solve the problem. Perhaps there was a gear missing? Perhaps the motor was installed upside-down? Further disassembly looked challenging, and the risk of breaking something rather large.
Then, I had a sudden (and, sadly, rare) flash of inspiration: a DC motor will run in the wrong direction if the polarity of the power source is reversed! And, so, I opened the battery compartment, where, it transpired, my friend had installed the batteries the wrong way round. After reversing them, so that the positive and negative terminals matched the label in the compartment, and reassembling the system, much fun was had by all.
My first thought was that thinking like an engineer had saved the day. Rather than simply declaring the toy broken, I had investigated the problem, understood how the system worked, observed the failing component, analyzed the cause of failure, and, most importantly, corrected the problem. But, upon further reflection, I realized how being an engineer had worked against me. After all, human error by the consumer (my friend) was much more likely than mis-assembly by the factory. Someone less intent on finding a mechanical problem would likely have thought of the possibility of a human cause. For that matter, someone less comfortable taking things apart would have probably started with the one user-serviceable part: the batteries. So, sure, I can now explain the inner workings of a disc gun — but I could have solved the problem in 30 seconds instead of 30 minutes if I had come at it from a different angle.
I suspect I make analogous mental errors in lots of other situations. In 2015, I shall try to determine when not to think like an engineer. Perhaps I should start by making a requirements document and developing some acceptance criteria. Or is this a problem where thinking like an engineer is unhelpful?
Technically it’s thinking like a novice engineer. This is behavior we all first go through and now I’ve been become quite adept at breaking in fresh out of college interns/new hires. The novice always complicates the solution – the experienced engineer starts at the easiest and works backwards (user error is easy to diagnose). I’ve gone back through old designs of mine and found they often contain superfluous elements that added complexity and failure modes.
And with that a related legend that I’ve always enjoyed http://www.snopes.com/business/genius/where.asp
Bryan, I agree that a better engineer than I would have started in the right place. So will I, the next time I see a problem like this! I’d like to think that in the software domain, I’d have been much more likely to get to the more likely answer more quickly; I’m a novice mechanical engineer, but not a novice software engineer. In any case, I plead guilty to sensationalism in my choice of title!
One of the things I notice here is that you may well have been applying knowledge from the wrong domain. There are very few toys these days that are electric but yet have so little electronics that they will do anything at all with the batteries in backwards. And so, for most toys, the observed symptoms (“it runs, but runs wrong”) would immediately rule out the problem being a mis-installed battery.
(For that matter, most battery boxes used to be designed so that if you put the battery in backwards, the battery wouldn’t make contact on one end. This seems to be becoming less common, sadly.)
So the lesson I’d draw from this is question your assumptions — which requires being aware of them! — and think broadly before thinking deeply. I run into analogous issues when interviewing candidates sometimes; some of them will quickly latch onto a small piece that looks like part of the solution to the problem and start deriving algorithms and writing code, without first working out whether it’s a piece of the right way to solve the overall problem.
Or, in another analogous example, consider the way that the most useful response to “how do I make my software do this strange thing?” is often, “what are you really trying to do?” and then explaining the better way to accomplish that goal that doesn’t involve the strange thing at all.
Thinking like a toddler considered helpful: Ask yourself “Why?” in an iterative loop until you stop getting good answers, and then ask it a couple more times to be sure!
Thank you for the advice!
“Battery backwards doesn’t make contact” is more uncommon for a practical reason: modern rechargables’ nubs are so short (or rather, the non-nub part is so long) that the ridges will actually prevent a correctly-installed battery from working.
Every engineer should work in tech support for a few days 🙂