Why?

Recently I had the occasion to start learning and writing firmware.  If you’re like me, you’ve spent most of your software career writing web applications in a high level language, and have never needed to worry about memory management, or space constraints, or even what data structure to use.

Ok, so I’m being a little facetious with that last one, but for most web applications, Big O notation simply doesn’t matter: Most data structures and algorithms are Good Enough.  In fact, you could throw a dart at any major data structure and it will perform adequately for most workloads¹.

So this means Computer science classes are a waste of time, and we should all just start writing Web apps, right?

Well… no. Throughout the course of learning how to program hardware, I’ve encountered from very stark realities: Hardware is the honey badger of platforms. Whereas other platforms may be forgiving, or may let you get away with something that isn’t a “Best Practice”², hardware simply does not care about your feelings and desires to launch software. You have 16KB of Ram, and 256Kb of ROM, and that’s it (and in SoC terms, that’s a lot). All those optimizations that we used to make fun of? Well now we’re doing them.

I wasn’t totally unprepared for this turn of events; I had been going through the Programming Pearls book for years³, and so my mind was open to the challenges of writing low level code.

But, nothing I’ve ever done professionally has really prepared me for this. I’ve worked on a few “Web Scale” projects, but mostly been able to optimize code without having to really do low level stuff. Since there’s a tradeoff to business for optimization, it’s always been a ‘good enough’ approach.

And that’s my fault.

The entire world around me is filled with answers, but I’ve never asked the right questions at the right time. Imagine how good at programming I would be if instead of taking apart the computer and put it together, I simply kept asking people “how can I program this?” Or imagine if instead of partying and wasting my college years playing Tribes, I had asked my professors what I would need to learn to build a compiler?

My father (a reporter and journalist) used to say, “It isn’t the man with the answers, it’s the man with the questions.”⁴

What if I had taken his advice sooner? Where would I be now?

I’m privileged to be able to work across the entire software stack, and working at a hardware startup has been extraordinary; but I can’t help but wonder what I’d be doing now if I had asked questions sooner in life. Would I have gone to MIT? Would I have fulfilled my potential sooner? Would I have understood what I wanted to do with my life sooner?

I’ll never know, of course, but, as they say: The second best time to plant a tree is right now.

If there’s one piece of advice I have for my 7 year old self, it’s: Ask ‘why’, and don’t stop until you’ve found the answer. And then find another question to ask.

1: “Most” meaning most, of course. If you work with Web Applications (or even most applications), your user base or data set just isn’t large enough to worry about this sort of stuff; you’ll generally find greater gains fixing things elsewhere. That isn’t to say it doesn’t matter at all, just that for most of us, it doesn’t matter most of the time. It’s like the Pareto principle, only less succinct.

2: Used un-ironically, for once.

3: Really, I keep picking it up, doing an exercise, and putting it down. It’s like Godel Escher Bach for me.