17
Avyiel
6y

Spent 6 hours implementing a feature because my senior didn't want to use a 3rd party plug-in.

After said 6 hours, went to look at the plugin's source code to get some inspiration with a problem I was having.

Guess fucking what? Plug-in was implemented exactly as I had done it to start with. Even better, actually, since it fixed some native bugs I couldn't find a way around.

Went back to my senior, showed him both sources and argued again in favour of the plug-in.

Senior: "Meh, I'm not sure. Don't really like to keep adding plugins"
Me: "Why? Do they cause performance hits? Increase memory usage?"
S: "No, not all. But I don't like plugins"

/flip

We ended up using the plug-in, but I "wasted" a whole day doing something we scrapped. Guess I learned some interesting things about encryption on Android, at least...

Comments
  • 6
    and then there's the npm modules that literally consist of five lines of code...
  • 3
    Third party dependencies tend to pile up liability in the long term, that's why your senior doesn't like it.

    Worst case is ending up in a dependency hell where shit breaks if you update, and other shit breaks if you don't.
  • 2
    @fast-nop Schrödinger's code :D
  • 0
    @Fast-Nop yeah, he did tell me to hard code the module version on our packages.json when I finished implement this feature.
    Hopefully nothing will break down lime though BlessRNG
  • 1
    @balte I love elegant and concise solutions, but packaging 5 lines of code... 😅
  • 1
    @Fast-Nop This is where every legacy application I've worked on in the past three years is at, and not one of them has a functioning test suite.
Add Comment