Caffeinated Coder

When I first started writing this blog, I devoted several posts to planning and describing my efforts to become a better developer.

Although I was inspired by a certain unnamed developer’s public quest to read a book a week for six months, I never chose reading technical books as one of my goals.

I’m not sure why I didn’t consider reading technical books as a worthwhile endeavor at the time. Perhaps it was because I was overly infatuated by my RSS reader or maybe I was just fixated on the burgeoning list of tools, frameworks, and open source projects that I had only recently become aware of after finally branching out from my Microsoft-centric comfort zone.

Whatever the reason, I now find myself with a very different perspective on what will help me grow the most as a developer.

For one thing, after reflecting on my own strengths and weaknesses I realized that I have been focusing on breadth of knowledge for too long and now need to concentrate on increasing my depth of knowledge about software development. I decided the best way to remedy this current imbalance was to embark on a methodical journey to finally read the dozen or more high quality books on software development that I currently have collecting dust on my shelves.

My 2010 professional goal is to read one of the technical books in the picture below each month for twelve months and then do a blog post reviewing each one.

When I first hatched this plan a few months ago, I put some serious thought into the best way to ensure that I would actually meet this goal. I knew that publicly announcing an ambitious goal would provide some motivation, but probably wouldn’t be enough, especially since I have been apt to abandon blogging for 4-5 month stretches these days.

Instead, I opted to take the SMART approach, which is acronym that describes the characteristics of well formed goals. I first read about in Pragmatic Thinking and Learning: Refactor Your Wetware and was impressed how such a simple concept really helped me to refine my goals in ways that made me much more likely to achieve them.

How did I make my goal SMART?

• S – Specific – I didn’t just make a vague statement about reading more technical books. Instead I went to the trouble of picking out exactly how many and which ones I was going to read (although I left the order unspecified to give me a little bit of freedom to pursue what was most interesting or relevant to me at the time).
• M – Measurable – Writing a blog post review after finishing each book not only serves as a clear finish line for each monthly goal, but also provides a good way to mentally assimilate the information in each book from a SQ3R reading perspective.
• A – Achievable – I didn’t want to make myself miserable for a year with unrealistic demands on my time, so I sat down and thought about the maximum number of hours I could realistically spend doing technical reading in a week (10 hr) as well as how many pages I average an hour on technical reading (25 pg) and how long my biggest books were (800 pg). After doing the math, I figured out that I could realistically handle one book a month, especially if I alternated between easy and challenging books. So far I’ve validated my hypothesis by successfully tackling one of my toughest books in January, CLR via C# by Jeffrey Richter, and also being ahead of schedule for finishing my February book, Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck.
• R – Relevant – Besides addressing my concerns about focusing too much on breadth of knowledge and not enough on depth, I also found these goals to be particularly relevant to me because I had just received 6 new ones in the mail due to my amazon gift certificate windfall that I got from taking JP Boodhoo’s Nothing But .NET class last fall and thus was suffering from a nasty spike of unread book guilt.
• T – Time-Boxed – Setting clear time deadlines is essential in order in terms of both motivation and measuring success. I chose one month reading iterations because they were easy to track (my January book is…) and it kept me on a brisk yet sustainable pace.

As I already mentioned, I’ve completed one of my books so I’m off to work on my first review.

Popularity: 1% [?]

Here is a list of what I would most like to learn in the coming year.

1. StructureMap – This is the one new technology that I will likely be able to implement at work in the first quarter, so I made it first on my list. I’ve been using the Dependency Injection pattern on an almost daily basis over the last six months as a way to make our codebase more testable, but I still haven’t taken the time to learn and start incorporating an IoC Container. Up until recently I had planned on using Windsor since I managed to make it through a few tutorials on it last year, but Jeremy Miller has given StructureMap so much attention lately in terms of a enhancements and documentation that I decided to try it instead.
2. JQuery & QUnit– I only recently joined the rest of the world when it comes to using ajax and modern javascript frameworks while I was working on my recent Rails side project (I do mostly middle-tier and back-end development). I used Prototype simply because it was the default for Rails, but now I’m ready to try the much hyped JQuery framework along with QUnit, the unit testing framework that goes with it. Since I tend to learn much better when I have a concrete task, I’m going to start by re-implementing all of the Prototype functionality in my Rails app in JQuery.
3. MVC Framework – I doubt I’ll have the opportunity to use this at work anytime soon since switching an existing project from WebForms to the MVC Framework would be a major rewrite. However now that I have a pretty good grounding in an MVC framework (RoR), I’m curious to see how the new Microsoft version compares.
4. IronRuby – I’m also excited to see what the IronRuby experience is like compared with RoR. The RoR stack has been criticized in the past for poor performance and limited API and IDE support, so I’m anxious to see whether running Ruby on the DLR will be the answer to these problems or whether it will just seem like a cheap knock-off of the original.
5. Git and\or Mercurial – I finally graduated to Subversion this last year, so now it is time to challenge myself with a distributed source control system. There’s no way we would go through another upgrade at work anytime soon, but it will be fun to experiment with these tools on personal projects.
6. Django – I don’t have plans of doing any real development in Python or Django, but a friend of mine swears that this is way better than Rails, so I’m curious enough to at least go through some tutorials and sample projects so that I can decide for myself.
7. Erlang – I’m going to finally try a functional language this year. I mean it this time. Really…
8. Lambda Expressions – I can fumble my way through samples, but I want to ratchet up my understanding a few levels so that I can naturally incorporate this C# 3.0 goodness into my daily development.
9. PowerShell (again) – I dug into this technology pretty deep about a year and a half ago when I first started this blog and even gave a couple presentations to user groups on the topic. Unfortunately, I fell victim to the ‘use it or loose it’ phenomenon and struggled mightily to do even the simplest of tasks during a recent automation project. Nevertheless, I was reminded about how cool this product was and got inspired to relearn it and start trying to use it on a regular basis this time around.
10. Ubuntu – Finally, it’s been far too long since I’ve played with a flavor of Linux. With VM’s I really have no excuse anymore.

I guess I’d better quit writing and get started…

Popularity: 18% [?]

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.

Popularity: 8% [?]

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.

Popularity: 6% [?]

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?

Popularity: 12% [?]

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.

Popularity: 7% [?]

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.

Popularity: 5% [?]

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.

Popularity: 4% [?]

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

Popularity: 5% [?]

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!

Popularity: 4% [?]