Ask HN: How to help an engineering team come to a consensus on best practices?

8 points by semicolonandson 4 years ago | 9 comments

As my engineering team grows, there are naturally differences in opinion as to how things should be done

- e.g. "Should a single X.js file contain both the React component and its styles OR should we create both an X.js (which contains only React and no css) and a linked-to X.css files?" - e.g. 2 "Should we use dash-case for CSS class or camelCase or snake_case?"

I've scheduled a meeting next week where the goal is to reach some consensus. Seeing as I will be moderating this meeting, I wonder how I should approach things? Should we agree on some basic goods up-front (e.g. codebase consistency, standard community practice) and then proceed to rate each competing practice along these dimensions? How do I deal with nebulous goods - one I hear often is "this approach is cleaner". But many of these times I don't see a difference in cleanliness or any pragmatic value in that aspect of cleanliness. And then if consensus cannot be agreed informally, would it make sense to put it to vote anonymously and chose the most popular practice?

One of the factors that makes this challenging is that many best practice candidates started as innovations by one individual, and human nature being what it is, that individual is going to fight tooth and nail so that their innovation is chosen -- even though someone else is fighting back every bit as intensely for their competing innovation.

I am open for any ideas whatsoever here. I'm a long-time programmer but started managing programmers so don't have any good framework for dealing with issues.

And big picture: I would rather have an engineering team that is passionate about the best way to do things rather than one that couldn't care less.

ganeshsridharan 4 years ago |

I learnt a technique from my previous managers that I follow to make decisions. It is called "Tenets".

Tenets are neither wrong nor right. They are laid out so that everyone knows what are some of the non-negotiables.

In your case, for example, you could come up with the following tenets 1. All of the code should follow consistent patterns 2. Speed of creating a new component should be less

etc.

Now once this is done, you can share these tenets to the group of the participants and ask them to rate their proposal on the tenets. Finally you can take an approach based on the ratings.

IMPORTANT NOTE in decision making: 1) Decision making is not a democratic process. So make it clear that who is the owner who is going to decide on the final solution. Everyone can share their opinion but there should be only decision maker 2) Based on the tenets you come up with, there could be cases where some of the points (like dash-case vs. camelCase vs snake_case) does not matter. In those cases, do not spend time on going back and forth. Just take a decision and mark it as final 3) Make it clear to the audience how you are going to decide (like the tenets framework), who is the decision maker even before going to the meeting and make sure they agree to those. 4) After a decision is made, send a summary email (or write a document) on how you took the decision and if there is a time to revisit it.

r_hoods_ghost 4 years ago |

Firstly "best practice" is a much abused term and at least some, if not all, of what you are talking about is not identifying and establishing best practices but instead about establishing conventions. Things like should we use CamelCase or snake_case are conventions and which one you adopt is basically arbitrary. If you make wide use of a framework or are using a language like Python that has a strong preference for a particular convention, use that. If not, toss a coin. But don't debate it. Say this is the convention you are going to use, it needs to be this way for consistency and readability, and then enforce it at code review. You can actually do this with a LOT of supposed best practice discussions. You can then focus on ACTUAL best practise discussions. Get your team to identify pain points in your current processes and also things you do well. See if there are common industry practices that you aren't using and assess whether these are good candidates for best practices (sometimes they are. Often they're not). Look at how your (successful) competitors do things and also other companies you admire.

shoo 4 years ago |

I guess part of it is really hashing out how decision making in your team works, and getting everyone on board and used to that.

For the category of decisions it is acceptable for the team to have authority over: one way this could work is to have people present candidate ideas, put issues to vote, then if the team cannot elect a winner, someone in a leadership position (you?) gets to cast the deciding vote.

there are obviously some categories of decisions that the engineering team should not have the authority to decide, e.g. ones where they might have conflicts of interest. e.g. maybe all the developers in the team want to rewrite the product in $HYPED_TECHNOLOGY to be able to put the experience on their resume and then trade it for better jobs, but risk ruining the product and the business (where people might be making the decision with their personal-career hat on, rather than their whats-my-best-professional-recommendation-for-the-company hat on).

bjourne 4 years ago |

Hard to give general advice without knowing the specifics. If one engineer insists on that everyone should use version control while another prefers to write to a shared active directory folder, then one engineer is right and the other is wrong. If someone insists on Pokemon exception handling (http://wiki.c2.com/?PokemonExceptionHandling) they are also wrong. But arguing over whether to use camel-case or snake-case for css classes is just pointless bike-shedding. If the engineers can't agree on that then there is probably some personal issues involved.

Maybe you can ask both engineers to create a document describing why their best practice is the best one? If one engineer spends his whole weekend writing a 30 page essay on why their best practice is the best and the other does not, let him (or her) have it.

codeptualize 4 years ago |

This sounds like bikeshedding. I also wonder if this is really about camelCase vs snake_case etc, or is there something else going on that is being battled out through these irrelevant things? This might be more of a personal/team issue than a technical topic, and if it is you should focus on solving that.

But if it really is a technical question I would suggest to try to make the most objective decision possible, so list your goals, list pro/cons of each option, make a decision matrix, decide, move on. If it's purely subjective a vote could work, but then someone might lose, idk how well that does, I would just go with the "mainstream" option.

The other option is for you to just decide and take the conversation to goals; I assume you are trying to build something and most of the things you describe will not impact the end result in any way. Motivate people to focus on the things that make impact.

hirundo 4 years ago |

Discuss it ... and then dictate it. Engineering teams are better run by hierarchy than consensus. "A camel is a dog designed by committee." Would you rather have a dozen people put whatever they like in the soup pot, or let the best cook select?

mttjj 4 years ago | |

This is the right answer. And I’ll go one step further: Discuss it, dictate it, then automate it. (Sorry, couldn’t find another alliterative word.) My point being: whenever possible roll these best practices into build tools (auto formatters, style checkers, static analysis, etc) and then fail builds if they violate these standards. That way it’s impossible for engineers to get them wrong.

There are definitely things that can’t _yet_ be automated like this but do as much as you can.

We still encourage discourse on our standards if engineers have opinions about them but you’ll never get widespread adoption without some sort of enforcement.

shoo 4 years ago | | |

> automate it

this is such good advice, at least for low hanging fruit where there is already a solid tool for automating it.

by running code formatters such as `go fmt` or python's `black` as a mandatory lint stage in CI (or git pre-commit hooks or whatever) you never have to argue about code style again. everyone can be equally annoyed by the style spat out by the formatter, and spend their energy arguing about something else.

jrib 4 years ago |

Have a list ready beforehand with "defaults," i.e., your opinions on each. Distribute it before the meeting and let people know the format ahead of time.

I'd suggest running through anything that the team has a disagreement on, letting everyone present their reasons, then just vote by majority.

Automate as much as possible in the checks during pull requests so that your team doesn't waste brain cycles on it.