Back Into the Shell

When a few friends and I started Skitley earlier this year we made the decision to host our applications on a linux stack and began using Digital Ocean for our hosting. The choice was driven mainly by price of hosting and tooling, but also I have fond memories of Unix/Linux from my early days of programming. Admittedly, those days are about ten years in my past so I may have the rose tinted glasses on, but it still seemed the best choice.

In making this move, I’ve been sent back to the world of Putty, SSH, and working from the shell. There have been a few hiccups in getting back on that bike, but the improvements in tooling and the general technical skills I’ve picked up over the past few years have made it a smoother acclimation than I had anticipated.

Step 1: The Editor (VIM)

One of the first things that really hit me was how little I remembered the vi editor. When I was in college all our work was done from a Sun Solaris shell using vi as our editor. I remember my professor trying to impress upon us why this completely “counter-intuitive tool” was superior to say, notepad. By graduation I still wasn’t sold on the idea, but I could fuddle my way around well enough that I didn’t complain much anymore. Fast forward to today as I’m working through tutorials online simply trying to remember how to exit the damn editor on my new Ubuntu Server droplet and it all starts coming together. The simplicity of chaining smaller commands into larger useful pieces now made sense. Years of working in Eclipse/Visual Studio/Sublime Text had taught me to be fairly efficient in editing with a standard text editor, but now I could really see the potential. No longer was I stuck with the crude home/end/pgup/down and shift+arrow combinations to move around a file. the many detailed forms of movement built into the vi commands made going exactly where I need to be in only a couple strokes a reality.

Soon, at my normal day job, I began using gVIM in place of notepad++ and began looking for plugins to simulate vim commands in Visual Studio, SublimeText and even in Chrome. I also began to crave the power of some of the linux tools for searching and scripting so I found myself installing things like ack for windows. I moved to cygwin so I could use my familiar commands like ls, and somewhere along that path I stumbled into PowerShell.

Step 2: The Shell (PowerShell)

PowerShell has been around for a while now, and I knew it had the full .NET framework behind it and that it was praised by window sysadmins over the classic windows shell. What I didn’t anticipate was how quickly you could pick it up and start doing useful things. My previous experiences in learning Bash scripting and DOS batch scripting were filled with confusion and frustration, but PowerShell was quite the opposite. Soon I had almost as much custom code in my powershell profile as I had in my .vimrc. I began running mercurial from the command line instead of the tortoise GUI, and I created a set of helper functions in my profile for MSBuild so I spent less and less time in Visual Studio.

Today, I have reached a point where I rarely open visual studio anymore. I’m running three monitors and three applications: PowerShell, vim, and Chrome. It’s strange being a web developer using these tools. My very world is built around the mouse dominated UI of the web, but I do almost everything from a command line without a mouse. My colleagues are often confused as to why I would want to use a tool from the 70's over the grand new tools like Visual Studio, and it’s really hard to explain (as my old professor knows) just how much nicer it is. I admit that the build chain is greatly simplified in VS and the intellisense can help make things incredibly fast and accurate added together with the real-time syntax checking. In the end I find the editing experience in VIM/Powershell is just a greater benefit to me.

Step 3: The Result (Efficiency)

While it might seem weird when I think about it, I know for a fact that I’m producing code faster and faster as I become more accustomed to these tools. I’m finally starting to understand what that professor was trying to pound into our heads all those years ago. It also makes the transition between the Windows environment at one job to the linux environment at the other so much more fluid. I’ve begun digging deeper into the world of vim commands via the book “Practical Vim” by Drew Neil. I can’t wait to see what my productivity looks like in a few months. I encourage any developer who has been in the industry for a while to check out vim or emacs just to try it. You may just find it helps you the same way it’s helped me.