Coding is natures way of showing how sloppy your thinking is, not writing natural language text. It is really easy to hide sloppy thinking behind natural language, otherwise there would be a lot of overlap between great writers and great coders, but there doesn't seem to be much correlation there at all. Coders tend to be precise with their language, but most people prefer to read imprecise sentences so you easily gravitate towards imprecise language if you try to practice writing.
* Use bold text once or twice per section to break up the monotony and draw the reader's eye to where you want it.
* Shorten! Cut away anything optional to the reader understanding your main point, and move it to footnotes, sidenotes, or a linked document/page.
* Have someone read your first draft. If they ask a question, don't answer it directly! Update your draft instead.
* Use lists religiously! Walls of text tend to repel attention.
My favorite article  happened to use all these tips, if anyone wants to see an example. Happy writing!
There's usually a critical insight that allows an algorithm to be understandable.
Wikipedia descriptions for btrees and tries are almost enough to implement them.
I don't like it when developers say the code is the documentation. I don't want to read your code to understand how you implemented the solution to the problem. I would rather read a plain explanation of what you're trying to do.
One thing there isn't enough of is task-driven documentation. Typically there's a getting started guide and a reference manual, with a huge gap between the two.
The getting started project is usually at the hello world level - ok as far it goes, which is not far.
The ref manual typically has a list of all moving parts but often lacks a list of concepts and terminology. So you look up $thing and have no idea how it fits into what you're attempting to do.
A series of mid-level task-based examples ("How do I...") for the most common use cases goes a long way to bridging that gap.
Also list any platform specific quirks. (Not just "To install this use homebrew $name for MacOS and apt-get $name for Ubuntu.")
And run a forum where people ask questions. Collect the most common questions into a literal FAQ and/or include them in examples/reference.
Never say "That's in the manual." Especially not when the manual is 1000 pages long and gives a two sentence description of every feature with no use cases.
And any time I got pinged in Slack I'd try to find the answer in that doc and link to relevant section as response.
While I found that most people would not read through the entire doc when it is written or the first time it is shared for comments (can't blame them, attention spans are rare these days), they did however start referring to the the doc first after a couple of times of getting the doc link in response.
Recently I read a tweet that describe text as a liability, just like code. And now I feel all docs should come with an archival/revival date. We need more "canonical references" and less long living design review docs that are often shared around as reference docs.
One of my first real job assignments was a relatively large C project (client/server architecture) behind a simple CLI. I was given the opportunity to document it relatively well (not just the CLI, but the internal design as well). Ten years later there are multiple GUI clients implemented, some even at other companies. One guy even replaced the client-server UDP protocol (don't ask) with a TCP one. Aside from reviewing pull requests for stuff like that, I don't think I've ever had to explain how any of it actually work aside from pointing them to the docs.
However, documentation is a "concrete galosh", so I've learned to reduce the sheer volume of docs, and try to tie them to the code, itself. I write about my approach here.
Basically until you practice clarity, word choice, and active attention to writing (no spell check, no assists), communicating anything of complexity becomes a planning exercise. How much will it take to convey this information in text? Would a picture work better? A graph to support?
I've made a nice living "translating" from Subject Matter Expert (A/C/E, SaaS, Wall St) into business language for RFPs. 9 times out of 10 a person can talk out a story to me just fine - meanwhile they've stalled writing anything for 3 days past the deadline so it's just making my life more difficult. It's obvious people hate writing in the business realm.
Why? Because once it's written down there's a paper trail and accountability. That scares people who want to use language in shady ways. Hence the phone call after your email to talk about what you just mentioned but not by using the Reply button. Sooooooo predictable....
It's a leadership and project management failure. What should be done is gates where your shit never goes live unless you have it fully documented.
I can keep docs for myslef in almost any way;) but docs maintened by a team need something easy to use. Plus on-premise storage because of security and privacy..