5 ms·

As everything, it depends on the context. Following a set of rules blindly just for the sake of it when you and your team is producing good quality code and hav

As everything, it depends on the context. Following a set of rules blindly just for the sake of it when you and your team is producing good quality code and have a good team culture is absurd. However, relying on “best practices” guidelines might be useful in scenarios where you don’t want to fall in your own (or someone else’s) subjective opinion that doesn’t necessarily imply the best solution. As a personal story, not so long ago, I was the technical leader of a team that had the tendency of not following even the most basic set of common sense standards. The code base consistency and practices around that code where an absolute mess. Chaos and opinions everywhere. Everyone had his/her own way of doing things. So in order to have everyone on the same page and producing something predictable and consistent, I had to heavily impose a set of best practice guidelines. I felt kinda bad at the beginning as I don’t like to behave as a dictator but the good thing is that, at the end, everyone felt the benefit and new team members were able to catch up and being productive quickly as everything followed a pattern. So, yes, best practices might be a useful resource for drawing a line when everything else is just an opinion without technical support behind (or a poorly one).

charles_f 5y ago
> I had to heavily impose a set of best practice guidelines. I'm curious, why calling them "best practices" in this case rather than just guidelines? Or conventions?
- Octabrain 5y ago
  In my case is a question of habit. But yes, I can see the term “best practices” being perceived as very conclusive. Like implicitly saying “this is the very best and if you don’t follow it you’re doing something wrong”. So I agree on “good practices” or “guidelines” (or even just a simple “recommendations” or “conventions”) as a better option.
mbrodersen 5y ago
Agree. “Best Practices” often disagree with each other. So you need to understand the context and pros/cons to pick the right one or decide not to.
jseban 5y ago
> As everything, it depends on the context. Following a set of rules blindly just for the sake of it when you and your team is producing good quality code and have a good team culture is absurd. It is absurd yes, but this is exactly how every single team I ever worked with, have functioned. And it's been promoted by managers who don't want to make too much effort in actually understanding the work, and by asperger syndrome developers who do anything to avoid having to use their judgement, and possibly being "blamed" for making a wrong decision. You sound like a good leader, but honestly that change you made optimised for planning purposes (predictability), and for developer turnaround, and there might have been a "custom practice" solution that would have been much more productive in terms of actually delivering value, although it would have taken much more careful investigation into the code base and people's opinions.
- Octabrain 5y ago
  > It is absurd yes, but this is exactly how every single team I ever worked with, have functioned. And it's been promoted by managers who don't want to make too much effort in actually understanding the work, and by asperger syndrome developers who do anything to avoid having to use their judgement, and possibly being "blamed" for making a wrong decision. I can understand your point of view given your experience and completely agree. However, in my case, believe me, it was not a question of careful investigation nor anything like that. My team was a mix of lack of experience, lack of knowledge (and the annoying habit of not reading the bloody documentation of the tooling), duct taping mentality, years of technical debt, folklore mentality etc. And I was the newer member and in charge. So, in order to fix that, I had to use sometimes "best practices" as the tablets of stone, otherwise literally every PR would have been a push and back. In other occasions, we simply reached an internal consensus. The author of the article uses the word "hate" which I think is too extreme. I truly believe that everything depends on the situation and general "best practices" guidelines might be a useful resource. There are no golden hammers in anything, even less in computer science.

charles_f 5y ago

> I had to heavily impose a set of best practice guidelines. I'm curious, why calling them "best practices" in this case rather than just guidelines? Or conventions?

Octabrain 5y ago
In my case is a question of habit. But yes, I can see the term “best practices” being perceived as very conclusive. Like implicitly saying “this is the very best and if you don’t follow it you’re doing something wrong”. So I agree on “good practices” or “guidelines” (or even just a simple “recommendations” or “conventions”) as a better option.

mbrodersen 5y ago

Agree. “Best Practices” often disagree with each other. So you need to understand the context and pros/cons to pick the right one or decide not to.

jseban 5y ago

> As everything, it depends on the context. Following a set of rules blindly just for the sake of it when you and your team is producing good quality code and have a good team culture is absurd. It is absurd yes, but this is exactly how every single team I ever worked with, have functioned. And it's been promoted by managers who don't want to make too much effort in actually understanding the work, and by asperger syndrome developers who do anything to avoid having to use their judgement, and possibly being "blamed" for making a wrong decision. You sound like a good leader, but honestly that change you made optimised for planning purposes (predictability), and for developer turnaround, and there might have been a "custom practice" solution that would have been much more productive in terms of actually delivering value, although it would have taken much more careful investigation into the code base and people's opinions.

Octabrain 5y ago
> It is absurd yes, but this is exactly how every single team I ever worked with, have functioned. And it's been promoted by managers who don't want to make too much effort in actually understanding the work, and by asperger syndrome developers who do anything to avoid having to use their judgement, and possibly being "blamed" for making a wrong decision. I can understand your point of view given your experience and completely agree. However, in my case, believe me, it was not a question of careful investigation nor anything like that. My team was a mix of lack of experience, lack of knowledge (and the annoying habit of not reading the bloody documentation of the tooling), duct taping mentality, years of technical debt, folklore mentality etc. And I was the newer member and in charge. So, in order to fix that, I had to use sometimes "best practices" as the tablets of stone, otherwise literally every PR would have been a push and back. In other occasions, we simply reached an internal consensus. The author of the article uses the word "hate" which I think is too extreme. I truly believe that everything depends on the situation and general "best practices" guidelines might be a useful resource. There are no golden hammers in anything, even less in computer science.