Image by rawpixel.com
As a new programmer, there are multiple pitfalls awaiting you in your learning process. In fact, a lot of these mistakes are necessary as they reinforce learning through experience. However, encouraging learning through mistakes is not equivalent to encouraging making any/all mistakes possible.
It is wise to not only learn from your own mistakes but those of others too. In this article, I address 5 mistakes I made as a new programmer that hindered the speed and quality of my progress.
I don’t claim to be a faultless expert in my craft. I have come to understand that part of the experience of being a programmer is constant learning. Perhaps, I’ll never stop being a beginner, for even if I have years of experience, picking up a new technology makes me a beginner in that specific technology. The mistakes I talk about in this article are ones that will surely hinder any programmer’s progress regardless of their experience level.
1. Moving too fast
This one might sound ironic to most beginner developers. I get it, I’ve been there. You want to be prolific as quickly as possible. There are many possible reasons for this, maybe even as many as the number of people who make this mistake.
For me, one of the reasons was my desire to create things. As soon as I picked up programming, I read all these wonderful stories about the possibilities that come with honing this skill. I grew up with software: video games, websites, etc.
I wanted to be a part of the exclusive group of people that had the ability to create those virtual worlds, and I wanted that immediately.
This led me to accelerate my learning artificially. So I rushed through tutorials, books and free courses. Throughout this period, I was looking for material that would get me creating useful things instantly. However, this was a mistake on my part.
As I was rushing through this process, I didn’t allow myself enough time to get a solid grasp of programming fundamentals. It was easy to follow along with tutorials and make minimum changes to the code to create something slightly different.
When I looked back, I realised I didn’t understand much about the underlying principles that made everything work.
Another reason for rushing my learning was the self-induced pressure to be as good as the developers I learned from. It almost became a competition, as I wanted to be as smart and productive as they were.
I’m aware that it’s a toxic mindset, but that’s why I’m writing this article. My young, impressionable self did not consider that these people had years of experience under their belt.
Ultimately, there are several things that you have to understand as a new programmer:
Firstly, this takes time. A lot of time. Practice makes perfect, but it has to be good practice. The people you look up to, likely have years of experience to back up their skills. If it took them that long, you should be prepared to be just as patient and consistent.
Fundamentals are important. I know this is the boring stuff, but this is the stuff that defines your versatility as a developer. When you see developers picking up new programming languages or frameworks in a couple of weeks, that is because they have a good grasp of the fundamentals. These fundamentals tend to be shared among different technologies. So learn them.
This isn’t a race. Software development isn’t going anywhere anytime soon. You have to learn, but you don’t have to learn by next week. There will always be room to create. Innovation will always be welcome in the world. Take your time. Besides, it’s in your best interest to create something of high quality. Something people will actually find useful and enjoy. That only comes when you’ve put in the hard work to learn the boring stuff that truly makes you a good developer.
2. Copying code
A mistake I’m very ashamed of but one many developers are very familiar with. To clarify, I don’t have a problem with copying code in general, only the way I used to do it.
Let’s first discuss acceptable scenarios in which copying code is okay. If you’ve written the code before, you understand its logic and flow, and simply want to reuse it in another project, this is fine. If it’s someone else’s code that you’ve read and completely understood, this is also fine.
There are circumstances where I would advise against copying code. Firstly, if there are any potential legal issues then do not copy the code under any circumstances. This isn’t something most beginners have to deal with anyway. For me, as a beginner in a rush, I had the terrible habit of copying code that I knew would solve my problem instantly.
I would type an error message into google, find an answer, paste it into my source code, and repeat until I found a solution that worked. Once my problem was solved, I would continue coding my terrible application.
This ties into the first point as it was a product of my impatience. I wanted a problem solved as soon as possible, but in the process, I wasn’t taking the time to stop and investigate it. I didn’t think about it critically and understand the solution clearly.
Getting stuck in this field is normal. It’s even more frequent for a new programmer. The most important thing isn’t whether you get stuck, but how you handle it. These moments give us the opportunity to learn, grow and become better developers.
You are robbing yourself of the opportunity to become a better developer by skipping the hard work required to get past these hurdles. This also plays a big part in helping you develop your fundamentals and have a deeper understanding of the technology you’re using.
3. Comparing myself to other developers
As the old saying goes: Comparison is the thief of joy. This statement deeply resonates with me. I remember being miserable for a large chunk of my life as a new programmer. I would look at more experienced developers and compare my skills to theirs.
I would make projections and gauge how long it would take me to become as good as they are. This happened with almost all developers I came across: Other beginners, mid-level developers, even seniors with 20 years of experience!
At the time, I thought the constant comparisons would serve as motivation to push myself harder. I imagined progressing by leaps and bounds out of sheer dedication. This would all stem from comparisons to others, right? Well, no. Not at all.
This is actually tougher than it seems. I actually think comparison can be positive, but only in very specific situations. For example, working in a team and gauging your output in relation to the overall output of the rest of the team. I believe it’s important to match your pace with the team.
Too fast and you’re probably overlooking important details/and or alienating teammates. Too slow and you’re holding everyone back. However, because of the nuance involved, beginners tend to overdo this. Especially if you’re learning alone like I was. It’s hard to get a strong grasp on how much comparison is too much and determine when it’s hurting your progress rather than helping it.
My advice would be not to worry about others at all. As cliche as it sounds, it’s an important rule to keep in mind. Unless you’re going to be a competitive programmer (in which case, this doesn’t apply to you). You have to keep your head down and do the work necessary to get better. Do enough today to be a slightly better developer than you were yesterday.
Your only competition should be yourself. You are learning your craft. It’s ok to be bad at it in the beginning. It’s your discipline and consistent hard work that will allow you to progress over time, not how you directly compare to the next developer.
4. Trend hopping
As a new programmer, I was excited to create things once I started getting a decent grasp of programming. So much so that I let the excitement go unchecked. In my initial programming frenzy, I would pick up any shiny new language/framework I came across.
If the marketing was compelling, you could bet your money that I was going to adopt it. I excused this behaviour by labelling it “experimentation” but I knew what it was. Experimenting was the last thing I could reasonably call it. I was looking for tools that masked my deficiencies as a programmer.
This ties into the first mistake. If I had strong fundamentals, I would have better equipped myself with the ability to discern between technologies that were useful to me and ones that were not.
I’m definitely not an advocate for over-specialisation. I think that even advanced programmers could benefit from some degree of versatility, as it gives you the ability to pivot into another technology whenever required. However, over-diversification is also as bad.
There’s a happy medium somewhere in the middle. Instead of being a jack of all trades and master of none, try being a jack of a lot of trades and master of one. Have one area where most of your focus in building your skills is directed and a few other areas where you’re comfortable enough.
These areas of focus can change throughout your learning phase and even throughout your career. As long as you don’t try to bite off more than you can chew, you’ll be fine.
5. Complacency
The Dunning-Kruger effect is a cognitive bias where individuals overestimate their abilities. As I stated before, as a new programmer, I always compared myself to others, even other beginners.
Even though we all start somewhere, we don’t all necessarily start at the same level. Whenever I came across a new programmer whose skills weren’t what I would deem to be equal to mine, I allowed my ego to take over which led to an overestimation of my skills.
This is something that takes a lot of self-awareness to identify and correct. At the time, it was the cause of a lot of frustration. On one hand, I had a lot of people who were not as good as me yet, but on the other hand, I couldn’t build anything I was proud of with the skills I possessed at the time. Part of the problem was that my complacency stopped me from progressing.
I was stuck with mediocre skills and an average knowledge base at best for longer than necessary. I wasn’t motivated to learn because my ego convinced me that I already knew enough.
Complacency is a dangerous trap because it slowly drags you down without you even knowing it. It’s even worse in the software industry because there is an inherent demand to keep learning. Therefore, if you’re not learning, you’re actually getting regressing. It’s important to be self-aware at all times. Keep learning. No matter how much you know, it should never be ‘enough’. Always seek new information.
Final thoughts
The point of this article is not to make you hyper-vigilant as a new programmer. It’s good to have self-awareness. Knowing what habits to look out for that might be holding you back is vital for your development. I still have a lot to learn as my career progresses and I might even be making mistakes I’m not aware of right now.
The most important thing is doing our best to keep getting better in all aspects of our careers, and whenever we can, help others who might be prone to making the same mistakes we’ve learned from. If we do this, we won’t only have better developers but better communities too.
Finally, you’ve made a great choice by picking this discipline, whether it’s a hobby or profession. You have decided to embark on a journey that will allow you to create wonderful things. That being said, take this path for all its difficulties and rewards, but always remember to have fun with it.
