Coding Without a Net - The Week of No IDE

I can't deny that most of my programming career has been supported by one or more Integrated Development Environments (IDEs) helping me along.  In fact, it was only my early coding days back in the '90s when I was using Perl in a Linux environment that I worked without one.  It's always been Visual Basic, Eclipse, InterDev (don't ask), or Visual Studio guiding my hands along the surface of the code.  But what if there wasn't an IDE to help me?  Could I go back to the basics and still be productive?

It's uncommon these days for a developer to work completely without an IDE.  While we may cut over to a plain text editor to get some low level work done, we are typically happily pecking away within the square confines of a syntax-colorized, project-analyzing, "intellisensing" application that automatically compiles and often deploys our applications.  They are generally a great boon to productivity.  And then, sometimes, they're not.

My current IDE is Visual Studio. (By the way, did you know Visual Studio has a free version?)  We have just upgraded to VS2015 in my shop and it's looking promising, but VS2012 had a tendency to simply go out to lunch for a while, usually when I was right about to complete a coding task and see it work.  Sometimes, its syntax checking or intellisense would just hang up and refuse to work until I restarted the whole IDE.  And then there are the file management operations that would sometimes take 30 seconds or more, even if it was just a file rename.  Sure, it was probably some plug-in or a specific sub-feature that was causing these issues, but the sheer complexity of the system makes it nearly impossible to track these down.

Most of us, once we get past the basic learning phase of coding -- beyond "Hello World" in C, Java, Python, or whatever -- will start using an IDE and never look back.  And who could blame us?  It helps us create the function signatures, warns us when we use bad syntax or sometimes even incorrectly refer to a class or variable.  Heck, the best ones give us drop downs in context of what we're doing and show us what methods we might want to call on an object, or what public classes are available which start with the letters "Person."  These hundreds of tips from moment to moment save us incalculable time.

But one day a few months back, during a particularly bad morning with Visual Studio, after many freezes, two crashes, and a co-worker suffering the same agony, I began to wonder:  What if I kicked Visual Studio to the curb for a week and made a go of it alone?  Just me and a basic text editor.  Could I actually get work done?  How long would I last?  I began to secretly formulate a plan for a "Week of No IDE"

First, I'd want a text editor beyond just notepad; there's no reason to hamstring myself further.  Thinking back to my Linux days, I decided it might be fun to give my old VI skills a reprise and see if I could still hack with it.  I found a Windows version of gVim that looked promising and grabbed a few VI keystroke cheat sheets to use until I get my chops back.

Second, I'd need to figure out how to do all the other coding tasks (the ones that don't involve actually writing the code) without an IDE.  My two main operations that are not coding are building the project and using source control.  Fortunately, Visual Studio and Team Foundation Services (our source control system) both have decent command line tools for those tasks.
Third, I'd need some human help, because, hey, it's been a long time since I worked without an IDE looking over my shoulder and correcting my syntax.  Having a coding partner would help catch the stupidest of errors and would also subject someone else to this pain... uh... experience.  Misery loves company.  So I asked my co-worker Todd if he'd give this a try with me in a multi-day pair programming session that would last as long as we could both stand it (and each other).  He agreed in spirit, although I think he's likely to bail if things get too hairy.  I won't blame him if he does.  This is above the call of duty.

Fourth, I needed a week where not a lot was going on.  It's not that I don't plan to get some work done, but I don't want deadlines breathing down my neck because I'd be immediately tempted to go back to IDE-land.  As it turns out, we are in the Christmas season, and this coming week is likely to be a bit low-key.  We've just deployed a new update to our flagship product and work on the next phase has just begun.  It's a perfect time to try this temporary experiment.

Check, check, check, and check.  All this leaves is for me and my co-conspirator to give it a go, so starting next Monday morning, Todd and I are going to be pair programming in gVIM for Windows, using the command line Team Foundation Services client, and using the command line Visual Studio compiler to build.

I am also going to be live-tweeting our experiences, trials, and tribulations, at @jptillman (my personal twitter handle) and will roll those tweets up into a post on the Above Average Programmer blog soon after we are done.

Additionally, I want to invite anyone else interested in participating in the "Week of No IDE" with us, even if it's not the same week, to try it and post your experiences here in the comments or in the comments of the tweet-blog I post later.

Even if you don't decide to give the "Week of No IDE" a try, even if you do try and it ends up more like the "20 Minutes of No IDE," I encourage you to raise your awareness of your IDE and how it supports and guides your work.  Is that support causing you to lose certain coding skills?  Is your thinking perhaps too IDE driven?  Do you rely on debug-mode to solve every coding issue?

After some careful thought and experimentation, your answers to these questions may surprise you.  Investigating these questions and answers more closely just might help you on your path to becoming an Above Average Programmer.