Overall
I enjoyed this as advice from a senior at least ten intakes ahead of me. It was written quite a while ago, and the first thing that struck me was how different the era’s view of coding is from today’s. In a present where Web 3.0 is the topic, the book carries the air of a time that was sceptical even of Web 2.0. It would have been hard back then to predict the changes AI would bring.
Today an LLM proposes astonishing code fitted precisely to the situation even from abstract requirements, and developers often copy and paste it straight into the codebase without adequately understanding its deeper meaning or how it works.
The author’s warning about “code you typed with your own hands that you yourself, of all people, do not understand” goes beyond simply not knowing what the code says. The message was that you must also understand the impact of adding or modifying that code, and how it connects to everything else. Closing the book, I find myself asking: do we properly understand even the single line of code in our hands right now?
Affection for development came through the author’s writing, along with a sincere wish to pass that affection on to those who come after. It made me revisit the attitude, the pride, and the professional ethic a developer should hold.
Above all, I resolve to think harder in order to write code that stirs the imagination and that anyone could relate to.
Notes
The more imaginative the programmer, the more finely they think about the relationships between objects. They define an object’s role and character precisely, pull design patterns out of memory, and pay deep attention to the relationships the objects form.
The programmer’s fingers, racing across the keyboard, suddenly stop. He takes a sip of coffee and stares into space for a moment. One hand holds the cup, the other still rests on the keyboard. And quietly, logical reasoning raises its head in his mind.
Think about it for a moment. Of the eight hours we spend doing our jobs at a company, how much of that is really “work”?
By [Sascha Lobo and Holm Friebe]’s argument, the reason I cannot concentrate properly on my work, whether at home or at the office, is … not the environment but that the work I am doing is ultimately not “my” work.
The boundary between work and play in the digital age
… it is as clear a fact as the reality that most of what we learn at school turns out to be of little practical use. … The amount I newly learn about the Java programming language that I use for my job will not exceed what I learn from the Javasoft website or the newsletter Heinz Kabutz sends out.
Designing precise objects, writing the best algorithm, hunting a bug late into the night — programming is, at many moments, hard to distinguish from “play”. It is hard to put into words, but there is unmistakably a great deal of play in the act of programming.
If something is making life hard for you as a programmer … that something is never programming itself.
Computer graphics as a hobby
Just as Stone Age humans drew a magnificent bull on a cave wall with a charred stick instead of paint, computer users confined by the era’s limit of text mode expressed their dreams by arranging 128 characters. Their imagination had no limits at all.
Some thoughts on SOA (service-oriented architecture)
If I look at it and can understand nothing and feel nothing, then the painting is not a sophisticated abstraction faithful to modern technique — it is simply rubbish.
The age of the mashup
Because the problem is not the technology but the imagination that creates added value.
Metalanguages and the abstraction of programming
Picasso, who painted realistically in his youth, came gradually to paint abstractions with the detail stripped out, and that was probably because the level of abstraction in the images he imagined internally kept rising.
Look at code written by people whose skills have not yet matured and the algorithms are excessively literal and flat. Because they are preoccupied with implementing whatever logic is immediately needed, without regard for reusability, error checking, unit testing, or extensibility, the code contains no concise implication or direction. The code becomes tedious prose rather than a poetic description that stirs the imagination.
If you are a programmer writing dozens or hundreds of lines of code a day, take a moment to consider whether the program you write every day is prose or poetry.
A programmer should write poetry, not prose. Not long-winded prose confined to a particular context, but poetry that is elastic and easy to extend in meaning. If an if-else block is a prosaic element, then a factory pattern is a poetic one. If one hundred-line method is tedious prose, ten five-line methods are savoury verse. The programmer is a poet.
AOP (aspect-oriented programming)
The “inner type declaration” feature makes it possible to add new fields to an object dynamically. … I have doubts about whether such a feature is desirable.
AOP … provides a syntax for programmatically capturing particular parts of the program code — join points — that is, a way of defining metadata whose subject is the program source code itself.
The pleasure of unit testing
When you take on implementing a new feature, one of the important abilities a programmer must have is to picture the entire process in your head — thoroughly digesting the requirements, designing calmly, reviewing the design with others and revising what needs revising, writing the code, writing the unit tests, and refactoring parts of the existing code where necessary — and to estimate the time as close to reality as possible.
People for whom writing unit tests has become a habit feel uneasy writing naked code that is not dressed in unit tests.
The seven stages that make up programming
If engineering goes from the abstract to the concrete, then programming goes from the concrete to the abstract.
Object orientation, unit testing, refactoring, and a holistic grasp of software
The magic of object-oriented technique is that it enables an astonishing reversal: adding new features or code to existing software and yet having the system’s complexity decrease rather than increase, so that the programmer’s understanding of how the whole system works rises rather than falls.
Refactoring with no unit tests in place is worse than doing nothing at all. It is a more irresponsible attitude than a mathematician at a conference falling in love with themselves while advancing a proposition they cannot prove.
There are cases where code you typed in with your own hands is not understood by anyone — least of all by yourself.
Agile programming
When managing software, moving slowly but safely is preferable to moving fast. It goes without saying that agile is not a panacea applicable to every software project.
Defensive programming
More often than not, the more correct solution is to suppress the urge to insert an if-else block and create a new method or object instead.
Programmers produce bugs more often knowing a bug will arise than not knowing.
There is no project in the world where you are given 100% sufficient time to finish the code, carefully weigh the defensive principles, write unit tests, and revise the code bit by bit until you feel it is done, and only then submit it.
The principles of defensive programming must be applied instinctively in the moment you write a single line of code here and now; once that moment passes, there is never a chance to go back to that code.
Refunctoring, which takes the laughter out of code
Object orientation is like delicate surgery: done well it cures a serious illness, done badly it is apt to ruin the body. Twisting into complexity, in the name of object orientation, code that could be implemented simply in two lines and has nothing wrong with it, is not a wise attitude.
Happy programming
Just as a novelist does not write a novel to read alone, a programmer does not write a program to be read alone either.
Writing programs that read like a novel
Even among experienced, senior programmers, people mistake code readability for the surface appearance of code that can be unified through these “coding conventions”.
The better a programmer’s skills, the more often they feel the urge to write compressed, cryptic code; restraining that urge and focusing on writing restrained code that conveys meaning easily is the second essential of making “a program that reads like a novel”.