With so many resources available today, learning software development can still be a challenge. The anxiety of constantly changing technologies, along with having to sort through vast amounts of content, all while committing hours of your life to complete courses and books can be daunting.
Software development courses and content can also quickly become outdated. To top it all off, there are just way too many distractions in the Information Age.
We all need a strategy to filter out the noise and to keep us focused and on track for mastering the really important ideas. Regardless of your level of experience, this is my call to action for all developers.
I want to get my thoughts down before I forget, and practice what I preach by utilizing the same process that I’m advocating for here in this post. I’ve used the same MVP method I’ll be discussing in this blog post in order to write what you’re reading here. I’m focused more specifically on code and engineering, but in theory, these ideas are applicable to most creative projects.
Learning versus Doing
It only takes one Google search to realize that we’re living in a great time to learn software development. There are obviously more choices now than ever before, but generally you can study via courses, classes, tutorials, etc., or you can learn by doing and building something.
An approach that many of my co-workers at WebDevStudios utilize is a hybrid of learning and doing. The approach basically works like this. First, take a course, read a book, or dig into some documentation for something you’re interested in learning.
Spend some dedicated time to study and do exercises in order to learn the basics of the new concept. However, it’s important to not stop there. This is the stage where too many people feel they’ve grasped the material. After a few months, their understanding will probably diminish significantly.
Instead of moving on to the next shiny new idea that competes for your attention online, take an equal amount of time to build something with that new knowledge. Studying to learn is absolutely important; it’s what helps us grow as developers.
If you want the knowledge to stick around, you need to put it to use. Building (practice) is equally as important as studying. You need to test your knowledge and confirm that you’re really able to put the ideas to use.
MVP Method—Your Loyal Friend
The hybrid approach of learning and building pairs itself well with the MVP method. MVP stands for Minimum Viable Product. According to Wikipedia:
A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.
Someone who I’ve been fortunate enough to work alongside and learn from is Sal Farrarello, Principal Engineer at WebDevStudios. He describes the MVP like this:
Building with a MVP mindset helps avoid the classic pitfall of not finishing a project. With an MVP, you get something out the door fast. It may not have everything you want but it does something for you. Even if you never touch it again, you’ve got something.
Stick to the plan.
Before you even get started, put some upfront time into planning your project. Ask yourself what features it should have and what a completed project looks like.
If you’re following the MVP method, you’ll want to set the scope of your project to be as small as possible. The aim is to set realistic goals that you know you’ll be able to chip away at, then ultimately be satisfied enough to call it done.
Lastly, it’s really important to stick to your plan. From my experience, one of the quickest ways to enter the danger zone is get distracted from the original plan and to start adding features that you think would be “cool.”
The beauty of working in a minimalistic and iterative manner is that you can always make a new Git branch for version 1.1 later. For now, FOCUS on the plan you’ve agreed to with yourself.
Make the repository now!
In the spirit of the MVP method, don’t wait until you’re well into coding before making a repo for your project. The status can remain private until you feel like it’s ready to share, but there’s no better time than the present.
A way to keep yourself inspired and motivated is to put some care into the README file. It’s ultimately the first thing people will see when they visit your repository, and it puts a flag in the ground in terms of inspiration to finish your project.
I personally think GitHub is an incredible place for documenting your ideas while you put them into practice, and it provides a great channel for other developers to find your code and learn from it. One instant benefit of doing this is that instead of digging through random folders on your hard drive months from now, you’ll always know exactly where to go in order to find that code.
Add a twist to make it interesting for yourself.
Doing a personal project doesn’t have to be a dull task. Consider incorporating something you’re interested in.
It’s a chance to express yourself, and to add something unique. If you to like birdwatching on the weekend, create a project related to that. If you’re into a particular sport, maybe find a way to display data in a unique way related to the sport.
Set yourself up to remain interested, so that when things get tough, which they usually will at some point, you’ll have the inspiration to push through and finish.
I was recently studying a course on React. When I finished with the course material, and while it was still top of mind, I started brainstorming for ways to put the major concepts into practice.
The project is small and does only one thing. But, I feel like I’ve done the most important thing for the moment. I’ve built something with what I just learned. I can now call it complete and move on to a different project with ideas that I thought about along the way.
Standing on the shoulders of giants.
From my personal experience, I’ve found that about halfway through a personal project, self-doubt can start to creep in. It becomes easy to start comparing myself to others with thoughts like, “Is this really worth sharing?” or “What’s so original about this anyway?”
As part of my personal growth, I’ve found it helpful to remember that we’re all standing on the shoulders of giants. Perhaps someone scouring GitHub for a working code example will come across your incredibly simple, easy to grok repo (with awesome README) and stand on YOUR shoulders.
Giving yourself a framework like the MVP method and a project with an intentionally small scope, you’ll achieve several things. You’ll have less impostor syndrome because you’ll be too busy working to compare yourself to others. You’ll stop worrying about what others think, because you’re doing the best you can in this moment.
In my opinion, a small finished project gives much more pride than a lingering monster of an unfinished project. With this newfound inspiration, perhaps I’ll go back and reframe some incomplete projects with a new, more realistic scope. I know in the future, I’ll start small and finish small.