This article makes an explicit assumption: that code that is easy for you to read at a glance is inherently "good". The article then makes weird quasi-moral judgements like, maybe if you are a single person writing difficult-to-read code then "maybe you just don't need to write good code". Code that is optimized to be easy to read often has lots of duplication and very little abstraction.
This is even a well-understood tradeoff, and is why people working as cogs in massive organizations are often expected to code in languages like Java, Go, or C, which all purposefully offer very little in the way of abstraction, so the code is somehow more "obvious" and easier to read by whomever comes into the codebase next and needs to rapidly make some kind of change without breaking stuff.
The problem is... this is actually really shit code. The more duplication you have and the less abstraction you have leads to way more places for bugs to creep in. Yes: having the weird unified mechanism that no one is used to to handle memory management or authentication might seem a bit annoying when you sit down to someone else's code, as they are effectively using a bespoke framework.
But, let's reframe that: they are using a "framework"! And it probably has some kind of internal logic, and was likely designed for a reason to solve a real problem! If you take a few moments to orient yourself in the codebase, rather than assuming "I don't understand this so I guess it is bad code" you might come to understand it and then appreciate the work that went into the abstraction.
The alternative to this is frankly code that I enjoy, as I'm a security engineer looking for bugs: I'm going to look for things that are duplicated for bugs that were fixed in one place but not the other or for correct--yet somehow slightly different--behaviors which lead to parser differential vulnerabilities; even just boilerplate: the chance you got it right everywhere is about 0.
>Code that is optimized to be easy to read often has lots of duplication and very little abstraction.
Absolutely wrong and people need to stop pushing this narrative or put their money where their mouth is and use assembly. The people repeatedly saying this have probably experienced bad abstractions and gross OOP spaghetti code and improperly generalized this to "DRY bad, abstractions bad".
It’s much easier to sit down and start typing. And it’s somewhat easy to read that code and know what it does, line by line.
Abstractions inherently push away the details that enable this kind of lower level understanding. They have baked in assumptions that may or may not be explicitly documented.
Good abstractions provide leverage, but they are mini languages. They have their own vocabulary, their own execution model, extension mechanism and so on.
Good abstractions are clear and well factored pieces, but that doesn’t mean they are or should be easy to read without making an effort to understand their meaning. That’s not necessarily what abstractions are about.
That’s why tutorials and guides are so important. People need examples to ease into a new vocabulary and mental model.
Assembly (and JVM bytecode, WASM etc.) is very easy to read and understand. You learn these languages in what, an hour and a half?
But their vocabulary speaks about things you don’t necessarily care about when writing a web app or an ETL pipeline. People use abstractions to express something in a particular mental model or domain. Only in specific cases that means it’s optimized for ease.
It's not even well understood what abstractions are, in the first place. It usually ends bad when one starts with the premise of "I must abstract this, I must generalize this" etc. Most "abstractions" are terribly leaky.
I find it much more helpful to approach it like "This is what needs to happen, now how do I split this into different parts in a way that minimizes the interactions?".
I like how A Philosophy of Software Design discusses this issue you described:
> An abstraction that omits important details is a false abstraction: it might appear simple, but in reality it isn’t. The key to designing abstractions is to understand what is important, and to look for designs that minimize the amount of information that is important.
> Code that is optimized to be easy to read often has lots of duplication and very little abstraction.
I would disagree. I dont think you understand abstraction which is what Object Orientated Programming addresses. A class written once, deployed many times, which can include things like screen control resizing rules, or classes which handle reading and writing to disk or other things like that.
A class is a classic form of abstraction and thus can easily be read.
What I have not seen mentioned once in these discussions, is different coding styles.
I've seen UI design documentation but I've never seen coding framework's apart from Hungarian Notation in windows [1] but things like variable name formats, whether the code should be in classes, Routines, or Procedures.
Having worked on a number of different projects, I've worked on source written by single/sole dev's and I've worked on source written by multiple dev's from all around the world.
They all have their different styles of programming, they all have their quirks, their eccentricities and the current batch of programming tools including visual studio enables these differences which make debugging or securing code more difficult.
I dont think many managers or bosses understand programming either which is why the coding style is not something thats been mentioned. Even teams using tools like Github where there is discussion taking place with the code will force a group style onto the code.
This is even a well-understood tradeoff, and is why people working as cogs in massive organizations are often expected to code in languages like Java, Go, or C, which all purposefully offer very little in the way of abstraction, so the code is somehow more "obvious" and easier to read by whomever comes into the codebase next and needs to rapidly make some kind of change without breaking stuff.
The problem is... this is actually really shit code. The more duplication you have and the less abstraction you have leads to way more places for bugs to creep in. Yes: having the weird unified mechanism that no one is used to to handle memory management or authentication might seem a bit annoying when you sit down to someone else's code, as they are effectively using a bespoke framework.
But, let's reframe that: they are using a "framework"! And it probably has some kind of internal logic, and was likely designed for a reason to solve a real problem! If you take a few moments to orient yourself in the codebase, rather than assuming "I don't understand this so I guess it is bad code" you might come to understand it and then appreciate the work that went into the abstraction.
The alternative to this is frankly code that I enjoy, as I'm a security engineer looking for bugs: I'm going to look for things that are duplicated for bugs that were fixed in one place but not the other or for correct--yet somehow slightly different--behaviors which lead to parser differential vulnerabilities; even just boilerplate: the chance you got it right everywhere is about 0.