The Developer DRY (Don’t Repeat Yourself)
Developers often learn the useful heuristic DRY (Don’t Repeat Yourself). Having a concept repeated across a codebase many times makes understanding and changing systems much harder than it needs to be. Applying the DRY heuristic to code nudges developers towards higher cohesion. High cohesion means having a single concept in a single place. Applying DRY appropriately to improve cohesion makes it easier to understand a system, and evaluate the impact of new changes which reduces the chance of bugs. After all, duplicating code often allows for a part of a system to behave differently than another, which may be undesirable behaviour.
There are certainly times where DRY code isn’t as useful. Increasing cohesion sometimes leads to unwanted coupling and therefore increased coordination. Sometimes it makes sense to have duplicate areas because two concepts are diverging, or are less cohesive ideas. Imagine, for example, you have a price for a SAAS system, charged on a regular basis. You want this concept represented in one place in case you change your pricing. Now imagine, you are want to target two different audiences and introduce different pricing tiers. Having a single concept that represents the subscription price is no longer useful. Instead, you probably want to model this as tiers, each that has a single price. When applied dogmatically, DRY slows down innovation and experimentation.
Although DRY is generally a good heuristic, applying the DRY heuristic in a different context (communicating with people) can backfire spectacularly.
DRY for leaders (or it’s okay to CRY)
If you’re a leader and you associate DRY with Don’t Repeat Yourself, try to rewire your association so that DRY reminds you to *Do* Repeat Yourself. Alternatively, you might choose the sometimes appropriate and hilarious acronym, CRY or Continually Repeat Yourself when it comes to communicating with people.
Why is DRY (Do Repeat Yourself) Important
When technical folk step into leadership roles, many forget that they’re dealing with people instead of with computers. Where people might be used to typing code into a computer for a relatively predictable output, this same approach will not work when dealing with people. There are many things that can possibly go wrong when we communicate:
- The same words have different meanings – Programming languages have very specific keywords and special symbols. A single character missing can be the difference between a program working or not working. The same keyword or symbol always mean the same thing to the compiler/interpreter. In the real world, we sometimes use different words for the same meaning (i.e. synonyms). People are much better at dealing with ambiguity, but one big downside is that we might use the same words but apply different meanings. We nod and think everyone understands each other but instead there are big misunderstandings. It’s one of the reasons Domain Driven Design encourages the idea of a Ubiquitious Language. This takes time (and repitition) to establish.
- People are constantly distracted – Ping! You’ve just received another email. Ping! Someone just sent you a DM on slack. We’re all constantly surrounded by distractions. When you’re saying something, or when someone reads your message, anticipate distractions. A distraction might mean someone forgets to read the rest of your message, or they missed a key part of your conversation. In the age of remote working, a poor network connection only serves to amplify this.
- People often start problem-solving and stop processing information – It’s a very normal and human behaviour to try to short-circuit conversations. You might be sharing information with the intent of solving a specific problem but someone is almost always jumping ahead with how they would solve that problem. When someone is focused on problem solving, they have to trade-off active listening to put that energy towards thinking about the solution. When this happens too early, people may jump to the wrong solution because they didn’t hear the full context.
If you’re communicating something important, don’t fall into the pattern of “Send-and-Forget.” You might recognise this communication anti-pattern if you hear yourself saying, “But I already told them once. They should know.” Good leaders know that when you are communicating an important message, do not apply DRY as in “Do not Repeat Yourself.” Instead, they remember to apply the DRY or “Do Repeat Yourself.”
Lean on the “Rule of Three”
But how many times should you repeat yourself? Try at least three times.
Three times is a useful rule of thumb. Three times might mean broadcasting an important message three times over a time period such as sending an email once, a reminder the day after and once more a week later. Three times might mean using three different channels to reach as many people as possible. You might share an important message at a town hall through a presentation, but chances are that someone is going to miss out on that meeting. Applying the rule of three, you send a follow up email (a different channel) and link to a recorded video (a third channel that’s persistent) that is uploaded to a wiki.
Of course, the “Rule of three” is a bit more like a heuristic and recognise it’s sometimes okay to CRY (Continually Repeat Yourself) 😉!
Like this article? Subscribe to Level Up, a free curated newsletter for leaders in tech offering the best reads on leadership, tech, organisations and processes. If you’re looking to level up your communication skills, then check out the self-paced course, “Communicate Like a CTO” at the Tech Lead Academy.
