I’ve been working full time as a frontend developer for about 3 years now. I also have a bachelors degree in computer science.

I really feel like I leveled up this past year, and I wanted to share two things that stand out to me that I learned.

Keeping git work organized

It doesn’t really matter how small/large your commits are, but what matters is keeping it focused. Write a good description for your commit and don’t make unnecessary changes that aren’t related to the commit message. If you see something unrelated that needs fixing, don’t mix it in with your current work. Same goes for pull requests, which I always squash commit.

The goal is if you want to revert your commit/squashed pr later, it should only revert what’s described in the commit message. It will cause problems if the revert also brings a bunch of unrelated changes.

When to abstract

There’s a lot of opinions about DRY or WET code bases, but I think that’s confusing. When you have A and B, and you’re wondering if you should bract the shared code (let’s call this shared abstraction C), ask yourself this. Do I want it so a change to C affects A and B, or do I want changes to A to not affect B and B not to affect A?

It’s like your building knobs/dials into your codebase, and it’s up to you if you want a single dial to affect one thing or multiple things. You know you built the right dials when product asks for something later, and it’s as simple as turning the dial you created.

On the other hand, if you build something as two dials that should have been one, you may find you turn dial A and forget to turn dial B. This sounds simple, but your codebase may have thousands and thousands of dials, so the right consolidation can help with managing large projects.

In summary

Idk if that made any sense, but as I progress in my career, I’m finding I’m able to manage larger projects with less overwhelm.