MVPs and Iterating Your Way to a Finished Product
I have long struggled with building the projects I set out to build and fill my GitHub with. This is due to a crippling penchant for perfectionism at all costs. This is dangerous for your mental health, productivity, and prospective employers.
I began to feel stifled and overwhelmed by the scope of the projects I was creating...until recently.
Recently, Dan tweeted something which led me to scrap all the extra features in my apps. and coming up with a smaller concept to ship called an MVP.
MVP stands for Minimum Viable Product. This is an app with a small set of features you ship to have something ready to consume.
An MVP helps new developers fill their portfolios with meaningful projects. This will help them stand out from other new developers. This is if the code is clean, well structured, and the project is functional.
You can always iterate on the MVP instead of trying to perfect a project: no software project is perfect. You might as well ship.
Open Source is not some fad that software engineers are fanatic about. It is the lifeblood of software development today.
Using an open-source platform like GitHub (opens in a new tab), GitLab (opens in a new tab), or Bitbucket (opens in a new tab)1 will showcase to prospective employers what you are working on. It also shows how well you're doing with what you're working on, and it also shows growth and your learning process2.
A lot of times, new developers, myself included, want to hit it big on GitHub and get thousands of stars on a project and make the trending repositories list (opens in a new tab).
Stop. It's definitely a trap.
Having a popular repo on GitHub is rare; there are 350 million+ users on GitHub and even more repositories. The odds are against you, at least at first.
Getting your feet wet in open source, building your skills, is the best thing you can do when you're starting out. Once you get a feel for open source, you can build something more significant. If the developer community finds it interesting, the stars will come.
Shawn Wang (opens in a new tab) is a popular React developer at Netlify. He tweeted the phrase learn in public which encapsulates what I mean when I say you should open source your MVP:
Learning and failing in public is an important part of getting your work noticed. The more you iterate and share, the more visible you are to prospective employers. This is why it is important to get something out the door.
I wanted my current app, Check Yo Self to be a beautiful, full stack environment to check your markdown blog posts. It went through many iterations but, I stalled on building it. Every shiny new thing I wanted to add to it to make it perfect overwhelmed me; it was crippling.
I have been working on this app for a year and a half, almost two years now. It should be, considering its simple premise, finished. The scope creep, the feeling that it needed to look better than similar apps left me paralyzed. I was unable to work on it. It killed my productivity and I stopped working on it for months.
After watching Dan's talk and reading his tweets, I decided that I should build a few features. Then, after they're built, I can iterate on it.
I am also working on a CLI tool. I have been working on that for 8 months now and it's taken that long for the same reason.
I stripped all the extra options and have been working on it for the past few days.
Considering all the small npm tools out there, I can make a tool with a couple small functions that are useful. That's it.
This relieved a lot of the stress I was feeling over the course of the past year. Now I knew I could ship something and not have the weight of abandoned (opens in a new tab) repos (opens in a new tab) littering my GitHub profile.
You can build pretty much anything you want, even if it there are similar tools out there. You have a unique perspective and you can bring that to a project that someone else has built. You'll build it in a different way.
You'll then have something to add to your portfolio and resume to be proud of. You can always build on top of what you have later.
I'd choose GitHub over all the other ones. It is the de facto standard currently. Most employers who look for open source contributions do so at GitHub. ↩
There's a lot of debate about having your GitHub be a requirement for a software engineering position. If you work 9-5, have a family and other obligations, open sourcing side projects or side projects in general, will not be something you're able to do. Contributing to open source would be difficult as well. It is something new developers should look into, regardless. ↩