Today I want to talk about a way I think about debugging: as a story that we tell to ourselves and each other. We often face bugs without much information. Consider an error like this: npm run build The 'compilation' argument must be an instance of Compilation What? This error comes from my work, and changes that I made caused it. I pushed a change to our codebase that removed a flag hiding errors. When the errors were exposed, we had to upgrade dependencies. Along the way, I broke the build, and no one knew it for a while. ...

Want to learn a tricky topic and sharpen your learning skills at the same time? In this post, I’ll use the Feynman Learning Technique— a method of learning complex things by explaining them simply— with a sprinkle of LLM magic, to deepen my understanding of JavaScript promises. What is the Feynman Learning Technique? The Feynman Learning Technique is a learning method defined by Nobel laureate physicist and bongo drummer Richard Feynman. My perception is that it’s been pieced together from things that Dr. Feynman said over time. ...

I’m proud to announce the launch of my digital guide to software debugging, Don’t Stay Stuck: A Debugging Guide for Rising Engineers! I’ve been working on this guide on nights and weekends, and it’s the distillation of a decade of debugging triumph and tragedy. Product Pitch Have you ever been stuck on a tough bug and felt you had no path forward? You’ve tried everything you can imagine, and nothing is working? And then: a sharp engineer drops into the session, asks a few questions, and fixes the bug almost immediately! What is this superpower? ...

Today I gave a talk to my team about the Twelve-Factor App Methodology. The Twelve-Factor app is an important methodology for building software-as-a-service drafted by developers at Heroku in 2011. It outlines best practices for app setup, portability, deployment, and scalability. I chose to share this because I think it’s relevant to all software engineers, and part of our shared language and conventions. And, I want the teams I work with to follow it, and for each of us to be a champion of its conventions. ...

Confluence was messy. Our documentation felt outdated, hard to navigate, and unreliable. Rather than scrap everything and start over, I decided to try something different: a Kaizen. Here’s what we did, what we learned, and how it went. What is a Kaizen? Kaizen is a Japanese business philosophy that can be translated to mean “Change for the better.” It can be an event, too. Before this experiment, I’d observed a Kaizen workshop once in a factory, but I’d never led one myself, or heard of one done on a software team. ...

A suggestion about data: generate it now, and figure out curation later. Example: Labeling Tickets Here’s an example from my work. When I write software engineering tickets, I label them; if I’m writing a ticket that improves patching, I’d label it “security.” In Jira, those labels are links. Click “security” and you’ll see dozens of tickets that we’ve written to improve our security posture. And so, when a stakeholder asks: “What are we doing about security?”– we have an answer. All because we continually applied one little label. ...

Pastures which are subject to overflow should be avoided. All lambs born in April or May should be drenched about August or September following, to be certain of ridding them of worms that may later cause their death. This is output from a tool I built called Veterinary Ipsum. It’s something I’ve created a few times: a Lorem Ipsum generator specific to my company’s business domain. What is Lorem Ipsum? Lorem Ipsum is placeholder text used to communicate the design of a document. If you’ve ever seen website copy like “Lorem ipsum dolor sit amet”, that’s Lorem Ipsum. ...

“I’m still getting this random 404.” Want to sound pro? Banish “random” from your software engineering vocabulary. Considering the Modern Usage “Random” has a modern usage; let’s consider it. Take this example: “I got a random bill from my dentist.” We hear: “This surprising thing, a bill from my dentist, happened.” We get it. It works. So what’s my issue? Merriam-Webster defines “random” as “lacking a definite plan, purpose, or pattern.” And so, this usage is incorrect, because the bill isn’t random: someone at the dentist’s office sent it to you because they believe you owe money. ...

Eight years ago I wrote a post called You Should Blog. In it, I made an argument that I still believe in: public, professional writing is something every engineer should try. Today, I want to share why I write, and have for over a decade. It’s made me better The first reason is that over time, I think it’s made me a better programmer. To give you an example, here’s an opinion I hold, and how writing helped me solidify it: ...

I think a mark of a great engineer is being willing to change one’s mind when presented with new information. Here are four technological things I’ve changed my mind about. Own Your Confusing Software Before: “If a customer thinks software is confusing, they might just need training.” Today: “If a customer thinks your software is confusing, it is confusing.” When building a SaaS product, it’s easy to write off difficult or noisy customers. Especially if that’s part of a team’s culture. ...