10 common mistakes when learning to code and how to fix them
15 min read
Starting with programming can be both exciting and exhausting at the same time, its a demanding activity that needs a lot of focus and energy to do it correct and consistent.
I am going to share 10 mistakes I think most beginners make and some advice on how to navigate away from those mistakes and accelerate your learning journey and career.
1) Trying to learn everything in a single day
Most beginners I meet are very interested or in a hurry of a job search, this can be a motivating factor in the beginning but if you don't have enough patience, it'll undermine your efforts to reach expertise. The human brain can only learn so much within a given time frame, so there is no point in trying to dump your brain with a lot of information.
Have a schedule or a time where you limit yourself to learn only so much and then spend time in other less brain-intensive activities, I found solutions to some of my complex coding problems when I am away from my computer and I also saw few other people said about similar experiences. So it's worth stepping away for a while and has some reflection on what you have learned so far.
Everyone is different and has a different method of learning things, some prefer videos, some prefer reading and some prefer to learn by reverse-engineering something. Find out which is your way and stick to that way of learning.
You should know that if your current learning method is working well for you or not and change the method if you have to. To find out which learning method works for you, take this test and use it as a starting point.
2) Focusing too much on the tools than the fundamentals
The frameworks you use are just tools that are built over the languages, so it is always better to learn the languages well first and then jump into a framework. It is also okay to learn both of them at the same time, but you will develop a tunnel vision which means not being able to think outside of the boundaries of your framework.
- Data structures,
- Object-oriented programming,
- Design patterns
- SOLID principles
These are some language agnostic topics that one should master in their career and the list is not definitive.
Doing the above two will allow you to switch easily between different languages and frameworks easily, so you can stay employable with little effort even if your favorite framework/language has been dethroned by something else.
If you are getting stuck on difficult topics such as dynamic programming, AlgoMonster is great place to learn and gain confidence. They have the most extensive coverage on the common patterns and also have content on object-oriented design.
To learn and improve your skills around algorithms, algodaily is a great website, For other items in the list Google is your friend. Also please let me know any other topics that you think that should be added to this list.
3) Learning without plan & goal
When you're learning something without a plan and goal the chances are that you may not stick long enough to master it or finish learning it. You may jump ship the moment you think that it is not for you or you think you found a better option. To avoid this, it is necessary to have a learning goal.
On the subject of goals, I would suggest you to set SMART goals. but,
What is SMART?
- T-ime bound
If you are interested to learn more about SMART GOALS please refer to this article. In layman terms, A smart learning goal is not just "I want to learn ReactJS", it should be "I want to learn React in 3 months and start on a junior level job". Creating a goal this way will give you a boost of what you can/will be once you finished learning this. Note that it has a timeline as well. Timelines are important to measure progress and make changes when necessary. I say timeline, not a deadline, it is okay to exceed this timeline as long as you're making good progress but don't run without a goal and a time you think will take to achieve it.
The above is a macro-level goal, you should actually split it into small micro-level goals and this where a plan and schedule comes in. A plan is necessary because without a plan it is easy to get lost in the day to day things and forget the overall picture. Once you set your goal, spend some time analyzing various things you need to learn to achieve your goal and put some time for each of them. Also plan on how long each day you can spend on learning.
A general rule of thumb when planning/estimating is not to over commit and under deliver. When you plan always leave room for your other day to day activities, good sleep (This is necessary to retain what you learned), and your day job (if you have one).
4) learning without doing
This is one of the biggest mistakes that some people do, I have seen people watch tutorials as they watch Netflix shows. It might give you a false feeling that you learned a lot, but you may not grasp most of the concepts unless you are Mike Ross. So what is the solution?
Get your hands dirty. Try what you learned just now, fail, try again. Once you feel that you can do it easily, move on to the next thing. Remember, we are learning things because we are going to need to do it in our job, so no point in just watching or reading about it.
When thinking about doing it, there is one thing we all stumble upon, What to build? You can think about ideas and spend some time on creating new ones, but a better way would be just replicating existing websites with what you've learned.
Build a Medium clone, Twitter's feed, Trello board, or a simple Todo list (That is the universal hello world of applications). You can also look for resources that give you simple app ideas such as this one from Florin Pop.
5) Not seeking help when needed
This might be easier said than done, identifying whether you can do something on your own or you need some help from experienced people can really save you a lot of time. When I was a beginner, I was obsessed with hashing and encryption, I tried to write my own encryption algorithm without even understanding the basics of cybersecurity, it took me a long time to realize that encryption algorithms are solved problems and me writing a better solution is highly unlikely. But the time I spent on that is lost, It could have been avoided if I had someone to tell me the hard truth and advise me to use existing methods.
The above can apply to a lot of topics. Mostly it can be summed up easily by someone who already knows it and then you can expand your knowledge based on need rather than trying to learn everything on your own.
Some people also might get stuck in some issue and they'll waste a lot of time with it without actually having a methodical way to solve that issue, this must be minimized to save time and can be solved by approaching a mentor as they can point you in the right direction.
I am not saying that you should not give it enough tries or you should always seek other's help, but use your judgment to realize if this can be solved by you or not. That is a skill one needs to master over time.
Once you decided that you need help, where to seek help? You can use the twitter hashtags like #100DaysofCode to tweet your doubts and you will get help from the awesome tech tweeters. If you're a beginner looking for a mentor or if you're an expert looking to give back to the people, CodingCoach is a great platform to find out mentors and mentees and to get help when you need it, Check it out.
6) Burnout / Losing motivation to learn
We all have to admit that learning is hard, you must find your motivation factor and keep yourself motivated over a period of time to learn continuously. But this is not as easy as it sounds, even people who are looking for a job that might change their life forever will also burn out and lose their motivation. Why learning is so hard?
It takes some strong effort and significant time from our everyday schedule, mostly we will be spending a lot of time in the beginning when your motivation is relatively higher. As time goes on you'll start burning out and it slows you down significantly even if you spend a lot of time learning. Burn out is real and it is important to keep yourself out of it to be productive in the long run.
What does it take to not burn yourself out? Have hobbies that are totally unrelated to computers, try to spend some away from your machine and it'll really improve your overall performance. Read a book, Go cycling, Swimming, Play some games. Do something physically extensive and have a good night's sleep and start your next day fresh.
I found myself more productive and positive when I spend a few days away from the computer doing physical activities. Don't beat yourself without taking rest, it'll only be counterproductive.
7) Underestimating the importance of debugging skills
If you ask me what is the one important skill that every developer needs to master, I would say debugging. I am sure different people might have different opinions but everyone would agree that debugging is a skill that is important which can save a lot of headaches when dealing with issues or other's code-base.
You should learn about debugging tools, techniques, how to isolate errors, or how to reproduce them in a stackblitz or codepen so you can approach others for help with it. Debugging is really easy once you learn how to rule out factors and isolate the error. These are some easy steps that you can use to debug in any language in general.
Always read the error messages first
Most frameworks/languages themselves explain to you what the error is and will give you some advice on how to fix them.
Google the error
One of the important skills a programmer can have is to be able to search different or relevant parts of the error in search engines and narrow down the results for his own issue.
Read the docs/FAQ
For any common errors that you might encounter, Flutter has some common errors when android SDK is not installed or when an android emulator/device is not connected. You can find these on their docs.
Master the debugging tool of your trade:
IMHO, Front-end web developers have the best debugging tools built right into the browser. Don't be afraid to spend some time learning about the browser developer tools and harness its power to your advantage.
To learn about the tools you can subscribe to this amazing Dev tools newsletter by Umar Hansa.
For chrome users to learn more about it here, Firefox users can learn more about your browser's dev tool here..
Debugging using breakpoints
You can use console.log statements to check values at run-time, but when if it is an object the browser will update the values to existing logs, because of the object reference. A better way to check what values are flowing through your program is to use breakpoints. You can stop the program at any point using this and check what are the current state of your application data. You can also use a watch to see how a single value is changing over the execution of the program. These two are really lifesavers for otherwise hair-splitting errors.
Embrace the power of an IDE
Most of the errors you face can be solved by using a decent IDE such as VSCode or IntelliJ products, you can't beat the intellisense an IDE can provide about the code and the language. Both of the mentioned editors also have inline debugging capabilities meaning that you don't even need to open your browser's dev tools and debug, you can directly debug right from your IDE by using breakpoints. That'll be like browser dev tools on steroids. It might be a little challenging to set it up but it's worth the effort. Please give it a try.
8) Being afraid of failure
This is something that is not often discussed, When you're learning something it is okay to fail and it doesn't make you unfit for that task. Failure is as important as a success because it can show you weaker areas of your skill and you should start focusing on that area.
So don't worry too much if you can't understand Flexbox or Can't fix a JS issue yet. It'll take time to get these things figured out and you must be patient and more importantly consistent with your efforts.
9) Getting into internet debates about programming
I can't go without saying this, a lot of beginners tend to get into debates or spend time watching comment threads over X language vs Y language or X framework or Y framework.
As beginners, we assume that our way of doing something is the correct way and all other ways are wrong. been there, done that. It is not really going to be helpful to you, instead, it'll box you within a cage of opinions that are formed by others.
The ideal way is you should approach any tool with a very open mind, try it for yourself and form your own opinion. If you can't afford the time to do it by yourself, fine. You don't need to have an opinion about every new thing coming up.
Try to stay away from people who have the mindset as "which is best X or Y", every tool is created for a problem and in programming, there are really different ways to solve the same problem. So it is okay to have 3 frameworks or tools to do the same thing, you should check them out and pick the right one which is suitable for you.
There is a very thin line between comparing two technologies in a healthy way and starting a flame war one over the other, the line is often blurry. The mantra here is,
Right tool for the right job.
10) Not creating good developer habits
This is something that is better built from day one, its hard to break free once you got used to doing things in a certain way. Below are some important things that a developer should be mindful of so one should start thinking about these things right from your learning journey. Trust me, your future colleagues will love you for these good habits.
Whether you're naming a function, variable, class, always see to it that the names are shorter and meaningful. I would trade shortness over clear and meaningful names that easily express the intent of the variable.
This is not something you should start worrying about when learning, but whenever you code a project, you should be thinking about software architecture.
How you are going to implement the project?
How different modules work and communicate?
Software architecture is basically about making the fundamental structural choices that are costlier to change once implemented.
cleaning up after yourself
It's like the boy scout's rule of software development,
Leave the code better than you found it
If that is too hard to do, try atleast not to make more mess in it. Handle your memory properly, Remove unnecessary imports, functions, and Variables. Handle your subscriptions(rxjs) or unsubscribe properly, free up any memory you occupied. These are the things that need to be taken care of when you finish coding a feature.
Write a good, meaningful commit message that is relevant to the change. It'll help your future self or the future maintainer of the code, this of course is not very easy, so you must start doing it properly from the beginning. Doesn't matter if you're the only one person committing to that repository or if it is just a pet project.
Follow this thread to learn from a lot of people about writing good commit messages.
My one tip is to forget git commit -m is an option, I always use git commit -v explicitly. If you're wondering what's the difference, -m allows only a single line message whereas the -v opens your default git editor and allows you to write really long multi-line messages.
Aligning your code is a good habit that you should develop from day one, sure you can let your IDE do the heavy lifting for you or there are tools like prettier but I would prefer to have that as nature rather than depending on some external tools. Setup a tool like Prettier once you got proper aligning and spacing habits.
Aligning is important because the code should be readable for anyone who comes after you or to your future self. Nothing is worse than long lines of unaligned code. There is a lot more to readability than just alignment, this one can be a good starting point.
Good developers also should master the subtle art of commenting, why would one call it art? because you need to figure out the sweet spot between over commenting and not doing it. Not every line has to be commented on because your code should be mostly self-explanatory.
One thumb rule of commenting is try not to explain what you're doing in the code, any developer can figure out what you're doing, it's the way you are doing it is what should be interested. Imagine I am going to refactor a function you wrote, you made some comment about what you're doing in each line, any of that doesn't matter because I am going to refactor and probably will clear half of the lines or rewrite it completely. If you handled a special business case or a special edge case, that's what important and should be documented so I can take that into account as well.
// This is where the magic happens
The above is not a valid comment. I did this comment when I was a starting out and now I am laughing at me looking back. It is tempting to think some piece of code as magic or some of the smartest code you wrote as magical, but there is no magic as Robert A. Heinlein once said,
> One man's magic is another man's engineering.
It doesn't matter how smart or magical it seems it will be always logical, even bugs that are very hard to trace will be most logical, only that you have to start thinking like a compiler/interpreter of that language.
These are my advice for people who are learning to code are on your first job. I don't consider myself a great developer but I think I made some of the mistakes from the list above and learned a great deal from them. What are your lessons learned in your career? Feel free to share your thoughts on this article in the comments or to me on Twitter.