Here are Pivotal we call our time between billable projects “the beach.” We spend most of this time working on projects which are internal or open source, sometimes both. One such project is Project Monitor and on my last go-round on the beach I got to work on it with my long-time colleague Mr. Saracco.
Project Monitor is a quick way for a team to see the status of their test suite. It’s basically a board of tiles, one for each test suite, colored either green or red depending on the current state of the build. It’s an interesting app to work on because it’s used in every Pivotal office and it’s part of our daily lives. It’s fun and it feels rewarding to work on something you see out of the corner of your eye every day. It’s also a little nerve-wracking. If you break something, every one of your co-workers knows!
Project Monitor has historically been a bit of a tangle. Frequently, a Pivot or two has a week or less on the beach and they’re tasked with implementing some new feature or fixing a bug and then they’re off on another project. Digging through the codebase, you can see there’s some baggage. Maybe there’s a beloved tool from a previous project, a half-used framework, or a–ahem–clever use of code. Not always, but sometimes, these things trip up the next developer.
A fundamental truth about code is that it has more than one audience. We often think of the compiler or the interpreter as the end consumer of our code, and of course that’s true. But it’s easy to downplay how important it is to think about the next set of eyes on your codebase. Even if you have no collaborators and develop your software in a sound-proof bunk, you have in the very least your future self to communicate with.
My biggest lesson from this go-round on the beach is that it is exceptionally important for open source software to code in such a way that optimizes for quick developer ramp up. This means writing code where intent is clear. It means minimizing dependencies so as to shrink the number of necessary technologies for a developer to additionally ramp up on. It means nice, clean commits with clear logs. In short, it means having a boatload of empathy for the next person reading the code.
On a private project with a small, tight team, there’s plenty of leeway. Someone with some history can just explain code that a new dev finds confusing. There is usually no such luxury on open source projects. Furthermore, the lifetime success of your project may be determined by willing members of the community standing up and pitching in. The next person to look at your code may not have any context at all. They will wake up, Memento style, and only see the code at hand. They do not have the history you do.
When you’re doing open source work, lease, please, please think of the next developer when you reach for that shiny new gem, that clever piece of meta-programming, that half-adopted convention.
