Comment by saghm
2 years ago
> I would much rather have to spend a few days to relearn a tool every few years and to get the benefit of that tool, than accept a lower quality tool just to avoid a few days work.
I've worked with engineers who studiously avoid configuring any sort of quality of life improvements for their shell, editor, etc. because they claim it makes things easier when they have to use an environment that they can't as easily configure, like sshing into a shared box without a separate user for them to customize. This mindset has always been hard for me to understand; not only does it seem like they're optimizing for the rare case rather than the common one, but it seems like they're actually just lowering the quality of their normal experience in order to make the edge cases feel less bad without actually improving them at all
> I've worked with engineers who studiously avoid configuring any sort of quality of life improvements for their shell, editor, etc.
This is me. It's really easy to explain my mindset here, though. If I get used to a nonstandard tool or tool configuration, then it causes real productivity issues when I'm using a system that lacks that tool or the ability to customize.
This is not a rare edge case for me at all. I constantly work on a half dozen very different platforms. Having each platform work as much like the others as possible is a quality of life improvement, and improves the efficiency and quality of my work.
But isn't that why we have config files that you can easily copy to a new system?
But I guess you have to look at how much time you'll gain from your copying your personal config, vs the overhead of copying your personal config itself. If you often switch to a new system where you would have to copy the config file, but if you only really edit 2/3 files on that system for which a personal config won't have much benefit, then it is understandable. If I need to setup a new server for example, that doesn't need to be configured heavily, but just some installs and small config changes, and won't have to touch it anymore after that, then why would I spend time putting my personal editor config there? But if I have a personal computer that I use daily, and I edit a lot of code, it would benefit me greatly to optimize my editor for my use cases. And whenever I get a new PC or I get a PC from work for example, I can just copy my config and benefit from it.
> optimizing for the rare case rather than the common one
This has been a common enough case for me to not get too used to super customized local environments. I'd rather learn the vagaries of commonly available tools than build myself a bespoke environment that I can't port anywhere easily. That's not to say I don't do any QOL changes but I try to be careful about what I end up relying on.
I’ve usually had this attitude in the past and for me it came from my background: I worked IT, help desk, PC repair, etc for years before I got into programming and none of those contexts allow customization. And then for a while I did infra work where I’d be ssh’d into a vanilla VM or container instance to debug a deployment issue. Even though I mostly work in my own bespoke environment now, I still try to stay fairly vanilla with my tools. It’s pretty nice to be able to reset my workstation every year to get a clean slate and know that it’ll only be a couple of hours of customization to get back to what I know.