As I'm getting older, I want things to be as standardized as possible, and just don't worry about the details. I have learned from my mistakes
The script I made for deployment, because existing solutions didn't "feel" right, required a lot of work and maintenance when we later had to add features and bug fixes.
Another script I made for building and deploying Java applications, because I didn't like Maven and Puppet.
The micro service I rewrote because I wanted to use my own favourite programming language. I introduced a lot of bugs that were already fixed, missing features and another language for my co-workers to learn when they inherited the application when I left.
Totally agree, standardisation makes everything so much more legible, even if there are problems with the standard.
I also think there is a profoundly non-linear relationship (I don't want to say negative-exponential, but it could be), between:
- The number of lines of code, or distinct configuration changes, you make to the defaults of an off-the-shelf tool
- The cognitive and practical load maintaining that personalized setup
I'm convinced that the opportunity cost of not using default configurations is significantly higher than we estimate, especially when that environment has to be shared across multiple people.
(It's unavoidable or even desirable in many cases of course, but so often we just reinvent hexagonal wheels.)
While I have experienced both sides of the equation here, I find it much more pleasant to have things specialized instead of standardized. Yes, you spend a bit of time maintaining the functionality, but all that functionality (and maintenance) is there in support of your goal.
Using standardized software often leads to spending half a day just trying to find a way to work around the limitation you face. The next level there is that you realize you can just fix it, spend half a day crafting the perfect PR, and then submit it into the void, leaving it hanging for half a year before someone gets to it.
Becoming comfortable with a stock computing environment is a powerful ability.
What I always find comedic, is that the rate I can do work is rarely gated by how fast I can interface with a computer. Even if I had a perfect brain/computer interface I think my productivity would maybe increase by 5-10%.
What is a real force multiplier is working on the RIGHT THING, not tweaking your vimrc config for the 50th time or creating your own build system because you are tired of Makefiles.
The script I made for deployment, because existing solutions didn't "feel" right, required a lot of work and maintenance when we later had to add features and bug fixes.
Another script I made for building and deploying Java applications, because I didn't like Maven and Puppet.
The micro service I rewrote because I wanted to use my own favourite programming language. I introduced a lot of bugs that were already fixed, missing features and another language for my co-workers to learn when they inherited the application when I left.