> > None of it is based on actual collective experience
> I think often best practices are based on experience
But not collective experience. Just some people's experience.
If you survey experienced people in different corners of the industry, you will not find agreement with whatever is currently being floated as a best practice.
Rather amusingly, best practices are often adopted much more strongly by the beginners (and the expert[0] beginners) rather than the experienced. When you reach intermediate level of experience you start questioning many of what you learned from the internet as a best practice and start looking for alternatives or just experimenting yourself with different ways of doing things.
But beginners will always out number the experienced, and they form an echo chamber.
This is because every year, many beginners join, but reaching an adequate level of experience to start questioning the crowd wisdom takes several years. By the time you get out of the rut of "best practices", you are in the minority.
Imagine a pryamid and you're in the middle of it. There's a lot more volume below you than above you.
> If you look at something like Clean Code today, it seems like a bunch of pretty bad advice, but in the context of the late 2000s Enterprise Java, it seemed like a really fresh breeze. We've already adopted the good ideas, and discovered that pushing farther in that direction was a bad idea.
I kindly disagree. I think people get better with experience. Maybe a long the way you encounter many different opinions and you try out different things. But I can't say that the particularly bad advice was useful for you in your journey to improve your skills. Quite the opposite, they might have been a hinderence, and maybe you would have grown a lot faster if you were lucky enough to not have encountered them.
I have no idea what Enterprise Java was like a decade ago, but I can't imagine it was much worse or better than it is now. I can't say I have ever seen a Java code base that I thought positively of. They might be terrible in different ways, but all terrible none the less.
> I have no idea what Enterprise Java was like a decade ago, but I can't imagine it was much worse or better than it is now
I have seen a bunch of it, well from pre 2005, and it tended to be horrific. You can still write java horribly, of course, but the codebases I've seen written in Java in the past decade are far, far better. I still don't like they approach Java developers take (the tend to architect in "elegant", ornate, massive OOP paradigms), but it generally is waaaay better than old enterprise Java.
> But not collective experience. Just some people's experience.
This is what collective experience is, though. Several peoples' experience.
> Rather amusingly, best practices are often adopted much more strongly by the beginners (and the expert[0] beginners) rather than the experienced. When you reach intermediate level of experience you start questioning many of what you learned from the internet as a best practice and start looking for alternatives or just experimenting yourself with different ways of doing things.
This is very much true. Best practices typically are aimed at beginners. Experts usually rely on tacit understanding rather than rules-based thinking.
> I have no idea what Enterprise Java was like a decade ago, but I can't imagine it was much worse or better than it is now. I can't say I have ever seen a Java code base that I thought positively of. They might be terrible in different ways, but all terrible none the less.
Here are some highlights of what early Java code could look like:
* OOP was unbelievably hot, but nobody quite knew how to do it, so they did all Gang of Four-patterns on all classes. If your class didn't at least end in AbstractBuilderFactoryFactoryDelegateFacadeVisitorImplDaoAdapterInterface, you just weren't with it.
* Logic and data typically wasn't separated at all. A class would frequently have both public static logic methods and mutable data.
* All functions had long boilerplate javadoc comments, none of them were useful.
* Extremely long classes that had zero separation of concern. Static access were very common, and the thread model was rarely well understood, so a lot of methods were "public synchronized static".
* Extremely long functions, longer than I've seen in almost any language. They could be hundreds, sometimes thousands of lines long. Often they were surrounded in one large try-catch as well, with half a dozen catch statements at the end that were all like e.printStackTrace()
* As icing on top, this was before runtime annotations, so you had megabytes upon megabytes of XML gluing the monstrosity together. This horrifying XML-Java chimera was a trademark of Java EE. In a way, Java EE was ahead of its time, because it's very similar to the YAML-golem that ties together Kubernetes these days.
> This is what collective experience is, though. Several peoples' experience.
No, this is not what I mean by collective experience. I mean something like what the vast majorit of experts agree on and follow in their day to day programming activities.
> This is very much true. Best practices typically are aimed at beginners. Experts usually rely on tacit understanding rather than rules-based thinking.
That means they are exactly not best practices. They are rails and safe guards for beginners to help them ramp up. Training wheels. They should never be used as an argument for an engineering decision.
What I remember mostly from the bad old Java days -- well, the "Enterprise Java Beans" days at least -- was all the bureaucracy and XML files for servers and containers and beans and stub classes and whatnot that you had to touch in order to get anything done.
> I think often best practices are based on experience
But not collective experience. Just some people's experience.
If you survey experienced people in different corners of the industry, you will not find agreement with whatever is currently being floated as a best practice.
Rather amusingly, best practices are often adopted much more strongly by the beginners (and the expert[0] beginners) rather than the experienced. When you reach intermediate level of experience you start questioning many of what you learned from the internet as a best practice and start looking for alternatives or just experimenting yourself with different ways of doing things.
[0]: By "expert" beginners, I mean people who got stuck in a rut. See: https://daedtech.com/how-developers-stop-learning-rise-of-th...
But beginners will always out number the experienced, and they form an echo chamber.
This is because every year, many beginners join, but reaching an adequate level of experience to start questioning the crowd wisdom takes several years. By the time you get out of the rut of "best practices", you are in the minority.
Imagine a pryamid and you're in the middle of it. There's a lot more volume below you than above you.
> If you look at something like Clean Code today, it seems like a bunch of pretty bad advice, but in the context of the late 2000s Enterprise Java, it seemed like a really fresh breeze. We've already adopted the good ideas, and discovered that pushing farther in that direction was a bad idea.
I kindly disagree. I think people get better with experience. Maybe a long the way you encounter many different opinions and you try out different things. But I can't say that the particularly bad advice was useful for you in your journey to improve your skills. Quite the opposite, they might have been a hinderence, and maybe you would have grown a lot faster if you were lucky enough to not have encountered them.
I have no idea what Enterprise Java was like a decade ago, but I can't imagine it was much worse or better than it is now. I can't say I have ever seen a Java code base that I thought positively of. They might be terrible in different ways, but all terrible none the less.