Why You Suck at Coding (And how to get Better)
Some people seem to learn programming so easily, while other struggle. Why? When I first started learning to code, I was terrible, and I stayed terrible for a long time, until I changed my mindset.
In this post I’m going to give you a couple reasons why I sucked at programming (And why you might too), and how to get better
You’re Not Curious.
When I started learning to code I didn’t care about programming, and I didn’t care how anything worked. I was just trying to build a product so I could start a business and make millions.
This is the worst mindset a programmer can have. If you want to learn how to code, you have to be curious. You have to learn how computers work. You need to understand how all of the pieces fit together in your app and how they interact. Successful programmers WANT to learn how technology works deeply. Slow down, enjoy the learning process and be curious. That is how you learn to code.
You’re Doing too much at once. Learn Each Thing By Itself
There are a lot of moving parts in the world of technology. You’re always picking up new tools, and you have to learn how to use each of them. It’s easiest to learn how to use that tool in isolation before trying to integrate it into your project, otherwise, when you get confused you won’t know which tool is doing what. Before using MySQL in your app, try learning MySQL all by itself, that way you know how the tool works on its own. Anything new or unfamiliar you come across will be much easier to learn without all the extra moving pieces.
Once you’re comfortable with a piece of technology, THEN move it into the rest of your app. Sometimes I’ll even create an entirely separate project just to test out some new piece of code or thingymajig.
You’re Not Patient
It’s hard to stop in the middle of a project and go research something else seemingly unrelated. A lot of times that’s exactly what you need to do.
I had a problem with my live website, and I needed to fix something in the Apache web server. Something to do with “Virtual Hosts”. I didn’t know anything about Apache, much less this scary sounding “virtual host” thingy, so I spent a day trying to copy & paste solutions on StackOverflow, and nothing worked.
So my old brilliant self finally decided to read the manual on Apache. I didn’t understand a word they were saying, and I had 12 tabs open all with giant walls of text explaining Apache. I looked at the several miles of docs and thought “I don’t have time for this Sh*t!” and went back to copying/pasting from Stack Overflow.
After wasting three days, teary eyed, and ready to throw my computer in the trash and become a Monk, I Finally opened the Apache manual and decided to learn all I could about Apache, regardless of how long it took.
Within thirty minutes I had solved my problem. I only solved the problem because I was willing to read the documentation and learn about Apache. You have to be willing to drop what you’re doing and learn how to use stuff. That’s why patience is so important.
Some other things I’ve wasted countless hours (even days) on because I wasn’t curious or patient are environment variables, the $PATH, SYMlinks, and User permissions. Something always seems to pop up when it’s inconvenient. You need the patience to stop, take a deep breath, and do the research.
You Get Angry
Getting angry when you code is nonsensical. It’s stupid. (I still get mad more than I’d like to admit). Your computer gives you hints and tells you what the problem is. Throwing a tantrum does not help in any way. Sometimes it’s hard to decipher the message, but there’s always feedback. You’re a detective and you gotta figure it out.
Reasoning and brain power goes down as you get mad, making your job 100x harder. If you ever get frustrated then it’s time to take a break. Be willing to walk away from a problem and come back to it with a fresh mind. At the second sign of frustration, I’ll sit down and meditate for 5 minutes. Whatever you do… Stop throwing tantrums.
You’re Not Solving Programming Challenges
You have to apply what you learn to real projects, no matter how small. To a beginner, programming challenges are everything. You start out with small and simple projects like “reversing a string” and “saving a users favorite food to a database”, and gradually increase the difficulty. every challenge will teach you something important, and the more you do the better you’ll get. Big programs like Facebook or YouTube are just a bunch of little programs working together. By starting with these small programs you’re learning the fundamentals to build bigger programs.
You’re Not Reading Books!
Blog posts and Tutorials are great and all, but reading books is the way to go! Not sure where to start? Check out this Recommended Reading List for programmers!
You’re Not Reading the Error… Or the Manual
I’ve seen so many beginners copy and paste an error message and ask someone what the problem is, when the error message tells you exactly what the problem is. A lot of time the responder will copy and paste a snippet of the message they were given, and paste it back to them. You can’t expect answers or information to jump out at you. You have to actually READ and UNDERSTAND the error message. It’s not just there to torture you. Read read read! Understand! Also, read the friendly manual. The manual is your friend.
You’re Not Refactoring.
Code will not make itself clean. Once you start being able to complete your projects, make a conscious effort to keep your code clean, and refactor things as they need to be refactored. It takes a lot more planning, and a lot more thought, but you should always be trying to improve your code quality, and always be refactoring your codebase. You don’t have to get it perfect, but as long as you consistently try to follow best practices and improve, you’ll make progress.
You’re Not Building an Awesome Portfolio
Completing a “Todo list tutorial” isn’t coding; It’s copying. In school they call this cheating. It only counts when it’s your own project. Reading and following along with tutorials can help you learn new concepts, but you have to apply what you learn to your own projects in order to gain any benefit, otherwise you’re just plagiarizing.
When you go through a tutorial, make sure you customize something! Make it your own. Keep track of all your projects on Github or BitBucket, start simple, and add features to each project. It’s fun to look back on the programs you created and see the progress you’ve made.
You can start with a super simple project and add tons of features. Here’s an example of project-progression:
- Ask a user for their name
- Ask a user for their name and favorite color.
- Change the background color to their favorite color.
- Save the users name and color to a database
- Match different users with the same favorite color and tell them they should hang out because they have so much in common.
- Use your creativity to keep going.
You’re Spreading Yourself Too Thin.
This one some people may disagree with. Just hear me out!
It’s tempting to jump around from language to language, but in the beginning it’s a bad idea. You don’t want to keep re-learning the same surface level stuff like for loops, arrays, and variable assignment. Instead, you want to go really deep into one language/stack. If you’re really good at one language, you’ll code 10X faster, have higher quality code, build products faster, have more confidence, and get paid a lot more. (Besides, it’s not that hard to switch languages anyway)
If you go deep into a language first, you’ll have a much better appreciation for differences when you do start experimenting with other languages. The surface level stuff is all very similar, so jumping around doesn’t do you much good until you’ve gone deep. That said, it IS important to experiment and learn new things. Once you’ve gotten comfortable in a language go explore!
If you want a job, or want to build a product, it’s helpful to be GOOD at a language, rather than being able to write a for loop in 50 languages.
Conclusion:
The main takeaways to become a better programmer are to genuinely be curious about how computers work, be patient, read the error messages, and to build cool stuff. If you put those elements together, then you’ll succeed as a programmer.
