In a recent article, David Haney asks if we have forgotten how to program. I think not, rather we evolved.
We evolved from writing technical not so useful code to writing specifications.
Don’t misunderstand, when I am talking about specifications, I am talking about code. I am talking about coding crystal clear specifications even a computer can understand.
How can we write “good” code?
Good code has two characteristics: it is useful for the business and usable for the developers. (usable in the meaning of Alexandru Bolboaca and Johan Martinsson , for more information please refer to Alexandru’s book currently in writing, or Johan’s blog).
To write useful code, we need continuous domain knowledge crunching and refining. We want to avoid technical stuff producing no direct value for the business.
To write usable code, we want to write code with clear abstractions, and easy navigate around these abstractions. We also want to replace/modify some code without pain.
From a business point of view, unless they are in a really specific context, they don’t need to know how to pad left. They don’t need to explain it either, because it’s obvious.
From a programmer’s perspective, we also rarely navigate in such an obvious low level of abstraction.
Rewrite everything?
In most modern languages, these obvious and technically common operations are part of the core framework. Even if we know how to code them, even if it is quick to code, we don’t want to, because it creates no value for the business, and no usability for the developers. It does not make our code better.
It’s dangerous to say « We should not depend on other libraries, we should rewrite what we need! » Where do we put the bar for « rewriting? » Should we stop using NPM? JQuery? What about .NET and Java? 
It’s not the user’s fault, it’s the design’s fault.
That’s a core rule from UX translated to usable software design. We should always keep it in mind when trying to understand a problem.
The lesson from this “left pad” story is not that we should re-write everything to depend on nothing, but that NPM’s design allows a library to be deleted, or worse, to be changed.
Imagine if Microsoft decides to change the behaviour of something widely used like String.Concat ? (or String.PadLeft if you lack imagination)
Asking every .NET developer to write these themselves is not the solution, even if writing a concatenation function is easy.
It’s unsustainable, a whole ecosystem cannot be built on an unstable foundation. If we want an ecosystem to evolve, we need a rock solid foundation.
This story shows how immutability is fundamental when thousands of users are depending on us.
This kind of dependency, when hiding obvious stuff, is not necessarily bad. It’s more like solid roots allowing us to grow up.
Dependency: the good, the bad and the ugly
The difference between bad dependencies (big frameworks) and good dependencies (little libraries) may be tricky. The key is: if the hidden part seems obvious to us and adds no value to our business, then it’s a good dependency. Otherwise we should prefer to rewrite it in complex contexts, because we will quickly be limited by what we don’t understand in our framework anyway.
This story should teach us that building an ecosystem is hard, and requires immutable, solid foundations. Please don’t re-write everything.
Let’s evolve together.
As usual, thanks to my kind reviewers: Brian Gibson, Jean Helou and Jérôme Avoustin