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 to consider, and identifying that breaking change seems impossible. Or, maybe you’re curious about how things generally break in your organization. The tool you need is git-bisect.

Great programmers aren’t fast because they’re great. They’re great because they’re fast.

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.

A programming style I try to practice could be described as: “there should be only one way out of a function.” Early returns can often cause more confusion than they’re worth. When possible, I avoid them in favor of a single return.

“The best time to plant a tree was twenty years ago. The second best time is now.” – Chinese proverb

I mentor adults who are learning to program after serving in the military. Some are in their late twenties, and some are twice that age. A common concern is that they are too old to be changing careers to programming.

In Things You Should Never Do, Part I, Joel Spolsky narrates Netscape’s ruinous decision to rewrite their browser from scratch. This introduced the following concept to me: “It’s harder to read code than to write it.” I believe this is true. Today I’d like to explain why.