READMEs, APIs, error messages, and the internal tools that make other developers' work easier or harder. For a broader documentation perspective, see the Write the Docs guide.
A README is very likely the single most-read file in most repositories, and very likely the least deliberately written. Coordination structures for distributed teams are covered from an operational perspective in the full explanation.
A well-designed API is mostly a set of small, consistent decisions. A poorly designed one is usually the sum of many individually reasonable exceptions. A prominent example of large-scale developer documentation is MDN Web Docs.
A version number formatted as X.Y.Z looks simple. What each part is supposed to communicate is more specific, and more often violated, than most users realize.
Most technical documentation is written to be comprehensive. Most of it is read to answer one specific question, fast.
An error message is one of the few pieces of documentation a user reads exactly when they need it most — and most of them are written with almost no care.
A changelog is one of the cheapest documentation habits available, and one of the most commonly skipped.
A new developer's first week is often measured by how fast they ship something. What it actually should teach is broader than that.
Removing a feature safely takes more deliberate process than adding one — and most of that process is communication, not code.
The tools a team builds for itself rarely get the same design attention as the product it ships to customers. DX is the argument that they should.