Surviving Your First Month as a Front-End Developer

As I've just finished my two first months in my first-ever programming job as a front-end developer for HoneyBook, I thought to capture some basic tools that I learned and helped me tremendously.
(For a version with a plot-line see this post)

Devtools is a Front-End Developer's Best Friend

Devtools in chrome is amazing. As someone who played around with html 10 years ago, I couldn't dream of most of what you can do today.

Cmd+Shift+C to inspect elements, then understand where they are in the components tree, reading all the Styles applied to them, can be 90% of understanding a front-end issue.
Writing new style rules directly in the devtools styles tab, or toggling off existing rules bring me closer to understanding the source of my troubles.
Also, if you see styling rules that have a strike-through that means they are overridden by another rule. Easy!

Into The Repo

Now - time to understand why things are as they are- which brings me to one of the skills that are paramount to this profession: reading other people's code.

What helped me the most is seeing how other people do it.
The one thing they all did was clicking on functions or variables names and going to see their origin, in a sort of drill-down. This takes time to master, but it's a basic, yet must-have skill.
The second thing, was to search cleverly.

Different Types of Searching

I learned you can search in specific ways, depending on what you need. I never needed this for my personal projects, but it's really useful when working on a large project or one that you don't know.

For a certain file you can search using Cmd+P in VScode.
For getting to a certain symbol (which can be a var or a function) you can use Cmd+T.
And if you want to see all places where a certain component is being rendered, you can use the general search (Cmd+Shift+F) and type <ComponentName - simple!

VScode has a lot more search options but those are most useful to me.

Gitlens Is the Bestttt 🔍

GitLens helps me see who lastly worked on some area of the code. I recently started using it to go specifically to the github commit from there, to see what that change was, and maybe there was an interesting comment during code review.

If the latest committer really did write something that can help me understand if my solution is a good idea, I consult them. Or the person that gave them a relevant comment.

Stress-Testing Your Solution

Now is the time to stress-test it. I see if the solution holds even when the div is bigger or smaller. I think of different scenarios like screen sizes, user states, different ways to get to this screen.
I search for all the places this div can appear (you know how to do that by now, right??).
I consult with QA sometimes about more conditions to check.

Even if you work at a place that has QA - do not skip this step! This is part of being an accountable owner of your code- which is what you should be.
Plus, as you are just beginning, most chances you WILL find things that you missed. Which is great because that's how you learn.

Check Yourself Again and Refactor

Just before I create the PR and ask for a code review, I check again in the diff between my file and the original one. Have I left any comments?
Can I use better names for my variables? Does the code make sense to me, or does it look complex and should be simplified?
For this stage I created a checklist of things that I know I should check + Add some if I got general comments in previous code reviews.
Take the time to present your best work and this will pay off!
Also, this will make your reviewer focused on improving or cleaning your code even more, instead of just finding obvious things you could have caught yourself.

Let me know if you have more tools that help you make those first months as a developer the best!! :)