Making things ship-shape.

Yesterday, I read this article all about shipping side projects, which offers an array of tips to do it more efficiently. If you're a software developer (or in fact anyone that works on their own projects alongside their day job), it is well worth a read.

As someone who regularly works on projects outside of my prescribed daily work, it made me reflect on the sad state of my shipping rate.

Logging into my BitBucket account, I have just counted 54 repositories. That's right, 50 and 4. How many have shipped? 3. Yes, I know, that's... not a lot.

OK, so that is a little exaggerated. Some of those were private projects where the goal was never to release them and some of them are University projects which I guess you could say I did 'ship' really. But the point still stands - my focus for most of them cannot really have been on shipping a usable product (whether I thought it was at the time or not).

This is the part I would like to change.

Several of the pieces of advice in the article, I am already doing. I carry a notepad with me most of the time. I have a trello board where my ideas get fleshed out. I even usually begin thinking with my project manager hat on, before switching it out for my developer cap. So far so good.

But what is the part I am missing, to have got myself in such a state that 50 vs 3 are my numbers?

Probably first up, is this:

Your objective shapes your approach to working on side projects. For example, if you want to learn new technologies, then maybe you shouldn’t optimize on shipping a complete product. Conversely, if you want to make something people use, then just choose the stack you’re most productive in.  

There are often times I want to try out some new technology. Out of the 54 repositories, there are actually quite a few were it is just another simple blog implementation in language X, and some that aren't really anything apart from being sort of syntax playgrounds.

Some, however, are projects I would have enjoyed shipping. For many of these I am guilty of thinking for too long about the tech stack. Even changing stacks because I thought it was a mis-use / suboptimal choice.

Next up, and closely related, this:

If you’re goal is to ship, then who cares (right now, at least) that you’re copying code and not being DRY. Put that tenth callback in that single 400 line index.js file, get it to work, then refactor that later when you have your “Editing” hat on.  

Something inside of me felt uneasy about this one. I follow KISS, YAGNI et al., I try to avoid over-engineering my components. But I also like to write code that is at least clean (and to me that means it being easily changeable is a key factor).

That said, I think the message the author is conveying is spot on. If it's a project you want people to use, therefore you are focussing on shipping - just write code that works. You can always come back and re-write the whole thing if it is something people are using and it is worthwhile to do so.

Next time I work on a side project I want to ship, these are the two pieces of advice I am going to focus on - worry less about using a perfect tech stack, worry more about getting that project finished and in the hands of a user (or two, even!)

Now I have a blog, of course, I will probably write about it when that happens... so until then, happy shipping!

Finally, thanks to @andyjiang for authoring the piece linked at the beginning that prompted this blog. Interesting, useful and fun read. :)