In a bid to become a web developer, you’ve read a bunch of tutorials and gotten your feet wet with a couple of guided projects. You’re building solid front ends from the comfort of your terminal. Everything is going great, except that you feel like you’re hitting some kind of wall. You feel like someone pretending to program, that you’ve hardly scratched the surface. Impostor syndrome closes in around you.
Before you panic, know that the fear of not knowing what you don’t know is common. Hence the idiom, tip of the iceberg. What lays under the sea is unknown and can only be discovered by diving. We’ll walk through some of the tasks that can help you bolster your programming skills.
Don’t Build Safe Apps
Sometimes, as we begin our journey learning a new language, we fall prey to the familiar. We build the same TODO app three times because we’ve become comfortable with it. We continuously create variations of a basic CRUD app because we can recall the steps from memory and debug issues that arise. We don’t want to dive deeper and grapple with technologies we’d never used before. But diving deeper is the only way to improve. Although learning to code by building is the best way to learn, we still have to make sure that these projects continue to take us out of our comfort zone.
These projects should be somewhat ambitious. You can either start off with an idea, or you can make a list of the technologies you would like to improve on and make the app using them.
Some ideas can include:
- A fake news identifier
- A Netflix for books
Those are just a few ideas, but you can be as ambitious as you want. The idea is that you want to be able to learn through trial and error. Learning how to build a REPL may force you to go down the rabbit hole of compiler theory. Suddenly, you’ve gained a deeper understanding of programming languages, which helps to demystify compiler errors.
Go the extra mile and build for open source
Going into open source is the best way to experience the wild without the need to land a job. Once there, you will be exposed to how version control works in a team environment. This differs vastly from your personal version control where you wore all the hats. Now, you will be forced to learn how to write code that conforms to a certain guideline. You will also be acquainted with the file structure of packages and learn to skim through them to find the relevant folder.
For all of these reasons, getting into open source can appear daunting. Thankfully, you can ease into it by contributing to minor issues. These issues can be as small as a typo that needs fixing.
Dig into the meat of code
As you become accustomed to making small contributions to open source, there comes a time when you should decide to graduate and become a major contributor. To do that, you need to be able to read code. Reading code is one of the best ways to learn to code, especially if you have access to the author(s) of the code to ask them questions. By looking at their code, you can start to see how professional code is written and organized and then emulate that style. Eventually, you’ll be able to recall solutions that you’d seen in other code when you encounter a problem and be able to implement the solution. The reward of that feedback loop will only spur you on to read and understand other code bases. Ideas gleaned from them can be used to help build your own personal projects and will make you a more valuable contributor too open source. Once you’ve gotten to the point of consistent open source contribution, you will be a far cry away from the days of useless TODO apps.