Caffeinated Coder

I just heard about Justice Gray’s blog challenge from the latest episode of Hanselminutes while running today. Although I think his plan to read one developer book a week for the next six months is rather insane, I agree with the premise that setting specific goals publicly is probably the best way to hold yourself accountable. Here are my goals for the next 6 months:

Add Tools to my Developer Toolbox - My productivity and troubleshooting skills would plummet if I were to suddenly stop using utilities like FileMon, RegMon, Fiddler, ProcessExplorer, TestDriven.NET, MSBuild, SQLPrompt, SQL Profiler, WinKey, and Lutz’s Reflector. In the next six months I am going to learn to use Resharper, NDepend, Roy Osherove’s Regulator, and a good packet sniffer (not sure which one yet).

Become an Avid Code Reader - Writers are commonly given the advice to read good books in order to become a better writer and I think the same holds true for developers and code. Unfortunately, it is easy to get caught up in only writing code or only reading a small subset of internal code that you are stuck supporting. I have my eye on several open source projects that I’d like to spelunk in the near future, including the Rotor implementation of the .NET framework, SubText, DasBlog, RSS Bandit, NHibernate, Rhino.Mocks, and WatiN. I also plan to use Reflector more often to decompile .NET assemblies and figure out how .NET framework and how other third party, non-open source .NET utilities work.

Step outside of my MS-OOP comfort zone - My big goal is to get through the Ruby For Rails book that has been sitting on my shelf for the last six months so I can see why there are so many Ruby fanatics and why dynamic languages in general are becoming so popular that even Microsoft has jumped on the bandwagon (Lamda Expressions, the DLR, IronPython, IronRuby, etc.). I am also interested in learning more about the various Castle projects, especially the Windsor Container which is supposed to help enforce the IoC (Inversion of Control) design principle that helps remove complexity and increase testability by parameterizing embedded dependencies. I would also like to install Ubuntu on a VM so I can see what the Linux OS looks like these days as well as make my way through an F# tutorial so I can break away from my OOP bias and understand the functional language perspective. Finally, I want to experiment with Boo, a CLI language that is a hybrid of Python, Ruby, and C#.

Become a Better Developer Community Citizen-  I’ve already taken steps in that direction this year by becoming more tuned in to the blogger community, starting this blog, attending local .NET user group meetings, and even agreeing to speak on Powershell at the next Topeka .NET User Group meeting. What I would really like to do in the next six months is to start contributing code to an open source project. I’m open to suggestions at this point…

Push Myself Lower and Higher on the Abstraction Stack - From a productivity standpoint, I think it is crucial at this evolutionary stage of the software industry to figure out ways to avoid writing tedious boilerplate and plumbing code by utilizing higher level abstraction tools as much as possible such as code generators (CodeSmith) and ORM tools (NHibernate). Conversely, I also plan on filling in some gaps in my own understanding by dropping lower on the abstraction stack and finishing a MASM Assembler tutorial I downloaded a while ago.

I am not going to create a firm schedule for these goals like Justice Gray did because I am much more productive when I let natural curiosity determine the sequence of learning. However, I am going to commit to writing at least one post on each of the following topics over the next 6 months:

• Resharper
• NDepend
• Regulator
• Packet Sniffer
• Impressions on the source code from at least one open source project
• Ruby On Rails
• F#
• Ubuntu
• Anouncement of which open source project I joined
• NHibernate
• Windsor Container
• CodeSmith
• Assembly

Whew, maybe I should have just agreed to read one book week too…

Fattening Abstractions - There is great power in naming things, which is why it is an integral part of nearly all creation stories (i.e. Adam naming all the animals in the Christian Bible). Unfortunately, learning acronyms, buzzwords, and high level abstractions often fools us into thinking we know more than we really do. This is why I’ve interviewed candidates who could talk for hours on end about service oriented architecture, but failed miserably when it came to a simple fizzbuzz programming test.

