TONY: We should take this outside. JARVIS (O.S.): I must strongly caution against that. There are terabytes of calculations still needed – TONY: We’ll do them in-flight. Before Your Take it Outside (Ship) There’s been a lot written in our industry about the value of taking it outside (shipping). Today I’d like to write a little more, with an idea that I think makes the value of shipping clear: shipping tells you, precisely, what matters. ...

I was the third engineer hired by my company, not counting our technical co-founder. I like that position, and it seems to play to my strengths. Who Is the Third Engineer? Who is the third engineer? Looking at the startup hiring process, I’ve noticed a pattern. The first engineer is usually a trusted senior that the founders know. The second engineer is the same, or a referral from the first engineer. ...

Today I’d like to talk about a quality that’s essential to success as a computer programmer. Let’s call it “comfort with discomfort.” As programmers, we live in this unsettling space. Here are some thoughts on discomfort and tips for dealing with it skillfully. Example: Grow Cube When I first started programming, I took a computer science course that presented a puzzle called the “Grow Cube.” You can play it online here: ...

Often, when you work as an engineer on a small team, you don’t have dedicated designers on staff. How can you deliver beautiful, intuitive software without designers? Here’s a trick that helps me: decoupling my design work from my engineering work. Clarification: I Love Designers! Let me start by saying: I love designers! An expert designer is one of the most vital people in an engineering organization. I’m not a designer. Great designers are rare, which is why, for much of my career, I haven’t had one. ...

Our industry has a concept of “10x engineers”, individual contributors who have the impact of ten colleagues. How can you become one? I’ll try to answer that in this post. But first, here’s the price of admission: you first have to be both fast and competent. And that’s not enough. What’s fast? Reducing waste in every part of your development process. Cutting to the bone the time it takes to type, save and share your work, communicate, and hack your way to something good enough to ship. “Fast” and “great” are tightly correlated in this field. ...

If you’ve ever watched me debug, you might think I’m moving slowly. That’s because I try hard to find every marker on the debugging trail. I believe this is one of the most valuable skills in debugging. What’s a Marker? Let’s say our debugging session is a trail through the forest. ‘O’ is where we are, and ‘X’ is the summit of a mountain. At ‘O’, we know little. At ‘X’, we understand the bug and we’ve fixed it. ...

Reviewing code is tricky. When I’m doing it, I’m trying to achieve a few things at once. In this post, I’d like to document the ways I try to add value via code reviews. My Background & Biases This is the second post I’ve written on this subject; here’s the first. Since 2022, my approach has shifted from strategic to tactical; I don’t prioritize design (the high-level programmatic approach) as much, which I’ll explain in a moment. ...

I recently calculated that I merge 0.8 pull requests every day into my team repo. Let’s round up and say I merge about one PR every day, delivering one or more features to production. I like this velocity, and in this post, I’ll explain how you can achieve it yourself. My ideal day as an IC goes like this: Morning: start a ticket Early morning/early afternoon: open a PR Early afternoon: respond to comments and merge PR Afternoon: deliver work to a QA environment Late afternoon: deploy to production This doesn’t happen by accident. It’s the result of processes— mine and my team’s. These are the ingredients of those processes. ...

I’ve been a practitioner of Shawn Wang’s ‘Learn in Public’ for years. In this post, I’ll share a list of ways I’ve found to learn in public. I think that learning in public can start with you, then your team, then the world. And so, these are ordered from small and private to big and public. Talk through a tough problem out loud. Instead of holding a difficult problem in your head, try building a solution out loud from a series of facts. “We’re seeing a bug on staging. It affects this page…”. Talk to a duck if nobody is around. ...

I recently hit a decade of professional programming. I’d like to take a moment here and reflect on what I’ve learned. This post is for me ten years ago. These ideas are always evolving. Maybe they’ll reinforce something you heard somewhere. Maybe you’ll agree, or disagree. I’d be interested to hear either way. Start now. “The best time to plant a tree is twenty years ago. The second best time is now.” Transitioning to programming was a leap for me. I wasn’t sure it would work. Now most people assume I’ve been doing it forever. It’s amazing what can change in ten years. Get started now. ...