Permanently forking a library is something I’ve observed on several teams. But, there are tradeoffs that aren’t always obvious. When to Fork: My Mental Model Here’s my mental model for evaluating when to fork: Dead project: this is the easy one. If the software is open-source and has an accommodating license, this can be a great solution to the “Build vs. Buy” question. Capable team that can maintain it: Got a team of pros who want to maintain a fork of a popular library for years? This might work. The library won’t merge or engage with your patch: You need the project to do X, but it won’t. After a reasonable effort, you might want to fork it. The Risks of Forking When you fork, until you pull from upstream or shut down your forked project, you own the code. You don’t have the maintainer(s) to help you, you don’t have new features from active contributors, and you don’t have enough eyeballs to make most bugs shallow. ...

Years ago, I watched a video where guitar teacher Justin Sandercoe explained a way to get better at guitar. It has changed my playing, and it might change yours, too. This isn’t my idea; it’s Justin’s. You should watch his video and visit his website. Why am I writing about it, then? Because I think it’s an invaluable idea, and I want to extend its reach and offer my testimony. Note: This post is part of April Cools, where writers publish something sincere but different from their usual work. I hope you find it interesting. ...

A missing README is rarely just missing documentation. It usually signals other things, too. A project that’s going to be difficult to set up. When I pull down a project without a README, I’m starting from zero. What kind of app is this? What backend, frontend, persistence layer, and dependencies are involved? Has it ever been set up on my operating system? Answering these becomes homework I didn’t ask for. A project whose purpose may not be clearly defined. What is this project? Why does it matter? Shaky domain language. What kind of users do we have (Customers and Employees, or Players and Coaches)? What can those users do? Without a README, this information is needlessly obscure. What if we have great docs outside the repo? Better than nothing, but docs should live close to the code: a text file in the project. This lets documentation travel with the code, ties changes together via version control, and gives the repo a clear front page. ...

A developer experience practice I’ve recently picked up is routine Friday reboots of my workstation. I think this can make your workflow (and even perhaps your life as an engineer?) a little better. Does This Sound Like You? You haven’t rebooted your workstation in weeks, and may be proud of this fact. You’re maintaining legacy code. You find setting up these projects to be finicky. You have uncommitted changes that you have to remember to reapply to get the projects working. You resist reboots or create obstacles to them, like programs that won’t close without confirmation. Sound familiar? I used to wear the identity “I never reboot” as a badge of honor. And yet, I know that rebooting my computer has value. ...

I’ve been participating in fully-remote software standups every day for over a decade, and over the past two years, leading them, too. Here’s how I run the best standup meetings that I can. Guiding Principle: Physically Stand Standups got their name because people physically stood up during them; use that as a guiding principle. I don’t stand up, nor do people on my team, and not everyone can. But, the idea is to keep the meeting tight. Standups shouldn’t be long. They should not be something you can step away from for ten minutes to flip the laundry. ...

Do you want to read more? Over a decade, I’ve been on a journey from casual to power-reader. In this post, I’d like to share the ideas and techniques that have helped me read more. First, some background. My Reading Journey I wasn’t much of a reader as a kid; I was more interested in drawing and building things. Today, I read 40+ books per year. This always includes a few programming books, a habit that’s rare in my field. ...

I recently re-read It Doesn’t Have to be Crazy at Work by Jason Fried and David Heinemeier of Basecamp. Here are some of my favorite ideas. I came up in the Ruby on Rails community, where Fried, DHH, and Basecamp loom large. I don’t agree with everything they say. But, I’ve always appreciated their articulate and passionate arguments about how technology teams can work better. I’ve read every book they’ve written. ...

One of my favorite engineering questions is: “What’s wrong with this idea?” It drives the conversation away from why the idea might work, and toward why it might fail. That perspective is invaluable when building. I learned this idea from Paul Arden: “If, instead of seeking approval, you ask, ‘What’s wrong with it? How can I make it better?’, you are more likely to get a truthful, critical answer."― Paul Arden, It’s Not How Good You Are, It’s How Good You Want To Be ...

What is a programmer but a series of PRs (pull requests)? I optimize PRs to introduce the best code I can, be easy to review, and document my work so I can make sense of it in the future. Here are some things I always check before opening a PR. Passing Static Analyses All of the static analysis tools in my project must pass locally. On a JavaScript project, that’s an auto-formatter (Prettier), linter (ESLint), and type-checker (TypeScript). All of these run on files I touch automatically. If that’s not feasible for you, a Husky pre-commit hook will do the job. ...

You might have heard that using blocking, waiting code, e.g., sleep in many languages, is discouraged. Why? Introduction to Sleep Sleep is a blocking, waiting function present in some languages. Here’s sleep in Ruby. # task.rb print "Starting task... " sleep 10 # Simulating some activity... puts "done." The user experiences a printed output, with ten seconds of time between the ellipses and “done.” $ ruby task.rb Starting task... done. It’s used when we want to wait for a task to be finished. Pretty cool, right? ...