At the risk of being self-congratulatory, 3rd-grade homework is easy for me. I’ve already memorized my times tables.
When a kid brings me their work, let’s just say I crush it. You might even say it’s EASY for me. But I certainly wouldn’t say that to my child who is struggling with the same problems.
Yet, little bits of this perspective slip into my language.
I say things like, “multiplying by 11 is easy.” Or, “you ‘just’ have to write the number twice.”
When writing for developers, we have to be similarly careful, but not because we know so much more (in fact, I assume developer readers know significantly more).
We do have more knowledge of our product than a dev encountering it for the first time. If we trot out “simple” and “easy,” we may cause developers to:
- Feel stupid
- Disbelieve us
Obviously, nobody wants to feel dumb. But that second one might be more harmful.
There are a bunch of these phrases to avoid. When I posted a few on Twitter, developers replied with more.
The natural question is… what should you write instead?
If you have the room, the Developer Content Mind Trick can walk through how difficult the alternatives are. Instead of writing how easy your tool is, show how hard it is to not use your tool.
If you don’t have long form space, you can still highlight the biggest frustrations of the current methods. There’s a reason your developer product exists and it’s because the “other way” is a headache to build, run, or maintain.
That perspective will help you across all your content. Digging into those problems is the first step of the D.E.V. Content Framework. The “D” is for discovery: how developers discover you.
(I like to say an alternative for this step is “dilemma.” The quandary is in the dev’s mind before they find your product.)
Perhaps the best reason to avoid those trigger phrases like “simple” and “easy” is they keep you surface-level with developers. They keep you from finding a deeper, more fulfilling understanding of your potential customers.
As your homework, see whether you can uncover another layer of developer problems. If you’d like help, reach out and I promise we won’t call it easy.