Coding is writing
Recently a friend asked what I do for a living. For the longest time I'd had difficulty answering this question. Somehow in that moment I realized we're similar to writers.
Libraries are similar to textbooks with numbered sections and a detailed index in the back. Functions are similar to paragraphs or text referenced by named and/or numbered sections. Instructions are similar to sentences or lines of text.
Professional programmers normally work together on the same pieces of text. Stitching many volumes of text together that reference one another. Professional programmers do both the authorship and editing.
As authors, we attempt to build something both the computer and readers can reasonably grasp in an economic timeframe. There being a clear emphasis on ensuring the instructions written match our original intent. Ambiguity cannot be deciphered by the computer. Instructions need to be conveniently understood by readers, but specific enough for the computer executing them. From the computer's perspective, there is no ambiguity, instructions must be exact.
During pull requests as reviewers, we work as editors. Ensuring correctness. Looking for ways to improve the work. Scanning to confirm text is malleable enough for future additions or modifications. Simple enough to understand. And finally confirming that the produced work matches its original intent. The ease of readability of the author's contribution determines how smoothly the pull request will be reviewed. The smaller the better. Code is written in units, not volumes.
Books are normally a single publication that are released and never structurally altered afterward. Programs differ in that we are constantly making alterations. Even years after the initial release. Partially because for a program to be written in a time effective manner, it must reference third-party libraries that contain blocks of existing text. Why write instructions twice, when they can be referenced.
Since externally referenced instructions must be updated to support new programs, older programs must also be updated for correct usage. Tangentially users demand addition, removal or modification of functionality.
All of these instructions create a large non-linear script. The computer reads the script with multiple cursors. Sometimes executing multiple blocks at the same time. Sometimes only one at a time. Using interrupts to change the active cursor. Single blocks of instructions can be repeated billions of times as the cursors jump back and forth to previously executed locations again and again.
Much of the difficulty in reading arises from the non-linear nature of the script. Depending on the instructions, programs will tell the reader, whether the computer or another programmer should jump to another portion of its instructions. Sometimes these instructions are in the same program or in another library entirely. Programmers call this type of non-linear execution "branching". The goal of the programmer is to make it easier for a reader to understand not only instructions, but references to instructions. Naming. They need to name their blocks of instructions well.
Programmers are authors. Writing primarily for each other. Ensuring that even with the non-linear nature and difficulty presented by code, we still have works that can be read. If not with enjoyment, then with the least pain possible.
Just as reading a difficult novel is exhausting, difficult code can be exhausting to understand.
Since writing consists of clarity of thought, planning and general skill it makes sense that major tech companies have shifted their interview practices to algorithm and data structure based questions. Organizations are looking for developers with the ability to think and communicate clearly. Preferably as fast as possible. Developer forums and news channels talk about the latest languages and frameworks, but many do not talk of the essential skill. Of being able to freeze and place your thoughts into code.