September 18, 2021

Malware Protection

Dedicated Forum to help removing adware, malware, spyware, ransomware, trojans, viruses and more!

A Rant on Personal Software Projects

A Rant on Personal Software Projects
A Rant on Personal Software Projects

Looking across your hard drive and GitHub, you might find hundreds of notes and skeletons of Git repositories. A veritable graveyard of software side projects. The typical flow for many of these projects is: get an idea, ruminate on the idea until it becomes exciting, eventually becoming more exciting than the current side project, notes are captured, a repository is created, and work begins at a blistering pace as the focus and excitement are there. There might be some rewrites or some changes in direction. Questions of whether the project is worthwhile or “what even should this project actually be” start to arise. Eventually, enthusiasm wanes as these questions continue to multiply. Progress slows as the path forward seems less clear-cut as it once did. The project is either sunset with a mournful promise to someday return or quietly put aside as something new and exciting comes to take its place. Sound familiar? Perhaps not, but the principles here could be helpful.

This particular article is largely a piece of opinion from one engineer to another. It’s about engineering the process by which you design a project to have better outcomes. There are many reasons why a project could be shelved or scrapped and not all of them are from a lack of clear project definition. In the case where it isn’t clear what the project is, it can be helpful to think about it in a more holistic/meta sense. There are two types of personal projects in broad strokes: technology demos and products.

0b10 Types of Personal Projects

The rust language logo being branded onto a microcontroller housing
Trying out Rust on a microcontroller is a fine reason for doing a project.

A technology demo is about the tech or the how. Perhaps you’re trying some new language or a new algorithm. It’s okay for it to be half-baked and clunky because that’s not what it was designed for. It was designed to be beautiful and interesting on the inside. In a way, when you step away, the project is complete because you got what you wanted: learning.

In contrast, a product personal project focuses on what it does and the experience as an end-user interacts with it. Maybe it has a great README, a slick user experience, or does something better than anything else out there. The point is that it is focused on the end-user that uses it rather than the person who makes it. It doesn’t particularly matter what it looks like on the inside. It could be based on COBOL and be a tangle of spaghetti internally. Clean code helps with maintenance and project longevity, but it does absolutely nothing for the product experience.

A BB-8 style robot
This robot looks awesome! If it’s all loose wire and hot snot on the inside, does it matter?

In a nutshell, it is about designing the project experience rather than simply the project itself. It begins at a more abstract level, starting with how you will approach this particular idea. Is it a tech demo or a product? Is this a project that’s an easy win? With these sorts of things in mind, you can start asking better questions. Questions that allow you to design what this will be. By being intentional about the process by which you make something, you directly influence the thing you make.

Let the Right Question Be Your Guide

For a product, you need to ask who the end-user is. Even if the user is you, that doesn’t mean you are static. Old bad code written by yourself is utterly mystifying; why wouldn’t an old, poorly designed product do the same? A product is about the end-user, not the developer, even if those two are the same person. Another good question would be, if Hackaday wrote about my project, what would they focus on and write about? (I’ll follow that up with “have I included clear, high-resolution pictures for them to use?”) As an end-user, what is the desired experience and how can it be simpler. It can be helpful to write these things down. Come up with a concrete plan, don’t change it or allow the scope to creep. If problems come up, go back to the questions you asked earlier and then redefine the scope. Try not to get distracted by the technology, and instead focus on what you’re trying to do. Don’t get too sucked into the how. A great example of how a product is designed and made is the Flipper Zero.

For a tech demo, have fun with it. Want to throw something else on there? Go for it. Perhaps you’re trying to learn some WebAssembly by porting Doom. There is no scope creep as there is no scope. As mentioned earlier, the focus is on the developer, not the user. Usability is not the focus here. Questions might be “what would be most interesting” or “how can I skip over boilerplate?”

But What Do I Know?

Of course, this is all just one writer’s opinion and has a sample size of one. It’s possible for a project to be somewhere in between a product and a tech demo, or neither. Nevertheless, adopting some of these methodologies has led to much more satisfaction with side-project endeavors. Do you have a different perspective? When you accomplish the goals you set out, do you move the goalposts or step back to tackle something new?