Author: DeanBlackborough

Posted on

Side project of a side project

I’ve been working away building the Costs to Expect Service for a while and we are starting to make some real progress, before I started work on the next app for the service I wanted to test a couple of small ideas, enter my Yahtzee game scorer.

I released v1.00.0 of the scorer on the 3rd of August, the initial usable version was released on the 21st July. I worked on it for an hour here and there and quite quickly got it to a point where I deemed it featured enough to get a v1 label, it isn’t done but when is anything?

Building the scorer was freeing, I quickly tested some ideas and designs without having to worry about conforming to the design on the main Costs to Expect App. I discovered a couple of bugs within the API and also created new routes on the API to deal with requirements unique to the Yahtzee app, I suspect if I had ‘added’ the scorer to the existing App I wouldn’t have come up with the same design.

Looking at the API from a different perspective has been worthwhile, it forced us to rethink, rather than have a monolith App that is capable of everything, we decided to break everything up. The API is the core of the service and we are now going to have smaller focused Apps that can more easily be designed for there intended purpose.

The current App is going to be slimmed down to expenses only, a budgeting app is in the works and Pro versions of both will come along some time next year.

There are going to be more side projects of side projects, we have a few in the works. They have to take a back-seat for now as I need to get on with building the Budgeting app and I’ve a freelance project or two coming up that will steal some of my focus.

Posted on

We all need a Development Manager

As a solo developer, it is easy to get lost in what you are doing and not necessarily working towards where you should be going. An excellent example of this is refactoring; “If I refactor this method/class, it will be easier to maintain.”

The chances are, if you smell an issue with a class or method, it needs to go through your refactoring process, it isn’t as though anyone else is going to do it, you are just one person.

The question is, does it need to be dealt with now? As developers, we are all guilty of wanting to refactor, and then persuading ourselves that the task is more urgent than it is.

I’m working towards releasing our SaaS product, mid-way through last year I decided I needed a little help to ensure I get to the release as efficiently as possible and not stray too far off target.

I decided to recruit the Wife.

Every Sunday, I gather all the tasks I’m planning to work on over the next week, the Wife and I then have a short meeting.

My Wife is not a Developer and has never worked in a field related to development. That doesn’t matter, all that matters is that your sounding board knows you.

I start by stating what I’m aiming to achieve for the week and then go through each of my planned tasks. For each task, I give a one-line explanation of what it is and how it will help achieve my goal. If I’m unable to provide a reasonable justification, or my Wife questions the validity of the task, it gets moved off the list.

Your sounding board needs to be someone that understands you. Your partner isn’t deciding whether you are working on the correct tasks, they are there to listen, you’ll both know if a task needs to go to the back of the list.

The longer you keep this up, the better the result.