Hobby Project

Declaring a hobby project

It is a good idea to let anybody looking at your project know, that you work on it as a hobby. This helps you set the correct expectations. You can use the markdown snippet below to do so in your README.

> **Hobby Project**
>
> This is a [hobby project](https://hobby-project.dev). It is worked on recreationally, and its
> resources are limited. This may impact you. Follow the previous link to learn more.

Organisational Considerations

These are some organisational ideas you might want to take into account.

Clear Goals

Feature creep is very dangerous to hobby projects. They usually run on minimal resources already, and in that situation adding a couple of features here and there be the difference between a success and another abandoned idea.

As a counter measure you should set explicit and specific goals from the very start. Everything that isn't either itself a goal or part of one, is implicitly out of scope for the project.

This also applies to logical or trivial extensions. If you really want to, you can tackle them once the core project is complete. Until then, leave them be.

Extensive Documentation

There most likely will be significant periods in which you will barely work on your hobby project, if at all. In those times it is likely that you will forget a lot of the things you know about it. This knowledge often takes a lot of time to rediscover, and the process is often annoying, which might make you abandon your project.

You can prevent a lot of this by extensively documenting your project from the very start. It is tempting to think something like "I'll get to a first prototype, then document everything." There is a good chance you'll take a break right after the prototype, and then have no idea where to continue afterwards.

Some of the things you should document:

• The project goals
• The overall architecture you decided on
• How to build/run the program
• A list of ToDos and their completion status
• The purpose of modules, data types, functions, …. Use the doc comments of your language, if possible, so that an LSP can pick them up.

Automated Testing

Automated tests are very important for all software projects, be they hobby or professional. You might think yours is small enough to keep track of everything in your head, but you would be wrong.

Even if you do manage without tests for the start, once a couple months go by you will forget your earlier decisions. Worse yet, you'll make incorrect assumptions about them, leading to bugs.

Without automated tests it might take you quite some time to notice that there is a problem in the first place. If that happens, fixing it becomes even harder, because you not only will have to regain an understanding of the original code, but also the intentions behind your buggy change.

All of this is quite time-consuming and annoying, which might make you abbandon your project all together. To avoid that, it's much easier to take the time to write tests upfront.

Technical Considerations

Reduce Dependencies

Most modern programmings languages, like Rust, JavaScript and Go have widespread (or integrated) package managers, that make it easy to use a lot of libraries. This is great, especially when starting, because it means you can minimize the work you have to do.

However, this also has a significant downside. You need to keep your dependencies up to date, because otherwise you might run into problems. Depending on the type of project you are building, not doing so might also lead to severe security problems.

This is easy enough if you only rely on a handful of libraries. It becomes significantly more difficult once you depend on several hundreds of them. So you should keep an eye on your dependencies and carefully consider if the time saved by using a library is more significant than the maintenance this will take.

You might also want to consider vendoring your dependencies, instead of using a package manager. This means including the dependency code within your own source code, and shipping it as part of your application. Doing so makes adding new ones more difficult, and dissuades you from doing so excessively.

Simplified Development Environment

Some languages, like C# provide very large toolsets, like Visual Studio. Those can be very time-consuming and annoying to set up. If you get a new computer during your project, this might mean you abandon it, because you are not willing to spend that time just to set up the tools again.

To avoid this, you should prefer languages or toolsets that are quicker to set up. For example, setting up Rust is a quick and easy process using rustup. If you combine that with an editor like Helix you might be up and running on a new system in about five minutes.

Targetting Baseline (web only)

If your project is a website or web app, you should strive to use only features that are Baseline Widely available . This should mean that you don't run into problems where browser behave differently, or only some support a feature. This avoids the need for fallback implementations, as it is much less likely that any user will have a browser that isn't supported. This also makes it a lot easier to tell a user that they need to upgrade their browser, if a problem actually arises.