Like most self-taught programmers, I started coding because I wanted to build something useful. Little did I know what that would entail: confusion, bugs, and an endless amount of frameworks and plugins to choose from and use. A majority of the time, I’ll admit, instead of building something useful, I’ve been falling into the same ineffective behaviors.
It’s hard being a self learner—you don’t have a curriculum that’s going ensure that you stay focused and that the problems you solve continually challenge you. You can get caught up in trivialities. And, without the structure of a clear deadline or an explicit grading-scale, it’s easy to not realize you’re getting sidetracked.
Sometimes we need a bit of a reminder; I know I do. So instead of trying out that next new framework (no name calling!) or creating another semi-useful plugin (I can call myself out here: Ency.js), I created the list below.
Here are the don’ts of learning how to code:
Don’t try to learn everything at once. There’s a lot of moving parts to programming. There’s the frontend, the backend, the database, the hosting, as well as the frameworks and plugins that glue it all together. With all these parts, it’s easy to get overwhelmed. But you don’t need to learn everything at once. Start with what you absolutely need: build and validate the core of your idea. Don’t get sidetracked trying to adopt a tool you don’t yet need–even if you think you’ll eventually need it. You’ll derive more value from using a tool when it serves a practical purpose; and slowly as you begin to need these tools, you’ll learn them, integrate them, and gain the capability to use them all together seamlessly.
Don’t overstress about picking the perfect tool. Your ultimate goal is to learn programming concepts. But, of course, you don’t use concepts, you use tools; and so, you also have to learn the specifics of the tools you choose. You’ll have lots of options to choose from: Ember or Vue, Node or Ruby, Sass or Stylus, etc. So just remember that any useful tool was created to fill a gap and satisfy different tastes, and so it optimized differently. Don’t try to be a maxzimizer or you’ll spend more time googling “React versus Vue” than you do programming. Quickly narrow down your search: look at the amount of stars, the open versus closed issues, the quality of the documentation, the philosophy behind the project, and the community around it. If you’re just getting started, favor good documentation and a thriving community. Still stuck? Don’t get lost in the abstract decision–write some code! Pick the tool that was easiest to get going with. If you need to switch later, you’ll do so with a better understanding of why and adopting the new tool will be faster and easier.
Don’t become dependent on your google searches. Yes, you want to pick a tool with a thriving community–you’ll have a variety of blog posts, tutorials, and stackoverflow questions to learn from. But don’t become dependent on it–there won’t be a guide for all your specific use cases, nor an answer for all the problems you encounter. As you become more comfortable with programming, learn to rely more on good documentation and well-written code. That’s where you’ll find the answer for most advanced use cases anyway, so rather than skimming through four pages of google search results for the off-chance that someone else wrote about your problem, learn to read documentation first and explore similar codebases second.
Don’t be afraid to dig into other people’s code. A great way to not only learn, but improve the quality of your code, is to dig into the code of a project you admire and try to figure out how it all works and comes together. You’ll naturally resist at first–it’s easy to see a project with 56,425 stars and think that the code inside is beyond your understanding. But do you know about functions, classes, and closures? Well, that sort of foundational knowledge is all you need to understand 95% of the code in most projects. As you dig in and begin to understand how it all comes together, you’ll begin to see that the code they wrote is not much different from what you’re capable of. The real difference is that they created something useful–and when you read other people’s code, you realize that you can do that, too.
Don’t try to create an open source solution for everything. Creating a plugin that solves a problem you encountered is a great way to learn and contribute. But done wrongly, this tedency can become time-consuming, distracting, and draining. You’ll find plenty of little ways that things could be improved. Ask yourself: Is it a strong enough pain-point? How many times have you felt you needed this? It sucks spending weeks to months building something no one is going to use, specially if you knew you were suppose to be building something else, and don’t care enough about the project to actively promote or maintain it. This advice is more important than not reinventing the wheel–it is about not squandering your time.
If you made it this far, I should probably tell you: you’ll probably still make these mistakes yourself–it’s human nature. But keep them in mind and come back to this if you need to. I have trust that you’ll catch yourself the second or third time.