Getting started is just the start

Marco Rogers had a great thread on Mastodon recently about developer experience. One post in that thread, though, stood out to me:

“Easy to get started” is also at the root of a lot of dysfunction today in my opinion. Getting started is cool. But you know what’s even better? Finishing the thing. Expanding the thing. Maintaining the thing as is scales. Changing the thing when the goals or requirements change. Improving the performance when users report that it’s slow. All of those things matter way more than “getting started”.

Marco Rogers

Marco is right, but I quibble with saying those things are more important than getting started. After all, you can’t get to the finish without the start. This isn’t just true for the code your project produces. It’s just as important for the processes and practices that you set up for your community.

As I’ve often said, the process should scale with the community. When you’re first getting started, you need very little process. But it helps to be thinking about where the process needs to go. This allows you to expand on your current processes instead of having to replace them wholesale.

For example, chapter 9 of Program Management for Open Source Projects describes a feature management process for a large and mature community. But what does it look like to get to that point?

To start, when you’re the only maintainer on the project, you can start by adding features via a pull request instead of a direct commit to the main branch. This gives you an obvious space to leave some historical notes about the choices you made in the process. It adds a little more friction, but not much, and it sets up a good practice to follow as the community expands. When you add additional maintainers, you can expand this to require a code review before merge.

As the contributor community expands, you can add a new requirement: opening a feature proposal in the issue tracker before implementing the feature. This improves communication and allows for broader input before you set metaphorical pen to paper. When you start seeing that process showing strain, you can implement a full proposal and approval process as described in chapter 9.

It’s tempting to set up a bunch of process early on to get things started. But too much process can prevent any work from happening. At best, it distracts from more productive work. You can’t anticipate everything. Start your process development. But starting is just the start. You’ll need to continually refine processes as you go. That’s easier if you think beyond the start.

This post’s featured photo by Brendan Church on Unsplash.