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.

  • Ephera@lemmy.mlEnglish
    16·
    23 hours ago

    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.

  • jjjalljs@ttrpg.network
    4·
    20 hours ago

    Good version control hygiene is important. My most recent job we were pretty good about commit messages for the PR, and then squashing that into a single commit when putting it on main. As you say, avoid unrelated things going together. You don’t want to have to revert a whole major feature because your “I’ll just fix it here” broke something.

    There’s a guy one of my old coworkers has been complaining about who never writes anything useful in his commit messages. It makes the git log useless and the code reviews harder.

    As for abstraction and such, sometimes it feels like it’s just coupling unrelated things together. It can be annoying when it’s like “I want to change this…and it’s used in 17 places for some reason. Guess I’ll check if all of those can handle this change, or this will be the one weird place that’s different…”

    I also worked with a guy that was a big fan of having two dozen one line functions. Monster functions are often bad, but a whole separate function like get_last_item(stuff): return stuff[-1] can be excessive.