Another case of someone discovering, after 10+ years in tech, that code is a liability and you're supposed to solve problems instead of chasing trends and padding the resume.
Great that he's spreading the word!
Great that he's spreading the word!
Yeah I thought that until I had to look for a new job and my resume just had boring old technology on it. Now I make sure I do some padding!
― George Santayana
"I've got news for Mr. Santayana: we're doomed to repeat the past no matter what. That's what it is to be alive."
― Kurt Vonnegut
https://www.indy100.com/article/this-man-is-painting-penises...
What the original saying is about is pretty clear from the words "condemned" or "doomed" to repeat it (depending on the version). [0]
The saying is not about "reinventing the wheel" as in "refining/reinventing something already positive". It's trying to steer people away from major mistakes. Like ones that lead to great human tragedies and loss. Of course, everything can scale, it can affect an individual or the whole world.
[0] https://en.wikiquote.org/wiki/George_Santayana#Vol._I,_Reaso...
-- I have no idea who originally said this, and DuckDuckGo doesn't seem to be especially helpful in enlightening me on the origin of this particular corollary to Santayana's quote
You can deliver so much more, so much safer using other techniques...
The important part is not introducing an entirely new language that no one knows, or changing around the entire architecture without really being able to understand the long term consequences.
Also, after moving to C#, I don't know why anyone uses plain old Java anymore. C# runs on Linux now. It's not the 90s anymore. Oracle is the dinosaur and MS now is kind to its developers. Plus I'm hoping that client-side C# will take off with WebAssembly.
> I don't know why anyone uses plain old Java anymore
You see, if we refuse to change, we can't ever get better.
However if youre strongest in Java then you should probably do Java.
Java 8+ is okay. Lombok helps. There's other great, mature libraries around. There's a choice of IDEs. There's JREs to choose from - there's even JVMs to choose from. Gradle makes build files not suck and makes it easy to add static checking and linting to the build process. AFAIK, C# doesn't have auto-formatting options outside the IDE.
As much as I used to have your view, Java is alive, works fine, and makes money. Or Minecraft mods.
Not only Java vs C#, rather JVM and CLR languages.
Copiers, phone switches, IoT gateways, SIM cards, military control units, drones, Intel ME and a couple of phones.
And all of them have libraries that work across all JVM implementations, regardless of the OS, not the hit-and-miss that still happens between Framework and Core, without a good story how to go cross platform [1].
As for Oracle, they rescued Java while no one else cared [0], kept Maxime alive transforming it into Graal, made several improvements to the language, while allowing jars from 20 years ago to still run unmodified in modern generations of the runtime.
I use both platforms since their initial releases. Each of them has plus and minus.
[0] - Only IBM did an initial offer, that they withdrew afterwards.
[1] - Naturally there is Xamarin, but it isn't without its issues and doesn't run everywhere where Swing, SWT or OpenFX run.
As long as you like telemetry: https://github.com/dotnet/cli/issues/3093
It is a tool that can be used masterfully or utterly abused.
Every craftsman has to invest in their tools. And for someone to truly master their craft they must sometimes hone their tool skills speculatively, without short-term gain, and by sacrificing the time and attention used for other things, like actual projects.
If everyone just obeyed their project manager and always focused 100% on the problem at hand, we would be producing sad, boring things. If you want to see what that's like look at enterprise applications.
That's an unbalanced conclusion. Code can be a liability but it can also be an asset.
Do we have limited resources? Maybe writing new code can help. E.g. In cars, the electronic fuel injectors have computer code determining the optimal amount of gas to inject to minimize fuel usage. Fuel efficiency is improved over older "non-computer-code" carburetors. Computer code is an asset that's equivalent to discovering new proven oil reserves.
How about the limited resource of bandwidth on networks? Code and algorithms like h.264/h.265 that shrinks video enough to make it practical to stream to homes maximizes the existing network without having to lay a bunch of new fiber optic cables to every house.
And consider all these YC companies that aren't worth much today. How do they become more valuable? They need to write more code. New features that customers find valuable requires coding. Even if the startup's code does not have patents, it will still be part of the tech portfolio assets that the acquiring company will include in the purchase.
The "code is a liability" seems to be true if one limits their focus to negative situations like npm leftpad and the Boeing MCAS accidents. In contrast, I don't think the astronauts thought the Apollo Guidance Computer was a liability if it helps them get to the moon.
That's where those aphorisms come from. No code runs faster than no code! No code has fewer bugs than no code! No code is easier to understand than no code!
maybe that's why he said:
> Not only a liability, but a liability among other things.
It was my mistake then and I misinterpreted "among other things" to mean : "Code is not just a liability but it's a liability among the other things I just listed like limited resources and limited brainpower" instead of "Code is a liability among other things I won't say explicitly like code also being an asset".
Because I interepreted it the 1st way, I wanted to emphasize the opposite view: that limited brainpower is why code can be an asset to relieve humans from mundane boring calculations to redirect that precious brainpower to higher level creative thinking. Limited resources also motivates new code that can be an asset to expand those resources.
Craftsmen are experts at applying a limited set of tools. That’s why they’re craftsmen. You hire them because they’re the best at doing the thing you hire them to do.
A simple tool, like a hammer, is not volatile over time. The house that you build with your tools is. It will weaken and rot, and given enough time it will crumble. It takes care and maintenance to keep it safe to live in.
It is the same with code in production; at some point in time in the future, through no fault of your own, the code can become "wrong" as reality changes around it.
Code is also costly to maintain, sometimes even for small code bases. As the world changes, so must the code.
One of the definitions of "liability" in the Merriam-Webster dictionary [0] is "a feature of someone or something that creates difficulty for achieving success". This definition is often met by code.
A simple tool like a hammer is rarely treated like an asset as it is expensed up front.
Code can generate cash flow through its replication and exchange, or its application. Whether this is higher than its depreciation and maintenance costs determines whether you’re losing money on it.
The above is an analogy of course, In actual financial accounting we typically see only see code or “knowledge capital” on the books after acquiring another company, usually as a fat chunk of “goodwill”.
You could almost call it "something (such as an instrument or apparatus) used in performing an operation."[0]
Definition 1C in the link you provided lists "a means to an end" as a definition of a tool, which I explicitly mentioned code was.
So I must concur, code is a tool. But I'm adamant that it is also a liability.
Code is the result of that tool. If you use a tool to build something you're constantly repairing/maintaining, then its a liability.
What was missing in the gp comment is that code is also an asset. The goal is to have the value of the asset greater than the liability. This ratio changes over time given a multitude of factors like problem domain and how well the original code was written.
For a long time, my bias was to write code when faced with a problem, without realizing the debt I was taking on and the other solutions available.
https://www.nemil.com/on-software-engineering/dont-write-cod...
If you think that is an argument against enterprise, you might want to take another look. I spent the early part of my career in enterprise, then moved to startups that serve government customers. Every app I have ever written is boring. I've been working on one boring app for most of the last 7 years. 7-figure ARR, and acquired, but boring.
Yet I consider my career, and those apps, to be great successes.
~ Dijkstra (1988) "On the cruelty of really teaching computing science" (EWD1036).
They are totally regional, programming-language subculture, and age related
The proponents of Atom/VSCode/Sublime/VIM etc will swear by it to the level of gatekeeping other competent software engineers away from them if they don't use that particular editor, and they all do - or can do - the same thing.