Coding Without a Net - The Week of No IDE, Days 3 - 5

This is the third in a series regarding my experiences in dropping the use of an IDE for my day-to-day programming tasks.  For some background, you may want to check out my initial post where I lay out my plans and the post covering Days 1 & 2.

The third consecutive day of the Week of No IDE found us fully tooled up and with an understanding of how we would interact with our code and the project.

One major challenge we had encountered in Days 1 & 2 involved the adding of new source code files to our project.  Reviewing this problem took up more than a little time.

When you write code in Visual Studio, each individual source code file must be referenced by the common project file in order to become part of the build.  The project file itself may actually, in turn, be part of a larger "solution" file containing references to multiple projects which can be part of a sort of mega-build.  These references to files are not just the location of the files, but also information on what role they play in the project.  For example, a Typescript file will be referenced differently from an HTML or C# code file.  While this may seem great for organization and make it easy for Visual Studio to create pretty displays, Microsoft decided that there was no need to make it easy to add these references without using Visual Studio itself.

The end result was that Todd and I found ourselves struggling to efficiently add a new Typescript file to our project.  The process looked something like this:

1. Create the Typescript file in the location where we want it to reside
2. Open the main project file, which is thankfully in XML format, in Vim
3. Locate an existing Typescript file reference in the mass of XML
4. Duplicate it, placing the copy below the original
5. Change the path in the copy so that it references our new file
6. Save the project
7. Build the project and ensure that our new file is included in the build

The same process worked for C# and HTML files, as well as others.  Although the process worked, it was not pretty or efficient.  I considered writing a quick utility that would do the dirty work for us, but we'd already lost time and I was more than a little annoyed that no one had already done this.  A Google search turned up nothing apart from StudioShell, which does not work outside of Visual Studio (no matter what its docs may say to the contrary), and a promising post on StackOverflow. All fell short of my goal, so I just stuck with editing the XML.   I may yet revisit this and do it myself.

(Don't get me wrong about StudioShell, however.  We already use it and it's a really great tool once you learn it.  You can do some very powerful stuff with it in Visual Studio.)

File-management challenges aside, Day 3 turned out to be relatively productive for Todd but less so for me due to administrative duties kicking in.  The good news is, we managed to move several items on the Kanban board during our first few days.

Both Todd and I took a week long break for Christmas in the midst of this experiment, so Day 3 was actually the end of our first "week."   Upon our return, we did not go back into pair programming mode.  Although our team members often pair up, we don't practice continual pair programming, so our final 2 days were executed solo.

During this time, I continued to work through difficulties with using my editor and the APIs, but I did manage to get into flow a few times, so much so that I neglected to tweet what I was up to.  Once I got past the desire for the editor to catch all my mistakes and instead let the build process point me to the problems, I found I was doing ok.

An interesting side effect of "build-based debugging" is that your time-to-build becomes critical.  I actually tracked down a few issues that had been causing our project builds to run longer than they needed to and shaved a few seconds off each build, which was huge for my new workflow.

Using the build as your syntax check also forces you to focus.  Visual Studio, like most IDEs, will analyze your entire project and show you a list of errors.  This is usually considered a good thing, but it can make you lazy, allowing you to jump around from file to file making wanton edits, without concern about their effect on other files in the project because the IDE's error list will warn you when you run off the rails.

In my case, only when you build do you get the news and the news is often not pretty.  So I found myself building far more often to ensure I hadn't gone too far astray.  This greatly focused my attention on where I was working at the time, and I do think it helped not only my concentration, but also my awareness of the effects of my changes.  I became a little more conservative in my changes to public method signatures, for example, and was more inclined to make my methods private, allowing external needs to force them into the public space.  This is, of course, good coding practice anyway, but I did feel new, positive influences on my behavior as a result of my workflow.

Overall, I think it was an interesting exercise which gave us some insights into our knowledge of our toolset, exposed us to some old but still excellent utilities, and which exposed the incredible lengths to which IDEs have become embedded in the workflow of software development.  I don't think our brief experience truly answered the question of whether IDE-reliance is good, bad, or just plain ugly, but it was a fun diversion and I think I did come away with a little more situational awareness of my coding activities.

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.