As software developers – our world is increasingly complex with each line of code. As technology progresses, we’re given more tools and more jargon. Our language can quickly separate us from the others that work around us, and isolate those that don’t really understand. It’s a developers job to try and make their work and their communication as simple as possible. One way to achieve simpler communication is through metaphors.
If you had 3 metaphors in your toolkit to be used at any time – it would these 3.
I come back to these metaphors time and time again as they’re really reusable for different scenarios.
… So how exactly do I use bricks, buildings, bikes and cars to enable stronger conversation?
Cars & Bikes
The car metaphor comes up a lot in Agile …
Build a skateboard, then a scooter then a car – not an axle, an engine and then a car.
There’s a reason this is such a widely used metaphor and that’s because it works!
Example: Describe refactoring like pumping up the tires on your bike – if you don’t it will run incredibly slowly, its tires might pop easier and it can only mean a small investment for a big impact in effectiveness.
Buildings & Bricks
When you think about an issue like a building, you can talk about the need to build a strong foundation, the concept of taking it step by step, or the fact that once you build a wall, it’s quite hard to change.
Example: When trying to talk about how you need to invest in your application architecture you can talk about how a house built on sand will not get bigger, it will just sink!
Recipes & Food
Making recipes is a great metaphor to be reused in many different scenarios, when you think of your work or life as if it were ingredients it can be easy to explain difficulties to others.
One of my favourite uses of metaphors is by Timber Hawkeye in his excellent book: “The Buddhist Bootcamp” where Timber talks about how life is like cake … I won’t spoil it, but I’d definitely recommend it for inspiration!
Example: When developers think about code re-use there is always a tendency to want to group and couple together components into manifestations that are only useful to that one developer or in that one scenario … So how do you explain this with a metaphor? Well … there’s a reason cereal and milk are sold separately and why you don’t find sachet’s of milk in cereal boxes … Some people like more milk, milk needs to be put in the fridge, so that’s why we don’t want to couple our code together too tightly!
I hope that helped you to think about how you can start using metaphors in your work – challenge yourself next time you have a conversation to use one of these metaphors and see what benefits you can bring to your conversation.
Question: What are your favourite workplace metaphors for communicating ideas?