5 mistakes I have made as a beginner
Tags: beginners, career
Published: 2020-02-09 15:15:02

*This article was originally published [here](https://nikolastojakovic.com/2020/02/09/5-mistakes-i-have-made-as-a-beginner/).*

I'll spare you a lecture about mistakes. I know you're here to read a concrete advice. After about four years of professional career and eight years since I wrote the first program, the time has finally come. I'm posting this in a hope you won't repeat the same mistakes I did. But don't expect to dodge all the bullets. In both, life and software development, the best you can do is to minimize the eventual damage.

## 1. Learning many languages

The first *real* program I wrote (and by real I don't mean [Hello world](https://en.wikipedia.org/wiki/%22Hello,_World!%22_program)) was a quiz game in C++. Not long after that I have tried VB.NET, Java, C, Python, C#, Ruby, JavaScript, Perl and even Pascal. I was switching languages like an expert in the industry with decades of experience, while in fact I wasn't even a strong junior. Thankfully, this period didn't last long. But I know there are still juniors doing it today. Dozens of times I would get a question on Quora in this form;

> I have learned A and B language, should I learn C, D or E programming language?

[Ironically](http://www.aplusdev.org/About/index.html), [all](https://en.wikipedia.org/wiki/B_(programming_language)) [these](https://en.wikipedia.org/wiki/C_(programming_language)) [languages](https://en.wikipedia.org/wiki/D_(programming_language)) [exist](https://en.wikipedia.org/wiki/E_(programming_language)) (imagine there were mainstream languages instead of letters). While it's true that experienced software engineers do know multiple languages, you should start by learning only one language. When you finish learning fundamentals of the language, you should start doing practical projects in it. Same applies to any tool / library / framework.

On the other hand, it doesn't mean you should spend whole your career knowing only one language. Reading about other languages and even playing with them from time to time will help you to broaden your horizons. You will discover new paradigms and new approaches for solving problems. Just don't become too obsessed with it like I was in the beginning of my career.

## 2. Focusing too much on the theory

The most common thing presented as a disadvantage of self-taught developers is a lack of formal education. For someone who is self-taught, I had good theoretical foundation quite early in my career. But it took few years before I filled my CV with projects I can show off to future employers. Not because I wasn't able to do the same thing in one year, but because I was losing focus on other things.

Now, don't take this wrong. Theory **is** important. There is a good reason why almost all people who are pushing boundaries of our field have computer science degrees and PhDs. At the end of the day, someone has to build the tools we're using on our job, from compilers to web browsers. But all the theory on this world won't help you to write a better code if you don't start **writing** it now.

Sure, writing top-down insertion algorithm for red-black trees from the top of your head is great, but does it really serve any purpose for a web developer working on small business sites? I highly doubt that. Try to enjoy the first year of your career as a developer as much as you can and build the stuff without caring whether your queries are highly tuned or whether your classes expose too much information. You will have enough time to worry about that later on in your career.

## 3. Avoiding to read other people's code

For a long time I had some sort of *fear* of reading other people's code. I was like, how can I understand something someone wrote X months or years before? Heck, sometimes I don't even understand my own code after a few months! Of course, I knew about comments, but I had no idea about documentation at that time (you should see the look on my face when I discovered there is a way to test your software automatically).

I finally became comfortable reading other people's code when I stumbled upon few problems which required from me to go beyond the library documentation. I had to truly understand what's happening under the surface. And for that, you need to dive in the source code. You need to step through each instruction and ask yourself questions in the process. You can't become a great poet without reading any poetry. And you can't become a great developer without reading any code.

This was an enlightening experience to say the least. It was the moment I realized there are no perfect developers. I have discovered chunks of dead code, unnecessary abstractions, obscure optimizations and lots of shitty code overall. Early in my career I thought that each of my projects will be an empty sheet. What they often don't tell you about software development is that you'll spend most of your time working on the code your colleagues have written. Learn to accept that and your life will be a lot easier.

## 4. Starting to learn with advanced projects

Compilers, operating systems, browser engines, databases, frameworks, CVSs... There are all sorts of fascinating things people have built in our field. Some of them have multiple human-life spans of work behind them and knowledge passed on by generations. I think pretty much every developer once in their career thought about making their own framework or programming language. Unfortunately, I spent too much time thinking about it and even trying to replicate some of this stuff.

Before you try to run, you should learn how to walk. It's not that you won't learn much from writing your own operating system, for example. You definitely will. But before you try to bite more than you can chew, do a research and see if you have prerequisites to even start doing something. Developing an operating system requires solid knowledge in dozens of topics. Computer architecture, Assembly, file systems, memory management, concurrency etc. And you still won't be able to write something even close to Windows.

Healthy advancement is the key. Moving some parts of your monolithic apps to isolated services can be example of that. Or writing a simple MVC application from the ground up in PHP, without using any framework. This way you won't become overwhelmed by the learning material and you will still learn more advanced stuff.

## 5. Not spending time with other developers

The first developer I have ever met was a friend from secondary school (I was 16 at the time). Before that I had no idea how important networking is. I discovered there are a few guys from my school who were also developing stuff in their spare time. That's how my professional career started. I did enough jobs to fill my CV with something valuable and landed my first full-time job in 2018. If it wasn't for this connections, my career would probably start much later.

People typically have this notion of developers being lone wolves avoiding any human contact. This has to stop. It's a toxic view which just harms the community. You **should** ask the questions. You **should** attend that meetup. One of the reasons why I started blogging was to make new contacts. But it doesn't have to be blogging. You may find public speaking more engaging. Or it could be that you're introverted and feel more comfortable speaking with people online. Everything is fine, as long as you don't lose the contact with the rest of community.

You don't have to spend time with other developers only when you need some help. Being active in the community allows you to keep up on the new trends too. You can explore new approaches for solving problems or even help someone else. One day on my job I struggled to design a layout for the cross-sell popup on one site. I asked colleague who worked as a front-end developer for help. He then introduced me to Flexbox and even gave me [Flexbox Cheatsheet](https://yoksel.github.io/flex-cheatsheet/). This is one of the advantages of working on-site; you can easily ask for help.

*P.S. Don't hesitate to share your own mistakes in the comments.*