After reading What You Do Is Who You Are early this year, I decided to write down what virtues I would want in my organization. After letting it sit around for 6 months, I think I’m still in agreement both with the ideas behind them and actually implementing them in reality, not just paying lip service to them. What do you think?
- Operate initially in good faith, trusting that other people want to help you, and will do what they can within their means
- Deal with bad faith actors when necessary, but minimize contact and focus on the immediate goal, do not get sidetracked into unnecessary battles
- Offload a task from someone else if you can spare the time. This builds trust, collaboration, and spreads knowledge and experience.
- Write tests, especially for code on the hot path, with more detailed tests the more complex and critical the behavior
- Get reviews, and respond to reviews either by changing code after discussion, or arguing successfully why something must be the way it is
- Do not review everything, as it wastes people’s time and patience, and slows down the overall operation needlessly
- Trust each other enough that we allow some code to go by without review when it’s simple enough, with the understanding that if it breaks, you own it completely
- Specifically, a database migration adding a simple column may not need to be reviewed, unless you’re uncertain about the naming, or a PR fixing a typo unless you’re uncertain
- Go with the person with the stronger opinion, if all other things are equal. It is likely that whoever cares more does so because of previous experience, and they are willing to stake their reputation on something so it’s worth seeing how it will play out. You might even learn the same lesson.
- Design ahead of time, and communicate design via simple but structured documents for discussion, before diving head-first into details of implementation of a complex feature or product
- Raise issues early, showing at least minimal research into an issue and possible solutions, even if you don’t have a solution yet. This shows preparedness, but also adds visibility which can help to better or more easily tackle a problem.
- Prefer text-based communication such as chat or email, as it leaves a searchable and forwardable record. Fall back to call/meeting if this fails, but try to leave a written record of the results somewhere for the benefit of your future self and others not present.
- Avoid personal attacks, and reprimand those who engage in it publicly. This includes appeal to ignorance (e.g. “you should go read a book”) or other vaguely-worded attacks that are not constructive and only seek to agitate. Remove repeat offenders.
- Call formal meetings only when necessary, prepare an agenda, invite only necessary people, and have a clear goal of output for the meeting
- Allow meetings to be cancelled if questions end up answered over email, chat or in-person
- Allow meetings to be rejected if the person calling the meeting shows no effort of research, no agenda, and has no idea what kind of questions they want to ask in the meeting
- Allow impromptu meetings when topics are immensely time-sensitive, but have it be the exception and not the rule
- This applies during peacetime. During wartime, of course, all meetings are by definition time-sensitive.