5 ms·

It's simply impossible to have reliable "best practices" in programming. It's still a young field and most of the ideas floating around are just fads. Yesterday

• marginalia_nu 5y ago
  > None of it is based on actual collective experience. Just the opinions of people who are good at marketing their ideas. I think often best practices are based on experience, but they stem from a lost programming zeitgeist that the new practices have replaced. Before Don't Repeat Yourself became popular, there was a serious problem with code duplication. Now there is a serious phobia of code duplication instead (to the point where it's a problem). DRY was good advice in a world where DRY was an obscure idea, is bad advice in a world where DRY is a popular idea. 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. These books and ideas were lauded for a reason, but often that reason isn't there anymore.
  • hsn915 5y ago
    > > 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. [0]: By "expert" beginners, I mean people who got stuck in a rut. See: https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/ 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.
    • gilbetron 5y ago
      > 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.
    • marginalia_nu 5y ago
      > 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.
• ford 5y ago
  I believe the RoI on best practices is generally correlated to the scale of the application and engineering team you are working on. A large number of best practices come from Big Corp engineers or organizations. Big corps have thousands of engineers that need to be able to read and contribute to code from many other teams. They have systems that need to be able to handle millions or billions of users. In situations of massive scale strictly adhering to best practices is worth the investment, since it will make code easier to contribute to (readability/architecture standards), make sure it does what it's supposed to (unit tests), or keeps things performant. But the RoI of following best practices decreases as you move down the spectrum of scale