Deciding if a Personal Project is Dead Weight or Good Opportunity
Dead weight or good opportunity? This is the question I ask myself when I find that the personal project I’m working on is becoming too large and complex.
I’ve been working on it for hours at this point and have so many good ideas and frameworks/libraries that I want to implement, but the sheer amount of information causes me to become overwhelmed. I have to sit back and ask myself if I can actually complete this project. It’s a very stressful situation.
Does this situation sound familiar?
But even if these projects aren’t required, we devote time and energy to them. So what happens when we run into a problem with our personal projects that stresses us out? Do we keep working or give up?
Let’s find out what our best course of action is by asking two sets of questions, and then if we decide to move forward, how to get to project success.
When I run into a problem that causes a roadblock in a personal project, the first thing I do is go over the scope of the project. I ask myself these questions:
- Do I have enough time to put into the project?
- Do I have enough resources?
- Is there something else I could do with my free time that would be more beneficial?
If the answers to the first two questions are yes and the last question is no, that’s the first sign that you should follow through with the project.
If you don’t have enough time or resources, or your free time could be better spent elsewhere, then it’s time to think of another project that would be better suited to your constraints. There’s little reason to continue with a roadblocked project if you can work on a more beneficial project that fits your time and resources.
When judging a project’s ability to fit your scope, remember that learning a new technology will almost always take longer than you think it will. In most cases, working out the kinks with the technologies you already know will take longer than expected. Maybe an extra 20 minutes, maybe an extra six hours.
For example, if you only have a week to start and finish a project, you probably don’t want to start said project if you need to learn more than two frameworks/libraries.
Everyone has different constraints and abilities, so it’s up to you to figure out what works best.
The second set of questions I ask myself is about return on investment.
- Is what I’m going to learn worth the time and effort?
- Is it worth continuing and pushing through the roadblocks?
- Will the effort on this project expand my knowledge of frameworks, libraries, and their uses?
One of the best things about working on a personal project is learning new things and practicing new skills.
But sometimes I find that I’ve picked a project that has so much to it, I don’t know how to fit all the pieces together. There’s a framework I’d like to learn and a few libraries I need to freshen up on. So what happens when I get in over my head?
Working through a large project pushes me to thoroughly read through the documentation and tutorials in order speed up the development process and avoid “reinventing the wheel.”
If you get to a roadblock, you need to determine whether putting in more effort will benefit you in the end. Even if you have the time to do so, if you don’t gain valuable knowledge and skills, it might be time to give up the project.
Once you’ve answered these questions and decided it’s worth it to move forward, you may need to reevaluate your project. It’s great to implement all your newfound knowledge, but there are steps you can take to more easily get to a successful, finished project.
The first thing you want to do if you’ve decided to move forward with your personal project is actually a step backward, but trust me, it makes up for itself later down the road.
What I do is look back through my code and see if there is anything I can remove to reach a Minimum Viable Product (MVP). Because your project is a personal project, one piece of advice is simply to get something done, even if it isn’t the perfect result you had in mind.
Maybe there was a feature that was giving me a lot of trouble but I don’t really need it to reach my MVP. If I find such a thing in my code, I remove it but keep the idea in the back of my mind for later down the road.
Reaching an MVP is important because it prevents you from putting too much functionality into the project that could end up breaking, causing even more stress. You don’t want to frantically search through your code for bugs and remove important code in large portions in order to alleviate the bug. That deadline (if one exists) is something you’d like to beat, is it not?
Sure my project isn’t as flashy as it was prior to reaching my MVP, but it works, and it works well. It does everything it needs to. Nothing more, and nothing less.
Ideally, you want to determine what your minimum viable product is prior to starting a project, but any project is a learning experience. It’s okay to go back and reevaluate if you need to.
Libraries and Frameworks
One of the reasons I do personal projects is to learn new libraries and frameworks, and I bet that’s one reason why you do personal projects, too. Learning new frameworks and libraries means you will have less code to write for your personal project (trying not to reinvent the wheel, remember?), and it also means you will be more marketable at your job.
If you’re anything like me, you can get lost in learning these new things. But if you hit a roadblock with a personal project, and if you’re trying simply to get to a minimum viable product, you don’t have time to learn everything.
Normally, when I learn new frameworks or libraries, I make a bunch of small projects that focus on the larger functionalities that are provided and implement those functions that are under the umbrella of the larger task. When I do have time, it really makes the learning process a lot easier and far more enjoyable than, for example, creating one large project that fully implements the framework or library.
But since we don’t have time to do all that work to get to our finished product, it’s better to focus on exactly what we need to know. I suggest reading through all or most of the documentation for each framework or library, unless you know exactly what you are looking for and are only interested in some of the functionality provided by the collection (framework/library).
If you don’t have time to read through all of the documentation, just read up on what you need, and then come back later when you have more time. It’s much easier to have read the documentation and know exactly what to look up when in need of some help versus watching an instructional video on part of the collection and then having to search through the documentation for information the instructor may have missed or purposely left out.
Here’s a good video on some popular frameworks to take a look at.
Now that I’ve reached my MVP and implemented my desired libraries and frameworks, I need to do some refactoring, and in the process, move reusable code into modules that can be imported.
The structure of the program is bound to be a little messy at this point. It’ll make the code more readable in the main project file and will make bugs easier to squash if I create some modules. On top of improving readability and reducing the difficulty of debugging, creating modules will alleviate some of that anxiety from the sheer size and lack of organization of the main project file.
When it comes to creating a module, you may want to consider creating a wrapper class, in that it wraps all of the functionality into one name and possibly makes the usage of an underlying class easier to deal with. Ideally, this class will have a descriptive name like “FileReader.” Not only will this class have the ability to read-in the contents of a file but it may also have the ability to record the time of the file’s last modification, for example.
This “FileReader” module should be kept simple; you don’t want it to do anything too far out of scope like write to files. If a single module does too much, it defeats the purpose of making a module in the first place. At that point, it’s practically a full-blown program!
Now, I’m not saying that everything should be “modularized.” I would only suggest creating a module for tasks that are repeated or for easing/expanding the use of another class or module. Maybe a “FileReader” class already exists but only has the ability to handle one file at a time. You could “wrap” that class in your own class that allows you to select a folder and read the contents of every file in said folder.
I personally would not create a module for reading the contents of a file, as it is already made pretty simple in most programming languages out of the box.
A module I would actually consider creating would be something along the lines of a file manipulation module. Not only would it have the ability to read and write files, but it would also have the ability to filter out certain words or add a preferred format to the file.
I wouldn’t add too much more functionality.
We don’t want to get carried away and add the ability to translate text into various languages. (Not in this module, anyway.)
Now that we have some modules and have reached our MVP, we can consider adding new functionality, given that time permits. If it doesn’t, at least we reached our MVP and can wrap things up knowing that we have a complete project.
Don’t walk away forever though. You did put a lot of work into this project, right?
Take advantage of the newer versions of the frameworks/libraries you used. Maybe you learned a new design pattern that is perfect for this project in particular. Maybe the programming language you wrote the project in had some major updates. Maybe a service you use is no longer available. Or maybe you just love this project and want to improve upon it.
Turning Roadblocks Into Good Opportunities
What should you take away from this advice?
Ask yourself a few questions to determine if it’s worth moving forward. If you decide it is, there are a few things you can do to make it easier to finish your project.
Ultimately, you should try to reach your MVP. Create modules when and only when you have enough similar — but not exactly the same — code that could use some modularization.
Don’t make modules too big or complex. Split large programs up into smaller parts for better understanding and easier readability, until you are ready to recombine them.
Go back and give old projects some love every once in awhile. You did the work, so it’s worth a revisit to see if you can improve it.
If it’s challenging, it is absolutely worth pushing through. You almost always learn something from a challenging experience.
Thanks for reading, and I hope this helps you with your large projects!