Understanding Requires Real Work

Originally published on Tumblr.

People learn differently. I learn by doing.

When I studied physics, I could memorize all the equations I wanted, but until I’d demonstrated them with a physical experiment, I don’t think I ever fully understood them. That’s probably why I ultimately gave it up. Once demonstrable proofs started requiring equipment my school couldn’t afford, I couldn’t keep up.

Things aren’t so different in the software world I live in now. I’ve noticed this over and over. I’m happy to learn a language by reading a book, but it takes a lot of hands-on work to really know it. I understand CSS, but I’m like a two year old with his first crayons when I try to do anything remotely interesting with it.

I’m a long ways from my physics days, and I’m not building web sites, so I’m not embarrassed to admit these deficiencies. It’s a lot harder to admit that the same is true with my company’s product.

We deliver a service via an API. I was involved in early design session. I sat through meetings about the pros and cons of various decisions. I reviewed various drafts of the API. I watched it evolve. And I sell our service, so I talk about its API all the time. But until this week, I didn’t completely understand it. I didn’t completely understand how well designed it is, and I didn’t completely understand how powerful it is.

So what changed?

I finally got a chance to perform a physical experiment. Last week I decided to write a wrapper for the API in a language that I still vaguely remembered. Because I’d just delayed a trip to the UK, my week was pretty clear, and I had a three day weekend at the end of it. I figured I could do it.

It was difficult. It was much more difficult than I expected. It made me feel stupid, frustrated, and sometimes happy.

I struggled to re-familiarizing myself with a language I used to know well. I had to catch up to three years of changes. I had to re-connect with the discipline of programming. That meant ignoring my mail, my twitter feed, and the people around me. But mostly it meant that I had to completely understand our product, understand it well enough to use it, not just sell it. I had to understand its subtleties, its structure, and its point of view. And what I learned was exciting.

I learned that our product is better than I thought it was. I learned that it’s richer, and more robust. I thought it broke new ground, and now I know it does. I learned that it’s coherent in a way I wouldn’t expect a 1.0 product to be.

And I remembered that understanding requires real work.

I spent four or five solid days to reach this point. It wasn’t efficient. Every engineer in the company is a better programmer than I am, and everyone could have done a better job faster. And because I was time-constrained I asked a lot of questions I should have resolved on my own. Sometimes I could hear the “I wish our CEO would go back to doing his job" in the answers I received, but everyone ultimately put up with me gracefully.

I’m lucky I had time to do it. This will help me do my job better.

Two lessons I learned:

It’s critical that everyone in the company stay intimately connected with our product. I don’t know how to do this for non-technical personnel, but we need to figure it out.
Every technical person needs to use the product. It’s not enough to build something related or supportive. That doesn’t give a sense of what we’re selling, or what we’re trying to achieve.

I couldn’t be so excited without being grateful. I’m grateful to my co-founder who managed to design and build this product despite having to deal with the same startup distractions I do. We’ve been working together for twenty years. I should know what he’s capable of, but sometimes I forget. And it it takes real work to remember.