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.

A common anti-pattern on sites where code is discussed, such as Slack, Stack Overflow, GitHub Issues, etc., is to post a screenshot of code when asking for help. This technique has many problems, and there’s almost always a better alternative.

Conditional logic has its place, but often there’s a better alternative. Today, we’ll look at a Ruby solution: a hash with .fetch.