No, I don’t mean whether you spend too much time on social media during times you’re supposedly coding. What I want to talk about is how we code when we’re working on a solo project and/or not within a formal project context. When you’re working on a small toy project or just working solo, it’s easy to skip over all the folderol of a formal project. In fact, that can be one of the advantages of those types of projects, right? Less overhead and bureaucracy! More nimble! I think that it’s in just this situation that you should be most focussed on using – and evaluating – your workflow.
If all you’re doing is messing about with code for the sake of trying stuff out, you’re probably fine. (But if messing about with code is how you do your design, maybe give some thought to that process as well!) Disposable code is fine, so long as you are truly committed to throwing it away. As soon as you have code you want to save, it’s time to think about process and workflow.
Source code control is the easy part. You are using source code control of some sort, yes? But even here, it’s good to practice using the tool as if you were in a larger team, even if it’s just you. Don’t commit everything to the master branch. Do include meaningful commit messages. Use pull requests. And don’t forget to add project level documentation to the repository, at the very least a basic readme.
Set up testing code and strongly consider setting up a continuous integration process. This is the step I most often fail at. In fact, my unpaid side gig this week is to figure out how to use travis-ci to see if I like or not. I’ll also be adding test code to my current toy project. If you play with new tools on a smaller scale project and when you’re not under an external deadline, you have the luxury of poking around in the corners of your tools and trying different options. That means I have time to try more than one CI tool on the same project to see if I have a strong preference in any direction.
Even if you never intend to let anyone else run the code, it’s still a good idea to think about issue/enhancement tracking. Here I’m talking about internal, developer facing tracking, not the public facing type. (Although it’s possible to solve both at once depending on the project.) Think about your issue tracking interfaces with your source code control. Think about how change control interfaces with documentation. (You do have at least basic documentation, right?)
Another piece you might overlook is distribution and archive. If an executable (or source code) is sent to someone else, you really should be keeping track of who it was sent to. Does this need to integrate with your CRM solution or your billing/invoice solution? Maybe yes and maybe no, but it should be a conscious decision. When things get hairy, traceability can be a hugely effective tool, but only if it’s in place before you need it. And even if you’re not delivering projects to someone else, it can be useful to have an archive of finished projects.
What are the benefits of doing this work, even if no one else ever sees it? First, it gets you in the habit of defining and following a work flow. Developing good habits now will make it automatic to apply them to larger more complex projects. It also gives you a chance to learn and evaluate the tools in your workflow in a more contained situation. Second, if you ever do need to bring in additional developers, the project will be in a good state to hand off with a minimum off fuss and flailing. Third, maintenance will be much easier and less stressful. And because of the second point, you might even be able to farm out the maintenance tasks, freeing your time to do other more interesting projects. Third, a clean project with good workflow makes it possible to re-use code, either in another project, or in another context entirely.
Sam Herdman 