A common, problematic 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) The idea is “we need two users to compare behavior against, so let’s make User A and User B.” In this post, I’d like to argue for variable names like this: frequent_user = create(:user, last_log_in: today) unengaged_user = create(:user, last_log_in: last_year) frequent and unengaged are not literal suggestion, but rather representatives of an idea. That idea is that such variables are visually distinct and carry more meaning. ...

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. Identify Alias Opportunities With the ’typeless’ Command I found this trick a long time ago from, I believe, Thoughbot’s Upcase course. I call it typeless, and it’s a well-worn alias in my .zshrc: ...

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. YAGNI— You Aren’t Going to Need It. Why? I believe it: Is a relic of the past Doesn’t do what people think Isn’t Ruby-ish Is associated with unproven performance claims I’d like to see it deleted from the code I work on, and I don’t think we should be enforcing its presence most of the time. ...

When I create Agile bug tickets, I leave the story points blank. Why? Two reasons: pointing bugs creates the wrong incentives, and bugs are hard to estimate. Bug Terminology First, some context. Pointing is an Agile process of estimating how long a piece of work will take, or how complex it is. Bugs are defects in a computer program that produce undesirable behavior. And so, pointing bugs means trying to estimate how long it will take to fix a bug, or how complex it is. ...

“What did you do this week?” I’ve written a weekly summary for myself and my teams for years. It helps me think through my work and shows people what I’m working on. In this post, I’ll explain how to use this tool. Why write a summary Why write a weekly summary? Two reasons: it helps me think through my work, and shows people what I’m working on. Taking thirty minutes to pause, reflect, and plan helps me sharpen my thinking and transition from week-to-week. Many developers keep a rubber duck on their desk for this reason. Rubber-ducking lets you talk through your problem at the speed of speech, and is excellent at exposing shaky assumptions. Weekly summaries codify this into a predictable, public routine. ...

Here’s a technique I’ve used on launches: instead of a big scary waterfall, or, in tandem with a phased release, let customers opt into a new feature. On the first step of your legacy app, add a link to the new app that says “Try our new beta app!” Then, add add a link to the new app that says “Go back to the legacy app”, and track clicks to it. ...

I have collected a group of mentors over the years. I call on them frequently to talk through tough problems. I think I’m better at my job because of this regular, impartial outside feedback. I’d wish this for everyone! In this post, I’ll try to reverse-engineer the path I took to get here. I think it comes down to three things: finding smart people, being mentorable, and giving back. Find Smart People First, you have to find great programmers to learn from. ...

An engineering technique I recommend: when you sign up for any service, even on a side project that’s just getting off the ground, create an email group called dev@<your-domain.com> that forwards to you and any other technologists, and use that email to sign up. I’ve worked on dozens of projects where the founding programmer signed up for every conceivable infrastructure service– think AWS, Heroku, Google, Facebook, etc.– with their personal email or individual work email. The problems this causes are many. ...

Here’s my simple framework for answering questions on Stack Overflow that reach and help people and earn reputation. I answer questions by: Finding the question Gathering information Answering quickly Making comments obsolete As a working example, here’s an accepted answer of mine: ‘Converting React files to Typescript’. I’ll be referencing it throughout. Why Bother Answering at All? But first, let’s check in. Why bother answering questions at all? You don’t get paid or promoted because of it. ...

Hard-coded test expectations have many benefits that I’ll explore in this post. Here’s a kind of assertion I see often in tests: # Code class User < ApplicationRecord def full_name "#{first_name} #{last_name}" end end # Assertion expect(user.full_name).to \ eq("#{user.first_name} #{user.last_name}") And here’s that same assertion with a hard-coded expectation, which is almost always better: expect(user.full_name).to eq("Jake Worth") A hard-coded expectation is an assertion about behavior that is just dumbly spelled out. They’re better because: ...