Category: Development

Posted on

Solo developer – multiple projects

A person sitting on a tiny island working on their laptop

I have numerous projects on the go and many more waiting to be started. There are not enough hours in the day to work on everything on my to-do list.

I’m good at finishing projects, it is rare that I start something and do not get it to a useable point (though it can happen). I tend to only start a project when I consider it worthwhile, have a real passion for it or think I will learn something significant from creating it.

The categories

To try and manage everything, I loosely group my projects into three groups. These groups are “have to work one,” “have to support” and “want to work on”. I have not been able to think of better names so we will stick with these for now. I use these categories to prioritise my limited development time. All my projects get some development time, but the categories help me decide how much each group gets.

“Have to work on”

My API is the backbone for all the Apps under the Costs to Expect umbrella. The API is the only constant (for now) in the “have to work on” group. The API is continuously reviewed, and I try to spend a reasonable amount of time refactoring and rewriting. Continuously refactoring the API has paid dividends, I rarely find significant issues or bugs. Any section of the API which feel a little “meh” get reworked. When I work on the API, I try to make sure each new release include more tests and I try to improve the documentation.

“Have to support”

“Have to work” on and “have to support” are subtly different. “Have to support” means bug fixes and upgrades. “Have to work on” means bug fixes, refactoring, new tests, and any necessary development. Many of my Apps live in this group, I fix issues as they arrive and try to keep them all running well.

“Want to work on”

My “want to work on” group changes constantly, this is the new and interesting stuff. I’m writing Budget Pro right now; it is a new App for the Costs to Expect service. I am hoping to release the alpha of Budget Pro before the end of June. As soon as a project in this group gets to a “releasable” state, it moves into one of the other two groups.

New stuff

When projects move between “categories” I find time for the new stuff. I might start something completely new; client work might come in or I decide to go back to one of my other projects.

Sustainable

You might think that over time it is inevitable that the “have to support” group grows too big for one developer to manage. If this happens, I will employ someone to work with me. I have gotten close to needing help a couple of time but so far, I’ve been lucky and always managed. Less active projects naturally get retired, either their times passes, or I’ve moved on.

I love having so many projects on which I can work. I can switch between backend and frontend at will, switch entirely to support or testing or just focus on something new, like C++.

Posted on

Laravel 10 – Updating my projects

Image showing two notifications on a phone saying "You have new software updates"

I have numerous projects which are built utilising the Laravel Framework. Each time there is a new major release, you need to ask yourself the same question; how long until I update my project? There are two follow-on questions; in what order should I upgrade? And is it worth upgrading this one?

I try to ensure all my projects get updated to the latest version of Laravel. However, I am not one of those eager users who updates their Apps and website on release day. When it comes to updates, I am conservative with my own projects. It is typically worth waiting for at least some minor releases which catch the inevitable bugs.

Most of the time, the order that I update is simple. The Apps which are in active development and any which could or will benefit from any of the new features go first.

Laravel 10 is different

Laravel 10 is a different release. The major benefit is not the new features, and it isn’t immediately obvious. The major benefit will come with time, all the user land code is now strictly typed.

Unlike previous Laravel releases, for Laravel 10 you should not simply update your composer file and run update. To benefit from the changes in Laravel 10, you need to update all your user land code to be strictly typed. If you simply run composer update you are not benefiting from the new typing. You need to ensure your user land code is strict.

There are services and tools that can help you with upgrading your projects, the obvious one being Laravel Shift. Though if you have several projects, this can get expensive quickly. In addition to the financial costs and time cost, you need to consider whether a project will have any future development. Is the project a personal passion project that is likely to just fizzle out?

Updates have begun

To date, two of my projects are using Laravel 10. I upgraded one with Shift and a little TLC, the other I upgraded manually. At release time, Budget Pro was still in the preliminary stages of development. It had minimal user land code which I needed to type.

With my other umpteen active projects, their time will come. The two most urgent are my API and a large client App for a customer. The updates for these projects are going to be complicated tasks that I will manage manually. I don’t want to hand over the job to Shift because as much as I like Laravel Shift, these projects are too critical. I expect I will start the update when I want to use a new feature introduced in Laravel 10 or a later point release.

Being a solo developer, it can be hard to justify the time. Any time that I dedicate to updating and validating is time I could be using to refactor, add new features, marketing, or anything else.