This post was originally posted to my blog.
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.
Dan Abramov at JSConf 2018
This talk by Dan Abramov opened my eyes to React and JavaScript. It helped me to clear out a lot of the burden I was carrying by trying to create the perfect app/tool.
Dan Abramov on Twitter
Recently, Dan tweeted something which led me to scrapping all the extra features in my apps. and coming up with a smaller concept to ship called an MVP.
So What is 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.
Real artists ship. —Steve Jobs
Pick an MVP and Open Source It
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, GitLab, or Bitbucket1 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.
Open Source But Don't Go Star Chasing
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.
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.
Learn in Public
Shawn Wang 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.
Experiencing Perfectionism
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.
Let's Go.
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 repos littering my GitHub profile.
Conclusion
You can build pretty much anything you want, even if 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.
Get set up on GitHub, create a repo, get a little documentation set up for it, and share it on Twitter, LinkedIn, Hacker News, wherever.
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. ↩
Top comments (10)
dev.to has been a journey of progressively less crappy MVPs. I think I released the first version about five days after deciding to take on the project.
I was just listening to you on Indie Hackers. When editing this, I thought about joining dev.to for the first time back in 2016. That app was in stark contrast to the app you have today. Brava!
There's an interesting argument to be made against MVP in favor of SLC. I've fallen into this trap myself, by focusing on making something that works rather than something with added value. In essence, I was lacking the 'Lovable' part.
Going open source is something you can do regardless of achieving MVP or SLC status :-)
This is an interesting take on this. Thanks for the link.
I like the focus on having a usability mindset. Shipping a finished, but unusable (not lovable) product seems like it would hurt your brand.
Your product should be usable. If not, why ship it? My problem was feature creep and being overwhelmed by the scope of the project. It shouldn't have taken so long, to be honest. I have one more critical feature to build and until that is built, it won't be shipped. Hoping for Monday but if that feature isn't there, it won't be shipped.
In the corporate world determining the scope of work that produces the minimum feature set to solve the need is so important when you are seeking approval from the higher-ups on your project.
For every project or feature-add I determine the minimum needed to make it usable, start making money from it, or realize the benefit. I pitch it like: this much effort will get us to here, we can launch, then bang the rest out with continuous releases until complete. If the fully-completed project takes more than a couple months it may get cancelled halfway through because priorities shifted, so bite-sized chucks are important.
Finance wants to start depreciating the capital hours ASAP, execs want to see benefits ASAP, and customers want to see progress on their feature ASAP.
Now with that first release you can gather feedback and maybe the features you planned aren't really needed, the basic features are good enough and priorities have changed, or customers want something different than they thought they did. You haven't wasted 6 months working to be feature-complete to find that out.
I think indie hackers would be a good place to see MVP in action almost. This is a community of people working to get their ideas out there and usually in an MVP first, and then iterating.
I follow Dan Abramov too! He has a lot of good advice. Iterative development is always a good practice. It gives you a chance to release new features and get feedback on the current ones before implementing new ones.
If you're not following Evan Czaplicki too I would do that. He's the creator of Elm and he has a lot of really good talks! Here's one of my favorites:
Code is the Easy Part
Thanks for sharing!