My early induction into the world of computer programming was with Smalltalk (after the obligatory courses in LISP and Fortran at the University). I also remember a brief period I spent with Forth. Those were early days (for me).
The real world of making a living as a professional programmer demanded different programming discipline (my first paying job was coding COBOL in 1990; later, I progressed to Java). Back then, the prevailing sentiment was that real pros know how to write code on paper. Only amateurs/dilettantes need to check if their code works correctly every time they make a change to it.
Today I find myself completely flipping that sentiment on its head, and replacing the arrogant, foolish confidence of youth with the humility of mature age. Experience teaches us many things; most important of all is to be humble.
Proceed gingerly
I’m noticing how all prominent software engineers who I follow and learn from tend to write code in micro snippets. They tread lightly, and never seem brash, despite decades of their hard-earned experience in the field. They always make minimal changes to the code and then rush to check if everything still works. Experienced software engineers cherish steady state, and are hell bent on keeping their system running at all times (Ron Jeffreys famously said “The trick is to never let the code not be working”).
That approach is the exact opposite of the approach I was practicing 20 years ago. I remember spending hours making changes to the code without stopping, not even once, to check if the code I changed would compile, if it would build, if it would run, and if it would it produce the expected results. I was too confident at that time and convinced that I know exactly what I’m doing.
Of course, I was dead wrong, and now when I look back at the code I wrote many moons ago, I cringe in embarrassment.
So after learning my lesson the hard way, I now prefer to proceed gingerly. I like to write code in short bursts of micro changes. Maybe change one line and then immediately run everything to see if it still works correctly. In short, I now write code interactively.
What does it mean to write code interactively?
The technology we are presently using to develop software is called code-as-text. We write instructions to the computers using text, an approach that is meant for producing processing logic that is (hopefully) readable by other humans. But computers do not understand text, and they need code-as-text to be translated into binary instructions. That translation is typically provided by compilers/interpreters.
Now, the problem with this approach is that, since computers don’t understand text, they have no opinion about the text we write as a set of instructions for them. Computers take that code-as-text and then attempt to execute it. If the first pass is successful (i.e. code-as-text compiles into code as binary machine instructions) the computer will take it and blindly run it. If it encounters something wrong, or not-executable, the machine will merrily crash (or hang, or freeze).
So we see that it gets fairly easy to author many bugs and defects, because computers never push back on any meaningless instructions. Code-as-text is the culprit here, and it needs to be fixed.
In the early days, we were using plain text editors to write computer programs (vi, for example). Those editors did not speak programming languages, so it was up to us to ensure proper syntax and semantics of the code we were writing.
Enter IDEs. Sophisticated tools, such as Visual Studio and VS Code are a far cry from those primitive text editors from the past. Today IDEs speak many programming languages. Many of those IDEs are extremely opinionated and will not let us type incorrect syntax.
That level of sophistication is extremely beneficial, as it is getting us much closer to the ideal – full blown interactive programming in real time.
When writing code, it is extremely important to get the feedback as soon as possible. Waiting for the feedback only after we write many lines of code and then wait for it to compile, build, deploy, run, is truly unproductive. Thanks to today’s advanced technology, we get an almost immediate feedback in our code editor regarding not only the correctness of our syntax, but also regarding the quality of our code as well as the security.
It is therefore important to embrace this new age of interactive programming and take full advantage of all the sophisticated tools we enjoy today – VS Code extended by SonarQube, ReSharper, WhiteSource Advise, and many other useful commodities. Doing that ensures we’ll cut down on bugs and defects while improving the changeability of our code (i.e. lowering the cost of change).
Top comments (0)