This post is about how to write software well. It was inspired by this post with a similar title. Read it and write yours. These ideas aren’t advice but rather notes about how I do my best work. If you’re new, some of these ideas might seem obvious, but they get harder as you progress, or your understanding of them deepens, or you’ll encounter engineers who embody them in surprising ways. ...
Our industry has a concept of “10x engineers”, individual contributors who have the impact of ten colleagues. How can you become one? I’ll try to answer that in this post. But first, here’s the price of admission: you first have to be both fast and competent. And that’s not enough. What’s fast? Reducing waste in every part of your development process. Cutting to the bone the time it takes to type, save and share your work, communicate, and hack your way to something good enough to ship. “Fast” and “great” are tightly correlated in this field. ...
Over the past decade, I’ve settled into a daily programming routine that helps me stay productive. It centers on code review, moving tickets forward, finishing in-progress work, and documenting what I learn. Here’s the exact workflow I use. Why Have a Routine at All? Many programmers don’t have a routine. So, first let me answer: why have one at all? A routine at work can be a double-edged sword; overemphasize it, and your day can feel too predictable. ...
Great programmers aren’t fast because they’re great. They’re great because they’re fast. I’ve sunk a lot of time into being fast at Vim. I’ve used it as my text editor for eight years, co-organized a Vim Meetup, and I’ve written about Vim on this blog and Hashrocket TIL dozens of times. Why? Because I want to be a fast programmer. In this post, I’ll explain why I think being fast at programming is a worthy goal. ...
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. I learned this in IT. When a screen froze, the IT professionals I worked with would stop and count to ten before taking action. You’re watching a process run, it seems to have frozen, and you’re getting no instructions. Before killing it, stop and count to ten. If the process is still hanging after that, kill it, if you must. ...
“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. ...
A concept that I admire is ‘Doing the Hard Thing First’ via Ben Orenstein. Ben described on the Art of Product Podcast Episode 50. Here’s my summary: Choose the hard part of the problem, the part you’re unsure about, the part that success depends on, and solve that first! The Hard Part of the Problem The hard part of the problem will be the most differentiating, and therefore valuable. If it was easy, there would be no opportunity. You’re lucky that Schlep Blindness has failed to hide it from you. It might be impossible, at least the way you’re thinking about it. Solve that problem first before investing any more time in the idea. ...
Write programs that do one thing and do it well. –The Unix Philosophy I believe in working small. I love small Git commits and pull requests. When I commit, I like a short message. The code should only do what’s described by that message, in limited migrations, each of which can be rolled back. The changes should touch a limited number of files, and leave a green test suite. Everything should be reversible without side effects. ...