Auto-formatting code is good, and you should be doing it all the time. Why? It helps you write better code in real-time, preempt trivial discussions, and maybe even democratize programming.

Code reviews are important on many teams. Do them well, and your code ships quickly and safely. Do them poorly, and your code ships slowly and riskily. I try to contribute good code reviews. In this post, I’ll share my process.

I think the most important factor in consistent delivery is understanding the work. When you understand the work, you build what the stakeholder wants, better and faster.

We’ve all seen this: a frustrated coworker hunched over a computer after hours, flailing alone against some impossible bug. Go home, coworker. Don’t stay stuck.

I’ve been using, teaching, and stanning Vim since almost the beginning of my programming career. Yet, when asked to explain this preference, I stumble. In this post, I’d like to explore why I love Vim.

Today I want to talk about a common technique: disabling failing tests to allow a feature to ship. Maybe sometimes you gotta do it. But long-term I think it causes more problems than it solves.

Here’s a trick that that has helped me as a programmer: before doing anything major, like killing a process, stop and count to ten.

A convention I see in Ruby tests are variable names like this:

user_a = create(:user, last_log_in: today)
user_b = create(:user, last_log_in: last_year)

Any command you type out manually, or even tab-complete a few times, can be shortened. A common shortening technique is the terminal alias. Here are some tips that help me write better aliases and cut my terminal keystrokes.

Open a production Ruby file, and you’ll often see this magic comment at the top.

# frozen_string_literal: true

Today I’d like to argue that most Ruby files do not need this comment. You aren’t going to need it.