8 ms·

Eh, kinda. Calling something a "best practice" is basically an appeal to authority. It means, "this is the right way to do things, for reasons I don't have time

• swixmix 5y ago
  Reminds me of US Generally Accepted Accounting Principles (GAAP). I don't need to be perfect, just consistently good enough.
  • RNCTX 5y ago
    Or Tesla/Uber/etc, in which rules don't apply to you so do whatev
• theptip 5y ago
  One thought to add here - when you appeal to an authority, which one is it? In the OP example, it seems the senior dev is saying “on my authority”. And sometimes that is enough, especially if the senior dev can give examples of when not following this practice bit them. But sometimes there is a higher authority, such as “it’s what is recommended in Google’s SRE book”, which is probably good advice if you are building a large SRE team. (Though as you say, not in all situations.) I think in the worst case, “best practice” can indeed be used to shut down discussions of a leader’s preferences. But you can smell that out by asking for concrete examples, and asking how widely the practice is recommended. A good “best practice” should be justifiable and explainable. All that said, sometimes as the senior engineer you need to go with gut feel; “this design smells like it will give us trouble within a year” is the sort of thing I sometimes say. But I think it’s important to be honest that it’s a hunch, not a certainty in these cases, and discuss/weight accordingly.
  • floverfelt 5y ago
    Yep exactly! I think if you broaden the concept of "authority" beyond literal authoritative sources it gets even more murky. Are you appealing to the authority of speed? Compilation time? Readability? Functionality? I dunno, and it often (especially around readability) comes down to the developer's/senior engineers preference.
  • kelnos 5y ago
    > All that said, sometimes as the senior engineer you need to go with gut feel; “this design smells like it will give us trouble within a year” is the sort of thing I sometimes say. That's a really great perspective. There are a bunch of times where I have a preference for or against something, but I can't point to a specific example of when that thing was good/bad, or any objective data about it. It's just that my experience suggests to me (via murky pattern matching in my brain) that particular thing will be good or bad. It's certainly weaker evidence than data or concrete examples, but I think it's still valuable and worthy of consideration.
  • chmsky00 5y ago
    “Best practices” smells like such a marketing term it should be tossed in the bin. It’s poetic language that has nothing to do with specific problems. What people usually mean when it comes to engineering is “be safe, reliable, and correct.” Security best practices to be safe. Developer best practices for reliability. Etc etc “Best practices” is hand wave-y fluff for “do a good job” and doesn’t need a technical definition. Make sure you’re secure, reliable, and correct given the engineering context, and odds are you result in a system that also has a lot of specific best practices in place.
    • Dudeman112 5y ago
      I think it's very telling just how little engineering there is in Software Engineering that people can call best practices "just preferences" or "marketing fluff" and not be immediately laughed out of the room. Because that's what would happen if someone suggested "best practices smells like a marketing term" in an actual engineering discipline.
• dragonwriter 5y ago
  > Calling something a "best practice" is basically an appeal to authority. If presented on its own, but then, any conclusion presented on its own without supporting context and analysis is the same. > But really, "best" and "right" are highly situational A description of a best practice that doesn't provide a sufficiently precise description of the situation to which it applies as a best practice is generally inappropriate, unless it is the conclusion of an analysis of applicable best practices to a certain situation, in which case the scope is specified in framing the analysis. It is true that lots of things described as best practices for particular situations with supporting rationale and up getting detached from their logic and context and becoming cargo cult best practices.
  • w0mbat 5y ago
    Even worse are people that talk of "code smells", applying their personal opinion of style in a judgmental and often unjustifed way.
    • dragonwriter 5y ago
      Code smells aren’t conceptually about style but indicators of potential (possibly latent) bugs. A code smell is different than a style problem (though they overlap), its a thing that warrants attention because of risk of hiding errors.
  • mbrodersen 5y ago
    Smart experienced software developers disagree on “best practices” all the time. What is “obviously” the best practice to you is “obviously” not the best practice for somebody else. Now what?
• asdff 5y ago
  Identifying a best practice is actually not as hard as people realize imo (although it may take some time), and only becomes hard when you let emotion and sources of emotion come into what should be a rational decision making process (such as preference for a certain tooling for reasons like familiarity or popularity in the field today rather than outright advantages vs other tooling). To identify the best practice for anything, you start by doing a review of all the available practices in the field for a given problem you are working on. Then once you've reviewed the literature you can work out the pros, cons, caveats of each of these tools, and how these considerations affect your particular use case and your expected results. Then after doing that, the best practice out of available options will be readily apparent, or at the very least strongly justified, not by an appeal to authority or popularity or familiarity, but by looking at what the underlying technology actually does and how its relevant or not to your particular task at hand. In the end you will find the very best hammer available out of all the hammers people have made in this field for your particular unique nail.
  • lucumo 5y ago
    That sounds like a beautiful example of letting perfect be the enemy of good. Just like your design choices have trade-offs, is it important to realize that there's a trade-off between finishing sooner and making a better solution. Diminishing returns are usually very much in play with analysis. (I would also challenge the notion that every situation has a different "best practice". That's just creating a solution. "Best practices" are usually general advise that is applicable in most situations.)
    • asdff 5y ago
      You shouldn't take forever, but what I'm saying is a best practice emerges after doing however much due diligence. Maybe you spend an hour looking into it and that's it, but you should do your due diligence to vet what sort of approaches you can take to solve your particular problem as best you can, so you can make the best decision based on the evidence you've been able to find within however much time you are working with. A professor gave me a word of advice once, "a week in a library can save a month in the lab."
