One dev's "you've just gotta learn how we do things" is another dev's "holy hell why does this codebase have its own mind-bending do-everything hyper-abstractions that don't exist outside this organization". (I'm thinking not of the basic concepts of popular FP languages so much as the powerful abstractions they can be used to create. Though if a company invents its own language, that can very quickly enter the 'overly large gap' range.)
I agree that there's a spectrum here, but IME it's very easy for existing devs familiar with everything to underestimate the gap between newcomers' knowledge and their own, or to overestimate how much it's needed. In the worst case, you end up with brittle spaghetti 'abstractions' where the old-timers swear up and down that everything is perfectly sensible and necessary.
(I've personally seen this kind of overestimated necessity twice, in the context of API design. In both cases, the author of a public library published a new version incompatible with the old version, under the justification that users really ought to learn and pay attention to the fine details of the problem space that the library is solving, and that changing the API is a good way to force their hand. But from an outside perspective, the fine details weren't really important for 99.9% of use cases, and it isn't practical for every dev to be conscious of every tradeoff and design decision in the whole stack.)
> the worst case, you end up with brittle spaghetti 'abstractions' where the old-timers swear up and down that everything is perfectly sensible and necessary.
i had this at last place. all previous members of the original team were gone. it was myself and a part time dev (1/2 days per week).
writing new tests would take longer than writing a change - not because we were writing a significant amount of tests. because the “factory” spaghetti code god class used to create all tests was just a nightmare.
got to the point where i just focussed on manual QA. was faster for each change (small team helped there).
and rewriting from scratch on 20k existing LoC for that repo wasn’t gonna work as we just didn’t have the people or time.
basically — we didn’t have time to deal with the bullshit.
keep it stupid.
for the love of everything good and sacred in the world, please, i beg you, keep it stupid (addressing this generally, not at the parent).
it’s easier to get it right, quickly, when it’s done stupidly.
—
i now want to have a moan into the vast empty space of the interwebs:
the data/mental model for the whole thing was just wrong. split tables for things that had a 1:1 relationship. code scheduling for worker tasks spread across multiple services. multiple race conditions i had to redesign to fix.
oh and no correct documentation. what was there was either wrong or so high level that it was essentially useless.
and roll-your-own-auth.
apparently thus was all done under the clean code cargo cult. which tracks cos there were so many 10 line methods everywhere which meant jumping around constantly.
I agree that there's a spectrum here, but IME it's very easy for existing devs familiar with everything to underestimate the gap between newcomers' knowledge and their own, or to overestimate how much it's needed. In the worst case, you end up with brittle spaghetti 'abstractions' where the old-timers swear up and down that everything is perfectly sensible and necessary.
(I've personally seen this kind of overestimated necessity twice, in the context of API design. In both cases, the author of a public library published a new version incompatible with the old version, under the justification that users really ought to learn and pay attention to the fine details of the problem space that the library is solving, and that changing the API is a good way to force their hand. But from an outside perspective, the fine details weren't really important for 99.9% of use cases, and it isn't practical for every dev to be conscious of every tradeoff and design decision in the whole stack.)