Do senior devs use terminal/VIM? Do they type faster?

András Tóth - Jun 24 - - Dev Community

A reply to this great post about productivity of console proved to be quite popular, so I decided to turn it into an article and add a bit of extra.

(Skippable) Little Story About DOS and config.sys

First a little story. I was a kid in the 90s and my dad had a computer at home. I totally got sucked into it; mostly to play video games. Back in the day we had DOS (Disk Operating System) and it was terminal based. You started Windows 3.1 from the terminal and not the other way around. 🙂🙃

To juggle with files and folder, I used Norton Commander. It had two panes for two folders and you used F5 for example to copy (if I still remember correctly) from active pane to the other. I've gotten really-really fast with it, so fast in fact, that one day I have accidentally deleted the important looking config.sys file. Since there was no "Bin" back then, and I didn't know about the undelete command, it was a huge trauma to me: ruining dad's computer (which I didn't as I realized later) by being reckless. Later a friend of mine gave me his notes he learnt about DOS configuration in IT class, and I could recreate the file (and go back to playing games that required EMS memory handling instead of XMS).

So it is safe to say I was growing up not using the mouse and doing everything in the terminal. Yet, I have no particular love for it.

Do You Need Serious Terminal/VIM Skills?

I try to use a great IDE as much as possible and the terminal as little as possible.

Why? Let's say I'm writing and fixing unit tests. The jest integration runs in my Webstorm works as a breeze: I get diff, I can click on the failing test, it jumps to the relevant line in the codebase, I can put in a breakpoint if I want it and so on. Lightning fast, I have everything at my hands, no need to manually scroll, load, struggle with something. 21st century experience.

I do advocate for learning the keyboard shortcuts while using the IDE and also to learn tricks like multiline cursor editing and so on, because they save so much time.

Do you need great typing speed? Is using a mouse an anti-pattern?

Now, about typing speed. When I code, I write a little and then mostly I think for a while, then type out my code, then check the results (either through a unit test or on the frontend). It's more like a quick chess game than a horse race. It's not a typing competition, it's not a copy-paste-modify extravaganza. In case I've written the samish thing multiple times I tend to step back to evaluate what to do with this repetition. Do I need to extract the code or am I expecting them to grow in a different direction very soon, therefore no need to extract the code? It requires stopping and thinking, nonetheless.

Half of my "coding time" is actually also talking with stakeholders, making agreement with my colleagues on what to work on and what not to work on. Sometimes you do a lot of damage to a codebase if you start solving the problem in the wrong place (e.g. is doing the join on the frontend the right place for it or is it better suited in the database?) and sometimes you have to advocate for an easier path to take.

Terminals, CLIs and Mental Mapping

Finally, about CLIs: personally, I hate command line interfaces. They violate the "avoid mental mapping" principle of clean coding: you have to memorize the flags for each CLI tool, remember if -f stood for file or force or folder or something completely different.

There is no "Codex of CLI Conventions", no "Knights of Inter-CLI Consistence". Every CLI is special in its own ways, and to remember the quirks of each is mentally taxing for me.

The only things I do in the terminal are basically "npm start" or "npx something something". Very, very limited instructions.

Why People Might Prefer Terminal over Full-Fledged IDEs?

This is going to be pure speculation on my side:

  • maybe there is this "Coder/Hacker" image which glorifies stream of logs in consoles
  • or people are influenced by a famous engineer who uses terminal for everything
  • can be a bit of impostor syndrome: the Big Fish uses terminal and VIM therefore if I don't they will think I'm just an impostor; you are not!
  • neurodivergency 1: some people have very low tolerance to any type of slowness, they prefer high responsivity; IDEs, since they provide many functions tend to have problems with that time-to-time
  • neurodivergency 2: some people have excellent mental mapping abilities (great, reliable memory) like my university math professors; I assume they tend to prefer tools with hardcore mental mapping; since it's a "superability", not the norm, I would not force it on others, personally (I don't have it - I love clean code for this reason)
  • using console is a great way to freak out grandma or your parents that you are so intelligent you can speak directly with the CPU

Do Senior DEVs Use Terminal/VIM then?

I think most of us do not. Personally, I feel there tend to be a lot of friction with the people who push CLIs and bash scripts on others as they increase the mental load on others who are neurologically not that great at mental mapping. If you can keep common projects working without hacking too much in the terminal, without adding magic lines to .bashprofile, you should do your own thing. Also if you are working alone, you are 100% free to choose the methods that let you stay in the zone.

Therefore my productivity hack is to get a good IDE and learn it well! The shortcuts, the multiline editing capabilities, the integrations (in my favorite IDE, you can run an SQL statement from a TypeScript to manually test your query; how cool is that?).

In a team, you have to code and plan your productivity in accordance of the tools available. If you "muscle" your code through by typing quickly and a lot, there is a chance you will ignore very effective coding assistance tools, while you have the illusion of productivity since you type a lot, and press Enter a lot.

In reality you might be doing double/triple work. Think before you strike!

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .