I haven't written in awhile and I'd like to spend more time imparting lessons I've learned about software development, deployment pain, and maintenance pain. Lesson one: if you can't do it with vim and some terminals then you are going to be experiencing pain eventually.
There is a certain attention to detail that is required when you keep your tooling simple as simple as a text editor and a terminal. When you do it you discover all kinds of neat little things, like that hard-coded dependency that doesn't exist in your Linux flavour, or the tests that need your PATH to be just that way, or those database migrations that don't ever set your database up from scratch. If you don't use tooling that papers over these sharp edges then you go out of your way to dull them, either by redesigning the system sanely or by building the next level of abstraction, the level that keeps you safe.
You might think this level of attention to detail is overrated. Or more likely your boss does. In the end the pain still comes. Remember those variables that are subtly different in name but with significant differences in use? Or more exciting, that spelling mistake that is everywhere in your project? Your IDE was helping you by autocompleting, but other team members didn't stop to think if it was helping them do the right thing. If you don't use autocomplete these kinds of mistakes become obvious very fast, and because you don't want to be typing ultra-long names you spend more energy on good names.
Maybe names don't matter to you (which would be silly), but I know you remember that project with stacks of functions 10 levels deep, passing way too many arguments from the top to the bottom. But that handy function introspection feature lets you go up and down super fast, and the autocomplete helps you repeat the method signature so you're not only 10 levels deep but the call tree has a painful number of branches.
Live preview modes in IDEs are pretty cool, but the same thing can be made on the command line and more fine-tuned to specific use cases at that. Build pipelines and test suites are far less brittle when you break it back down to first principles. "But it passes in my IDE" is bullshit and is also reflective of my disdain for the growing "Docker-everywhere" culture. Rebuilding these pipelines so that engineers can run everything locally without a specific IDE forces you to clearly lay out prerequisites and build the parts so they are robust. This can be as simple as your prerequisites being listed in a README file as well as specific package names in a puppet script, or making sure some modules work in Windows. You will find bugs in this process, and those are bugs that were waiting to burn you when you start tweaking your brittle build pipeline.
But really, the most important reason to use vim is that you can set up your terminal to be green on black. Throw in a tiling window manager and it is two monitors full of nothing but mysterious green on black text. Your boss will leave you alone because they will assume you're actually Neo.