Not Just for Neck-Beards, or: How I learned to stop worrying and love the terminal
When I first started out as a developer, I was ignant with a capital “IG”. The internet was just catching on as a thing, with those little silver AOL disks arriving in everybody’s mail what seemed every other day, and computing power getting cheaper and cheaper. I bought my first PC from eMachines while still in the Marines, and wowed my barracks-mate when I showed him how we could link up our computers on a local LAN to play Quake 2 against each other. It was soon after that, I started taking programming courses at Copper Mountain Community College in Joshua Tree, California.
The language they taught was Visual Basic, and for me, it was a life-changing experience. As a kid, I’d watched on in awe as certain friends were able to write their own games or hack the local phone companies (at least one friend landed some jail-time for this), but always found it inaccessible, as it involved delving into that most nebulous of tools, the command-line. To me, the command-line represented the old-guard of computing, as I remembered playing Oregon Trail and Snake, and writing BASIC programs on the blinking green-and-black screens of the TRS-80’s my middle-school had in their computer lab. It conjured visions of neck-bearded old hippie nerds, modern-day Gandalfs with esoteric knowledge of a computer’s inner workings that I thought I’d never understand.
When I discovered Visual Studio and its UI-building tools that let me put together a user interface as easily as playing with blocks, and write code behind the UI by clicking interface elements, I knew THIS MUST BE THE FUTURE. Not long after, when I had a reliable internet connection, I discovered Macromedia’s WYSIWYG (What you see is what you get, pronounced ‘wiz-ee-wig’) editor, Dreamweaver, and immediately devoted all of my time to learning the ins and outs of the software. I discovered that these tools were known as IDEs… Integrated Development Environments… alongside the visual tools, you also got features like code-completion, syntax-based color-schemes, and FTP tools built right into the editor, and visually helped you out in setting up a server on your development machine. Feeling as if I’d just been handed Excalibur by some strange woman lying in a pond, I dove in head-first and began my journey into web development. No need to use the antiquated, text-based tools of yesteryear, I thought. Leave that shit to the neck-bearded intellectuals.
I couldn’t have been more wrong, but I wouldn’t truly discover how wrong until years later.
Professionally, I continued down my path. I learned to craft rich content with Macromedia’s other famous tool, Flash, and learned ActionScript… a language, like Javascript, that is now a superset of ECMAScript, but was originally based on HyperTalk. When CSS came out, I started designing bigger and better websites. When C# came out, I upgraded my Visual Studio and started writing applications in applications for WPF. I learned vb.net as well, but in the end, it wasn’t enough for me… I’d done a lot of my learning in a vacuum, and found myself struggling to find jobs where I wasn’t ‘the tech guy in the office’, who was, in addition to writing applications, also expected to install software on everyone’s machine, manage (and design) the company’s websites, manage the network, and in some cases, repair my boss’ 10yr-old daughter’s computer, all for a wage that even fast-food workers turn their noses up at today. I was determined to learn all I could, and get ahead, and that’s when I decided to learn PHP. PHP was, at the time, one of the most popular languages available for use on the web, and was the language backing a theme-able blogging engine called WordPress, which was just starting to gain traction at the time. I found Wordpress to be an enticing shortcut, in theory… it was free, and allowed you to quickly spin up a website that could be tuned with plugins and themes to be whatever you needed it to be, and it was pretty easy to get everything you needed up and running on Windows. However, in learning more and more PHP, I began to despise it (for reasons too numerous to go into here, but mostly because it’s god-awful ugly), and started dabbling in Ruby, instead. Ruby had this framework called Rails, which had a lot of tooling that would allow you to spin up a new webapp and serve it, directly from the command-line. Its tooling would allow you to enter simple commands to generate boilerplate, ready-to-run code. It… didn’t play nicely with Windows. I’d learned enough Linux skills to run Apache hosting Wordpress sites on my company’s servers to have gotten over my initial fear of the command-line, but I hadn’t really embraced it yet, until my frustration over trying to get Ruby and Rails to run without issue on Windows. I decided to start working more and more in Linux VMs, learning more and more about just how powerful a tool the command-line really can be. Moreover, I was amazed at how many people were still using what I’d previously scoffed at as being an antiquated tool to develop, build, and run modern software. As the wool of youthful arrogance was slowly pulled from my eyes, I learned that apps run from the command-line generally run faster, due to not having a performance-hogging visual UI to worry about. I learned that Ruby ran better on Linux because it took advantage of certain terminal & system-based tools that are common on Linux distros, but which required a ton of hoops to be jumped through to make work on Windows. When Node came out and I started playing with it, I discovered that the same thing held true for that, as well… while you could (and still can) get Node working on Windows, it was remarkably easier to do so on Linux, through the terminal, and that many tools readily available on Linux were just not there on Windows. BASH started calling to me, compelling me to learn more and more, and I obliged. Fast-forward a couple of years, and I was now rarely using the WYSIWYG features of my editors, preferring instead to always have a terminal window open, running my applications directly in the browser while I was working on them. The more I worked in Ruby, the more I came to rely on the command-line, not only to run my apps, but also to install, manage, and run software. I was delighted to learn, upon landing my first Pro Rails gig, that all of the tooling which ran so great on Linux, but not on Windows, also worked great on MacOS (this is due to MacOS being a UNIX variant, itself). Moreover, I relished the freedom that working in the command-line afforded me. I started to seek out ways in which I could improve my workflow, through judicious use of the terminal. So, at this point, I wan’t scared of the terminal, but I still had not fully embraced it.
I was using RubyMine at the time; yet another IDE, (one specific to Ruby), which allowed me to run a terminal in a handy window at the bottom of the screen. I started at this time, to use EmberJS as well, a JS Front-end framework that included a lot of the same type of scaffolding tools that Rails provided. I also started using the terminal to automate a lot of my workflow… I set up cron jobs and started writing BASH scripts to install software and libraries that I’d need; I abandoned the UI-based version-control tools I’d used in the past in favor of exclusively using Git from the command-line, and wrote custom aliases for common commands I found useful. I thought I was really getting the most out of it, but despite this, I still clung to a lot of my old prejudices when it came to running software directly in the terminal. To me, that flashy UI-based stuff was still the way to go. It wasn’t until I reached my current job that my eyes were truly opened.
By the time I started working for NBC, through Railroad19, I had parlayed the skills I’d acquired over the years into a decent career. I’d more than quadrupled what I was making since I started working in the industry, to the point where my salary was not only competitive with what others of my skillset were making, but actually ahead of it. I knew my way around the tooling and the languages I was using, and knew where to look to find the answers I didn’t have. Still, I wanted more… the craving for knowledge and a deeper understanding of my work and my tools never really went away, and the more I used my flashy UI-based IDEs, one shortcoming started to become glaringly apparent… namely, they felt bogged down and sluggish. I’d noticed some of my co-workers used Vim… one of the antiquated (so I thought, but TBH, their website still looks awful) editors of yesteryear that I’d dismissed as being one of the tools of the neck-beards. I scoffed for a while, but soon realized while pair-programming with these guys that they were able to accomplish things at a blindingly fast speed that I, with my hunt-and-peck typing and reliance on the point-and-click mouse-driven workflow, just could not keep up with.
I increased my productivity by switching from the Java-based RubyMine to VSCode, and while I enjoyed working in that editor immensely, I still couldn’t quite match the speed of the guys who were using Vim (This is an unpopular POV for most at VWC, who still swear by VSCode… it’s a matter of personal preference, really). I started noticing others in the industry used it as well, and recommended it over any other. “Hipsters”, I thought, “man-bunned, indoor-scarf-wearing, into-everything-before-it-was-cool douchebags”, trying vainly to put it out of my head… but my jealousy over my co-workers productivity finally got the better of me (also, we all work remotely, so at the time, I really had no idea if any of them had a man-bun… and as it turns out, no, they didn’t). I fired up Vim, and got to work learning it.
The first thing I noticed was that my install looked a hell of a lot more sparse than those of my co-workers. Vim in and of itself is really no more than a simple terminal-based text-editor, and it takes a LOT of love and configuration to mould it into a full-fledged IDE. Things I’d taken for granted in other editors, such as line-length delimiters, file explorers, tabbing entire selections, code-completion, bracket-closing, syntax highlighting… all this needed to be added in as plugins and configuration options. I won’t lie… getting Vim to behave like a full-fledged IDE takes a great deal of effort, and the terminology is different, so tabs don’t work like you might think they should, if you’re coming from a UI-based editor. However, the payoff was immense. Combined with the tmux terminal multiplexer, I was able to give myself a completely customized development environment, one tailored specifically to my needs and tastes that did exactly what I told it I wanted to, and that sipped resources, as it had no graphical UI to render. I have, at any given time, 3–4 projects open in Vim that I can switch between with simple keyboard shortcuts, each able to hold open multiple files to such a level as would cause a system failure if trying to keep the same amount open in any other editor I’d previously used.
Even more keystroke commands allowed me to quickly navigate and edit my code without ever taking my hands away from the keyboard… a time-saving hack that I really had not expected to do me much good, as I’m a notorious hunt-and-peck typist. Even that started changing… as I learned to rely less on the mouse, my typing actually improved. And then another odd thing happened… when I would switch back to VSCode, I found myself trying to use the keyboard shortcuts I’d learned for Vim, and getting annoyed when hitting yy on my keyboard just typed ’yy’ instead of copying a line. I’d become the thing I’d previously mocked… someone who was completely hooked on a piece of software I’d ignored because I thought it was too old to still be useful. The truth is, Vim has been a mainstay in the development community for so long because it is what you make of it… a tool that gives you the complete and utter freedom to make your own choices about how you want it to look, feel, and behave. I now have a terminal running permanently in full-screen, while I work, and rarely need to leave it to accomplish anything. My productivity has grown to the point where opening a UI-based IDE and waiting for it to start up fills me with a great deal of impatience, and watching it start to bog down as I leave more and more files open makes me cringe. I still have VSCode installed on my machine, but the truth is, I never use it, except to keep up to date with it’s capabilities for the folks I mentor. I’ve learned to truly love the terminal and all the freedom and power it provides, and I don’t think I can ever go back.
