5 ms·

Right, but have you ever worked in a place where no practices at all are being followed? Where there are hacks after hacks, giant classes with giant methods, no

• rewma 5y ago
  > I agree, following a “best practice” without understanding the “bad practice” that it’s trying to prevent is silly. But just discarding best practices because no one understands the reasons behind is also silly. I would argue that there is also a lot of value in following team-level best practices even if you do not fully grasp the rationale or understanding "bad practices". For starters, it ensures that the team's work complies with the principle of least surprise and follows a common and standard style, which helps with onboarding and forming a mental model of where and how all things are.
• floverfelt 5y ago
  Yup, I 100% agree. The point of the post wasn't to bemoan practices, more just that it's frustrating to be told repeatedly that a certain thing is a "best practice" when really it's just what the developer who wrote it preferred. Software Engineers should just say "this is how we like to do things" and not pretend that there's a holy grail of correctness when really it's just what they like.
• dkarl 5y ago
  > But just discarding best practices because no one understands the reasons behind is also silly. So what do you do with a "best practice" that doesn't make any sense to you? Do you just keep doing it forever because you can't understand why anybody would invent it in the first place? To take an example I'm familiar with, there's a good chance if you don't understand a Java OOP best practice it's because you've never encountered the problems it was designed to cope with. The OOP design principles that came out of the 1990s and became orthodox in Java around the turn of the century were built to solve the problem of scaling monolithic application development to teams of dozens or hundreds of developers. You would have dozens of people, imperfectly coordinated, hacking on a monolithic codebase for an application that was released quarterly (if that!) and ran on servers that cost more than the CEO's car. The coding style innovations of that era naturally focused on coming up with more and more ways to add layers of protective abstraction, and on training programmers to add those layers to their code no matter what, even if it doesn't seem worth it because 99% of the time, if somebody didn't understand that it was worth it, it was because they were inexperienced and hadn't lived through a horrific integration debacle that delayed the quarterly release by a month. In my opinion, if your problems don't resemble those turn-of-the-century enterprise monolith problems, then you shouldn't program in turn-of-the-century OOP style, and you should take "best practices" from that era with a huge grain of salt. You should only use them if you can see how your codebase will benefit from them. Even Java, the bastion of OOP conservatism, is acknowledging that "best practices" are relative by adding record classes. Record classes are first-class language support for violating the best practices that were drilled into generations of Java programmers! (There are people who do have those turn-of-the-century enterprise monolith problems, for example, library developers! They ship their changes to hundreds or even thousands of people they've never met, who don't keep up with project updates, and who don't budget time to deal with breaking changes. So a lot of the ideas turn out to be really valuable! Just not for, say, small teams building microservices.)
• mbrodersen 5y ago
  Most places I have worked had zero agreed standards. It wasn’t a problem at all. And people didn’t waste their time getting into fights about how to interpret the “agreed standards” or policing it. Great!