Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Your rant reminds me of this: https://devrant.com/rants/5107044/
-
@gintko i hope that's a joke making a jab at SO, and not an actual, real, screenshot
-
@Midnight-shcode this one is not real, but I think it’s based on a real post that was deleted long ago, though could not find anything with wayback machine. Either way, it doesn’t change the fact, that some answers on SO indeed suggest to use jquery (or other libraries) for simple stupid things
-
Many devs still havn't grasped that dependencies are both an asset and a liability as well. That's why they fail to properly weigh both aspects against each other.
Package managers have exacerbated the problem because they made recursive dependencies "easy". That let devs fall into the "kid in candy store" mode so that they download code from all over the internet with no idea whose code they're even running. -
@Fast-Nop This is so accurate!
-
This is what happens when people hear some principle or guideline, think it sounds good, and blindly use it going forward but without actually thinking deeper about it and definitely without being critical in each individual situation to see if it REALLY applies and makes sense.
DRY is a good general principle. KISS is a GREAT guiding light. YAGNI is GENERALLY correct. Curly's Law should USUALLY be followed. Not re-inventing the wheel is typically good advice.
But none of those are absolutes, and if you just stick to them every single time without any thought then you wind up doing stupid things like bringing in a library to left-pad a string, and then disaster strikes.
You have to understand the principles enough to know when coloring OUTSIDE the line is actually the right choice, because sometimes it absolutely, positively is. -
@IntrusionCM my approach is just to not approve PRs, unless logical reasoning is given. Of course, it’s not perfect and doesn’t work for larger teams, thus streamlined process would work the best (even though introduces some friction).
-
@gintko yeah...
In my case we had frontend devs who wanted e.g. hardware upgrades as their clusterfuck of e.g. middleware bukkake with 7 plus middlewares just didn't work out so great...
Could name a few other examples (mixing several frameworks, creating incompatible dependency chains, incompatible node versions in same project, etc.) but in my opinion devs should be stopped from adding dependencies unless they are able to handle the responsibility. -
For my current project, I somehow approved PR of my colleague to import some fishy validation library. And it was obvious it was fishy, as he had to rely on reflection, to make it worse he had to do some custom field mapping (because library didn’t support custom field names). Yet I approved it, perhaps was lazy, or just felt bad for my coleague to basically refactor everything (in case I rejected it) - kind of proves there’s no place for emotions when reviewing.
Anyway, now everytime I have to work with that validation library it makes my blood boil. Something, that’s supposed to be single if, now requires bunch of boilerplate code all over the project…
Related Rants
Underlying pure C library and NodeJS wrapper
Truth..
May be just me, but I am quite frustrated with complexity of systems nowadays, even more how it’s became a norm for developers to import a library for every little sh*t…
Like, do you even need to import that OSS library, can’t you make it without it? Is it really worth it to import that monstrous library of 10k loc, just so you can save writing those 50loc for just once?
It almost feels like it’s driven by logic “if you don’t own the code, then you don’t need to maintain it”. But ironically you still need to mantain it, only now not the code (best case), but the library itself. You have to upgrade it (for security, bug fixes) and you better pray there’re no breaking changes. And if you encounter an edge case/bug that no one addressed yet, then well, I bet you wished you didn’t use that library in the first place.
It’s so much easier to support small piece of code within your codebase, than fix a bug in a library, that possibly has thousands of unnecessary dependencies, enormous abstraction trees, and infinity loc to support all possible use cases, which your project doesn’t even care about.
Just to make it clear, I am not talking, about cases where some library would really do some heavy lifting for you, it would be non-sensical not to use it in that case.
And talking about complexity, let’s not even mention microservices, kubernetes, and other hyped stuff…
Does anyone else shares the sentiment?
rant
complexity
dependencies
overengineering