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! But what can we learn from this idea? In this post, I’d like to explain how I’ve used this advice to solve the hard problems in my work. ...
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? Recently after 6.5 years, I removed the Hashrocket Dotmatrix, a powerful set of tools, from my workstations. In this post, I’ll discuss these tools, and why and how I uninstalled them. What is the Dotmatrix? The Hashrocket Dotmatrix is a set of configurations built by generations of consultants at my previous employer, Hashrocket. ...
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. They are: It’s okay to start over, for the right reasons Prioritize getting it working Save your work When getting help, don’t show up empty-handed It’s Okay to Start Over Code Retreats is a programming community that encourages throwing away first drafts. Starting over can be helpful when you’re learning a new technique or trying to improve. ...
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 Practical Example As an example, consider the “liking” feature of Today I Learned. This is an icon under each Today I Learned post that you can click to indicate: “I like this post.” ...
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. ...
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. ...
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. ...
When possible, I prefer to use the presence of data to represent a boolean, rather than a boolean itself. Example: Error State Here’s a bug vector I see a lot in frontend code. Imagine we’ve made a network request that returns an error. Our code sets a boolean errorState, meant to convey “we are in an error state”, to true. Then we display an errorMessage in that condition: if(isErrorState) { displayMessage(errorMessage) } The problem here is that we now have two variables tied to our error condition: isErrorState and errorMessage. And when that happens, it’s easy to put the app into one of these illogical states: ...
An idea I find useful as an individual contributor is starting my consulting with this phrase: “I think that…”. The idea is to let your arguments stand on their own, rather than appealing to your experience or other authorities. I think a mark of a mature engineer is having strong opinions, weakly held, that you can articulate. Having some experience is a conundrum. You know a lot of good and bad ways to do something, but you can’t just download your expertise onto someone else. If you don’t share it wisely, it’s easy to sound pessimistic, preachy, or arrogant. ...