Caffeinated Coder

I recently came across an excellent blog post via Dzone from Ben Watson called 5 Attributes of Highly Effective Developers.

He lists humility, love of learning, detail-orientedness, adaptability, and passion as the most important traits that a developer can have in order to be effective at their job and provides some well written insight into what he believes each of the different traits really means. For example, he has this to say about humility:

…humility isn’t pretending to be worse than you are and it’s not timidity. So what is it?

Simply put, humility is an understanding that the world doesn’t begin and end with you. It’s accepting that you don’t know everything there is to know about WPF, or Perl, or Linux. It’s an acknowledgment of the fact that, even if you’re an expert in some particular area, there is still much to learn. In fact, there is far more to learn than you could possibly do in a lifetime, and that’s ok.

Once you start assuming you’re the expert and final word on something, you’ve stopped growing, stopped learning, and stopped progressing. Pride can make you obsolete faster than you can say “Java”.

His thoughts inspired me to come up with a few corollaries of my own. I refer to them as corollaries because some of them are related to humility and passion, which are Ben’s attributes.

Ensure the Right Problems are being Solved

One of the fastest and most talented developers I’ve ever worked with also turned out to be the least productive member of the team because he continually had to rewrite his code since it never matched what the stakeholders envisioned. I’ll be the first to admit that stakeholders are a fickle bunch, but other developers on the team, who were not nearly as fast or smart, turned out to be much more effective in the long run simply because they constantly asked clarifying questions and sought regular feedback on their work. That led me to one of my most important maxims: It’s not how fast you can churn out code that matters, but how long it takes you to get an acceptable product to your stakeholders.

Creatively Reformulate Problems

Some of the most productive moments I’ve had in my career have resulted from taking a step back from a difficult problem and critically thinking about each of the problem’s underlying assumptions. Many times the assumptions proved to be erroneous or incomplete, thus making way for a much simpler solution. I can think of a few instances where I was able to get around the problem by creatively tweaking the user interface or workflow.

Other times I’ve been able to eliminate the problem entirely by honestly communicating the cost of the feature to the stakeholders, who then removed it from the project list because it didn’t provide enough value to justify the cost. There are definitely times when the brute force technical approach will be required, but I think a developer who is willing to try finessing a complicated problem first will almost always come out ahead.

Use Questioning As a Learning Tool

Sometimes it is not a matter of knowing what question to ask, but rather knowing when to ask it. I recently caught myself squandering perfect learning opportunities because I was afraid that asking my questions would make me look stupid. Conversely, I routinely witness developers pass up similar learning opportunities because they view another person’s skills or platform as vastly inferior to their own and thus erroneously assume that there are no valuable lessons to be gleaned.

On the opposite end of the extreme, it is common to waste learning opportunities by too quickly asking to be spoon-fed an answer without first applying any effort to solving the problem. It is justifiable to occasionally take shortcuts when the project is under a tight deadline or you are in a true collaborative mode (i.e. pair programming), but I think that truly effective programmers value the research and problem solving skills more than one single answer and will thus tend to discipline themselves to be a little self-reliant whenever possible in this area.

Temper Passion with Pragmatism

I agree with Ben that passion is a key trait to look for in a developer, but I’ve also seen otherwise brilliant developers reduced to utter ineffectiveness because they expressed their passion in negative ways one too many times and consequently alienated their co-workers and destroyed their own credibility. Unless you’re spiking the workplace coffee with mind control drugs, you’re likely to only have a limited amount of persuasive currency to spend on convincing your co-workers to switch to the latest and greatest language, tool, framework, or process. Truly effective developers are good at prioritizing the changes they want to help bring about and will consequently let the little things go (without so much as even a snide comments).

The other thing I notice in effective developers is that their passion is grounded in some form of objective criteria so that they are able to calmly provide both pros and cons of a technology that are situational based. That means that they can immediately identify situations where their favorite technology would be inappropriate. Passionate developers who are ineffective don’t often make such a distinction, which usually leads me to conclude that what they are really need is a religious cult or social club to fulfill whatever void that their current language, framework, or platform of choice is filling for them.

In conclusion, it takes more than raw mensa level brain power and passion to be effective at your job. If you want to be or find someone who is both Smart AND Get Things Done, then you have to focus on a few non-intellectual qualities like emotional IQ and self-awareness as well.

This is the sequel to my Seven Things I Did Right in 2007 post. Now I am going to cover the “Stop Doing” and “Start Doing” categories of my agile retrospective format.

What I want to start doing in 2008

1. Become a Committer on an Open Source Project- I took a few steps towards open source involvement with the Cruise Control project this last year, but still haven’t even submitted a fix to an open source project yet. Partly I want to become a committer because I feel guilty for all the free stuff I’ve enjoyed from the open source world over the years without ever contributing anything back, but I also think that this will be a good career growth opportunity in that it would expose me to new codebases, development styles, and project types that I don’t usually get to work on.
2. Establish Book Reading Habit- I can’t help but feel embarrassed every time I walk past my bookshelf these days and see the dozen technical classics that I’ve only partially read. I decided that the only way I’m going to finally finish them all is if I carve out a regular reading schedule. I’m going to start by spending 2-3 lunch hours a week reading in a nearby cafe.
3. Seek out new kinds of speaking and writing opportunities - This year I’d like to challenge myself to speak at bigger venues like code camps or conferences. As far as writing goes, I would like to submit at least one article to a major publication like MSDN magazine as well as seek out some paid guest blogging opportunities.
4. Learn Ruby - Partly I have this as a goal because I am sick of reading all the hype without any first hand experience on which to form my own opinions. Mostly, however, I finally have a real reason to use it because my wife wants me to build a site for her new jewelry business and my hosting company already has the required Ruby infrastructure in place.
5. Start using ORM frameworks and IoC containers - I feel as though I missing out on a couple of extremely key technologies by not using frameworks to assist with data access and dependency injection. That is why NHibernate and the Windsor Container are at the top on my list of things to learn and start incorporating into current projects in 2008.

What I started in 2007 that I want to STOP doing:

1. Staying up too late - I used to get to bed at a decent hour, but during the last six months I have been regularly staying up until 1 or 2 in the morning reading blogs, writing posts, and playing around with new tools and technologies. Although that is a very productive time of the day for me, I’ve also noticed my alertness the next day tends to suffer. A sleep deprived developer is a stupid developer, so I’m going to try to discipline myself to stop working a little bit earlier each night this year.
2. Reading only about technology - For the first time ever, almost all the reading I’ve done this last year has been technical. Besides making me extremely boring to talk to, I fear that I am also on a course to burn myself out. My first task is to find some good fiction books to read this year. I’m open to suggestions…

Since continuing old habits is much easier than starting new ones, time will tell whether or not I will be successful in any of these endeavors. Regardless of the outcome, I do think there is value in at least taking the time to formulate and verbalize a plan.

I know this is rather late in January to be doing this, but I’ve been rather distracted with the blog migration and this was one of several posts that’s been languishing in a half-finished state in my drafts folder for the last several weeks.

Instead of doing the typical new year’s resolution list full of unrealistic goals, I decided that I would follow an agile retrospective format and sort my thoughts into the “Keep Doing”, “Start Doing”, and “Stop Doing” categories. In this post I will just focus on the “Keep Doing” part and then I’ll tackle the other two categories in the next post.

Here are seven things I would like to keep doing in 2008.

1. RSS Surfing - It wasn’t until the beginning of 2007 that I really became an avid reader of blogs. Now I struggle to keep my hundred plus feeds organized and prioritized, especially since I supplement the flow of information with posts from Reddit, DZone, and del.icio.us. Despite the overwhelming amount of material, I am still hooked on the blog format and see it as the single biggest driver for my professional growth this last year.
2. Blogging - Besides enjoying the actual process of writing, I have been surprised by the affect this blog has had on my motivation to learn new things and dig deeper into my current understanding of technologies and practices. I don’t know how many times I’ve stopped in the middle of writing a post to research something more in depth or try out something new because writing about it helped me detect a gap in my understanding that I otherwise would not have noticed.
3. Speaking - I volunteered to speak at two .NET user group meetings for the first time in my career this last year and was pleased with the results. Whereas blogging encourages me to dig a little deeper into small pockets of knowledge, a commitment to speak for 30-60 minutes on a topic forced me to go very deep into a subject and begin to gain some real expertise. There’s nothing like the fear of looking stupid in front of a group of people to make you hone your skills.
4. Social Networking - Last year was the first time I made a consistent effort to develop and maintain professional relationships outside of my immediate workplace and it has had a profound impact on my professional growth. I’m not talking about the benefits that come from shmoozing my way into opportunities that I’m not qualified for or don’t deserve. I just mean that I’ve noticed that the more time I spend interacting with really smart people, whether through conferences, user groups, blogs, or email, the more new ideas I encounter and the higher expectations I tend to adopt for myself.
5. Automating My Workflow - It takes effort and discipline to invest in your own productivity, especially since it often slows you down in the short term. Traditionally I have been too focused on my short term goals to put much effort into removing inefficiencies in my own work processes. This last year, however, I worked hard to start identifying and streamlining my own needlessly repetitive tasks with the help of tools like ReSharper, WinKey, and SlickRun. I’ve been extremely happy with the results so far and look forward to learning new productivity tricks this year.
6. Taking Professional Risks - Last fall I took a big risk by changing jobs. I had invested almost 5 years at my old job in learning the intricacies of the internal systems and the business domain as well as earning the trust of my co-workers . The idea of starting from scratch was scary. Although there were times when my ego didn’t appreciate becoming a novice again, the rate of my professional growth has skyrocketed from being exposed to new methodologies, domain challenges, codebases, and people.
7. Regularly Experimenting with New Tools - Thanks in part to Scott Hanselman’s tool list, I’ve added more tools and utilities to my developer toolbox this last year than I ever have before and it has dramatically increased my productivity. Some of the new tools that I picked up this last year include ReSharper, SlickRun, PowerShell, MbUnit, FxCop, NDepend, Espresso, JIRA, NCover, WatiN, Firebug, Nant, and Rhino.Mocks.

I have certainly done plenty wrong this past year, but I like to spend time focusing first on the positive aspects of whatever I’m trying to improve. I find it helps me solidify good habits that I may have only accidentally acquired in the first place and will probably lose unless I make a conscious effort to recognize their value.

Don’t get excited. This is not a geek version of the “Birds and the Bees” talk.

I just finished reading another excellent scientific paper called The Expert Mind, which I discovered through one of Jean-Paul Boodhoo’s posts. The article examines the question of whether experts are born or made and offers some interesting insights into what it means to be an expert and the best ways to become one.

As you probably guessed from my recent “Is that Juice On Your Face?” post, I am fascinated by the question of competence and what leads some people to attain it while others, like the Juice Bank Robber, …well…er…don’t attain it. I often marvel at how some developers who are relatively inexperienced and have only average intelligence are able to attain a high level of knowledge and expertise that surpasses battle-worn industry veterans and off-the-chart mensa types. This article not only attempts to explain this mystery, but it does so through one of my favorite hobbies, Chess.

If you’ve ever seen exhibitions by Grand-Masters who play against scores of opponents simultaneously while blind-folded, it is easy to dismiss such people as talented freaks of nature with computer-like powers of analysis and photographic memories rather than view them as merely experts in their field who have trained themselves through long and intense study.

However, recent studies show that chess masters have only average abilities when it comes to memory and visual-spatial analysis. For example, despite having almost perfect recall for board positions related to actual games, the recall of grand masters turned out to be no better than average players when the pieces were arranged randomly on the board in unrealistic scenarios.

Based on evidence like this, the authors conclude that experts rely not so much on an intrinsically stronger power of analysis as on a store of structured knowledge, which takes an enormous amount of time and effort to attain. What appears to make much more difference than experience or talent is what the authors call “effortful study”, which entails continually tackling challenges that lie just beyond one’s competence.

