Posts

When I was learning to program, I was fortunate to pair with very experienced engineers. One day while coding, I said: “I think we need to use Ruby’s map method, but I’m not sure how that works. Let me look it up.” Later, my pair offered some feedback: “You can’t be looking up map. You need to know how all of Ruby’s Enumerable methods work.” This bit of radical candor was part of a series of challenges I faced early as a junior engineer. They shook me out of impending Expert Beginnerism. They expanded my concept of engineering excellence. ...

When I don’t feel like I’m making sufficient progress at work, I have a favorite technique: asking “What would finishing this today look like?” It’s a version of one of Tim Ferriss’ favorite questions: “‘What would this look like if it were easy?’ If I feel stressed, stretched thin, or overwhelmed, it’s usually because I’m overcomplicating something or failing to take the simple/easy path because I feel I should be trying ‘harder’…” ...

A design principle that’s crept into my programming could be summarized as: “Absence of color is better than the wrong color.” Color in user interfaces is hard. It’s a powerful overlay to your design that can carry positive, negative, or conflicting messages. It should be carefully applied in isolation from other design choices. An esteemed web designer I worked with once told me: “Color is the last step of my designs.” They’d make grayscale mockups, then pixel-perfect renderings, choosing fonts, icons, buttons, layouts, etc. At the very end, they’d sparingly apply colors: a brand-colored button, a secondary brand-colored link to send a support email. ...

One of my favorite product hacks is asking: “What’s the why?” Asking “Why” Before delivering a feature, stop and ask: why is this feature worth adding? Why is it worth the time for your teammates to review, for your stakeholders to approve, and for your users to adjust to? What are we getting from adding it, that’s better than anything else we could be building? It’s a shift to ownership. Here’s non-ownership: “Every app has a logout feature.” And ownership: “Our customers must be able to log out because we display sensitive information.” Non-ownership: “Our competitors’ apps send push notifications.” Ownership: “We can connect better with our customers throughout the purchasing process with push notifications.” ...

Write a little bit of code, and you may come to an unsettling realization: there are multiple ways to do almost any programming task. How do we choose between several that work? I manage this uncertainty with a guideline: writing boring code. In this post, I’ll explain what “boring” means to me. A not-boring example Sometimes programmers will write traditional JavaScript function functions and arrow functions in the same codebase: ...

Something I’ve learned as an engineer: when presented with the option of working on a big project, or doing anything else, take the big project. The Big Project™ is a new dashboard, an AR/VR/AI integration, an experimental mobile or hardware app, etc. They take multiple people days to plan, and at least a month to complete, possibly with multiple engineers. People on the team are excited (and possibly a bit intimidated) by the idea of being the lead on the Big Project. ...

We spent the time writing tests, and yet, a bug survived. Should we just stop writing tests? No, but we should maybe write better tests, and think about them differently. In this post, I’d like to explain a mental model I have that helps me write and maintain tests: thinking of bugs, and the tests that cover them, in classes. Bugs and Tests in Classes Every test has limitations. Unit tests miss the big picture, end-to-end (E2E) tests miss the details. Rather than chasing the impossible, that the test suite catches all bugs, I’ve found it’s preferable to think about bugs and tests in classes, like the classifications of the animal kingdom. ...

Have you ever seen a pull request that seems to completely explain itself? It’s a real artifact. I don’t know the project, yet I understand it. How can we get results like this on every pull request, from every developer on the team, every time? The answer is a pull request template. Templates give your team a format that’s detailed, discoverable, and predictable. In this post, I’ll share this technique and why it matters. ...

Here’s some advice about programming I’ve found useful: “Don’t ask for advice; ask for a code review.” In this post, I’d like to explore what I think this adage means. When learning programming, we think there’s a trick to it, that can be solved with advice. If I… …learn the right language, framework, or text editor …attend the best CS program, bootcamp, or workshop …master the ideal learning strategy or morning routine …I’ll have an advantage. In my mentoring of new programmers, many of the questions I answer are about topics like these. I think the answers matter much less than people might think. I stopped giving generalist career advice for a while because I felt like my answers to these questions weren’t helping people. Or that I was communicating my privileges and survivorship bias. ...

When it comes to controlling frontend presentation, developers often rely on booleans. However, this approach can be limiting. In this post, I’ll explore the drawbacks of using booleans and introduce a more versatile alternative: plain old strings with type safety. While this example uses React, the principles can be applied to other frontend frameworks as well. The Setup The React useState hook gives us local state, and it’s often instantiated with a boolean. Open any complex React codebase, and you are sure to see something like this: ...