Writing the Discord permissions guide taught me how different it is to write for someone outside my technical background. Typically when I write documentation, it's for other engineers who already know what a manpage is or how to navigate an API reference. Writing for college professors who run a Discord server but have never thought about roles or permission inheritance forced me to unpack things I normally take for granted. I had to resist the urge to explain why Discord's permission system works the way it does and just give the reader the shortest path to fixing their problem. The toughest part was the alternate-names sections, where I had to come up with the different ways a non-technical reader might describe the same issue.

I think this will do me well in my work as a software engineer. Even internal documentation isn't always for people with the same context I have when I'm writing it, so the habit of naming the problem, listing the symptoms someone might search for, and breaking the fix into steps with screenshots is the same thing that makes a good runbook or postmortem.

I think the biggest thing I learned was to structure the document around the reader's question instead of around how I think about the system.