Coding Without a Net - The Week of No IDE, Days 1 & 2

A few weeks ago, I posted an entry speculating on the effects of the use of Integrated Development Environments (IDEs) on programming skills and productivity.  At the end of December, a colleague of mine and I decided to give coding without an IDE a full test-drive.  Our flagship product's code-base is written primarily in C# and Typescript (which transpiles into JavaScript at build time).

My colleague Todd and I had decided to take on our "Non-IDE" work in pair programming mode.  This was primarily because we suspected that our combined knowledge of the programming APIs that we use on a daily basis would be more complete than what we knew individually.  It was also, I must admit on my part, a little bit of insurance that I would stay the course for at least a few days.  Nothing increases accountability like someone else doing the hard stuff with you.

Having Todd work with me also gave me the ability to occasionally tweet regarding our experiences.  I collected those tweets in a Storify post, although I was too scattered and intermittent to make them a good document of the experience.  I did leave a few technical challenges we encountered solely documented in the tweets, however, so they are worth taking a look.

The first thing we noticed when we were preparing for our first day was that our selected editor, Vim for Windows, was going to be a challenge in itself.  I consider choosing Vim as something of a mistake on our part.  While the goal of this week was to free of the IDE, it was not my intent to sacrifice even more productivity to learning a new editor.  Looking back, I would probably have avoided Vim for this week, but I have to say I fell in love with Vim and its power.  So perhaps the mistake was a good one to make.

After blowing far too much of our first day on getting our Vim editor configured the way we wanted it, and finding syntax colorizing for C# and Typescript, we finally got to work.  What we found was that Vim has some pretty good multi-file editing capabilities, even offering tabs and file system browsing.  This took some getting used to, but in the end, it sufficed.

We also found that our methods of building and performing source control operations required us to keep a few command line windows open. I use ConsoleZ,which I have found to be a top-notch command console for Windows.  There were also a few times we utilized Cygwin's console to give us access to familiar Unix commands like rgrep and tail, which allowed us to recursively search all our code files for keywords and to actively monitor log outputs, respectively.  These are functions that are normally handled by the global search and debugger functions of our IDE, Microsoft Visual Studio.

On the topic of debuggers, I had previously found a command-line debugger for .NET from Microsoft called Msdbg, but we decided that if we were going old-school giving up the debugger entirely was appropriate.  Our app uses the Log4Net logging library, so we leveraged that, along with "tail -f" in Cygwin, to monitor the execution of our code.  This worked pretty well, especially with ConsoleZ's buffer search feature.  The ability to turn on and off sections of logging was useful in tuning the output.

My two biggest challenges during this period were resurrecting my old Vim skills and recalling the .NET API well enough to code effectively.  Both became less of an issue as time went by, but I did not fully get back up my typical speed on either count.

Todd had less of a challenge with Vim.  He is an old Unix hand and spent many more hours using Vim than I had.  Vim is driven by keystrokes and his muscle memory was impressive.  Despite having been forced to use it in Unix environments for years, I never really embraced it.  Several cheat sheets by my keyboard kept me moving, but it was tough going.  Despite the difficulty, I stuck with it and did get better.  The end result:  I like Vim and its focus on using simple keystroke combinations to navigate and edit.  I think I'll use it from now on as my go-to all-purpose editor when its available.

The .NET API was where my advantage lay, as I have several years more invested in C# and .NET than Todd.  Even I found it difficult, however, to recall the less often used methods and their parameter requirements.  I found myself relying on the "type, compile, correct" method when I had an inkling of what to do, and relied on Google for the rest.  In the old days, I would have had a book by my side to look things up.  Fortunately, we are beyond that now.

My memory of .NET's APIs as well as our own internal APIs did become deeper as we worked, and I discovered I was inspecting the code surrounding my edits a bit more closely than usual.  This was, of course, because the IDE typically will flag not only syntax errors or API misuses, but thanks to our use of Resharper, we also get excellent stylistic assistance when coding.  I have to admit that I missed Resharper more than I missed my IDE in general.

All in all, the first couple of days was a period of self-discovery and frustration, with little actual work getting done.

In my next post, I'll pick up from Day 3, in which our spinning wheels actually catch some traction.