High Calorie Public Opinions - The blogosphere is full of brilliant people who passionately articulate their beliefs. Unfortunately, the human need to fit into a community (open source, java, ruby, agile, alt.net) often trumps the desire to keep an open mind. While the person who originally formed the opinion derived great value from the decision making process, the casual reader who easily adopts opinions like a new piece of trendy clothing gains nothing but unfounded and potentially misapplied biases.

Sugary old Habits - Paradoxically, the better you become at something, the more difficult it can be to learn new things. Once a habit becomes second nature, we forget that there are other alternatives and that we probably made our original choice at at a time in our careers when we knew less than we do now. This human propensity to stick with things that are comfortable and have worked well in the past is why the most experienced people in our profession are so often dismissed as irrelevant rather than respected.

Just one more block - The most helpful habit I’ve adopted while running is to respond to my first impulse to stop running with the mantra, “just one more block”. I think this also works well with learning. The next time you feel the urge to fall back on that same worn-out API or unproductive GUI-oriented approach, discipline yourself to take a minute and learn just one new method or one new keyboard shortcut. The investment will pay great dividends down the road.

Empty your Cup - This is a phrase that I remember from some zen book that I read in high school. The idea is that in order to learn something more deeply, you often have to intentionally forget what you already know so that you can approach things with fresh eyes. The next time you catch yourself dismissing a learning opportunity because it pertains to something you think you already know or have a strong opinion about, pretend that you are a newbie and see if you can glean an new tidbit or perspective.

Bite your tongue - Every once in a while, I’ll catch myself talking about or recommending a technology or tools that I’ve only read about but never used. I am now trying to get into the habit of not letting myself talk about anything unless I’ve at least downloaded the technology and done a proof of concept for myself. For me, this serves as extra motivation to take the next step in learning.

Approach documentation like a scientist - Treat techniques you read about like an hypothesis that you must scientifically prove with a unit test before you can confirm that it is true. I’ve caught myself several times regurgitating something I’ve read that I thought was very straight-forward only to discover later that I’ve slightly misinterpreted how it works. Documentation and resource sites are subject to the same ambiguousness and misinterpretation as requirements. Don’t trust your understanding until you’ve seen it with your own eyes.

If you’re crazy enough to run marathons for fun like me, you are probably familiar with a concept called cross-training. This slightly counter-intuitive approach asserts that you can actually increase your performance in your chosen sport by doing it less frequently and supplementing it instead with complementary activities. In other words, you will run faster and decrease your chance of injury if you replace a few training runs a week with weight-lifting, biking, or swimming.

I think the same principle holds true in the IT world. There are clear boundaries and activities that define what a normal developer activity or skillset is and I’ve noticed a strong tendency in both myself and other developers to stay within that comfort zone not engage in cross training by expanding our knowledge into complementary disciplines.

Developers commonly learn to write complex queries, use the ipconfig or ping utilities, and upgrade their own RAM, but usually defer to DBAs and network admins when it comes to index tuning, group policies, or rebuilding machines. It is easy for a Microsoft developer to ignore the open source community and never learn to use other platforms and languages. Corporate developers who are younger or come from a non-CS background rarely look lower on the abstraction stack than the Base Class Library to learn about assembly, core programming algorithms, the inner workings of a compiler, or the win32 API.

So what are some good steps to take in order to avoid this informavore trap and begin a technical cross training program? One activity that has worked out nicely for me so far is listening to RunAsRadio, a podcast co-hosted by Richard Campbell of dotnetrock’s fame that covers diverse IT Pro topics such as network storage technology, application virtualization, MOM, IIS7, the future of 64 bit computing.

Another activity that I plan to continue is the self-paced tutorial on Assembly that I started a few months ago with MASM. I wouldn’t want to program in Assembly for a living, but it’s not nearly as scary as people make it out to be and it has greatly helped me visualize what is actually happening at the processor level.

