The Steve Jobs School of Code Review

You might not be surprised to know that I'm a tough code reviewer. I teach people to see flaws in code most would find innocuous, and how to program at a higher level than most can imagine.

It's hard to lift people up to produce code at that level, but I've been refining how to do it for 7 years. But, perhaps counterintuitively, it's even harder to lift code to that level without lifting the people. A linter can tell you that the loop you wrote is already a function in the library, and an outsider can tell you that some of your edge cases can be merged. But the heart of code quality is about cleanly expressing ideas. To envision code that achieves this quality, I need to understand the essence of the design and the problem as deep as the creator.

But sometimes I really want someone to produce higher quality code, and I don't have the understanding to just tell them exactly how to do it. And for that, I have a trick, one I like to call "the Steve Jobs school of code review." Not that Steve Jobs ever did code reviews, but he did have a way identify room for improvement despite lacking details.

When engineers working on the very first iPod completed the prototype, they presented their work to Steve Jobs for his approval. Jobs played with the device, scrutinized it, weighed it in his hands, and promptly rejected it. It was too big.

The engineers explained that they had to reinvent inventing to create the iPod, and that it was simply impossible to make it any smaller. Jobs was quiet for a moment. Finally he stood, walked over to an aquarium, and dropped the iPod in the tank. After it touched bottom, bubbles floated to the top.

"Those are air bubbles," he snapped. "That means there's space in there. Make it smaller."

[source]

Jobs did not understand all the electronics inside the device, but he had a very strong intuition for how large it should be, and a test to show that it was possible to shrink it. When reviewing code, we may not have the depth of insight won by debugging and testing every line, but we can have a strong intuition about how complicated something should be. When the complexity before us exceeds the essential complexity, there are air bubbles of accidental complexity to squeeze out.

And so when I read code, I like to listen to my gut about how simple something should be. When I write code and find myself touching many data structures to answer a question, it's a sign that there's some clearer way to think about the problem that I'm missing. When I review others' code, I listen to my gut as I figure out where to look harder for specific improvements to suggest.

A code smell is an easily-noticeable heuristic that something deeper is wrong. And so searching for extra complexity is the mother of all code smells.

And I can "teach a man to fish" by encouraging others to do this process themselves. "Can you state clearly what this does," I ask. "Does it sound like something that should take 10 lines and 2 conditionals?" When they answer no, an opportunity arises to turn quotidian labor into a puzzle. Or if they realize the answer is "yes," then they know they may relax, for pursuit of further simplicity would be in vain.

Steve Jobs led great achievements in industrial design, UX design, product design, and film. Perhaps he could have been a great code reviewer as well. There's no other modern hero to remind us how an eye for excellence transcends fields.