How not to learn programming (if you want to build something useful)

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 ineffective behaviors.

It’s hard being a self learner—you don’t have a curriculum that’s going ensure you stay focused and that the problems you solve continually challenge you. You can get caught up in trivialities. Without 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 a shiny 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, React or Vue, Node, Elixir or Ruby 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 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 the one you’re capable of writing. The real difference is that they created something useful–and when you read other people’s code, you realize 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. But done wrongly, this tendency can become time-consuming, distracting, and draining. You’ll find plenty of little ways that things can be improved. Ask yourself: Is it a strong enough pain-point? How many times have you needed this? It sucks spending weeks to months building something no one is using, specially if you knew you were suppose to be building something else, and you 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 coder nature. But keep this list in mind and come back to as you need to; I have trust that you’ll catch yourself the second or third time.