I was not expecting a rabbit hole that deep. Who underwrite that api for shipping?
The Worst API Ever Made
Submitted 1 year ago by sizeoftheuniverse@programming.dev to programming@programming.dev
Comments
fsniper@kbin.social 1 year ago
FourPacketsOfPeanuts@lemmy.world 1 year ago
I’ve been pulling my hair out with the totally unrelated but also awful Marketing Cloud (owned by Salesforce). This article made me feel better.
DriftingDeep@lemmy.world 1 year ago
Have read this yet, but I’ll absolutely give a +1 for the “fuck marketing cloud” sentiment. It’s like Salesforce bought it, then gave up on it.
Sibbo@sopuli.xyz 1 year ago
Beautiful.
Pyro@programming.dev 1 year ago
The API is bad, I get it. But the author also seems a little too aggressive with the “my way is the best way” attitude.
Deely@programming.dev 1 year ago
Im not even 100% sure that API is really bad? Some hairness could be easily explained by performance reasons. You don’t want logging to take a massive amount of system resources.
SmoothC@lemmy.world 1 year ago
Yeah, it is really bad. And lazy. The kind of bad that people who don’t take pride in their work do. The kind of bad that makes great programmers quit
mycoffeeisready@exploding-heads.com 1 year ago
You’re right, I’ve seen some of hisbyt videos, he is not opened minded. This API does look shit.
Aceticon@lemmy.world 1 year ago
Curiously “my way is the best way” is (IMHO) the greatest cause of problems at the design and architecture level in the Programming World.
I’ve worked for almost 2 decades as a freelance designer-developer (aka contractor) across various industries and even languages and frameworks (all the way from server-side Java to web interfaces and iOS applications) and one quite common scenario was me being hired because some piece of software was pretty much unmaintainable, and that was almost invariably either a single designer-developer that did the whole thing during their oh-so-special learning stage were they’ve just learned software design and overengineer everything (in OO that usually means totally unecessary use of design patterns and inheritance for stuff were there is always and only 1 implementer) or 3+ people over the year who each got responsability for that software and decided “I know best” and proceeded to add a whole new layer with a different software design strategy, coding standard and sometimes even a different language, the result after a few of those being pretty much spaghetti code AND design.
By the way, you do notice exactly that kind of crap coming out as APIs and Frameworks from the kind of companies (*cough* Google *cough*) whose idea of Technical Architect is somebody with 8+ years experience and who never worked elsewhere: notice how the Android stuff has had various strategies for doing the same thing over the years, the API has grown over time massivelly (it was already too big and messy to begin with), there’s code-generators in the IDE to try and cover the gaps between newer techniques and older ones and they’ve even introduced a new language half-way for no actual architectural advantage (the pinacle of “I know best” genious is making your own language).
Personally during my time as Technical Lead I used to hire people very much based on “have you ever worked on a project over its entire life-cycle?!” because those burned by their own ignorant-yet-pretentious stage are the ones who get it that Ego is less important that pretty much everything else in making software and I firmly believe that “having seen and having had to maintain the results of your own fuckups” should be a requirement for anybody designing an API or Framework.
PoisonedPrisonPanda@discuss.tchncs.de 1 year ago
well summarized write up.
I am working on a 50 year old codebase which little documentation since “tHe COdE iS tHe ManUaL”…
its in the academic field although this does not mean that people took care about it.
and due to porting to newer language styles this thing is near impossible to get into.
I understand that times have changed much.
however to maintain this stuff progress has to be put on halt until a system is established to clean up this mess of 30 years of spaghetti code (assuming for 20 years it was alright)