- It's easier to understand what your customers will see: If they customise things, they'll need to figure those things out themselves anyway, but if you customise things, there's a chance you'll forget a detail and it'll leak out to your users.
- Nudge; Your automation tends to spread: If I have a deploy_to_prod alias, chances are it can only be used by me, but if my project has a deploy.sh script, then there's a path to get other people on my team to use it. If you've got the discipline for this by some other way, then that's great, but having to eat dog food meant I first had to make the dog food, and requiring (of myself) helped me build that habit.
- It's one less thing to think about.
Of course, the downside is that one day I woke up and found myself using zsh.
> "I feel that sharing files between different computers is now a solved issue, and the benefits I get from having personalized my work environments are so great that I gladly pay the small price of synchronizing that configuration between my computers."
Or when you work in an airtight environment, like in banking.
It is 'solved' when the only computers you connect to is small enough to be be described as 'my computers', which seems like a pretty narrow use case to me.
I would like to start using zsh but that would introduce too much of variation from the remote envs I might encounter.
Sometimes the defaults are not sane at all, for example urxvt, it's just a blank window with a very small font size, I'd advise to customize, but not heavily so that in a matter of seconds (the time to copy your config file) you can have the thing you're used to.
[1]: https://www.gnu.org/software/stow/
[2]: https://fedoramagazine.org/take-back-your-dotfiles-with-chez...
I started from this and customized it to my needs: https://github.com/geerlingguy/mac-dev-playbook
Here's a customization I would recommend everyone who spends a lot of time on the shell do: Be able to fuzzy find from the shell. The specifics aren't important, but here's how my bindings work (I use and recommend `fzf`[1] for this):
- `⌥z`: Fuzzy find recent directory (using `fasd`[2])
- `⌥c`: Fuzzy find recursive subdirectory
- `⌥e`: Fuzzy find recursive file
All of these work logically like this: If the binding is triggered at the start of a prompt, do what I mean (`cd` to directories, or edit a file), but if I've already typed something, insert it as a parameter, so for example I can hit `ls<space>⌥z` to fuzzy insert a recent directory (or just `⌥z` at a raw prompt to fuzzy select a recent directory to jump to).
I'd argue fuzzy finding is the major enhancement to computer productivity of the last twenty years. I recommend using it on the shell (assuming you use the shell often enough to justify it).
[0]: https://fishshell.com/docs/current/cmds/abbr.html
Interestingly I go the other way: I type fast, so I don't need to abbreviate. Instead I make my aliases and abbreviations memorable. EG for git instead of aliasing `checkout -b` to `cb` or something I alias it to `newbranch`. More typing than the two-character alias, but also more memorable than the default.
I find if a command isn't memorable I'll forget to use it, so I never build the habit needed to make it useful. Single-letter commands are especially bad for this. I've had z for years, and remembered to use it when I needed it maybe once.
Also +1 to fish and fzf, both are great.
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.
All I do is "sudo apt install fish" and I'm good to go with the 100s of out-of-the-box improvements it has over bash.
I like a 2 line prompt (where am I, what context am I in). A lot of people don't like this at all.