Rainy Day Coding

There’s a 70%* probability that anyone who makes their living as a coder today has at some point in the past completely disassembled their parents radio, VCR, or television.  

There’s a 90%** probability that at least 2/3 of the afore-mentioned 70% could not successfully reassemble said doomed appliance.

If you’re reading this, then I bet that you fall somewhere in that first 70%.  I’d also venture a guess that regardless of your inability to revive that poor defenseless VCR that afterwards you knew three times as much about how they generally worked and I’d even bet that the next time your treasured copy of Labyrinth was eaten alive by the treacherous four-headed beast that you had a really good idea of exactly what was going on in there and how to rescue David Bowie from its rectangular, steely mouth.

The reason is that once you’ve seen intimately how something works from the inside out, you gain a much better appreciation of what’s going on inside.  And if we’re talking software, then that means that you can understand intuitively how to best leverage the software to your advantage, and how to best diagnose problems when weird things start to happen.  Beyond this, if you understand the fundamentals at work behind the scenes, you can easily pick up new versions or different implementations of that technology with much less effort.  Take the VCR, for example.  There were hundreds if not thousands of different types of VCRs out there.  However, in most cases, the only difference was the choice of buttons on the front and the box they were housed in.  Once you realized that at it’s core a VCR is just a VCR, things started to become a lot less scary.

So how does this relate to software, again?  Easy:  there are a lot of great software tools and frameworks out there that can make your job much easier but may be a little scary to learn at first glance.  Take IoC containers, for example.  A good Inversion of Control container like Windsor or StructureMap can make your life much easier, but getting your head around such a tool by simply sifting through tutorials and blog postings can be daunting.  Why don’t you try building one a first?  At it’s simplest form, an IoC Container is typically just a hashtable.  Sure some may offer more advanced functionality like AOP-like functionality and auto-registration but the core functionality which allows you to easily swap out different implementations of a given interface is basically a hashtable.  Great, so now go build one.  Once you get it working, then you can try to add on the advanced things like AOP and auto-registration.

Isn’t this just Not-Invented-Here Syndrome?

Not really.  You see, I don’t intend for you to use your new IoC Container in production code at all.  Why would you?  There are tons of different IoC Containers out there just begging to be picked up and added to your project that have already thought of and handled tons more edge cases then yours ever will, have been tested in thousands of projects, and worked out all of the implementation kinks that you wouldn’t think of for at least a year.  So, why would you waste time building one?  Well now that you’ve built one from the ground up, you’ll understand much more of what goes into them and what exactly they’re trying to accomplish.  You’ll be able to grasp the different containers in a record amount of time as well as make a much more informed decision about which container is right for your project.  Also, when the weird bugs inevitably start to happen, you’ll have a much better chance of understanding and resolving the issue quickly since you’ll have a good idea of what’s going on under the hood.

So How Do I Get Started?

By diving in head first.  Write a test that declares one task that you expect your container to accomplish.  Then, implement it.  Think through the easiest possible way that you could implement it and then try it.  You may be surprised how simple many of these things really are.  And if you get stuck, lucky for you there are dozens of open source containers out there waiting whom would like nothing more than for you to crack open their source and take a peak inside.

Where Do I Go Next?

Anywhere.  Pick any tool or framework you’ve ever wanted to learn more about and try to clone it.  No tool is too big or too small.  Remember, it doesn’t have to work perfectly or be production code, it just has to help you learn what’s going on inside of them.  Here are some ideas…

• Build an IoC Container
• This is the inversion of control container we’ve talked so much about.  Start with a hashtable, then figure out how you automatically find interfaces and their implementing classes.
•  
• Build an OR/M with code generation 
• Tired of handwriting SQL?  Then write a code generator that will generate C# files with all of that boilerplate code ready to and that perfectly maps your existing objects to your database.
• 
  Build and OR/M with code synthesis
• Now that you know how to map your objects to a database, see if you can cut out the middle man of needing to compile C# files and just generate the pure IL on the fly when you call your database.
  
  Build and AOP framework
• Aspect-oriented programming is beginning to become more and more prevalent in our industry today.  Give yourself a head start of being ready for the next wave of programming techniques by building your own AOP framework from the ground up to truly appreciate how they work.
• 
  Build your own xUnit-like testing framework
• When Kent Beck built JUnit he actually built it using test-driven development.  See you can do the same and beat the ultimate Chicken-or-the-Egg problem.
• 
  Build your own mocking framework
• Ever wonder what sort of black magic mocking frameworks really are?  Now’s your chance to find out, you don’t have to build the next Rhino.Mocks but see if you can at least get started and understand how they mimic the calls you tell them to.  Then, try and figure out the key implementation differences that give Rhino.Mocks and TypeMock such distinctively different strengths.
• 
  Build your own programming language for the CLR
• That’s right, you heard me correctly.  Design and build your own language.  The CLR makes this dramatically easier than you may have ever imagined, which is one reason why we have such an amazing selection of languages on the .NET platform.  You’ll be amazed how much of a better appreciation and understanding you’ll have of both the compiler and runtime after you’ve seen it from the bottom up.  Start with the basic control structures and syntax, then try to add in your favorite features from your favorite languages you’ve worked with.  You may even want to try to address some shortcomings of your favorite languages.
• 
  Build your own programming language for the DLR
  Now that you know what goes on behind the scenes with a statically-typed language, embrace the future and try your hand at a dynamically-typed language using the new DLR.  Build the next Ruby or Python and understand what really makes these languages different from the statically-typed beasts we’ve all grown so accustomed to in recent years.
•  
Hopefully this will get you started.  Remember, you’re not trying to re-invent the wheel with your own production-worthy implementations, you’re just trying to gain a better appreciation of what problems these tools are trying to solve and what’s really going on behind the scenes.  It may be simpler then you think.

*I just made that statistic up.
**Yup, that one too.