3 ms·

One meets people who are really trying to look important by having more reports than the other managers. People who use Linkedin, say “best practices” without i

One meets people who are really trying to look important by having more reports than the other managers. People who use Linkedin, say “best practices” without irony, and like to tell stories about what programming was like 25 years ago when they were a junior engineer shipping Windows software. Then, mixed in with those folks, are a few people who are good at working with upper management, understand how the machine works, and build a pipeline of projects. And a few rare people who fix departments, create long-term programs, and know how to train managers. You don’t meet many in this last group, though.

hn_go_brrrrr 2y ago
What's wrong with "best practices"? I get the feeling the best practices you're complaining about are TPS reports, whereas I'm thinking more like "don't ship to prod on Fridays".
- klodolph 2y ago
  > I get the feeling the best practices you're complaining about are TPS reports, I’m talking about the actual term “best practices”, and not the actual practices themselves. The term is an ineffective way to communicate something. Managers and engineers alike should be able to explain what they do in terms that can be connected with concrete actions / concerns and understandable business goals. Terms like “best practices” are ineffective at doing that. Just like there are code smells, this is a “communication smell” and makes me suspicious that there are underlying problems or weaknesses in the speaker’s ability to communicate clearly. “Best practices” also implies some kind of independence of situation which is fictitious. “This team doesn’t use best practices for deploying code” -> unclear. “This team doesn’t use CI/CD, engineers spend too much time resolving merge conflicts, and we see too many regressions make it into production” -> clear. If you need to put it in a bullet point, you can say something like “improve velocity”, “ship fewer bugs”, or “less downtime”. I’m a fan of ambiguous or unclear language, but “best practices” strikes an unfortunate balance of sounding like it means something but wasting your words saying not much at all.
  - SpicyLemonZest 2y ago
    > “Best practices” also implies some kind of independence of situation which is fictitious. If you, say, have 30 teams whose projects come together into a product with a 99.9% SLA, you can’t have each team make completely independent judgments of what practices are best for their situation. You can try to, and many growing companies do. What you inevitably find is that the aggregate set of problems is too large, even when every team has a plausible story for why their individual situation makes sense. The only solution is to write down a “best practices” manual and insist that everyone must follow it, even if they don’t think some practice or another is necessary in their situation.
    - klodolph 2y ago
      Sure, you can invent a scenario where the term “best practices” is a half-decent term. I’m not speaking in some kind of absolute. I still think it’s not a very good term here. It’s not really describing best practices, is it? It’s just describing the practices that the teams are choosing to follow. I would name the document something like “development standards” or something like that. I’ve this called “meeting the bar” or “engineering excellence”. I like “meeting the bar” because the implication is that you haven’t succeeded if you don’t do what’s described. I like “engineering excellence” because it implies that you’ve gone beyond the minimum. I don’t like “best practices”. I also wouldn’t insist that everyone must follow it. You have minimum standards (everyone must follow) and a set of expectations which are higher than that (everyone should follow). I think it is a kind of common error to make long lists of standards that everyone must follow. It’s better to prioritize. The minimum standards should be short and connected to the most critical concerns like security, privacy, or legal liability. IMO, 99.9% SLA is not really that hard anyway, but I get what you mean. That’s like 2 whole hours of downtime per quarter.
      - SpicyLemonZest 2y ago
        I pretty much agree with what you’re saying, although I wonder how much it’s a euphemism treadmill. You don’t hear people talk about gold standards much these days. I’ve definitely seen overstuffed practices docs that end up as pointless (and ignored) checklists.

hn_go_brrrrr 2y ago

What's wrong with "best practices"? I get the feeling the best practices you're complaining about are TPS reports, whereas I'm thinking more like "don't ship to prod on Fridays".

klodolph 2y ago
> I get the feeling the best practices you're complaining about are TPS reports, I’m talking about the actual term “best practices”, and not the actual practices themselves. The term is an ineffective way to communicate something. Managers and engineers alike should be able to explain what they do in terms that can be connected with concrete actions / concerns and understandable business goals. Terms like “best practices” are ineffective at doing that. Just like there are code smells, this is a “communication smell” and makes me suspicious that there are underlying problems or weaknesses in the speaker’s ability to communicate clearly. “Best practices” also implies some kind of independence of situation which is fictitious. “This team doesn’t use best practices for deploying code” -> unclear. “This team doesn’t use CI/CD, engineers spend too much time resolving merge conflicts, and we see too many regressions make it into production” -> clear. If you need to put it in a bullet point, you can say something like “improve velocity”, “ship fewer bugs”, or “less downtime”. I’m a fan of ambiguous or unclear language, but “best practices” strikes an unfortunate balance of sounding like it means something but wasting your words saying not much at all.
- SpicyLemonZest 2y ago
  > “Best practices” also implies some kind of independence of situation which is fictitious. If you, say, have 30 teams whose projects come together into a product with a 99.9% SLA, you can’t have each team make completely independent judgments of what practices are best for their situation. You can try to, and many growing companies do. What you inevitably find is that the aggregate set of problems is too large, even when every team has a plausible story for why their individual situation makes sense. The only solution is to write down a “best practices” manual and insist that everyone must follow it, even if they don’t think some practice or another is necessary in their situation.
  - klodolph 2y ago
    Sure, you can invent a scenario where the term “best practices” is a half-decent term. I’m not speaking in some kind of absolute. I still think it’s not a very good term here. It’s not really describing best practices, is it? It’s just describing the practices that the teams are choosing to follow. I would name the document something like “development standards” or something like that. I’ve this called “meeting the bar” or “engineering excellence”. I like “meeting the bar” because the implication is that you haven’t succeeded if you don’t do what’s described. I like “engineering excellence” because it implies that you’ve gone beyond the minimum. I don’t like “best practices”. I also wouldn’t insist that everyone must follow it. You have minimum standards (everyone must follow) and a set of expectations which are higher than that (everyone should follow). I think it is a kind of common error to make long lists of standards that everyone must follow. It’s better to prioritize. The minimum standards should be short and connected to the most critical concerns like security, privacy, or legal liability. IMO, 99.9% SLA is not really that hard anyway, but I get what you mean. That’s like 2 whole hours of downtime per quarter.
    - SpicyLemonZest 2y ago
      I pretty much agree with what you’re saying, although I wonder how much it’s a euphemism treadmill. You don’t hear people talk about gold standards much these days. I’ve definitely seen overstuffed practices docs that end up as pointless (and ignored) checklists.