Perhaps the most misunderstood idea about programming, I think, is that writing code has nothing to do with art. Introductory courses or books to programming, while challenging to the point that as much as half of students quit halfway through, never teach coding to be a writing discipline, which is a shame, given that one spends a lot of time doing actual writing. In the end, good programs are ones that not only run fast and make only necessary operations, but they are legible as well.
Quadruple-nested-for-loops or promise hells for example, while sometimes necessary, will never be called pretty programs, no matter how hard one so desires this. But there are ways around such disaster writing, such as serial for’s or larger promises. The choice to use these code structures though, is decision-making that comes from writing. Not from engineering.
This is why beginner programmers tend to make such mistakes and continue to make them in their professional lives later on. No one is a born writer, and writing takes time and plenty of editing. Syntax, class/prototype functions and variables are equivalent to well defined verbs, commas, semicolons, etc., because you don’t need to use them. But doing so, will improve the written product.
What’s good code then? Regardless of genre, narratives are told in a small numbers of constructs that require variety. Garbled sentences, repetitive sentence structure and ambiguous word choice make the writing unbearable, while complex structure, unique words, and a variety of syllable and sentence length, word order and unpredictable use of case save readers from stabbing their eyes out. The same goes for code.
What’s concerning though, is that many programmers slope off on their learning as they move on in their careers, which is a real shame. Most artists develop their best work up to ten years after they started working in their medium. Given the amount of keywords and the plethora of standard library functions, a similar thing should be said about writing code, as each of these keywords can be used in a variety of ways that constitute either good or bad writing. Note, that this cannot be said about software architecture, or project management.
Where programming becomes very interesting though, is at the point where a project becomes large enough that the thought of good writing is buried under the numerous functional aspects of the code. In this case, geeks that wallowed in fantasy worlds such as Middle Earth, Harry Potter, Star Wars or the massive world of the Song of Ice and Fire series, have unknowingly practiced their skills of “keeping track” of multiple threads of storytelling and events, which is a much needed skill in when programming large code bases.
Why do I mention this? I mention this, because learning about Middle Earth is enjoyable because the writing used to create these worlds was written artfully and not for pure world-building per se. To keep developers interested in any given large project, the thinking goes, the quality of code needs to be high, which is why code reviews, even for people with multiple years of experience, can be beneficial.
There are many solutions in writing and programming, some which are complicated but necessary, others more convoluted but sophisticated. In math, a similar discipline to programming in the grand scheme of things, many new, more straightforward proofs, are discovered due to developments in other areas of mathematics. That is why developers ought to keep track of new frameworks or programming languages which can tackle emerging issues.
If one can express the same thing in fewer lines of writing, proof or code, the better the end result will be. Instead of developers torturing themselves through obscure classes or functions, it makes more sense to get a marginal training in creative writing, so that the written code is read with a sense of wonder instead of dread.
This is why there are a significant number of books out there on code quality and coding styles: The more we know about the different ways to write, the better our writing will become. Only like this, can overwhelming code bases be maintained without switching out developers every few months, or having to invest more time and money in understanding code no one from the bottom of their hearts wants to read.