• Jorengarenar 5y ago
  > somebody got flamed harshly when he mentioned using a global variable. Harsh bashing on global variables is such a dumb thing. Yes, they can be dangerous. Yes, many had problems due to using them. Yes, we should tell beginners to avoid globals. But there is no reason to ban them altogether. Experienced programmers should utilize them whenever it makes sense (instead of passing down a value of a local one to almost every function [sic]).
  • nyanpasu64 5y ago
    Global mutable variables are generally a bad idea because they have nonlocal side effects which are difficult to mitigate, like aliased mutable pointers but worse. Extra non-aliasing arguments and multiple return values are free of these issues, and a better tradeoff in almost all cases (unless you're sure you'll never run 2 instances of a system in the same address space, and you have specialized constraints possibly including embedded/safety-critical development and emulators). When experienced programmers utilize global variables whenever it makes sense, it tends to bite future generations. Windows's GetLastError is a mess (some functions set it on error but don't clear it on success), I'm not sure about POSIX's errno, and when threads were introduced, these variables had to be changed to thread-local state.
    • kayodelycaon 5y ago
      > When experienced programmers utilize global variables whenever it makes sense, it tends to bite future generations. Usually. There is one pattern I keep using in Rails to inject the current_user for the request into the model layer. At the beginning of a request, Thread.current[:current_user] gets set to the current_user. At the end of the request, it's cleared. For those unfamiliar, each Thread has its own Hash object and [] and []= instance methods to access it. It's a way to create global variables scoped to the current thread. To hide this implementation detail, I wrap this functionality in ApplicationRecord.current_user and ApplicationRecord.current_user= methods so no one accidentally uses :curent_user. The most common use case for this is to automatically set created_by and updated_by on a model, the same way created_at and updated_at are set. Cron jobs can do something like ApplicationRecord.current_user = User.cron_user if needed. Ideally, I would set this in a CronTask parent class so current_user is always available in the model layer. I always document these methods and explain exactly what is happening and why. Abstracting away from the implementation detail mitigates most of the problems with a global variable. Obviously, the Thread.current method does not work at all if you're using an event or actor driven architecture. Rails does a thread (or process) per request, so this works extremely well.
• 908B64B197 5y ago
  > He then explained that he was working on an embedded control system for cars and all the variables in that system were global. Everyone should write Embedded at least once. It's a completely different world.
  • m463 5y ago
    and hard real-time. It really inverts some priorities (I mean development priorities, not the priority inversion on mars pathfinder)
• SkipperCat 5y ago
  Sometimes "best practice" is not because we need to worship a standard, but we need to have a standard. If everyone does everything in a different manner, you wind up with a tower of babel and support becomes impossible. I'm of the mindset where an organization needs to agree to specific principles that everyone adheres. Not dogmatically but pragmatically. Having that shared "best practice" makes is easier to support other people code/system, allows people to get up to speed faster and as a bonus, allows you to make a blog post on Medium where you can call yourself a thought leader.
  • funcDropShadow 5y ago
    > I'm of the mindset where an organization needs to agree to specific principles that everyone adheres. Agreed. But GP was talking about context dependency of those best practices. E.g. what might be a good best practice for a large organization inside a FAANG might be very bad for others. Some organization have very immediate feedback cycles. A significant problem in Amazon's online shop will probably show up immediately in sales numbers. A significant problem in the control software of a plane, might kill a few hundred people in a few years before people realize there is a problem. Therefore you cannot a/b test which auto pilot works better in a certain situation. (Although Tesla might disagree about that /s). The point is every so called "best practice" should state under which precondition it is supposed to be applied. And most blog articles and books ignore that completely.
  • deleted 5y ago
    [deleted]
  • mbrodersen 5y ago
    My experience is that enforcing standards for everybody is really bad. Different projects are truly different and require different trade offs. Enforcing one way to do things is anti-agile.
• atoav 5y ago
  It is best practise to use RCCBs, because it turned out faulty wiring can kill people. But in Server rooms where you might not want to switch off the whole rack without warning when one device is faulty, you can use a device to monitor the residual current (RCM). Which issues a warning first, and only switches of when the residual current raises over the acceptable level. Different scenario, different best practise. (This is also the reason medical equipment is expensive). I think a professional should be aware why a best practise exists and how to deal with a situation where for some reason it cannot be applied as you showed with the embedded example. Don't forget however that many devs are against best practises out of lazyness or because they don't understand the reasons why they are best pracises.