Why is writing one of the most important skills as a software engineer?

Coding well and writing well are remarkably similar processes. They both involve drafting, revising, making things more clear and yet more concise, and tearing whole sections (or even the whole thing) up and starting again in order to get it right. The best programmers and the best writers practice this repeatedly until eventually their first drafts are instinctively very close to their best work, and yet they also have their work reviewed by team leaders or editors, and understand that the goal of getting others involved is to make it even closer to perfect.

But beyond that, writing specifications (or nowadays stories) that are complete, concise, and understandable by others — and not only just other programmers, is an important skill. You may be an excellent coder, but if you don’t have this additional skill, you can probably not be given team leadership roles.

And then there’s the matter of patent applications. They are hard to read, and even harder to write, and software engineers generally don’t write them themselves, but in many organizations they are an important element of the job. The engineers need to write descriptions of the work at a detailed level with as little ambiguity as possible, and do it in a way that the attorneys can understand so that they can translate it into the highly-structured format of patent claims. I actually encouraged engineers who worked for me to study applications because, just like software, they use abstractions to define the work at increasing levels of specificity, often including alternatives that could have been built but aren’t actually part of the work. I don’t, however, encourage engineers to write that way. We should leave that to the lawyers.