What I learnt in my first six months as a working (self-taught) developer

I'm over a year working professionally as a developer.

I was supposed to write the first lessons learnt after three months into my work. But time passed, and so here it is with the experience of a couple (10) more months. However, I think that what I learnt can be divided in two: my first six months, and after six months.

In my first half year, not only I was a newbie in coding, but I had to get used to tons of stuff that I never used: git flow in teams and docker to begin with.

After that, I got somewhat more familiar with all the technologies, so it was easier to concentrate on coding.

Before I got hired

My story about getting a developer job is coming from a long way in the past. I wrote about it here.

What I learnt in the one or two years of self teaching development were the basics: how to create something simple in a linear order, and some styling.

I also learnt through examples and a lot of Stack overflow 'investigation' how to put things somehow together and make it work.

A lot of copy paste not working and lots of sweat to make it work. Eventually, a big satisfaction of giving birth to something useful. I also learnt how to use databases and connect a backend to them and then to a frontend. Enough to try take-home projects for the interviews and fail almost all of them. But as they say, it takes one to make it worth it.

One month before the job starts

Once I got hired, I did what was not 'explicitly' requested, but I think is a good approach (especially for your future self).

I got in touch with my future colleagues so they could tell me what I should improve, or what tech stack should I add to my knowledge before the first day of work.

Of course it's all theoretical because you don't really know anything about the project you'll work on. But having a good starting point saves you a lot of time in the first month.

In my case was especially Typescript. I never used it before, so I took the opportunity. I had the documentation always opened and I took a brief Udemy course. I transformed everything to Typescript in my take-home assignment that I made for my initial interview. I had a list of technologies used by the team to check upon; I had maybe knowledge of two thirds of them but good enough skills on one third. The rest I just remotely heard they were existing.

The first six months

How would I describe it? At least overwhelming. Where I live, since you start a new position, you usually enter a three months period called trial or probation period. In that, you and the company have to decide whether you're a good fit to each other.

And each other have the right to leave with a 2 weeks notice. I know that's a lot less stressful than other countries, for example, as far as I know, the USA, where the 2 weeks are a permanent notice time. But still, that makes this time particularly sensitive. Especially passing from a senior position (my previous job as application support engineer) to a junior one where I had to prove myself.

It came to the first days where, apart from the initial setup, I had to get familiar with the codebase I had to work on. And then... apart from one small ticket for a small change, I was given the assignment to r-e-f-a-c-t-o-r the whole codebase. 🤯

That one came from some older vendor and my company took it, improved it a little and added the requested features. But it was over complicated, with lots of useless code. So yeah, they told me, just rewrite it from scratch using Typescript.

I confess I had my moments of panic. Frustration, impatience, other negative feelings here and there. Especially with the first PRs (pull requests in Github) which were reviewed with tons of comments on how to do things differently, or change code, or delete parts and remake others.

Well guess what? It was the best exercise ever. It allowed me to know from top to bottom the code, and slowly improving the quality of my programming, applying DRY and SOLID principles, algorithms, and so on.

Sometimes I had to remake things 3 or 4 times before having a good version. Eventually, for that particular project, I had only few, more 'coding style' corrections.

That doesn't mean I was writing code as good as my colleagues but it was an amazing progress for me. Of course, this wouldn't have been possible if I wouldn't have the most understanding colleagues, experienced and patient with all my questions and misunderstandings.

Some of the lessons learnt

Have patience with yourself. If they hire you as a junior nobody is expecting miracles. Take it one day at the time.
You can make some specific skills-targets. For example, this week I'll focus on Webpack, so at the end I'll know how to set it up. Or, as another example, today I'll take my time to figure out how to rebase the dev branch with my branch correctly, resolving all merge conflicts. When you are a junior, you can tell your colleagues that you'll take some time to understand how to do a thing. They'll be happy once you'll manage, because it'll save them more time, trouble and explanations in the future!
Don't lose temper with your colleagues even if they seem impatient with you. Sometime they're under pressure from the customer or the managers and they're just shielding you from some storm.
Related but as important: your colleagues are your best allies
Don't suppose that your code is perfect because it's working. First, a second pair of eyes will find bugs here and there. Second, there's always some ways to make the code cleaner and more readable. What you don't know, you don't know and can't see. So always suppose that the code will be corrected.
I am the type that passes hours trying to solve a bug because it's a question of self pride. If you don't have this, ask if you're stuck (but anyway try as much as possible by yourself, your colleagues are busy)
As mentioned, there is a ton of tools and tech that you don't use when you learn to code. For example, the whole git flow with a team (with PRs, merge, rebase, cherry-pick, all with conflicts resolutions because other people are merging their PRs); then setting up DBs(preview, modify, type them; containerization; webpack/gulp and so on for bundling and minifying; sprint planning and estimations; and the list goes on. But, all these are not expected to be known in the beginning. It takes a little time, and patience from all colleagues, and they'll click together.
No developer knows everything, everybody googles and do research. New technologies are coming out continuously, or they have to implement a tech stack they don't know. So everybody do tests and mistakes. But, what is different with a senior dev, is how they are quicker because they know what to look for. And then, they understand how to implement it. A junior developer does it by trial and mistake, but by doing so, they gain every time a little more experience on how things are working. That's how a dev slowly transition from junior to senior.

Thank you for reading and let's connect on Twitter!