When I started to call myself a software developer, back in 2006, the title was a loose fit at best – I was very green, and I knew this, but I did my best not to let it discourage me too much.  One of my strongest assets has always been my ability to learn and adapt based on observation and practice, and to do so quickly.  Usually the process begins when I know there is a better way to do something, and set out in search of it.  When I find something of interest, I start to read into it, and usually that becomes the rabbit hole that sets me off on an adventure.

When I started doing research on NHibernate in late 2007 after being discouraged with traditional data access and drag-and-drop designers, I never would have expected the adventure it led me on.

It all started when I began to look at a proprietary code generator and how it worked, and the massive amounts of code it spit out based on the database schema.  For a couple of weeks I made my best attempt to dig in and find out as much as I could without having access to the actual source code for the generator, to see how the data access was done.  After all, very little had to be done on the part of the developers using the tool – all that had to be done was make the modifications to the schema and run the tool.

Why did I feel like I needed to understand this data access?  Well, for one, just to make my life easier using the tool and understanding how it worked.  Secondly, I wanted to see if there was anything I could adapt and use for my own applications, just in the way of general data access strategy.  I became frustrated, and soon gave up on using anything that this application was generating because it seemed too complex for just data access.  I wanted something better.

I still remember the first blog posts I read about NHibernate.  titled “A Journey with Domain Driven Design (and NHibernate)” over on Ben Scheirman’s blog.  Many of the entries in the series were dated back in 2006, but they were still applicable enough for me to get my feet wet using NHibernate.  I printed out hard copies of the whole article series and read them several times, wrote many several applications, and started to get the hang of things.  The POCO (Plain-Old-CLR-Objects) and Persistence Ignorance approach to data access really resonated with me, and I wanted more.  After reading through the series, however, I got many more ideas in my head, and became very thirsty for knowledge.

Through the article I became exposed to Test Driven Development (TDD) and Domain Driven Design (DDD).  The more I read, the more I wanted to learn.  When I came across the ALT.NET groups, practices, and ideas, I found that there were many others out there who shared some of the same frustrations I had with the Microsoft-centric nature of .NET development.  I was able to learn things like Dependency Injection/Inversion of Control and the SOLID Principles.  I am not just plugging buzzwords for the sake of plugging, all of these things I have learned in the last almost two years have made me a much better software developer.

Even better is that there are a lot of really smart developers out there who have done lots of work in the public arena to get these ideas circulating, and are very much the developers who I admire.  They make me, as a software developer who is still early in my career, want to work harder to achieve the same excellence.  Some of them are listed in my Blogroll, although looking at it now I realize I still have more to add.

I really do feel that we never stop learning, regardless of what career path we choose.  I know I have not and never will.  I am happy to say that I have continued to venture outside my comfort zone, trying new languages and new platforms for software development.  My craft is to develop great software, and maybe learn a thing or two while doing it to make the next project that much better.