It turns out that what differentiates an expert from a novice isn’t that experts alone know how to engage in effortful study, but it is that experts continue to utilize this technique long after a novice stops.

Even the novice engages in effortful study at first, which is why beginners so often improve rapidly in playing golf, say, or in driving a car. But having reached an acceptable performance–for instance, keeping up with one’s golf buddies or passing a driver’s exam–most people relax. Their performance then becomes automatic and therefore impervious to further improvement. In contrast, experts-in-training keep the lid of their mind’s box open all the time, so that they can inspect, criticize and augment its contents and thereby approach the standard set by leaders in their fields.

Thus it appears that motivation is a more important factor than innate ability in the development of expertise. If you truly want to become an expert, then you have to resist the pull of complacency and constantly approach your field with the same passion, curiosity, and effortful study that you did when you first started.

So if being an expert appeals to you (which it probably does if you’re bothering to read professional blogs), then you have to start by asking yourself one question. Can you honestly say that you are still improving rapidly because you approach software development with “effortful study” or is your progress occurring at a snail’s pace because you are stuck in that complacent stage?

A psychology study entitled Unskilled And Unaware of It: How Difficulties in Recognizing One’s Own Incompetence Leads To Inflated Self-Assessments opens with the following amusing anecdote:

In 1995, McArthur Wheeler walked into two Pittsburgh banks
and robbed them in broad daylight, with no visible attempt at
disguise. He was arrested later that night, less than an hour after
videotapes of him taken from surveillance cameras were broadcast
on the 11 o’clock news. When police later showed him the surveillance
tapes, Mr. Wheeler stared in incredulity. “But I wore the
juice,” he mumbled. Apparently, Mr. Wheeler was under the
impression that rubbing one’s face with lemon juice rendered it
invisible to videotape cameras (Fuocco, 1996).

The paper then goes on to describe the results of four studies which led researchers to conclude the following:

1. Incompetent people will tend to grossly overestimate their skills and abilities. A part of the study, the subjects were given various tests and then asked to predict their scores and relative rankings. People in the bottom quartile overestimated their performance by an average of 45-50% while people in the top quartile actually underestimated their skills.
2. Incompetent individuals fail to gain insight into their own incompetence by observing the behavior of other people. After being allowed to review the test results of their peers, the estimates of the bottom quartile actually worsened while the estimates of the top quartile improved. This led researches to conclude that the mis-calibration of the incompetent stems from an error about the self, whereas the mis-calibration of the highly competent stems from an error about others.
3. The way to make incompetent individuals realize their own incompetence is to make them competent. In the last study, researches found that the estimation skills of the bottom quartile dramatically improved if they were given training in the domain knowledge of the test. Not only did their scores improve, but they finally became aware of their short-comings relative to their peers and revised their prior estimates downward.

This leads me to the following thoughts:

If you really did have juice on your face, you’re probably wouldn’t know it. This is a sobering thought. As Darwin said, “ignorance more frequently begets confidence than does knowledge“. In other words, if you are feeling particularly confident, then it is a good sign that you have some more learning to do.

The best way to ensure there is not juice on your face is to constantly seek feedback and learn: I like to think of this as a Continuous Integration for the mind. In order to become competent, I need to constantly feed new ideas and skills to my mental compiler and then unit-test them through rigorous community and peer feedback.

As a side observation, I couldn’t help but be impressed with the rigor with which these studies were conducted. It made me realize that there is a close correlation between proving a scientific hypothesis and debugging software. It is one thing to think you know the cause of an observed phenomena or an erratic, opaque bug, but it takes carefully planned and executed tests in order to adequately prove it.

I was setting up Cruise Control the other day and trying to figure out why it wasn’t working on a certain source control folder. I noticed a strange error in the cruise control log about there being an invalid character in the path, so I decided to take advantage of the fact that it is an open source project and download the source code so I could step through it in the debugger and see what the exact problem was.

