Looking at your hard drive and GitHub, you may find comments and skeletons for hundreds of Git repositories. A veritable software side project cemetery. The typical process of many of these projects is: get an idea, think about it until it becomes exciting, and eventually become more exciting than the current side project, take notes, create a repository, and work extremely fast Speed starts to focus and excitement is there. There may be some rewrites or some changes in direction. The question of whether the project is worthwhile or “what should this project actually be” began to arise. Eventually, as these problems continued to increase, the enthusiasm gradually weakened. Progress has slowed down because the path forward does not seem as clear as before. The project will either come back at sunset with a sad promise one day, or it will be quietly put aside because something new and exciting will take its place. Sound familiar? Maybe not, but the principles here may help.
This particular article is mainly about opinions from one engineer to another. This is about the process of engineering design projects to get better results. There are many reasons why a project may be shelved or scrapped, not all of which stem from the lack of a clear project definition. When it is not clear what the project is, it helps to consider it in a more holistic/metamorphic sense. There are basically two types of personal projects: technical demonstrations and products.
0b10 Types of personal projects
Technology presentations are about technology or methods. Maybe you are trying some new language or new algorithm. It’s okay to be half-baked and bulky, because that’s not what it was designed for. Its interior design is beautiful and interesting. In a way, when you leave, the project is complete because you get what you want: learning.
In contrast, product personal projects focus on its function and the end user’s experience of interacting with it. Maybe it has a great readme file, a smooth user experience, or it does a better job than anything else. The key is that it focuses on the end user who uses it rather than the person who makes it. How it looks inside is not particularly important. It can be based on COBOL and is a bunch of pasta inside. Clean code helps with maintenance and project life, but it does not help the product experience at all.
In short, it is about designing the project experience, not just the project itself. It starts at a more abstract level, starting with how you will deal with this particular idea. Is it a technology demonstration or a product? Is this an easy project to win? With these things in mind, you can start asking better questions. Allows you to design the question of what this will be. By being conscious of the process by which you make something, you directly influence what you make.
Let the right questions be your guide
For products, you need to ask who the end user is. Even if the user is you, it does not mean that you are static. The old code I wrote is very puzzling; why don’t old, poorly designed products do the same thing? The product is about the end user, not the developer, even if the two are the same person. Another good question is, if Hackaday writes about my project, what will they focus on and write about? (I will go on to say “Do I include clear, high-resolution pictures for them to use?”) As an end user, what is the experience you want and how can it be easier. It will be helpful to write these things down. Come up with a specific plan, don’t change it or allow scope to spread. If something goes wrong, please go back to the question you asked before and redefine the scope. Try not to be distracted by technology and instead focus on what you want to do. Don’t get too obsessed with methods. A good example of product design and manufacturing methods is Flipper Zero.
For the technical demonstration, have fun. Want to throw something else there? Go ahead. Maybe you are trying to learn some WebAssembly by porting Doom. There is no scope spread, because there is no scope. As mentioned earlier, the focus is on developers, not users. Usability is not the focus here. The question may be “What is the most interesting” or “How do I skip the boilerplate?”
But what do I know?
Of course, this is only the opinion of one author, and the sample size is one. A project may be between a product and a technical demonstration, or neither. Nevertheless, the use of some of these methods has made people more satisfied with the side project efforts. Do you have a different view? When you complete the goal you set, do you move the goal post or take a step back to deal with new things?