Posts

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. ...

Receiving feature requests is part of running a software team. Here’s how I handle them. What are Feature Requests? Feature requests are requests for behavior in a software product. Sometimes bugs get lumped in, too; it’s often a little messy. Feature requests come from both inside and outside your company. Some are valuable, some aren’t, others contradict things we’ve already built, or may want to build. Some come from customers who are about to churn. Others might make sense for one customer but would confuse others. ...