My 1 Year Reflection on Working as a Frontend Developer

Looking back… it’s crazy to believe that I accomplished my programming related goal and just how quickly the time has gone by!

It doesn’t feel like it was that long ago where I was still struggling, while trying to get my first developer job. Then I finally did it, moved to Europe and started working as a professional developer.

Wow!

Fast forward to today, and it’s already at the 1.5 year mark!

I’ve just been soooo slow in writing this post and getting it out.

However, I’ll just reflect upon my first year working as a professional frontend developer on a large e-commerce store project.

If you are curious to know what my typical day-to-day programming life is like, then you can have a read of my typical frontend developer workday article.

The start

I still remember taking the train to get to my company’s headquarters (HQ), so I could get proper onboarding for my first day at work. I was happy, ecstatic and excited to be starting a new career as a frontend developer and also a new life in Europe.

When I arrived at the office, I was greeted with a welcome card and a goodie bag. We got to also listen to a bunch of presentations and introductions from the HR department.

It all became real to me when I again had to sign my work contract, but this time in person, and then I got my very own, brand spanking new laptop.

It was awesome!

I spent almost 2 weeks going through onboarding and training, while staying in a hotel with buffet-style breakfast the whole time.

Overall it was a very pleasant experience and I slowly began to see the perks of working in tech.

I was also loving it! Plus the environment was relaxed, everyone was really nice and things were great.

Overwhelmed and humbled

When I got back to my apartment and went to the branch office in my city for my first real working day… I was impressed!

It was a nice office in the center of the city and near a university. Everything looked pretty much new and was very spacious.

There was a game area and a pool table! Breakfast was provided once a week. Fresh fruit was also there on some other days of the week. And all sorts of free drinks were available to you at any time.

This was a stark difference to the rundown, cramped, inside of an old house, and on the outskirts of a large city office that I worked at in my previous career.

Let’s just say that it was quite the upgrade!

Anyways, in the office that I was going to be working in from now on, I had met part of my team. Got set up at my desk and was introduced to the project that I was going to be working on. Which was a large e-commerce shop.

I got more project related training here and was just trying to absorb all the new things that I had to know.

Finally I met my subteam and was trying to get used to all these strange meetings that we had to do. These were meetings like…

• Dailies
• Sprint planning 1 & 2
• Refinement
• Coffee dailies
• Sprint review
• Subteam retrospective
• Overall team retrospective

And there were even a couple more meetings. It probably took me almost a month before I learned about all the meetings, and the times that they occurred at.

This was partly because I never got any calendar invites, nobody showed me the meeting schedule, and I only found out about meetings when people told me that I was supposed to be at one.

It was a bit of a disaster at the beginning! Haha

My first tasks

I remember my first couple of tasks were all very small CSS bug fixes.

One of them was this one-liner CSS change, but it was pretty confusing.

I wasn’t sure if I was supposed to be making the changes in the frontend repository or the general styling one.

The entire project codebase was enormous. It was hard to grasp what was going on.

I was unfamiliar with all the components and the structure of things. Plus to complicate matters even more, there were a whole bunch of style overwrites for different online shop variants. And (at the time), I didn’t know how to quickly find the correct CSS style within the code base either.

Things were just much more complicated and larger than any of my personal projects that I had built.

I still hadn’t learned about all the little tips, tricks, and shortcuts yet.

Getting Corona’d

So after about 1.5 months since I started working, coronavirus (COVID-19) had already started to inflict its damage in Europe.

Everyone in my company got an email from management that we were required to work from home from now on. I imagine that a lot of other people probably had similar experiences.

On a side note - this ended up being pretty much the last time that I worked from the office (minus a few sporadic visits over the rest of the year).

So I started working from home and really liked it. My office was just a few steps away inside my apartment and I had almost an extra hour each day since I didn’t have to commute anymore.

Life was getting better, and my goal of working from home was achieved… all thanks to the coronavirus!

However, a couple of weeks later I felt the power of the virus in another way.

Our client, and the project that I was working on, was forced to close all of their physical stores due to government regulations. Then to make matters worse, they also decided to temporarily shut down the entire company, including the IT department.

Everyone on the project was sent home (well… we were already at home) and forced to take their vacation days. It basically felt like we were about to get “laid” off.

Nobody knew when they would re-open, when we would come back or what was going on. It was dark and a complete flip from just a couple of months ago when I was riding a big high.

