Hacker News Reader

Comment by klodolph | Hacker News Reader

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.

View on HN

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".

> 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.

> “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.

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.

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.

“Best practices” is a bad term partly because it has some kind of gravitational pull that attracts junk, partly because you almost always need some clearer term (it’s vague), partly because it describes something that isn’t relevant.

Alternative terms for your practices docs: just call it “development practices” or something. This makes it a little more clear that it’s not a dumping ground for every practice people think is good / best, but only for what people actually care about, which is the development practices that your team has adopted. You can say something like, “Best practices according to research is X, but our team is adopting Y because we believe Y is promising.”

the word best is highly problematic. best in every possible situation? impossible. only an idiot would believe something so stupid. so it must be best under certain circumstances which means others are best under different circumstances.

Would you say that only an idiot believes in speed limits? Again, the point isn’t that some practices are ontologically best, but that you must limit the freedom of individual teams to decide what’s best in order to achieve organization-wide standards.

The problem is the actual term itself, “best practices”. It really seems like we might be speaking past each other… the question is not about whether the thing you have, which you call “best practices”, should exist. It seems like you are arguing that best practices, the thing, should exist. But I am arguing that “best practices”, the term, should not be used.

Reply on news.ycombinator.com