This is my experience as well. In my larval hacker days in the '90s, when my primary pastime was messing around with my Linux box all day long, I thoroughly enjoyed sifting through window manager and shell man pages to find each and every thing that could be configured, and I'd then proceed to configure each and every one of them to exactly what I wanted. My fvwm/bash/etc. config files from those days could probably be considered a form of outsider art by someone.
A common pattern in mailing lists/forums/etc. is the "just make it an option" guy. People are talking about their wishlists for future versions of <Gimp/emacs/Xorg/LibreOffice/whatever>, and sometimes these wishlists conflict. One group says a UI should be one way, another group says it should be some other mutually exclusive way, and a third group thinks the developers should implement both and just make it an option in a dotfile to make everyone happy.
Sometimes "just make it an option" guy is right, but in hindsight it should never be the default resolution to the disagreement. In those days I defaulted to "just make it an option", and really internalized that philosophy because it felt like all benefit and no cost. Why wouldn't you make everyone happy, if you could do that instead of making one group happy at the expense of another group? I think it's a really common trap people fall into early on because they have yet to directly perceive the costs that that approach can incur over time in software development. Sometimes they've also tricked themselves into overvaluing their workflows and muscle memory, which they may have defined in part because it was easier for them to define their own keybindings than memorize what the default ones were, which I now think is an antipattern in itself.
The main thing that changed for me is spending the intervening decades doing work on multiple machines all the time, running different versions of different OSes, often times starting from fresh installs. That made it more pragmatic to always learn software in its default config, and only tweak configs if it's absolutely necessary or otherwise pretty important to me. It's also forced me to learn all sorts of useful stuff that I probably wouldn't have otherwise. It also drove home just how much my desire to tweak configs was just because it was fun for me (and I had lots more free time back then), rather than something that made me more effective as an engineer.
But that's just from a user perspective. From a developer perspective, having "just make it an option" be the default form of conflict resolution leads to all sorts of unanticipated complications in practice. Every time an alternative code path is added for something, the code becomes a teensy bit more fragile and likely accrues a teensy bit of technical debt. The fragility and technical debt accrues over the years, and eventually can turn even the best software into an unmaintainable mess. I'm not dogmatic about it- some things should be options. It's just never my default position, and I have a much higher bar nowadays for making something an option.
I agree completely, but like to think of it a little differently.
While it's easy enough to put your dotfiles on github, and pull them down onto every machine you touch, or possibly even automate that, it doesn't solve the fundamental problem that software that requires extensive customization is not good software.
If the right trade-offs haven't already been made in the default configuration, then it's an immature application waiting for a rewrite.
A common pattern in mailing lists/forums/etc. is the "just make it an option" guy. People are talking about their wishlists for future versions of <Gimp/emacs/Xorg/LibreOffice/whatever>, and sometimes these wishlists conflict. One group says a UI should be one way, another group says it should be some other mutually exclusive way, and a third group thinks the developers should implement both and just make it an option in a dotfile to make everyone happy.
Sometimes "just make it an option" guy is right, but in hindsight it should never be the default resolution to the disagreement. In those days I defaulted to "just make it an option", and really internalized that philosophy because it felt like all benefit and no cost. Why wouldn't you make everyone happy, if you could do that instead of making one group happy at the expense of another group? I think it's a really common trap people fall into early on because they have yet to directly perceive the costs that that approach can incur over time in software development. Sometimes they've also tricked themselves into overvaluing their workflows and muscle memory, which they may have defined in part because it was easier for them to define their own keybindings than memorize what the default ones were, which I now think is an antipattern in itself.
The main thing that changed for me is spending the intervening decades doing work on multiple machines all the time, running different versions of different OSes, often times starting from fresh installs. That made it more pragmatic to always learn software in its default config, and only tweak configs if it's absolutely necessary or otherwise pretty important to me. It's also forced me to learn all sorts of useful stuff that I probably wouldn't have otherwise. It also drove home just how much my desire to tweak configs was just because it was fun for me (and I had lots more free time back then), rather than something that made me more effective as an engineer.
But that's just from a user perspective. From a developer perspective, having "just make it an option" be the default form of conflict resolution leads to all sorts of unanticipated complications in practice. Every time an alternative code path is added for something, the code becomes a teensy bit more fragile and likely accrues a teensy bit of technical debt. The fragility and technical debt accrues over the years, and eventually can turn even the best software into an unmaintainable mess. I'm not dogmatic about it- some things should be options. It's just never my default position, and I have a much higher bar nowadays for making something an option.