Finally, I am way behind the curve when it comes to learning about Ruby on Rails as well as exploring several Alt.NET open source frameworks such as Spring.NET, Windsor and MonoRail, so I plan to devote as much of my spare time as I can expanding my horizons in this area in the coming year.

Jeff Atwood recently wrote a blog post on Informavores that uses a food foraging metaphor to describe typical web usage behavior. According to this analogy, the ultra short attention span of most web users is not due to laziness or cultural ADD, but has more to do with an innate survival instinct that leads us to try to get the maximal benefit for the minimal amount of effort.

With billions of pages of content and sophisticated search algorithms that are spookily accurate, it just doesn’t make sense to spend time on pages with a ‘weak information scent’ when the information we want is likely on the next result page for a fraction of the effort. So the next time you start feeling guilty about hitting the back button within seconds of the page loading, remember that your itchy trigger finger may not stem from a character flaw but rather an appropriately unforgiving predatory instinct. Now, if only I can come up with an equally flattering metaphor for TV channel surfing…

Along the same lines, I’ve been thinking about a few common pitfalls that I’ve noticed myself and other developers fall into that I’ll call Informavore Traps. Here’s a short synopsis of a few anti-patterns of information foraging that I think tend to stunt our professional growth as developers and keep us low on the alpha-geek food chain.

• Self-Imposed Boundaries - These are unnecessary mental filters or borders that we construct in our minds that severely restrict our hunting territory.
• Indulging in Information Junk Food - This is the tendency to stop consuming knowledge on a subject once we establish a command of buzzwords and recycled blog opinions.
• Jack of All Trades, Master of None - This refers to the tendency to spend too much effort on gaining a wide breadth of knowledge and not enough time to become an expert in a particular field.

I’ll discuss my thoughts in detail on each of them during the next blog posts.

I’ve noticed my geek ego being aggravated a few times lately so I figured I’d better work on a more effective personal implementation of IHumbleProgrammer. My current implementation seems to be leading to errors in my thought process and even causing my learning to hang. Please excuse the VB.NET, poor formatting, and lack of a valid unit test.

I listened to an interesting prodcast on Channel 9 on my way to work this morning. I never had an inclination to listen to the MicroISV show before, but the title intrigued me: CrazyBusy - Overstretched, Overbooked and About to Snap! Strategies for Coping in a World Gone ADD“.

Multi-tasking has never been a strength of mine so I may be biased, but I definitely agree with his premise of the show that the frenetic pace that most of us sustain these days due to new technologies such as cell phone, PDA’s, and the internet is actually causing us to get less done. I view it as similar to the issues faced when doing multi-threading in programming. When used judiciously, multi-threading can dramatically increased the perceived speed and responsiveness of the application. However, if you go crazy with the number of threads that you use, the app will actually slow down to a crawl because it is spending all of its allotted slice of time just to reload the required data in memory and by the time that happens there is barely any time left to do any work before having to release control to another thread. It’s the same way with life, it may look like someone is getting a lot done when they are juggling dozens of projects at once, but it has been my experience that in reality the overall speed and quality decreases dramatically.

So how do you stop the madness? As for myself, I think I’m going to start with my email habits. This tends to be the single biggest interrupter during my day since I usually drop everything whenever I notice an email pop-up notification, even if it is just to read and delete it. I think I’m going to force myself to actually close Outlook and only check it on an hourly basis instead. The vast majority of time someone will talk to me in person or call me if they need something answered right away, so I might as well take advantage of the asynchronous nature of email and just ignore them until I am at a natural stopping point in my work. I’m also going to try to decrease the number of active projects that I have going on at any point in time as well as the number of technical topics that I explore. I’ve had a nagging feeling for a while that my understanding of topics is becoming more and more superficial and now I feel certain of it. Perhaps, I’ll even try to narrow the number of blogs that I track…nah….

[Wednesday, June 13, 2007 5:20 PM]