Documentation gets treated as the last thing you do: the chore that happens after the code works, if it happens at all. It is the task teams postpone, the sprint item that never quite gets a slot. I think that instinct has it exactly backwards. Docs are not the tax you pay at the end. They are the best design tool most projects never use.
The oldest and clearest statement of this idea is Tom Preston-Werner's Readme Driven Development, a blog post he wrote in 2010 while at GitHub. His argument was blunt: write the README first, before the first line of implementation. Not as a summary of what you built, but as a specification of what you intend to build. The README becomes the design document, the thing you work back from, and the definition of done is code that matches it. A decade and a half later this still works, because it forces the hard questions to the front. What is the name of this thing? What does it do? What does it not do? How does someone actually run it?
The payoff is not the prose. It is the thinking. When you have to describe an interface before you build it, you find the awkward gaps early, the arguments that do not pull their weight, the features that sounded good in your head and die on the page. The effort you spend writing is not lost time; it is the cheapest prototype you will ever build, because it fails in minutes instead of weeks.
There is also a selfish reason that has nothing to do with design. Every project eventually meets its own documentation deficit, at 2am, six months after you last touched the code, when you are the one who has to figure out how it works. Code is not self-documenting, no matter how often we repeat that it is. The reader you are writing for is future you, and future you is not nearly as patient as you assume.
The pushback is usually the same. Writing docs before the code is slower, feels premature, and the API will change anyway. It will change. That is the point. When the README is the spec, a change to the interface is visible as a change to the contract, and the code naturally has to catch up to the written word rather than the other way around. Projects like Stripe's developer documentation earned a reputation that became a selling point; teams choose tools partly because they are documented well. Documentation is not busywork. It is the most reliable way to make an idea usable, and usable is what turns code into something other people can adopt.