This. And then nearly equal in importance (or maybe more depending on your position), speaking. If you can code well, write clearly, and cogently argue your case without being a jerk about it, you will do well in the software business. Join toastmasters for at least a year.

You make money by being able to do things other people can't do, or won't do. Most programmers won't or can't learn to do these well, so those that do get a very big leg up. When execs and owners try to figure out who should become dev leads, managers, CTOs, etc, they will be looking for these skills in addition to technical chops.

'Speaking' has my vote over 'Writing'. If something is not clear then people turn to 'talking'

I agree on the order of importance, to be honest. But being able to write well really helps one's speaking too.

A shame to see this downvoted. I presume its because of the "Very few people are capable of this" bit?

I can't stress this point enough. Learn to write product plans. Documentation that delights people being onboarded to new systems is always appreciated, often by yourself months -- or years -- later. Well written bug reports, feature request, and such can easily cut developer turn-around time in half.

And to add one more thing: humility. Be the type of person nobody >needs< to listen to because they can so clearly follow you by example.

This a very important skill, especially for lead devs.

To people downvoting this, think back when you were last annoyed by bad or even missing documentation. I bet this was very recently, if not today.

Any recommendations on resources to learn/improve this skill?

I completely agree with you but it seems pretty hard to hone that skill if there's no one to give you feedback.

e.g. you write some internal docs but then no one lets you know how could they be more useful/understandable, until someone else comes and re-writes the docs.

Read. Read a lot. Look for successful documents and emulate their patterns. First, understand what the author was trying to accomplish with the doc, then study the structure of the doc, then dig into the language choices. But, if I had to pick one thing to study, it would be structure. I frequently read tech docs that come off as a stream of consciousness. You have to understand your audience and put the effort in to give them context (the problem, the requirements, the methodology) before giving them the solution.

Also write. Write a lot. And ask for help. If you work with/know someone who is considered a good tech writer, I bet they will help you.

Also learn how to diagram and do quick mock-ups. Visuals can help bridge the gap between what you can articulate and what the reader needs to develop a good mental model of the proposal.

[this comment is coming from someone who writes mostly technical design documents needing to communicate a technical solution to a problem while also considering multiple alternatives]

Read the book On Writing Well by William Zinsser.

Do some teaching / tutoring. You will get useful feedback by observing whether your students understand your explanations.

Thanks for the ideas!

this.

write a blog post about stupid pointless problems you solved. and make that blog post useful for anyone who came accross that problem.

It is useless. But it is good practice for you, because being able to write technical documents that are easy to follow is highly valuable.

Oh and get everyone you know to criticize it like a code review :)