DEV Community

Cover image for What was the starting point for becoming a mid-level frontend engineer?
Felipe Gustavo
Felipe Gustavo

Posted on • Updated on • Originally published at felipegs.com

What was the starting point for becoming a mid-level frontend engineer?

Introduction

There are some turning points in our lives that change our way of viewing things and the future. One important of mine is the podcast that I heard in mid-2014 that made me take a technical computer course and brought me to this software’s world.

After that, I went to college, started to work as a junior programmer and arrived at the position that I am today, as a mid-level frontend engineer.

I need to make a disclaimer here: this is not a guide or something like that, it is just a little of my experiences.

The initial step

So the year was 2019, I was working at that time as a junior frontend developer to a big corporation in Brazil. That was the first time working with a big product and I had some knowledge about React, but I didn’t have experience working in real apps and the whole frontend of that company was in React.

It is important to gain knowledge and practice a lot to become faster in building things and solving problems, but this is a natural process that can be accelerated if you practice more and study a lot.

But when I was a junior, all the sprints had stories that scared me, I felt like I was not capable of doing that.

What was that fear?

The lack of experience was what makes everything seems harder than it actually is. This creates a fear of doing something wrong, like creating bugs on production or even in a development environment.

At this point, deadlines were other terrifying stuff. Will I be able to deliver everything until the end of the sprint? Will I be able to solve this issue? Am I being a bad developer by asking help for other developers? It is normal to ask yourself this type of question, and answering them now: No, it is normal and part of the process.

Another thing that I remember of that time was that I looked for the tools that I used, and as I did not really understand how that worked, they looked like magic things.

At that time, I used React and Redux. Creating a reducer looked like rocket science for me. I did not understand how that was created, how that worked in reality, why I had to create a pure function and what the hell is a pure function? React looked like alien technology and so on.

This causes fear too, because we fear the things that we did not understand.

This point connects to the next phase.

Turning point

I was working, having to pay the bills and live, so I had time to study with less rush and stress. I followed the path that goes deeper in the base of frontend development:

  • CSS: I did an advanced course about CSS. That teached me how css works behind the scenes, how the box-model worked, grid, flexbox and Sass. That gives me confidence in styling applications.
  • HTML: I studied about semantic HTML, HTML5 and a little about accessibility.
  • JavaScript: I read the book series “You don’t know JS”. 6 books that explain a lot about the base of the language. That changed my way to code javascript.

The more that I studied, the more I was confident to get harder tasks at work and improve my ability to solve issues and participate in meetings.

But I had a real turning point that changed a lot my behavior and my vision about programming, tools and software development.

It was an in-depth blog’s article that talks about reverse-engineering, the gains of doing that and a guide of how to do that. This blog taught me a lot, they had a lot of advanced and deep articles about React, and other frameworks, like Angular.

Talking more about this article, after reading it, a wall of fear broke in my head.

The article explains how to learn about how a library works by reading its source code and tracking the use of the library, organizing the points of study and creating an environment to use tools like devtools to do this work.

Those tools, like React and Redux, that was magic for me, were shown as just a bunch of code, with great logic, patterns and structures, of course, but in the end, it is just code.

Code that I can read and understand, using data structures and design patterns that I can learn and use. After reading those articles, I started to look at source codes and learned how to build software with it.

I lost that fear.

And the confidence with the knowledge makes me more comfortable to use that and start to help others. At work, this makes me start to take harder tasks and carry projects alone, which, in the end, made me become
a mid-level developer.

I’m not saying that this path is simple or something like ‘read this article and you will become a mid-level developer in a few months’. This is not so simple, and getting a promotion does not even mean that you really achieve a higher level of experience and knowledge.

But the whole point of this post is to recommend the in-depth article, and try to bring this point of view, that it is not something that we saw in other places.

Here in dev.to and other tech publications we saw a lot of the same type of content. A huge number of beginner's guides of technologies, the same discussions and explanations of the same topic. But how many times have you seen an extensive and deep post explaining how a library or framework works behind the scenes?

Look at a big codebase and understand that at the point of being able to write and explain that is not simple. It is hard to do, takes a lot of time, but can be rewarding:

  • Having in-depth knowledge about a library can make you an expert on that and maybe become a specialist.
  • You can contribute with that project and that can bring opportunities to you in the future.
  • You can create advanced content about that, a type of content that we do not have in a good number.

Research source:

Top comments (0)