Moving beyond the "what" to the "why"

Earlier this afternoon I posted this thought to Twitter:

Scary Thing #1 as an engineer: people who just want the magic words rather than wanting to understand the problem.

My buddy Geof suggested on Facebook that I should take it easy on managers, but I let him know that no, I wasn’t talking about a manager, I was talking about a fellow engineer. And so then I got to thinking.

Now, I work in the aviation industry. We have very strict regulations and processes we follow when we write embedded software, and for good reason. Let’s face it, when you’re next flying in an airplane, you’d like to hope that we didn’t screw up the code in your Flight Display or your Autopilot or your GPS. So at the beginning of a development program we write a software development plan, where we explain in nauseating detail exactly how we’re going to go about developing the software. The tools we’re going to use, the processes we follow to review the code and fix any errors, the way we’re going to test it, the whole nine yards.

Now, if you’re a new hire right out of college, I expect that you’re going to be able to take that Development Plan and follow the processes we’ve defined. And I don’t really expect you to understand yet why we’re doing it. But before too many years go by you have to make the step to get past understanding the “what” of the Development Plan and get to understanding the “why” we wrote it that way.

Sure, some training will help. Sit down and read a copy of DO-178B sometime when you get bored. And some mentoring along the way is very valuable. But eventually, if you’re gonna turn into a really good engineer, you’re gonna have to be able to think through it for yourself. Hmmm… Here’s our regulatory objective. Here’s how we’ve done it in the past. But… we could do something different, it would be more efficient, and it would still achieve the same root purpose_, which is what we’re really after._

Because engineers, after all, are a pragmatic people. (We’ll ignore the curmudgeons among us for a minute.) On the whole, their primary objective isn’t simply following the book. They’re more interested in finding an efficient, elegant solution that does it right and, in our industry, does it safe. Beyond that, if you’ve got an idea, say so!

So this is my plea to my fellow engineers out there. (And yes, the fact that I’m writing this at 8:30 on a Friday night is sad proof that I’m an engineer.) Use your heads. Think about it. Start trying to understand the why and don’t just be satisfied with the what. Eventually it’ll start to make sense, and when it does, you’ll be well on your way to becoming a successful senior engineer.