I was sure that I was going to get my walking papers from my company any day, since I hadn’t even worked there for 90 days. I couldn’t even imagine that they would keep me on standby, especially as a junior.

Several days had gone by where I was in a limbo state and I still wasn’t sure what was going to happen to me.

Finally, I found out what a really good company is like. One where they take care of their employees. So instead of laying me off, they kept me on hold.

WHAAAAT?!?!?

I was very shocked and grateful!

Then a week goes by after our client had made that decision, and they decided to reverse it. My guess is that they probably realized how important IT is to the online shop, which was also their only source of income coming in.

However, they didn’t bring everyone back… maybe only half of the people.

Unfortunately, I was one of the last ones to return back to the project. I ended up being on the sidelines for around a month or so, and just worked on some internal projects for my company.

Development is slow

When I finally got back onto the project, I felt a bit rusty with my programming. Mostly because I was working on something pretty different with the internal project that I was put on.

So it took me a sprint or so to get back into the groove of things. As when you don’t practice daily, especially as a beginner, you lose your abilities pretty quickly.

By this time in the project I had completed several tasks and was slowly starting to get a hang of the whole project and the codebase.

I was more comfortable working my way through the code for simple/easy tasks. However, anything a bit more complicated, and I was lost again.

And one of the things that I realized was professional development was reeeeeeally slow.

Unbelievably slow!

For example… when you are working on your own project you can push right to the master branch and a small change takes a matter of minutes.

Not on a large project and in a professional setting!

First the task, or bug, ticket needs to be created. If it is a bug, it needs to be verified by the QA department. Then the task will need to be refined and estimated. The Project Owner (PO) will eventually bring it into sprint planning and if a developer picks that task, it will only then be taken into a sprint.

Finally a developer will start coding up the solution or fix. Once they finish, they will also need to manually test and check that everything is okay. Sometimes this can be very annoying if you need to check many different site variations and also edge cases. If possible, they also need to write unit or integration tests.

After that you open up a pull request (PR) against the master branch, and you need to get a certain amount of approvals from other developers. Sometimes they get you to make changes and this can go on for days. Once you get your approvals, you have to get QA to check and verify that you did your work properly.

Then and only then, are you allowed to merge your task. That is assuming it passes all the pipeline checks prior to merging. Otherwise you will be blocked/delayed.

Next you will be trying to merge your task, but many other developers will also be trying to merge their tasks at the same time. If you don’t “beat” them… the whole pipeline checking process has to start from the beginning again.

Why?

Because you can only merge a task when it has the latest master version.

When you finally manage to merge the task, you also have to get PO approval. Only then is the task fully finished!

So a simple and quick fix on a personal project turns into a very long one when working in a professional setting on a large team.

Halfway point

Around the halfway point is when I really started seeing some good growth in my progress and capabilities.

I was comfortable finding bugs and better knew where I needed to go in the codebase to fix them. I became very good with CSS issues and minor JavaScript fixes.

I also didn’t feel “useless” anymore, like when I first started working. I was able to spend a decent portion of my time without needing help from more senior developers. If a task was simple, I wouldn’t need any help at all.

I also slowly started taking more challenging tasks that required me having a deeper understanding of the JavaScript and React code, and also having to change code in multiple files or repositories.

This was both challenging and frustrating for me, but when I was stuck I was able to ask some senior developers for help.

I’m really glad that I started working at a large company that has a lot of senior developers. It is super important to your career to have that option of having someone more experienced to ask for help.

Having that support, I ended up learning things so much quicker from my more experienced colleagues and saved myself a lot of stress. I still had a fair bit of stress anyways, but it was much less. So having such colleagues on your team is very invaluable and it has helped both my growth and skills as a programmer. Especially in JavaScript and React.

Around this time I also started learning more and more about GraphQL, since we use it in our project. I wanted to better understand how it all worked on the frontend and also a bit on the backend/server side. To further solidify my GraphQL learnings, I wrote this Gentle Introduction Into GraphQL article.

First major task

After the halfway mark and when I felt even more comfortable at work, I had wanted to challenge myself.

I was mostly fixing bugs at work, got quite good at this and in the future wrote a how to become better at solving programming bugs post. I was also great at doing easier tasks that had to do with styling, or JavaScript. Unfortunately, I wasn’t spending very much time applying my React skills and I began to notice that I was forgetting some key React concepts. I really didn’t want my skills to regress any further.