It wasn’t long before I discovered the source of the error, which was a newline character embedded in the source control folder name. Since I am a vocal Visual Source Safe hater, I naturally assumed that the problem had to do with VSS data being corrupted so I scheduled some VSS maintenance and called it a day.



When VSS analyzer did not fix the problem, I took a closer look and realized that I had unfairly blamed VSS and the real problem was a bug in the Cruise Control code that parses out the output from the VSS command line tool (thank god PowerShell eliminates the need for much of this parsing voodoo). If the folder path in VSS is too long, then the command output wraps and Cruise Control incorrectly inserts a newline character inside the folder path.

The problem was easy enough to fix by stripping out the rogue newline character, so I recompiled Cruise Control, replaced the problem dll, and all was well in the world.

At that point, it occurred to me that other people must be running into this problem, so I decided to try being a good open source citizen for once and submit the bug fix. I had never tried this before, so I read the contribution procedures posted on the home page and followed their polite suggestions. I created a diff file of my fix, wrote up a detailed description of the problem, and even found a unit test that someone had commented out that failed under the current code base and worked with my fix.

I was just about ready to submit a JIRA ticket in their bug tracking system, when it occurred to me that I should probably browse the current VSS tickets first. It turns out that my issue was not only recorded in the system, but had just been marked as resolved by someone else the week before. Doh! I guess I should have tried that first, huh?



Oh well, at least I got practice going through the procedure for being an open source contributor. There are still an lots of open tickets for the current Cruise Control release, so perhaps I’ll grab one of them while I have everything already set up.

After all, I don’t want to be an open source virgin forever.

I seem to have kicked into a professional goal setting mode lately and fixated on a number of ambitious goals, such as publishing technical articles, speaking at major conferences, and creating my own version 1.0 software. Although I feel invigorated by the challenge posed by these new goals, I also have the nagging feeling that I am making a mistake by going down this road.

Don’t get me wrong, it is not that I am morally opposed to having goals. On the contrary, my personality thrives on them. I get a thrill from breaking my own self-imposed boundaries whenever I latch on to goals that seem well out of my reach. I like strategically planning out how to achieve a goal and then carefully charting my progress towards the finish line. The satisfaction I feel right after accomplishing a goal is down right addictive. Mostly, I suppose that I like the structure that having goals provides my life.

Unfortunately, I have been on the achievement roller coaster enough times in my life to realize that the psychological rush that follows attaining a goal is relatively fleeting compared with the sense of disappointment that usually follows. I often cope with this uncomfortable feeling by immediately distracting myself with an even more challenging goal. Sometimes, however, I fall prey to a deep sense of disillusionment and can’t help feeling like I have just wasted precious time valuing something that ultimately doesn’t matter.

So what is a goaloholic like me supposed to do?

It is not as simple as going cold turkey. Whenever I try to swear off goals, I usually get bored and nagged by the feeling that I am wasting my potential and dulling my senses. This somehow feels like an even worse sin than my goal addiction, so I inevitably get back on the goal bandwagon.

Is there no middle ground between these two extremes?

The one thing that does seem to help me in times like this is to remember back to a lecture that I heard in college on flow. Flow is a mental state of hyper concentration that highly skilled individuals who are doing highly challenging work can attain. Athletes sometimes refer to this mental state as being ‘in the zone’.

When you are experiencing flow, then you are so absorbed in the task at hand that you get a distorted sense of time so that you are likely to suddenly look up from what you are doing and be surprised that hours rather than minutes have passed.

When you experience flow, the activity itself is intrinsically rewarding, so your actions seem effortless. This zen-like focus on the present moment offers a stark contrast to the darker side of achievement, where the focus is completely future oriented and on the end result rather than the process.

I occasionally experience flow while programming, but would like to experience it much more frequently.

Ironically, since a prerequisite for experiencing flow is both a high degree of skill and a high degree of challenge, most of my current goals can actually help me achieve this coveted mental state. However, elevating the experience of flow over the achievement of goals somehow makes my goals seem much more palatable. They are now merely laying the groundwork for a more substantive and longer lasting experience rather than being the ultimate prize.

