> Interestingly I go the other way: I type fast, so I don't need to abbreviate. That's definitely an interesting perspective I hadn't considered, thanks for sh

> Interestingly I go the other way: I type fast, so I don't need to abbreviate. That's definitely an interesting perspective I hadn't considered, thanks for sharing! I'll add one more note about automation and customization (this is only tangentially related to your post, it just made me think of it): Most people talk about automation and customization about doing things faster, that is definitely not how I think about it, the goal is to reduce effort. The goal of customization, automation, and software expertise in general, is to make hard things easy. Here's an example: Lets say you have ten different `git` repos that all have the same dependency you're updating that has an API change. If you're using entry-level tooling, this is a big hassle, e.g., if you're lucky you can do a find and replace, but you still are probably going to do it manually in each repository separately, and then you've also got a bunch of manual git commands to enter. So what do you do? Most likely you just put off the problem. But if you do this with automation, e.g., personally, I would use a combination of `vim` macros, fired on some CLI `rg`[0] matches, and some `tmux` synchronization to do the `git` steps all at once in all repos, making it essentially the same amount of work to do one repo as it would be to do all the repos. Which makes it pretty easy to do, so I just do it now to get it over with. This is my goal with automation, as an extension of software expertise, is to make what I consider to be "easy" be as much output as possible. [0]: https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep