Are you me? Our services with all the best practices are also the worst to work on because the business value is hidden in layers and layers of indirection, abstraction and nested packages. It’s like someone took a recipe card to bake a cake and wrote each word on a single page (because god forbid we ever repeat ourselves) and then abstracted away a function behind a series of factories and interfaces that will join those pages with string, and now each word has a single context-less definition so we can tick the “S” box in SOLID.
I think two things play into this: Layers.. it is just easier for people to add layers around something, not touching and understanding the original code and doing it right there. And then profs or someone else always says layering is good!
(It may sure be, or also sometimes such "hacks" are the right thing to do, but if that is always the default mode... uhh oh).
And second, university training: OOP, design patterns, software layers, all claimed to lead to structured good programming automatically still taught in 2023, which is just not true. By untrained or unexperienced personnel leads to worse than 80s spaghetti code..
Just yesterday I exercised with relative who is in university for exam.. Java, design patterns, arggh. Imo it just makes no sense at all to try to teach students inheritance and design patterns with Cat/Dog/Animal et al, it is so backwards. You need to program for a while bigger real systems to see some patterns emerge and their usefulness, and then can relate to the formal way and maybr use some patterns reasonably. But starting with those on toy examples just leads to what you describe:
People going in with their trained knowledge and applying that to everything without rhyme or reason. What could be a simple five liner function already becomes a convoluted abomination. Just one concrete example, but this then on many levels of software engineering.
Who or what will save our future? :D No, it won't be ChatGPT.
(Second lol btw, relative really showed me how likely all of then may use ChatGPT i. their online exams...)
I'm not too hopeful. In my experience, functional programming adoption is divided into two categories:
1) Proper FP languages with good enough semantics and necessary features to write functional code effectively. Those languages all fall into category of "too difficult" for the majority of industry, which seems to suffer from severe allergy to learning anything beyond "Intro to programming in Java 6" freshman class.
Even things like lambdas only recently stopped being too complicated for a typical programming shop that follows well-known best practices, such as "Programs must be written for inexperienced non-programmers with no prior exposure to the problem space to read, and only incidentally for machines to execute.", and "Would somebody think of the juniors?". Closures? Nah, the zeitgeist is still on the fence with this.
Yes, I have a sore spot for this. I've heard this reasoning many times in real life, and once was even target of it - an otherwise competent programmer and a good manager once asked me to stop using lambdas for event handlers in Java 8 (which the company had only recently adopted), for the sake of the juniors who won't understand. In fact, he meant specifically his favorite evergreen junior (who's been in that company a couple years longer than I was then). But guess what, couple juniors actually asked me to explain the how-and-why of lambdas to them and got it near-instantly. Said evergreen junior probably spotted the lambdas in the codebase too, or otherwise got interested in this, read up on the topic independently, and three months later was evangelizing basic functional programming in Java and otherwise upskilling his fellow coworkers.
But yeah, it's too difficult, your co-workers won't understand. Anyway, where was I? Oh right:
2) The other, arguably larger, kind of FP adoption: library-level and code style level implementation of FP features in languages with little or no natural support for them. This doesn't mean people understand FP extra well - they're barely aware of it at all. But every now and then some library gets popular - say, a sum type for error handling (typically known as Result, Either, Expected, or something similar) that's "obviously" "better" than exceptions. Except, that library is doing a half-baked implementation of a concept (e.g. monads) that doesn't fit the language, and the users don't understand what the approximated concept is, nor are they supposed to try (remember, FP is too abstract for a freshman after "Java 6 101" class).
The result is, as expected, an ugly mess in the codebase, displaying all the bad sides of imperative and functional styles, and leveraging none of the good sides.
Anyway, what is my proposed solution to this? For the industry to stop hating education and professionalism. To embrace the idea that the job of a junior is to learn, not to be the yardstick for complexity of the codebase. To encourage a culture of learning, of professionalism, at every level. To stop dismissing or banning techniques that reduce size and complexity of the codebase by large factors, just because one has to invest a couple hours of learning up-front to be able to use them. Etc.