So I took on a major task that involved building a new feature, which would also require me having to write a whole bunch of React code.

The task itself was having to hardcode a fake feature on the shop, which would get A/B tested. I had implemented the majority of the user story myself, but I was struggling to get one part working. Again, my senior colleagues saved me and showed me a cool way to get it to work properly using refs.

Around this point, I also realized that I had some React knowledge gaps and needed to work on them. So I began to study, learn and later on wrote this article about How to use React Refs and React Forward Refs.

I also wrote another post where I gave an Introduction to React useCallback.

Taking more challenging tasks

The last couple of months before my 1 year mark, I decided to work on a really big feature and task (that was also quite complicated) with a senior developer.

It involved a lot of discussions with the senior developer, our PO and the design department.

We split the user story into numerous smaller tasks and during implementation there was a lot of checking/testing to do. We had many problems implementing it and there were all kinds of bugs/issues occurring.

It was a bit of a nightmare of a task to complete, but after spending a couple of months on it, we finally managed to push it into production. It was an awesome new feature and apart from a few minor changes to the design, everything was implemented as per the original concept.

By the end of this task, my confidence level and belief in my abilities had greatly risen. I pretty much felt comfortable tackling any task, except for the most challenging and complicated ones.

Looking back, I was happy that after the halfway mark I had started taking on tasks with higher difficulty and complexity. If I didn’t do that, I would not have grown as much.

The 1 year mark

When I compare myself from no working experience to 1 year of experience, it is really a massive difference!

Over the course of the year, I solidified my CSS skills and could even be considered as an expert here.

I increased my JavaScript knowledge through having my work peer reviewed, and being shown all kinds of neat JavaScript tricks or ways to refactor my code. I also learned about and started using some of the newest JavaScript features.

After I made an adjustment in the type of tasks that I worked on, my React skills quickly improved and developed much further. I was able to pick up more coding things from senior developers and understand advanced topics better. Learning and writing a couple articles about React topics also helped me here.

Then there is the topic of testing!

At the beginning, I had very minimal experience with testing code and basically didn’t know how to do it at all. This was a MAJOR pain point for me and I had a lot of stressful times trying to write tests. Thankfully my senior colleagues had taught me a lot of things about how to use Jest and React Testing Library. I also got a little bit into Cypress. While testing is still an area of weakness for me, I’ve gotten much better at it.

Finally, I also learned a completely new language with GraphQL. I had no knowledge whatsoever about it when I first started working and now I would say that I’m fairly comfortable with it on the Frontend and okay with it on the backend.

I’ve learned a lot of things in my first year, and I can’t wait to see where I’ll be when I reach the 2 year mark!

Final thoughts

What would I have done differently when I was still learning programming?

I should have bought/paid for more courses earlier on in my studies. It would have helped speed things up for me. Plus learning from a senior developer, and through guided project examples, happens to be the perfect learning method for me.

I think if I had also paid a developer to review, give me some feedback and comment on how I could improve my code in some of my portfolio projects, I believe this would have been invaluable. It would have let me see my weaknesses, improved my code/projects and helped me to code more like a professional developer.

Lastly, I should have spent more time learning how to write unit tests. If I had taken both Jest and React Testing Library courses, it would have saved me soooo much stress and pain of writing tests at work.

Were all the struggles and pain of switching careers worth it?

Yes!

Looking back, I would say yes.

Though in some aspects it wasn’t, like in terms of loss of earning potential and salary. But I did gain a lot of perks and benefits, so I can’t dwell on that.

A good way to summarize it is like this.

Those hard, struggling times made the whole journey all the more special and when you finally accomplish it, it is something that you can always be proud of.

Because let’s be honest, it is no easy feat to do! You need to put in a lot of hours, time, dedication and sacrifices to achieve this.

What advice would I pass to others along this path?

Don’t give up!

Keep following a process! Keep improving and building your programming skills, CV, interviewing skills and project portfolio.

Learn, iterate and keep going.

Because eventually you will become good enough that companies stop ignoring you and one of them will end up giving you a chance.

If you still can’t figure it out on your own, consider hiring a coach or paying someone who has already made it for help.

And if you do end up paying someone for help, make sure you listen to and follow their advice.

Ohh and also try not to complain (too much)!

Positive thoughts… positive energy… positive outcome!