Team of One

I have been writing programs of varying complexity since I was in the 6th grade, so, call it 39 years. For a portion of that time, call it 14 years, I worked on code that had other people contributing to it. During that, what, 36% percent of my programming life, I learned many lessons that I’ve carried into my solo programming.

Tools, best practices, all kinds of work patterns and code idioms show up in my personal projects not because they’re the most efficient way to get the project done, but because I’ve learned that if I ever do want to collaborate with someone, then that’s made a heck of a lot easier if I do some planning in the beginning. Also, because I love future me, I don’t want to give future me some big pile of spaghetti code with all kinds of undocumented special cases just built in.

So now we get to the problem, for me. Whenever some tool gets an update, it displays some kind of alert (“Hey, there’s a new version of me!”) and probably some release notes telling me why I should update the tool. Now I get to become buzzword compliant and try to figure out if the new feature is something that I want to use. If I were part of a larger development team, the odds are that I would. In my team of one, some of these features translate well, but a bunch don’t. For example, I don’t need to use Slack to communicate with myself, and I sure don’t need a plugin that sends a message to a Slack channel every time I push a commit.

The latest source of feature anxiety for me has been continuous build / integration services. Everybody (well, Bitbucket and Gitlab and Github) has some kind of build service and there are hooks to integrate the service with other tools. Your IDE can display build status, or your VCS GUI app can stick indicators next to commits based on output from the build system. That would be cool if I were still collaborating on a giant code base with 300 other developers. No more asking, “Who broke the build?”

But, and this is a thing, I have written a bunch of libraries. Some (one) of them are useful enough that I’ve made them public, while others (maybe seven) are not yet in a state where I’d feel comfortable putting them out in the wider world. Some are hosted on Github, some in private repos on Bitbucket. And a build system needs to have access to all the dependencies. Ultimately, I’d need to release these libraries to Maven Central or some other public artifact repo.

Which is really just saying, I get nerd sniped by the release notes.