Engineering

The best code is the code you don’t write. The second best is code that’s obvious. I’ve been thinking about this a lot lately. Early in my career, I was proud of clever solutions. Now I’m proud when someone reads my code and says “that’s it?” A few principles I try to follow: Delete before you add. Can you solve the problem by removing something? Boring is good. Use the obvious pattern. Save creativity for the problem domain. Optimize for reading. Code is read 10x more than it’s written. None of this is original. But it’s easy to forget when you’re deep in a problem.

We spend years learning to write code. Courses, tutorials, practice problems. But reading code? You’re mostly on your own. This is backwards. Most engineers spend more time reading code than writing it. Understanding a codebase, reviewing PRs, debugging—it’s all reading. A few things that help me: Start with the tests. They show intent. What is this code supposed to do? Follow the data. Where does it come from? Where does it go? What transforms it? Read the types. In typed languages, signatures tell you a lot before you read a single line of implementation. Use your debugger. Step through execution. Watch values change. It’s faster than staring at static code. Like any skill, it improves with practice. Pick an open source project you use and read it. You’ll learn something.