Has anyone else experienced flow? Has this experience been substantive enough for you to be a primary motivating force in working towards excellence or are there other more compelling reasons that drive you to excel?

Preemptive P.S. - While having women swoon and throw panties at you is certainly a compelling and motivating force, it is probably not a legitimate expectation for anyone other than Justice Gray.

It’s been two months since I set out on my 6 month self-improvement plan to being a better developer. During my last one month update, I set out some specific goals for month two that involved learning about Resharper, NDepend, F#, the Windsor Container, and the ROTOR codebase and then writing some blog posts about my efforts. How did I do this last month?

First, I accomplished one major thing that wasn’t even on my radar screen when I came up with my goal list. I resigned my position as an architect and took a job closer to home as a C# developer. I think it finally occurred to me that if I was on the right career path, then I would have written a post about being a better architect rather than one about being a better developer. Certainly, the most important step to becoming a better developer is to actually spend the majority of your time developing, which was something I was doing less and less of at my old job.

I also think that it is important to challenge your biases by periodically exposing yourself to new languages, processes, and problem domains. In that sense, I think my decision to leave my comfort zone in a VB.NET shop in the banking industry and switch to a C# shop in the retail industry will do more to make me a better developer than all my original goals put together. That being said, how many of my original goals did I manage to accomplish?

I do feel pretty good about the amount of time I spent on my tool goals this month. With Resharper, I actually took the bold step of shelling out my own money for a personal license so that I could use it at home and on my new job (ok, I was spoiled as far as licensing goes in my old job). I also wrote a few posts sharing some learning resources I used, expressing my desire to be a Resharper Jedi, and singing the praises of the unit test runner. For NDepend, I mused on its proper place in the ever elusive quest for code quality, shared my experiences with analyzing WatiN, and explained some of the basics of CQL.

I also made satisfactory progress on my code reading goal, although I didn’t do it with ROTOR like I originally planned. I did actually download ROTOR, but once I realized that the codebase was in C++ and thought about the fact that I should probably be spending my time looking at C# code because of my new job, I opted to spend time digging into WatiN instead. I wrote some general thoughts on exploring a new code base and shared some setup notes that gave me trouble when first trying to build the project.

My non-MS goals did not go nearly as well. After successfully registering for the ALT.NET conference, I decided to swap out my F# goal for my Ruby on Rails goal in this category. I did get a few chapters read in Ruby For Rails by David Black, but I’m still making my way through the basics and haven’t reached any epiphany moments yet that were worth writing about.

I got nothing at all done on my Windsor goal and did not make any contributions or opening inquiries into an open source project yet. I think I am going to wait until I figure out which tools I will be using extensively in my new job before committing to an open source.

So what’s on my agenda for the next month?

1. Tools: Regulator, MBUnit, and more on NDepend
   
2. Code Reading: Rhino.Mocks
3. Non-MS: Ruby on Rails
   
4. Higher on the Abstraction Stack: NHibernate

Once again, I will aim to write at least one post on each of the topics in the next month. Hopefully, I will attain all of my goals this time around.

Participating in the open source community and becoming an avid code reader were two themes in my six month roadmap to becoming a better developer. I made progress in both of these areas in the last few days by downloading and exploring the source code for WatiN, an open source library that I have used recently for creating automated web tests. I still have quite a bit more exploring to do before I’ll fully grok how WatiN works, but I thought I would share a few of the code reading techniques that I’ve been finding helpful.

My preferred starting place on any new project that has good unit test coverage is to pick some unit tests for common scenarios and then run them through the debugger. I chose the Google() test from the IETest class in the WatiN test project because I had done the equivalent in my own test code when first learning how to use the library. As a side note, this was the first time that I’ve used the Resharper test runner and I was duly impressed (I’ll wait until the next post to share my thoughts on how it compares to other test runners).

Once I get a feel for the style and basic flow of the code through some of the common usage paths, I then find it helpful to use Resharper’s Type Hierarchy window and VS’s Class Diagram to explore the inheritance hierarchies.

