"Show don't Tell" is a hugely useful lesson which you can use in fiction and non-fiction to make your writing stickier and (usually) more engaging.
It also has a couple of very useful applications in software development.
From Wikipedia:
Show, don't tell is a technique often employed by writers to enable the reader to experience the story through action, words, thoughts, senses, and feelings rather than through the author's exposition, summarization, and description. The goal is not to drown the reader in heavy-handed adjectives, but rather to allow readers to experience the author's ideas by interpreting significant, well-chosen details in the text.
Here's an example:
Tell: "In Sweden Witches visit at Easter"
Show: "The bonfires had been lit. Fireworks danced across the sky and all around the village excited children dressed as witches were collecting sweets from their neighbors. They aren't trick or treating -- no, they're leaving their neighbors beautifully decorated letters in exchange for their sweets. For this isn't Halloween, this is how they celebrate Easter in Sweden."
And, another:
Tell: It was early spring.
Show: New buds were pushing through the frost.
---
Now ... take a look at what I wrote above. I started with a TELLING sentence, but just telling you didn't help much. And then I added the wikipedia quote which TOLD you a lot more, but it probably didn't sink in. If your brain works like mine then things probably only started making sense when you got to the examples. You're brain leapt into action and started comparing and contrasting. Only then, I suspect, did the difference between TELLing and SHOWing start sticking in your brain.
---
How does this apply to software development?
We use the SHOW don't TELL all the time nowadays, but there was a time when we did a lot more telling, as in, "The system shall do this ...".
We use examples. We flesh out ambiguous (and dull) sounding requirements and turn them into examples and stories "Hey, I'm a user and I want to do this concrete thing so that ..." and, taking it a level even deeper, concrete tests. We build prototypes - so we can SHOW what's we are thinking - rather than just TELLing our customers what the software will do. We use personas - they put flesh on an imaginary user and make them more real so that we can "put ourselves in their shoes" and have empathy with them. We demonstrate our software, often, so that we can SHOW concrete, tangible progress, rather than just telling our stakeholders "we've done X, Y and H".
And, here's a thought to end with: If you think about coding, it's TELLING the computer what to do. Testing is SHOWING what it actually does. We need both.
---
Sometime soon I'll tell you when it's very important to disobey this rule of writing. Tell don't Show!
