This One Line of Code I Wrote Is Awesome

Sometimes I feel like my journey to becoming a software developer is a story about how my ability to write code is shrinking in scope.
Why?

Well, when I first learned the fundamentals of computer science and some elegant algorithms I thought- this is great, one day maybe I can invent new algorithms! Those can change how whole systems work!

Later, in bootcamp, when I realized algorithms were not for me (right now anyways) I was amazed that I can create a whole app in one week - I can do anything with the tools I just learned!

Two months ago I was humbled to start my web development career in an amazing startup called Honeybook as a frontend engineer.
And in this post I'll tell you how I spent the better half of a day writing one line of code.
And how I'm actually proud of myself for that.

Most Code You Write as a Junior Is Incremental

The reality is, in 2022, so much code has already been written. Whether it is whole frameworks and libraries, open source projects, scripts and tools.
Even senior developers work most of the time on improving, fixing, refactoring, expanding existing code.

Even if you do start a project from scratch- as a junior, you will probably find a good example to start from (one you found or even wrote yourself in the past).

So, writing just a few lines of code will, and should happen to you. Especially when real people are using the product - which makes this a lot more scary/exciting!

So now I'll tell you about why I'm proud of that line.

The Div That Went Looking For Trouble

So, one day I got a jira ticket assigned to me. There was some div who's name I'll keep confidential as to not shame it, that was displayed when it wasn't supposed to.

Devtools is a Front-End Developer's Best Friend

The first thing I did, was to go see the problem myself.
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 or toggling off existing rules bring me closer to understanding the source of my troubles.

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.

This for me has been a big challenge, I have to admit. And getting to know my way around a codebase was pretty overwhelming at first. (Ok yeah it still is).
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 that was too fast for me, but I did get the general idea.
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.

After all that searching, I understood WHY this div has a z-index issue. What a Zillennial.

Thinking of Solutions

This is the part where I like to think of a possible solution - then, ideally, search the codebase for similar solutions. This can give me ideas about best practices of using specific syntax, or maybe finding out some util function already exists.
At this point, I prefer to stick to the way things are done "conventionally" since I don't feel like I know enough to say why everybody's wrong.. yet.
But really, I learn so much from reading other developer's code!

If I have some sort of solution in mind, especially one that will be longer to write, sometimes I like to consult with someone beforehand.

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. Anyways, GitLens is amazing, srsly.

Now You Draw the Rest of the F**Ing Owl

This is not the place to teach you how to code, so assume I know how to code and fix the thing.

Not Finished!

It worked!
My one line has put that div back to where it belongs HAHAHA!!
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.

Yes, we have QA. No, it doesn't mean we don't check ourselves.

After that, I open the PR. I ask for a code review. I wait. Sometimes I get comments. I fix what's needed. I wait for some more things that need to happen for my code to reach production.
But then.. It finally happens.
My PR gets to production. Billions of users (roughly) are happy and will NOT see the div when they shouldn't.

Maybe it sounds small and insignificant.
For me it's one more win. I made a difference. UI issues are a big part of how users perceive the quality of software.. Ain't this the truth.

And I'm sure next time it won't take 5 hours. Next time it will be like 4.5 max.

Confused? Thankful? Or still have questions? Let me know in the comments! ☺️👇