A list of things I used to believe and don’t anymore, collected over twenty-odd years of building products and teams.
Compiled languages are safer than interpreted ones
ā¦until 2013
I began my professional career writing Java, and Java taught me that correctness was the compiler’s job. If it built, it was probably right. That felt like safety. It took me years to see the crutch: I had no testing practice, so a clean compile was the only thing telling me the code worked.
Tests changed that. Once tests describe what the system should do, the compiler stops looking like a safety net and starts looking like spellcheck. Betterment began as a Java shop. When we considered replatforming in Ruby, plenty of us were wary. Yes, we decomposed our Java monolith, bit by bit, into distributed domain services on Rails. The biggest pieces of the investor experience have been running on Ruby for nearly a decade. Safety comes from how you prove the code correct, not from the language you write it in.
Good, expressive code doesn’t need comments
ā¦until 2020
Ruby taught me how much you can say with a name. Code can read like a sentence, so I decided comments were a failure: if your code needs one, your code isn’t good enough. I discouraged using them at all.
I had overcorrected. Code can show you what it does. It can’t tell you why. Why this tradeoff, why we don’t do the obvious thing, when to reconsider. Comments that document decisions are some of the most valuable lines in a codebase.
The software is the thing that matters
ā¦until 2017
I used to think the software was always the product. Make it elegant, make it fast, make it correct, and the rest would follow. Then I spent a few years at MealPal, where the product was a $5 lunch that should have cost $15. Nobody was paying for an app. Get the price right and people forgive almost anything; you could take orders off a spreadsheet and they would still line up. (We did. They did.)
What makes or breaks a company is almost never the software. It’s the people, the focus, and a real understanding of the problem you’re solving. The software is how the product reaches the person who wanted it. That’s all, and that’s enough.
Managers get in the way, and they don’t want my help
ā¦until 2013
For most of my early career I thought managers were overhead: people whose job was to fit me into an org chart. On every team I hit the same wall. Something was broken, I knew how to fix it, and the answer was “stick to the roadmap.”
Then one manager did it differently. Instead of managing the frustration out of me, he aimed it. Go fix it, he said. That’s your mandate now. He called me a wolf and got out of the way, and that space turned into real leverage for the whole team. A manager who clears the way is the highest-leverage relationship you have. I’ve spent the back-half of my career trying to be that for other people.
Excelling at your day job makes a career
ā¦until 2015
I believed in a kind of cosmic justice about work. Give a company your nights and weekends and it gives back; do great work quietly and you’ll be taken care of. It’s comforting, and it’s false. No one is watching your work as closely as you. Waiting to be noticed is a strategy for staying exactly where you are.
Doing a job well proves one thing: that you fit that job. It’s not a claim on the next one. If you want more, you have to say so, out loud, to the person who can do something about it. I waited instead, and I paid for the silence in time I don’t get back. No one is coming to advocate for you. The people worth working for would rather you asked.
It’s good and right to appear smart
ā¦until 2016
I used to think sounding smart meant having the answer ready before anyone finished the question. It came from insecurity: when you’re not sure you belong, you hold onto every edge you have. Tricks, jargon, big words. A big word is a small wall.
The people I learned from, whose counsel I sought out, did the opposite. They focused on expressing ideas accessibly and showed up curious. An answer worked out alone and handed over whole might be expedient and right, but it leaves people feeling talked at, without being committed co-owners in the solution. The joy is in the solving.
Parting Thoughts
Changing your mind is the work. These are hard won lessons, and there will be more. The next version of me is already re-reading this, shaking his head, and adding entries to the README.