5 types of engineers I met as a Technical Writer

#watercooler #technicalwriting #discuss #jokes

Relatable memes on collaboration styles

Being a Technical Writer in an engineering world can be tough. We work closely with engineers, but we're not engineers ourselves. Our job isn't to code, but to deliver a product that's well-described and clear for the target audience. This requires us to go around and bother engineers with questions, often uncomfortable ones, and keep them away from what they want to do most – coding.

In my career, I've met engineers with very different attitudes towards documentation. Ever wondered what engineers look like from a Technical Writer's perspective? Spoiler: it's a mixed bag. I've divided them into 5 main types, each illustrated with a meme below.

Note: I use "he" throughout this post for simplicity, but these types are gender-neutral – I've met all of them in every gender.

1. Good boy

That's our favourite boy! If he was a dog, he would definitely be a golden retriever. He's a perfect collaborator – always thoughtful, helpful, and truly engaged in the project. You're not afraid to ask him questions, knowing he won't judge you, but take your feedback as something valuable that will help improve the docs. He carefully reads your comments, takes an active part in brainstorming, and takes your feedback to heart, so that next time he publishes a document, it will be even better. I even remember fighting with my fellow Technical Writer colleague over who would work on the docs with our golden boy.

Definitely the best type of engineer to work with!

2. Mr. Better

"Everyone can write, it's not a big deal", thinks Mr. Better. He ignores or rejects any review comments, and he's always sure that his docs are perfect and don't need any improvement. Prerequisites at the end of the document? "That's the intended design". A request to make the concept clearer? "I don't see the problem, it's clear enough". A suggestion to add more details? "I don't want to make it too long, it's already long enough". He's the one who always says, "I know how to write docs, I'll do it myself", not understanding that writing technical documentation is not only about putting words on a page, but also about structuring information, making it clear and concise, and considering the audience's needs. The result? A document full of jargon, unclear explanations, missing information, and a confusing structure that's more frustrating than helpful to the user.

Probably the most demotivating person to work with.

3. Jon Snow

Every company knows this guy. You approach him to ask a question about a project he's supposed to maintain, but as soon as you ask, he looks at you with a blank stare and says, "I don't know". You ask him again, maybe rephrase the question, but the answer is always the same: "I don't know". You start to wonder if he really knows nothing, or if he's just pretending so that you won't ask him to write docs.

There's also another version of Jon Snow who knows nothing but pretends to know something. He confidently gives you an answer that sounds like it should be correct, but when you think about it, it doesn't make any sense. You ask him to explain it further, and he starts to ramble about something that's not even related to the original question. This type of Jon Snow is even more dangerous, because he can lead you to wrong conclusions and make you waste time chasing something that isn't true.

4. Minimalist

The Minimalist thinks that documentation is overkill. Code itself is enough. You approach the Minimalist with some questions about the feature he just shipped, hoping to update the docs. He looks at you like you're an alien. "We don't need documentation, the code is self-explanatory", he says. And if you push back? "If someone doesn't understand the code, they shouldn't use the feature".

The funny thing is, ask him to explain his own code six months from now, and he'll stare at the screen with the same blank look as Jon Snow. But that's a future problem – right now, the code is obviously clear, and writing it down would just be a waste of time.

There's a softer version of this type, too: the one who admits he doesn't know how to write docs, or that he doesn't have time. That's fair – that's literally why tech writers exist! But more often, it's just an excuse. He thinks docs aren't important, that nobody reads them anyway, so why bother?

5. Robot

You open a diff and see a big, never-ending pile of docs. You scroll through them, and reaching the end takes you ages. You decide to give it a try and start reading the content, but you quickly realize that even though it's written in English, it's definitely not written in a human-readable manner. Everything is generated. It reads like Lorem ipsum — and that's about all you get out of it. You decide to reach out to the author and ask some questions. As a response, you get a generated answer copy-pasted directly from ChatGPT:

Absolutely — I can update this section so the documentation is fully comprehensive and self-contained. Want me to handle that next?

You ask yourself: "Is there anybody out there? Or is it just me and this robot?".

Conclusions

Time for some honest self-reflection. Which type of engineer are you? A Good Boy, hopefully? Or do you recognize a bit of Mr. Better or the Minimalist in yourself? Or maybe you're a completely different type not mentioned here? Let me know in the comments, and feel free to share your own memes! 😁