These are my longer essays.
Bugs are part of software. Reporting bugs well is a necessary skill in an ever-growing number of job titles. In this post, I’d like to explain how to write a perfect bug report and offer some bug-reporting best practices. ...
Imagine you’re debugging, and you’re stuck. I have a technique that’s going to help. Think of an action you might take. Predict what will happen when you take that action. Take the action. Check if you were right or wrong, consider that information, and repeat. ...
We’ve all seen a desire path. They are footpaths created by erosion from human and animal traffic that communicate a wish for a path that doesn’t exist. When you walk on a paved path toward a destination and notice a shortcut in the earth, that’s a desire path. It’s the way people go, rather than the way we would wish them to go. ...
Ben Kuhn’s ‘Think Real Hard’ shares a problem-solving checklist from the scientist Richard Feynman: Write down the problem. Think real hard. Write down the solution. On its face, this advice is ridiculous. If only we just sat and thought about the problem, we’d win a Nobel Prize like Dr. Feynman! ...
Scenario: you need a database record that can belong to one record or another, but not both. Polymorphism and exclusivity. One approach is to create a polymorphic-style association at the data layer. By doing so, you’ll get data integrity built in, rather than trusting it will be enforced by each tenant at the application layer. ...
A lot of people start programming with shared dotfiles, copied from a team or online. I did. Maybe you’re ready to move on; how would you do that? ...
You’re creating a React app, and want to organize your components. Or maybe you’re working in a legacy codebase, with many components in one directory, and you want to better organize them. In this post, I’ll document an approach to this problem that has worked for me. ...
I used to have a bad habit when working alone: I’d start a feature, begin doubting my approach, throw away my work, and start over from scratch. Sometimes more than once. The result? Wasted energy, abandoned code, confusion about what I had and hadn’t implemented, and repetitive rework. This post is a collection of thoughts on this practice. ...
Some code is broken, and you can’t figure out why. Maybe there are a lot of changes, and identifying the breaking change seems impossible. Or, maybe you’re curious about how things break in your organization. The tool you need is git-bisect. ...
You’ve been working on a big set of changes, and haven’t committed to Git yet. Now, you want to commit some, but not all, changes to a file. Let’s look at adding patches. ...