Why?
Whatever craft we are pursuing, we all need to build something to gain experience and mastery. Obviously, software development doesn't escape this reality. Theory is important but using the knowledge in actual projects and solving problems enhance our comprehension of the subject.
Side projects always seemed amazing to me. Building something during my free time to solve a problem I have, or a problem others may have is a big reason why I started to code. The more I learn about programming, the more I realise its powers.
Like many developers, I started a lot of side projects. Every time, the pattern was the same. I was excited for a few days, perhaps a week. Then, I started to encounter more difficult problems, or I realised the project would take a very look time or life happened and I stopped working on it for a few days...
My Github account is a graveyard of potential projects that I just couldn't bring to life. Not mature, fully developed, married with two kids in a big mansion kind of life. A gigantic proportion of these projects didn't even go past the embryon stage. Every mistake is a lesson. Which brings me to this post.
A possible solution
One of the problems was that I did my thing alone. Nobody knew about it. And I totally dismissed the power of accountability. You will know about it. I'll show you my progress, every week. I'll just need enough discipline to write a blog post about it once a week, during the week-end. I'll mention the problems I faced, solutions I chose, and how I managed ( or not ) to spend time on the side project I am working on.
My rules
A lot of people came up with similar "frameworks" for learning and side projects. Here are the rules that I chose. These are totally arbitrary:
- Choose a project. No languages, libraries or frameworks restrictions.
- Spend one month on this project
- Just build a MVP ( Minimum Viable Product ). Don't get drown into details. Get the big picture
- Code will be on GitHub. Every blog post will link to the repository.
- After a month, deploy the application, whatever the state is. From there, either choose to keep working on it for another month, or switch to a new project
- If the project is over before a month, start a new month with a new project
- Report your progress, problems and failures each week in a blog post
One month seems to be long enough with the time I have to create something decent. One week would be too short. If the project is going well and I'm enjoying it, I could spend another month on it, keeping the same rules, but updating the requirements of the project. Reporting my progress will probably help putting things in order, and not going in several directions at once.
First Side Project
For the first project, I chose to do an application related to the Blizzard video game HearthStone. Players build decks with cards based on the Warcraft world. The application should allow players to track their records and their progress with their different decks:
- Users can access a catalog with all the cards and build decks.
- Users can export their decks to the game.
- Users can add the outcome of their games.
- Users can see how their decks perform against other classes.
- Users can login with Twitter or GitHub.
That should be more than enough to get me started.Let me know what you think and I'll see you in a week!
Top comments (1)
I approve of this method and have done the same very recently. I started with a VERY small project just to calculate some probabilities around scenarios involving rolling a die.
It has certainly helped me stay true to the project and I have come back to it more often than I have done in the past on other side projects.
My only mistake was not blogging on Dev.To. :p One day I may port it over.