Low-Friction Coding Part 1

What is low-friction coding?  To me, it's removing as many of the barriers between you and getting a piece of code finished as possible.  There are many factors that can slow your progress.  Some of them are beyond your control (more on these in a later post) while others can be eradicated by working smarter - not harder.  Below is a list of things I do to make coding go smoother and faster and make it less of a burden.

1. Code on Adequate Hardware - today's development environments (IDE) and tools use more resources than ever.  This means that coding on a machine lacking in resources is going to show up in a noticeable loss of productivity.  For me, it's normal to have two or more instances of Visual Studio open, to be running a local instance of Sql Server and IIS and to have other tools open to help me along the way.  These all consume a huge amount of memory.  For my development machine, 2 gigs is the minimum.  If you're developing for WPF or Silverlight, use even more memory and make sure you have plenty of graphics horsepower, as well.  Your code files load faster, compiles take less time and any tools or add-ins you may be using will be more responsive.
2. Code Comfortably - I can remember, as a consultant, writing code at conference tables, elbow-to-elbow in a noisy room.  As far as I'm concerned, any distraction eats into my productivity and bumping elbows while being subjected to everyone's chatter certainly qualifies.  To the extent you can, wallow out enough room that you can work comfortably.  Familiarity also comes into play, for me.  I carry a mouse that I particularly enjoy using with me at all times so I can avoid having to use a mouse that doesn't work properly or comfortably.  Also, don't forget about ergonomics.  Achy body parts are certainly distractions, as well.
3. Use Available Tools - Writing boiler-plate code over and over again won't make you any more productive.  Personally, I use CodeRush and Refactor! from Developer Express to help me get ideas into code faster.  CodeRush allows me to enter a few key strokes and get a template for a code construct entered directly into the code file.  This saves a few key strokes and time, but the time adds up during the course of a project.  Refactor! allows me to rearrange my code faster with tools that intelligently move code around without breaking it.
4. Use Patterns - What's all the buzz about design patterns?  Simply put, there are a lot of software problems that continually get solved over and over again.  Why expend the time and effort to solve a problem that has already been solved?  I know.  It's tempting to not invest the time into learning even the most basic patterns.  Who has the time for that?  Truth is, once you learn a few and start using them, you'll recover the time you invested to lean them very quickly.  Spend some time at ootips.org to learn some of the basic, most used patterns.
5. Use Code Generation - Most applications have similar requirements when it comes to data access.  In this area, there are proven best practices (though just what THE best practice is, is debatable) and generic approaches that we code over and over again.  Wouldn't it be nice if you could get this code, customized to your application, for free?  This was the promise that drew me into using SubSonic.  This tool looks at your database schema and generates business classes and collections that align with your database table structure.  The classes are database aware and can update, delete or add themselves into th database.  Cool stuff and there's no telling how much time this tool has saved me, to date.  Of course there are other areas of an application where code generation makes sense - maintenance screens, possibly parts of validation (data type, length and the like).  Whether you use available tools or grow your own, having code generate code certainly helps things along.
6. Know What Your Writing - It should be common sense that you don't start coding until you know what your objective is and have, at least, some idea of how you're going to get there.  Still, many jump in and try to figure things out as they go.  Stop to think how many cycles are wasted with restarting from scratch or trying to fit code written on the wrong premise into an ever changing application.  I try to think through the entire portion of code I'm about to write, beforehand.  What pieces will I need to build?  How will they fit together?  What data will they exchange?  In what form will that data be?  Does this problem fit nicely into a pattern I've learned?  My objective in this exercise is to know enough about the solution to the problem that my actual coding becomes little more than just typing.  If I've settled things to the point that I'm not making design decisions as I go, I know my implementation will get from my head to code much faster and be much better code, to boot.