That's a strange take. Do you mean that you would rather call external binaries directly, like Bash does, or that you would rather re-implement all functionality you need, however complex?
To me, there is value in the process and craft. It started as a one year challenge to use only stdlib in all projects, for work and personal code, and became a way of life. Though it may not work for everyone, or all languages, or all skillsets, it was a revealing experience.
In retrospect, it made sense given that in my community we make our own furniture, instruments, tools, foods from whole items. Code seemed like the next logical step. During travels, once there was a man who had a word in his language for this. He said it was an aphorism loosely translatable to "the beauty of struggle". As he explained it, this is the positive benefit gained in return for the time and effort to do something as an act of appreciation of the craft, and how the value in the experience surpasses the debt of time and sweat.
To put it in a more modern and eastern philosphical context, think of it like Kata.
I too suffer from obessively overcoming challenges. I will say this, in a snarky and friendly way. I hope you understand.
If developing with high level abstractions wasn't challenging enough, your vision was too small. Surely you can think of a problem to solve that even Copilot would be of little use.
Imagine what you could build if you got a little more help from third party libs and a little more ambition?
I appreciate you for relating your experience. It's not ambition or challenge that is lacking, we are what's commonly called 'Amish'. This is just how we do things.
I'm sure this creates more questions than it answers, however, I hope it lends some context as to how we've both arrived at our own respective happy milieus.
Having done enterprise java for so long, I strive to be as reductionist and minimalist as I can be in order to avoid dependencies outside the JDK.
Vying for "you aren't going to need it", trying to keep things as simple as I can.
But it also comes down to not overcomplicating stuff we've already written.
Obviously there's an urge to reuse your own libraries, but you have to strive to not overcomplicate them as they're applied to new use cases as you drive the peg in to a rounder hole.
It's very easy to FactoryFactoryFactory in Java, but flexibility and configurability leads to complexity and black hole of combinatorial testing.
Almost better to fork the earlier library and hammer it to fit the new space without regard to its old use in the other system. But that leads to file replication (notably files of the same name doing subtly different things). And there it's a challenge to go "gee which one should I use" when you're working on version 3, when what should be happening is "pick the best one" and keep hammering.
We used to have our general purpose "catch all" library which, in the end, indeed, "caught all". "Oh look, somehow I have jars from Clojure, Groovy and Scala, when all I wanted was a URL Builder."
