Yesterday I made an offhand comment about the long story of how I got started with Vim, so I figured I’d follow up today with that. That story takes us all the way back to 1999.
Fresh out of college, I landed a job with a startup e-commerce site called LinuxMall.com. Not quite by accident but certainly a lot of luck was involved, and some hubris. I was armed with a B.A. in English and Communications/Journalism, as well as a few years of undisciplined and unguided tinkering with Linux.
I’d emailed LinuxMall.com about a possible job, and the founder (Mark Bolzern) was kind enough to roll the dice on me. My job description was ambiguous but involved marketing, writing, and assorted promotional activities.
But part of the job was updating the LinuxMall.com web site.
Website editing? We’ll do it in production
The site, at least the front page, was plain HTML. We didn’t launch a dynamic site until later in 1999, if I remember correctly.
LinuxMall.com was cutting edge 1999 web technology: 600 glorious pixels wide with multiple tables, a few GIFs and lots of s. We even had a CGI search form.
Changes to the front page involved logging into the server and editing the HTML directly.
Mark had a rule about editing the site: You had to do it with Vim. I’m pretty sure it was Vim. It was definitely a vi variant, of which there were several you could choose from at the time. I ran Slackware on my laptop, but I believe the web server was using “Linux Pro” which was a variant of Red Hat Linux. (Not Red Hat Enterprise Linux, that didn’t exist yet.)
Whether this was a gating factor to limit the number of people who edited the site, or an anti-Emacs thing, I don’t recall if I ever knew in the first place. No version control, no staging site… just fire up Vim and edit directly.
It’s important to emphasize that my tinkering with Linux had taught me almost enough to be dangerous. I ran everything as root. I’d figured out how to compile my own kernel out of necessity, but as often as not if I horked something on my test system I just would re-install and start over. My troubleshooting skills and command line skills at the time rivaled a potato, at best.
With great trepidation, I set out to learn how to edit with a vi-like editor. The first two weeks were unpleasant. Moving around the file and making edits took much longer than I was used to in a GUI editor. As someone who could touch type with decent speed (somewhere between 85-100 wpm), being slowed to a crawl by a new tool was very annoying.
After the first two weeks I was competent enough to make basic edits and save the file without looking things up. I didn’t enjoy using Vim, and if I’d had an option I’d have bailed and used a simpler text editor without hesitation. But I didn’t have the option, so I kept plugging away. I got fast enough that it wasn’t super frustrating.
After about a month, I had developed muscle memory for basic editing operations and started exploring a bit. I got fancy with search and replace, learned about regular expressions, and so forth.
Six weeks in? By then I was hooked and there’d be no turning back.
I’m not sure it’s a great management practice to force people to use specific tools in this way. But I’m actually glad that I was forced to learn Vim on the job. Having a reason and application for learning a tool is the most effective way for me to learn new things. It also helped give me confidence that I could learn other utilities, system administration, etc. Sometimes a (not-so-gentle) nudge is needed.
Happily, despite its age, Vim is still alive and kicking and available on pretty much any platform you’d care to use.