Becoming A Better Developer

Are You Mocking My Code?

Russell Ball — Wed, 19 Dec 2007 06:12:44 GMT

I've been playing around with mock objects using Rhino.Mocks for the last few months, but today was the first time that I had an unfettered coding win and became a true convert.

I was introduced to NUnit about five years ago from a co-worker (thanks Dewayne) and gradually became a true believer. Unfortunately, I was a late-bloomer in the area of mocking, so by the time I finished my last big project I had left a suite of about 500 database driven tests that took almost 2 hours to run and were a maintenance nightmare. The vast majority of my unit testing efforts revolved around SQL initialization and cleanup scripts that massaged the database into just the state I needed for each tests case scenario.

Although this approach definitely made me a wizard when it came debugging data-related production issue quickly, it was too high of price to pay for the benefits I was receiving. Although I remember thinking in the beginning that this "realistic" approach to testing was much more valuable than the "fake" tests that didn't hit the database, by the end of the process I was no longer so sure. I still believed in the value of unit testing, but I knew there had to be a better way of doing it.

During my stint as an architect, I read enough about mocking to know that it was a good idea in theory, but of course I had little opportunity to put that theory to the test. Now that I am a code monkey again, I can say with certainty that mocking is an absolutely essential aspect of Test Driven Development and not simply a "nice-to have" supplemental activity like I assumed before.

Why is Mocking Critical?

It makes debugging easier - When a database driven test fails, the problem could be anywhere and in my experience it is most often related to a problem with the initialization script (i.e. accidental order-based test dependencies). This often led me to ignore test failures when I was pressed for time because I knew that it was likely just another false alarm. However, when a test that uses mock objects fails, I am not only fairly certain that it is a problem with the code rather than the test, but I also know exactly where the problem is because I've guaranteed the behavior of every piece of code except the part that I am trying to test.
It makes writing tests faster and easier - One of the biggest barriers to adoption for TDD for most developers continues to be the perception that it takes too long. I can give a dozen reasons why that perception is wrong, but in the end I think it is more productive to simply find ways to shorten that process. That is exactly what mocking does. Writing out a series of Expect.Call() statements is an order of magnitude faster than trying to write data manipulation statements.
It makes tests execute faster - Don't underestimate the power of fast feedback. Even if you are not a die-hard continuous integration practitioner, you have to admit that the longer your tests take to run the less likely you and other developers will be to actually run them. Even if you do religiously run them at night, the longer feedback cycle dramatically decreases one of the main benefits of TDD, which is the increased coding speed that comes from test-backed confidence and not having to waste time on excessive analysis and fretting about possible unknown collateral damaged.

What does Mocking Require?

Interface Based Programming - If you use Rhino.Mocks, then every class that you mock must implement an interface. With the help of ReSharper, interfaces can be created from an existing class and propagated to the rest of your codebase with just a few keystrokes. This alone makes the price of ReSharper worth it if you are going to start using mocking in a Legacy system that was designed without using interfaces.
Dependency Injection - One of the first stumbling blocks I ran into came from complex collaborations from objects that weren't able to be mocked because they were created inside of methods. You can quickly get around this with a little refactoring by making collaborating objects private member variables and then adding a constructor overload to expose them during testing. It is usually a relatively fast and low-risk design change to make.
Identifying Code Seams - If you find yourself getting frustrated and beginning to think that you are stuck in a code base that is impossible to mock, then stop and read the book Working Effectively With Legacy Code by Michael Feathers. I'm about a quarter of the way through this right now and it is one of the most helpful tech books I've ever read. The author is fearless and infinitely resourceful when it comes to getting code of any language and any quality under test. In fact, many of his examples are in C++ and even C, so that means that you have no excuses when it comes to your own project. He gives lots of practical advice on how to find the "seams", which are the easiest and most cost-effective places to modify code so that you can begin to mock it.

A Practical Example?

Here is an MbUnit test that I wrote today before I tackled a production bug that was assigned to me. It mocks the IPaymentTypeItem, which has read-only properties and thus is normally only allowed to be populated from the database. The Expect.Calls() are just done for the methods and properties calls that are actually made on the object in the piece of code I am testing. You can get a full tutorial with better explanations of the API calls here.

   1: [RowTest]

   2: [Row("%B409999999999999^Russ's Coffee Emporium^09011211000019900000000?;","409999999999999")]

   3: [Row(";4409999999999999=090112110000199?","409999999999999")]

   4: public void Should_Load_Correctly_With_Partial_Track(string trackData, string expCardNumber)

   5: {

   6:     MockRepository mocks = new MockRepository();

   7:     IPaymentTypeItem payment = (IPaymentTypeItem) mocks.DynamicMock(typeof (IPaymentTypeItem));

   8:     Expect.Call(payment.BinFirstDigit).Return(expCardNumber.substring(0,1));

   9:     Expect.Call(payment.IsCreditCard).Return(true);

  10:     Expect.Call(payment.PaymentTypeValue).Return(PaymentType.VisaCard);

  11:     mocks.ReplayAll();

  12:     FinancialCardEncoding encoding = FinancialCardEncoding.CreateCardEncoding(trackData,payment,true);

  13:     Assert.AreEqual(0,encoding.Errors.Count);

  14:     Assert.AreEqual(expCardNumber,encoding.PrimaryAccountNumber);

  15:     mocks.VerifyAll();

Rhino.Mocks is certainly not the only mocking framework out there, but so far I like it because it takes a strongly typed approach rather than relying on strings which means I get to use intellisense. Whatever framework you do choose, I highly recommend that you take the time to learn it well and incorporate it thoroughly into your development as soon as possible.

Where Do Experts Come From?

Russell Ball — Mon, 26 Nov 2007 05:45:41 GMT

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?

Is That Juice On Your Face?

Russell Ball — Tue, 20 Nov 2007 06:42:49 GMT

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:

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.
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.
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.

Still an Open Source Virgin

Russell Ball — Tue, 06 Nov 2007 14:10:59 GMT

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.

Hello, My Name is Russell Ball and I'm a Goaloholic

Russell Ball — Mon, 05 Nov 2007 06:00:36 GMT

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.

Two Month Progress Report on Being a Better Developer

Russell Ball — Wed, 19 Sep 2007 13:25:57 GMT

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?

Tools: Regulator, MBUnit, and more on NDepend
Code Reading: Rhino.Mocks
Non-MS: Ruby on Rails
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.

Adventures in Open Source: Spelunking WatiN

Russell Ball — Thu, 06 Sep 2007 06:32:34 GMT

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 Progress Report on Being a Better Developer

Russell Ball — Wed, 15 Aug 2007 01:04:44 GMT

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:

Tools: NDepend and Resharper
Expand OOP/MS horizons: Windsor Container and F#
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.

My Six Month Roadmap to Becoming a Better Developer

Russell Ball — Sun, 15 Jul 2007 14:52:23 GMT

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...

Informavore Trap # 2: Information Junk Food

Russell Ball — Fri, 06 Jul 2007 03:16:51 GMT

This is a follow-up to my original post about cognitive traps that hinder learning and stunt professional growth. Information junk food refers to any information gathering activity that prematurely satisfies your hunger to learn and provides fleeting emotional pleasure in lieu of actual intellectual nourishment.

Some information junk foods to avoid:

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.

Some Healthy Alternatives:

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.