The Type Hierarchy window window in Resharper works well when I am in the middle of examining code and want to know more about the classes being used. Several other options under Resharper’s Go To menu, such as Usage, Inheritor, and Base also work well for this type of exploration.

 

 

 

 

 

 

 

 

 

 

Finally, at some point I usually want to understand the big picture and see how all of the classes relate to each other. In this scenario, the View Class Diagram in the Visual Studio Team Edition really shines. It is especially nice since you can adjust the level of detail you see and then simply jump back into code by double clicking on a class whenever you are interested in a particular member.

 

Here are a few setup notes to keep in mind if you decide to download and build WatiN yourself:

• I downloaded the 2.0 zip file that contains the source, but the solution file that comes with it appears to still be in a 1.1 format because it prompts you to upgrade the project when you open it in VS2005.
• You will then get a compile error that the name ‘isSTA does not exist in the current context’ because the required conditional compilation symbol is not set in the solution.You will need to add ‘NET20′ to the Conditional Compilation Symbols field on the build tab under the project properties.
• In order to get the Test project to compile, you will need to download the Rhino.Mocks dll and fix the missing reference.
• Depending on which test runner you use, you may find that the majority of tests fail due to the apartmentState not being set to STA, which can be fixed with a config file change.The Apartment Thread needs to be set to STA because WatiN uses COM interop with Internet Explorer.
• If you try to download and upgrade the 1.1 version, the project will have an invalid reference to Interop.SHDocVw because VS2005 has a different wrapper around IE than VS2003. In this case, you’ll need to manually remove the invalid reference and add a reference to ShDocVw.dll from the System32 directory.

Happy spelunking!

One month ago, I joined the epic struggle of Justice Gray (a.k.a. ”Justin the Metrosexual”) to “change the world” by publically sharing my roadmap to becoming a better developer. Justice’s own dubious plan involved reading one developer book a week for six months while presumably trying to prevent his brains ooze out of multiple orifices, a truly remarkable feat that should not to be attempted by anyone who has legitimate fears of losing cerebral tissue in a horribly sticky, uncomfortable manner.

Because misery loves company, he also started a mad game of tag with the aim of tricking as many other developers as possible into publically agreeing to give up their own free time in the name of becoming even geekier. I personally think that this whole idea was simply a plot hatched by Justice with the aim of diverting otherwise virile programmers away from the limited female population that will have anything to do with geeks in the first place, thereby improving his own otherwise meager odds. I mean come on…have you seen his picture? He obviously needs all the help he can get…:-)

In commemoration of my own one month anniversary of having succumbed to this evil plot, I feel compelled to provide a progress report. So far, I have made modest gains in exploring non-traditional MS technologies by working my way through various tutorials on Boo and the Windsor Container. I also inched my way closer to the open source world by familiarizing myself with the PoweShell Community Extensions and kick-started my goal of become an avid code reader by downloading and perusing the code in the SubText project. As far as tools are concerned, I spent several hours puzzling over the various graphical reports of NDepend trying to figure out the ins-and-outs of cyclomatic complexity. Not a bad start, but time is dwindling away and I’m not quite as far along the path as I had originally envisioned.

In the spirit of holding myself accountable through public humiliation, I am going to try to increase my pace a little by committing to more concrete goals for next 30 days. Since I shy away from writing a blog post on a technical topic until I reach a certain level of understanding (it’s all relative of course), I am going to commit to writing at least one blog post on each of the following goal-related topics during the next month:

1. Tools: NDepend and Resharper
2. Expand OOP/MS horizons: Windsor Container and F# 
3. Code Reading: Rotor

I am also going to take a baby-step into the open source world by writing a personal email to Keith Hill offering my humble services on the PSCX project. If he is smart, he’ll say no, but at least I will have made an effort.

Until next month, may you have success in achieving your own developer goals while still managing to stake your claim on the geek-loving female of your choice.

P.S. - I recommend that you immediately delete any email or blog post that contains the word “Tag”. No good can come of it.