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.
As for When to abstract, you particularly want to deduplicate code that implements logic (as opposed to boilerplate code).
It’s much more likely for this kind of code to require changes or bug fixes over time and therefore for the separate versions to drift apart.
I’ve also found that you should still lean strongly towards deduplicating code, because it isn’t just you who needs to know to change both versions of a code snippet. Your colleagues need to know, too, including those who join the project later. And the chance of this working out as intended, is practically zero. If you have duplicated code, you need to assume that multiple versions of it will exist.