For as long as I can remember, programming has been pushed as a largely mathematical and STEM-based activity. To be good at programming, you not only had to be good at maths, you also had to have a solid educational background in maths and science.
It is a viewpoint that we have pushed heavily as an industry, encouraging young people who are considering a career in computing to focus almost exclusively on STEM subjects before their jump to university. It is a viewpoint so ingrained in our minds that we peddle it around as a fact, and without question.
But as the world cries out for more software engineers and industry has begun filling the shortfall by reaching out to people from diverse backgrounds, it is time to question the hegemony of maths over computing. Maths is undeniably important and necessary, but there is another skill that is absolutely essential when it comes to programming well, and that is English. Especially written English.
To put it another way, based on nearly 30 years of first hand experience coding, mentoring and teaching commercially, I have witnessed an almost one-to-one correlation between those who can write well and those who can code well. And inversely, between those who cannot write well and those who cannot code well.
This connection between maths and programming is of course deeply historical. Programming can trace its whole lineage right back through mathematical thinking and mathematical needs. When it comes to number crunching and evaluating numbers, nothing does it like software.
The connection runs so deep that programming is often shrouded in mathematical terms: pure functions, lambdas, closures, boolean logic, and so on. But there again, not all programming is maths, and certainly not today when software dominates every facet of life. If anything, most programming is less about maths and is more about communicating complex steps and flows in ways that make your software easier to work with.
Great programs communicate their intent clearly, and communicating intent is largely a linguistic skill. It may be bound by the syntax of your programming language - the syntax will constrain the ease with which you can say things - but the ability to communicate ideas through (for example) intentional revealing names and cohesive structures is a linguistic skill nonetheless.
Communicating intent requires 2 things: a programming language with a syntax that allows ideas to be expressed in ways that can be easily understood, and a powerful grasp of the written word so that you can actually express those ideas clearly.
It all starts with structure. Structure and decomposition. Without them, words become lost on the page, their meaning obscured by the lack of surrounding space. So, as a first step, we break things down into smaller, more manageable chunks. Each chunk serves a purpose: to communicate an idea or collection of cohesive ideas.
We decompose our writing so that it's easier to work with. And we decompose our software for the same reason. The process and rationale are the same.
Every chapter in a book, every paragraph on a page, every sentence exists purely to provide structure to writing. Similarly, every namespace, every class and every method serves the same purpose in our software. That is, to make our lives easier.
Structure and decomposition are key to making things understandable. They transcend maths and writing. Breaking a problem down is a general problem solving technique, but it is a technique that is absolutely core to programming. And writing for that matter.
Whether you agree or not, there is another skill that is indisputably part of the creative process, and that is empathy. Simply put, writing and coding require huge amounts of empathy and putting yourself in someone else's shoes.
If you care about the reader, you will care deeply about how you communicate and structure your thoughts for their benefit. Building user interfaces, creating APIs, defining method contracts, naming variables, etc, all require that you think long and hard about the users of your software. And not just your users, but the future developers who will also work on your code. In this regard, writing and coding are virtually indistinguishable.
The bottom line is, writers and programmers are problem solvers. They build narratives, and creating a decent narrative requires planning, thought, insight, and (yes) empathy. Okay, certain styles of writing come more from the heart than the head, and writers may deliberately confuse and obsfuscate to keep the intrigue or spark an emotion, but ultimately writers and coders share one thing in common - they are telling a story, albeit in a very different context, and in doing so they are tapping into a completely different part of the brain than we use for mathematical processing.
But writing is much more than just structure and decomposition - it is fundamentally about the words we use and how we use them. Programming is no different and although programs may work within a tighter set of rules than written English, the value of words, names and metaphors is no less important. Words matter.
By introducing consistent and revealing names and metaphors, we reduce the cognitive load on the reader and on ourselves. Good names allow us to maintain intellectual control over our code base. Write for other people not the compiler, and all that.
The thing is, naming is hard. But good naming requires a solid command of language, and specifically of English since that is what most programs are written in. It's back to my original point about the correlation between people who write and who code well. If you don't communicate well through writing, then chances are, you will probably not communicate well through your code.
The final point about the importance of writing is that a programmer's job is much more than just coding. It is also about communicating, almost constantly, across many different mediums and channels.
Every email we send to state our case, every proposal we write to win new business, every requirement we add to the backlog, every message we push onto an IM channel, each requires a command of the written word that cannot be understated.
Writing is everywhere, and being able to write well is an essential part of being a software developer.