It’s been a year now since I’ve started university and in that timespan, I have created many projects, some of which turned out successful and others with the exact opposite result. What that did teach me, however, is that there are certain common factors that sort’ve hint at whether a project is likely to succeed or not. Through this year of experience as well as a fair share of research on my end, I learned a lot about establishing outstanding side projects. I am by no means an expert in this matter but I do have a thing or two up my sleeve, so stay with me!
Rule # 1: Plan Everything Out (or at least the basics)
“By failing to prepare, you are preparing to fail.” – Benjamin Franklin
To make a great project, you want to invest time in laying out a general piece of how the UI will look, what functionality you’ll need, what libraries and modules you’ll be using, how you’re planning to set up the backend, and so on. You need to understand the problem you’re solving, the audience you’re addressing, and the platform you’re targeting. A common problem I see is that people often decide on a solution, algorithm, language, or scheme before really grasping what the problem is truly about. Dig deep into the matter and understand what, how, and why you’re pursuing this project. Not only does having a plan reduce proneness to failure, but it also allows you to set reasonable goals (daily, weekly, monthly, yearly) that will only increase your productivity and drive to finish that project.
Rule # 2: Understand How the Tools You’ve Chosen Actually Work
“Risk comes from not knowing what you’re doing.” – Warren Buffett
Understanding how certain libraries and packages work is essential to saving time on projects, reducing hacky code, and keeping you at an overall positive increase in momentum over time. A few months ago, I decided to use React, a JavaScript library, along with a Socket.io and Express server backend to make an online word game. Let’s just say, it wasn’t exactly the best experience one can have building a project. To start off, I did not know how any of those tools worked and this project was my first exposure to them. I spent three months making what someone can make in a week or so just because I constantly had to reformat my code and replan things out. I didn’t understand how React’s state management worked and how the web sockets interacted with the Express server to emit messages between each other and in subgroups. Learning how these tools worked beforehand would sure have saved me a decent amount of time and stress as well as enhanced the final product.
As a suggestion, I’d recommend making basic mini projects to test out these products before actually using them in the project you want to pursue. As an example, I’m currently interested in building a web application, and for that, I’ve decided to use an Express and DynamoDB backend. Both of these two elements are still a bit foreign to me, but I spent the past week (and will continue to do so this week) learning and testing them in small projects so that I really understand their quirks before actually using them in the web application I want to build.
Rule # 3: Stick to YAGNI (You Ain’t Gonna Need It)
“Always implement things when you actually need them, never when you just foresee that you need them.” – Ron Jeffries
YAGNI is a principle of that states that programmers must not add a feature unless it is deemed necessary. Sometimes you may feel that adding something is needed but after giving it thought, you actually realize that it isn’t necessary at all. Understand what’s crucial to your project and what’s not, and then build on that. At the end of the day, your project is meant to focus on what other people need, not what you want. If you satisfy your own needs, you’ve satisfied one person but if you satisfy other people’s needs, you’ve satisfied a significant amount of people. If you can satisfy both, then that’s awesome, but if not, then stick to the latter as it obviously brings your more traffic and success.
Rule # 4: Don’t Jump the Gun Too Early
“Nothing good ever comes out of hurry and frustration, only misery.” – Auliq Ice
As with other processes, you want to be patient throughout this journey. A lot of beginners fall into the habit of wanting to go too big too soon and end up collapsing because they rushed everything. Set incremental goals and patiently continue to hit them until you’ve hit the benchmark you’ve set to achieve. Success isn’t something that happens overnight; it’s a process that is a result of many days of consistent hard work.
Rule # 5: It’s Okay To Ask For Help 🙂
“I think the hardest part to get to is that point of asking for help or reaching out to other people and being honest with yourself.” – Mary-Kate Olsen
When I first started building personal projects, I felt like being independent meant that I didn’t ask anyone for help and that I figured solutions to my problems on my own. While that is somewhat true, I now understand that asking for help doesn’t reduce your independence at all but rather increases it as it allows you to break through barriers and continue progressing in an upward trend.
No matter what you’re doing, there’s always going to be expert individuals who know the craft more than you do, so there’s no wrong in asking them questions about how to do certain things. The catch here is that you don’t want to rush to them whenever you run into a problem. Take action on your own and do research. Only when you don’t find answers to your questions do you refer to these professionals.
In terms of asking the right people, you want to be asking people who have knowledge in whatever stack you’re working with. If you’re working with web related stuff, find a web developer who can help. If you’re working with machine learning, find someone who’s advanced in that and seek their help. In other words, take technical direction from someone who’s mastered what you’re dealing with.
Rule # 6: Don’t Get Stuck on Minutiae (Bikeshedding)
“Don’t let small things stop you from accomplishing bigger and better things.” – Sonya Parker
Bikeshedding occurs when you spend too much of your time and energy on trivial details of a larger concern. Instead, focus on the more important aspects first, and then if you have time, clear up the remaining, insignificant features. An analogy I like to think of is standardized testing. On these exams, you’re being measured for your accuracy on a certain time interval. If you get stuck on one problem and waste time by continuing to solve it, then you may not get enough time to finish the problems at the end, which may very well be easier than the one you got stuck on. The general rule of thumb is if you get stuck on one problem, then just skip it, and if you have time later, come back and attempt it again. Similarly, you want to be taking advantage of the time you have to build your project. Don’t waste your time on insignificant aspects of the project when more important features are to be attended to.
Final Overview
These are the most common rules that I’ve found myself violating this past year as well as heard or seen others violate which resulted in failed projects at an early stage. If you have any other rules that you’d like to suggest, feel free to pitch in and post a comment for everyone to learn something from you. I am learning from you all just as you all are learning a thing or two from me.
Sources
- Featured image can be found here.