Organizing Work as a Solo Programmer

In a team environment, you have things like bug reporting, feature request management,Agile approaches and sprints. If you're lucky you might even have a dedicated Scrum Master and Product Owner. But when it's just you, the idea of these sorts of constructs seems like overkill. Nothing could be further from the truth. Documenting your approach applies a type of structure that will reap huge benefits, not necessarily in the quality of your code, but in the productivity of your coding sessions.

</p>

Requirements Tracking

</p>

If you're using Github there is a feature of the site to track "Issues" for your project. Issues is probably a bad name for it though, because with a little metadata/label magic, it can track features, enhancements, etc. When I started working on my little side project, I setup a list of "requirements" that I needed for my first release. I have entries like:

</p>

</p>

These are just a few examples, but you get the idea. Once these requirements start to take form, you'll quickly realize it'll take forever for you to actually be able to release anything. That's where milestones come in. In Github you can use Milestones to group requirements and issues for a particular release. This gives you small victories along your path to awesomeness.

</p>

Issue Tracking

</p>

As I go through my testing, I inevitably find bugs. But sometimes I'm on a roll in a certain mode of thinking and don't want to have to context switch to deal with this new problem. This is where I use Github's Issues to log anything and everything I need to go back and address. This is nice for a number of reasons.

</p>

</p>

That last line is a big one. Prior to my discovery of the usefulness of this type of tracking, my commits were haphazard at best. My commits were largely just ways to save my code changes. You know you've got this problem if you always struggle with your commit messages. If you don't know what to type in a commit, then chances are you're not breaking your work up effectively. With issues and requirements, when to commit becomes automatic. You finish with an issue, you make a commit and push it. You finish a feature request, you commit and push it to the remote repo. Easy as pie.

</p>

Planning Your Workday

</p>

When your tracking requirements and issues, it makes your coding sessions more productive. If you're like me, you don't program full time, so you spend your nights and weekends coding your brains out. Because of that, you need to make your time as effective and efficient as possible. When you track your requirements, issues, etc in this manor you can simply sit down, look at the outstanding items, pick 2 or 3 and get to work. You'll want to keep in mind the difficulty of the issues your tackling and the time you have for this particular working session. It might be better to tackle a bunch of smaller issues (and get them finished) than half-starting a larger issue. But either approach you take, you'll be ready to tackle the work day.

</p>

To some folks these may seem like a no brainer. But for the solo programmer, the things suggested here may sound like overkill. The image of the keyboard cowboy hacking away and addressing issues as they spring up may sound sexy. You might even be delusional enough to think you won't run into issues and therefore don't need issue tracking. But either way, I beg you to try this approach and see if it benefits you. I know it has completely changed the way I work and how much work I get done.

</p>

comments powered by Disqus