An architecture does not live in diagrams but in the heads of the people who write the code. An architect who decides everything herself and checks everything herself becomes a bottleneck, and when she goes on vacation, the architecture stands still. That is why Microsoft advises the role to set the tone: explain decisions early and often, in reviews and in short rounds over lunch, so that the team itself makes decisions that fit the whole. This lesson shows how: in a conversation with one person, in the review of a pull request and in the review of a whole architecture.

Questions instead of answers

When a colleague asks, “Where does this code belong?”, the quickest help is the answer. The most lasting help is a question that leads her to the answer herself. Whoever finds it on their own understands the reason and can apply it next time without you.

Good questions in mentoring are open and lead to a source, not to your opinion:

  • “Which context owns this data?” (lesson 4.2.6)
  • “What happens when the same command arrives twice?” (module 4.6)
  • “Which rule of the house rules applies here, and what does the architecture test say about it?”
  • “Where would you look if you could not ask me?”
  • “What would you do, and what makes you unsure?”

The last question is the most important. It shows where the knowledge is missing, and often the person already has the right idea and only needs confirmation.

Questions are not always right. Answer directly when it is urgent (an outage, a deadline today), when it is about security (a secret in the code does not stay there a minute longer than the question takes), when the person explicitly wants an answer, or when it is only a fact (“The parameter is called @reloadAll.”). Questions whose answer you already know are not a quiz; whoever feels quizzed does not ask the next time.