Caffeinated Coder

It’s too hard to pick just one topic to delve into after a five month blogging hiatus, so I thought I would reenter the blogosphere by just spewing forth some random thoughts that have been floating around in my head lately.

1. Lamda soup is yummy – As you probably guessed from the title of the post, I’ve currently got C# 3.0 on the brain. I’ve been burning through John Skeet’s most excellent C# in Depth: What you need to master C# 2 and 3 book this last week and am finally beginning to grok some of the finder points of anonymous delegates, lamdas, and closures that have alluded me up until now. I especially like how the book explains the original problems that the new language features were attempting to address and also how it provides most of the examples in 1.1 first before showing how they can be rewritten more efficiently using the new 2.0 and 3.0 language improvements.
2. Side projects kill blogs – I started a side project back in February that has allowed me to learn a whole slew of frameworks that I’ve been itching to try like the MVC, NHibernate, Fluent NHibernate, JQuery, Windsor, and Sharp-Architecture. Unfortunately the pressure of learning all of those fun things on top of actually getting some work done pretty much sucked up all of my free time that used to go to blogging. By the time I finished the project a few months ago I was so burned out that I went on a fiction binge with such books as World War Z: An Oral History of the Zombie Wars, The Road, and Cryptomonicon. I think I’ve finally regained my sense of equilibrium enough to where I can start slipping some blogging back into the mix again.
3. Turning my back on Active Record – Last year I started down the path of using Castle’s ActiveRecord as a way to use NHibernate without all the messy XML mapping files. After having a chance to work with Fluent NHibernate, I’m ready to ditch the messy attributes and nasty inheritance dependencies of Active Record in favor of a more POCOesque approach. Clean entity objects AND no xml files? What’s not to love?
4. Third party controls are obsolete – When I decided to use Microsoft’s MVC Framework, one of my biggest concerns was the lack of built-in or third party controls. That was before I started to explore JQuery’s vast plugin community. With just a few lines of code and include files I was able to produce really nice looking calendar controls, autocomplete text boxes, media players, complex validation controls, and tool tips. It’s hard to imagine shelling out money for third party web controls ever again.
5. Bringing recruiting to the next level with the Rejectomizer 2000 – We are hiring for not one but FIVE separate positions in our department and yours truly has the dubious honor of being neck deep in it. As a polite gesture, we decided to send out an actual rejection email to anyone who went to the trouble to at least include a personalized cover letter with their resume. With our candidate pipeline being constantly refilled by 3 recruiters, Career Builder, and a stumbling economy this task quickly became a tedious chore…that is until I brought the full power of PowerShell to bear on the problem with a script that has affectionately been dubbed the Rejectomizer 2000 (source code to be provided in a later post). My most recent enhancement included adding a sound effect to the script of a flushing toilet, which I admit is totally cold hearted but at the same time it does help relieve the bitterness that tends to build up after sifting through hundreds of poorly formatted and otherwise indecipherable resumes in lieu of doing cool coding stuff.
6. Swimming against the Information Stream – While my 15 month old now twitters in her crib and my grandma reads her RSS feeds on the smart phone that is embedded in her walker, I have taken bold steps to swim against the current information tide by devoting myself more to good old fashioned tree killing modes of learning. I suck at multi-tasking and am sick of feeling like my knowledge is becoming more and more spread thin these days, so I’ve lined up 10 technology books that I’ve been meaning to read forever and decided to go on a strict RSS and twitter diet until I finish every last one of them.
7. Six Shooters should be outlawed – On a final note, I recently tested the limits of caffeine consumption by agreeing to drink a latte with six shots of espresso that one of my co-workers bought for me and then goaded me into drinking. Besides making my tongue a little numb and causing me to break out in a cold sweat, this highly potent drink, which we dubbed “The Six Shooter”, apparently sped up my response time by several orders of magnitude. According to office lore I responded to the question “what are you drinking?” before the first syllable had been fully uttered with a response that appeared to have been run through several very advanced compression algorithms. Moral of the story…don’t try this at home.

Cheers,

Caffeinated Coder

Popularity: 11% [?]

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: 19% [?]

I’ve been using ReSharper for over a year, but it recently occurred to me that I’m still only using about 1/4 of the functionality.

Although there are a plethora of cool, productivity-enhancing features in ReSharper, there definitely aren’t a year’s worth of things to learn. In fact, I’m pretty sure that I picked up most of my current repetoire of hotkey knowledge within the first week. Somehow I became complacent soon afterwards and stopped learning new features even though I was thrilled with the ones I had already acquired.

It reminds me of the The Expert Mind, a scientific paper that I wrote about last year in my post Where Do Experts Come From?. According to the authors of that paper, novices and experts start out learning at the same pace, but novices loose interest as soon as the novelty wears off while experts manage to sustain that same pace of learning long afterwards.

I decided that if I ever wanted to shed my novice status when it comes to this tool and become a ReSharper Jedi, then I had to take some strategic steps to restart the learning process.

Here’s what I did:

1. Favorite Features List: I made a list of all of the features that I am fluent with, which I define as the ones I use on a daily basis without having to pause to remember the hotkey. Although not as critical as the other steps, I still found this activity to be helpful in allowing me to solidify existing knowledge as well as reinforce good habits. I’m also hoping to use this list in my future efforts to convince several stubborn co-workers to start using this tool, which many have not yet installed even though we all have licenses.
2. Practice List: Next I made a list of all of the features that I’ve tried and found helpful but don’t use very often or very effectively. This is usually because I either habitually forget about the feature or else don’t have the hotkey combination memorized and therefore have to fumble around with the menu system in order to use it.
3. Try List: Finally I created a list of features that I haven’t tried yet. I populated this list by looking through the ReSharper menu system, going through the embedded tips, and rereading the posts in Joe White’s 31 days of R# series.
4. Daily Review of Try and Practice List: Next I placed these lists in a OneNote notebook (any simple text editor will work) and pulled it up to review several times a day in order to remind myself of potential new features to try and use.
5. List Item Promotion: Once I tried a new feature for the first time, I moved it to the Practice list. As soon as I noticed myself using a feature fluently, I moved it to the favorites list. This simple act of promoting features from one list to the next was not only useful in helping to keep me organized and establish concrete goals, but it also proved to be motivating since it gave me a sense of accomplishment every time I was able to move an item.

 

Although I’m sure that this simple technique that I thought up certainly played a role in restarting the learning process, I think that my sudden awareness of the psychological ‘novice’ pattern that I fell victim to played an even more critical role.

Once I move the last ReSharper feature from the Practice list, I plan to apply this same approach to other tools, new language features, and uncharted API.

What have you done to break out of a learning rut?

Popularity: 10% [?]

I recently read an thought provoking article by Nicholas Carr, entitled Is Google Making Us Stupid?

In the article, Nicholas describes a phenomenon that I have observed happening in myself over the last few years.

Over the past few years I’ve had an uncomfortable sense that someone, or something, has been tinkering with my brain, remapping the neural circuitry, reprogramming the memory. My mind isn’t going—so far as I can tell—but it’s changing. I’m not thinking the way I used to think. I can feel it most strongly when I’m reading. Immersing myself in a book or a lengthy article used to be easy. My mind would get caught up in the narrative or the turns of the argument, and I’d spend hours strolling through long stretches of prose. That’s rarely the case anymore. Now my concentration often starts to drift after two or three pages. I get fidgety, lose the thread, begin looking for something else to do. I feel as if I’m always dragging my wayward brain back to the text. The deep reading that used to come naturally has become a struggle.

The article attributes this general scattering of our attention and weakening of our concentration to our ever increasing usage of Google and the internet, which is structured in a way that promotes skimming and quickly jumping from one source of information to the next rather than focused reading. The author presents a wide variety of historical corollaries, research studies, and anecdotal evidence to suggest that the internet is fundamentally rewiring the ways in which our brain processes information. The overall effect is that we are becoming more like “pancake people”, stretched thin over vast amounts of information which we only interact with on an increasingly superficial level.

Although I admire minimalism and conciseness in writing and find my well-honed Google-Fu to be an essential skill in today’s landscape of information overload, I have to agree with with the author that it is a shame that all the benefits of Google and the Interent seems to be coming at the expense of our more traditional, focused reading skills.

It is just plain embarrassing to run out of steam 1/4 of the way through a Steve Yegge blog post even though I find the article interesting. It makes me feel like an out-of-shape, intellectual couch potato.

But what can be done to counter-act this GIADD (Google Inspired Attention Deficit Disorder)?

I decided to start by overhauling the way I read my RSS Feeds.

In the GTD (Getting Things Done) arena, there is a concept of separating ‘Processing’ from ‘Doing’. Processing just entails making important decisions about whether or not something is worth doing in the first place, what context it best completed in, and where it belongs in your overall organizational scheme. Since processing and doing are two very different activities that require different frames of mind (sort of like the difference between skimming and focused reading), you are supposed to finish all your processing before you move on to the doing or ‘Next Action’ part of the equation. This way you can get into and stay into a flow during each activity.

Since this concept has worked really well for me while processing email, snail mail, and various other inbox items, I decided to apply the same principal to reading blogs.

Here’s my new RSS workflow

1. Establish Zero Bounce Zone: First I organized my feeds into 4 simple groups as a way of prioritizing which ones I wanted to keep up with the most. I used Favorites, SunnyDay, CloudyDay, and RainyDay since they forced me to think of them in terms of how much time and motivation I had to read. Then I decided which folders I was willing to make a zero bounce commitment to, which means that I make sure I have processed every single post in those groups by the end of each day. I currently have about 30-35 blogs in my ‘No Bounce Zone’. I only process posts in the other 2 folders if I have time, which means I can still keep tabs on good potential sources of information without feeling guilty for having too many unread items in my RSS Reader.
2. Process All Zero Bounce Feeds Daily: All I am doing here is trying to decide how interested I am in reading the post. Sometimes I can tell just by the title, but sometimes I have to skim it to find out. If it is a very short post that doesn’t take much concentration to read, then I go ahead and just read it. Otherwise, I put a Read++, Read, or Maybe tag on the ones that I am interested in reading. If they aren’t interesting to me, then I just mark them as Read and forget about them (life is too short to read everything). Since all I have to do is make a quick decision about every item in this group, I force myself to take these in order and resist the urge to just process the obviously interesting ones first. This is a bad habit that leads to procrastination and ultimately unprocessed items at the end of the day.
3. Process Some Optional Feeds If Time: I tend to do this if I am all caught up on my ‘Zero Bounce’ feeds, but still have spare, otherwise unproductive minutes throughout the day that aren’t appropriate for more focused reading.
4. Read Some Tagged Items: I usually wait until I have at least 20 minutes of quiet, uninterrupted time before doing this. For me, this usually tends to be at night when my kids (and often my wife) are in bed. Having this quiet time along with a large group of quality, pre-selected posts that I know I am interested in reading thoroughly helps me me disengage from my normal internet skimming mindset and get into a more focused reading mode instead. When selecting items to read from this group, I skip around and choose what I am most interested in first. After I finish reading them, I remove the Read tag so it will disappear from my reading queue and replace it with some recommended or technology specific reference tags to make it easy to track down later if needed. I expect this queue to always have a large number of items in it, so I don’t worry about its size as long as I know I am churning through tagged posts at a respectable rate each week.
5. Periodically Recategorize Feeds and Tagged Posts: Between my interests being in a constant state of flux and the relative quality and content of blogs going in random cycles, I like to recategorize blogs and posts on a regular basis to keep things from going stale.

I’ve been doing this for a couple of weeks now and have already noticed a big difference in being able to focus more on reading. Surprisingly, I’m also getting much faster at skimming and processing since I’ve released myself from the need to comprehend anything beyond what will help me make a decision about whether it is worth reading.

Best of all, I finally feel in control of my RSS Feeds in a way that I never have before. Instead of feeling overwhelmed by thousands of unread items, I feel like it is a manageable workload so I am actually more motivated to keep up with the reading than I as before.

What are some of the things that you are doing to fight GIADD (Google Inspired Attention Deficit Disorder)?

Popularity: 8% [?]

I firmly believe that the answer to this question is…yes.

A Little Background (a.k.a. My Hermit Roots) – Like most geeks, I’m an introverted fellow by nature. I’ve never had trouble mustering the requisite polish when it came to interacting with clients and executives on the job, but when given a choice I would always rather be absorbed in code with my headphones on and a ‘do not disturb’ look of concentration on my face. Until recently, I preferred keeping to myself when it came my professional development and problem solving endeavors and routinely chose thick technical books, laser-focused research, and solo debugging efforts over blogs and community forums. I didn’t really see the point of developer communities and I doubt that I had a single person in my professional contact list that I didn’t know directly through a current or prior work experience.

The Slippery Slope into Community – I didn’t start to change my solitary ways until a few years ago when I finally decided to start subscribing to blogs in earnest (I know that I was extremely late to the game on this one). Before long, I graduated to leaving comments and then eventually to writing posts on my own blog, thus firmly entering into the realm of geek community by publicly exposing my own thoughts to the world for examination and potential (…ok probable) ridicule. Finally, through the magic of Twitter, OpenSpace conferences, and social networking sites, I began interacting with my fellow kindred geek spirits on a more informal basis and getting to know many of them personally. At the last conference, I was shocked when I realized that for the first time ever I was more excited to meet and interact with the other participants than I was to listen to the content of the sessions. That was the moment I first started to realize that my understanding and appraisal of geek community had significantly shifted.

A Place of Extremes - In the short time that I made the journey from geek hermit to neophyte community member, I have experienced the following highs and lows.

First the good…

• Real World Experience over Theory – Most of the content I see in traditional articles, books, and Knowledge Base entries seem overly theoretical and shallow because many are often based on idealized vendor technical specs or the author’s limited experiences with pet projects and demo applications. By contrast, many of the blogs or twitter rants I read are from people on the corporate front lines who are constantly dealing with the edge cases and pushing the limits of the technology. Despite being less polished than their more formally published counterparts, community based sources of information often yield much more valuable hints, insights, and warnings.
• Analysis and Recommendations over How-To – While traditional learning venues almost exclusively focus on the HOW, community discussions are often centered around the WHY. In the age of google, learning HOW to use a new tool, framework, or API often borders on the trivial, but figuring out which one to use can become an overwhelming decision. This is where being part of a network of really smart people who readily share knowledge and experience can really pay off.
• Perspective – No matter how large your IT department is, your work will be confined by a particular culture and set of technologies and practices. By contrast, online communities are usually comprised of developers from all over the world and thus offer fresh ideas and needed reality checks that you just can’t get from your co-workers. While your co-workers may be fearful or too polite to challenge your latest dumb idea, you can rest assured that developers you interact with ‘in the wild’ will be brutally honest.
• Camaraderie – Besides being a source for excellent recommendations and discussions, I find Twitter and the comment sections of blogs to be a place where I can relieve some stress from the day by being able to joke or rant. Sometimes the lack of “face to face” social constraints has a very positive affect and allows people who are normally quiet and serious in a work setting (like me) to be much more light-hearted and humorous in a virtual community. The Canadian blogging circuit in particular (Justice, Donald, D’Arcy, Tom, et. al) has been a reliable source of comedy relief for me over the last few years.

Now the bad…

• Anonymity Breeds Meanness – If you haven’t been personally zapped by an unnecessarily rude comment, then you haven’t spent much time in online discussions. In a process that makes road rage look tame, the anonymous aspect of online interactions can turn normally sane people into ranting, frothing-at-the-mouth maniacs.
• The Need to Shrink the World – The first time I looked at the world map of my readership base in google analytics or scanned the diversity of topics available on reddit, I was struck with the uncomfortable realization that the world was unbelievably ginormous place. Unfortunately, the first reaction that many have to this psychological shock is to try to shrink the world back down to a manageable size by dividing it into a small select group of enlightened technical wizards (to which they belong) and a massive group consisting of the rest of the dimwits. This is the driving force behind the formation of so many identity cliques that divide people along otherwise trivial lines with a frightening religious-like fervor (i.e. Mac vs. Linux vs. PC, Microsoft vs. Sun, Dynamic vs Static languages, Mort vs. Einsteins, etc.). The world is just a more manageable place if you have justification to dismiss a large portion of it as irrelevant.
• Flame Wars and Twisticuffs – As egos collide and tempers flare, even the most reasonable discussions quickly degrade into purse fights, twisticuffs (twitter fisticuffs), and flame wars. When this happens, the geek blood lust takes over and the pursuit of knowledge takes a back seat to the all consuming goal of winning the argument. I have occasionally been sucked into these “Lord of the Flies” type spectacles and I’ve always emerged feeling drained, dumber, and ashamed of myself.

What to Do? I admit that I occasionally have days where I am tempted to crawl back into my introverted shell and seal myself off permanently from blogs, twitter, and all other forms of geek community. Despite the silliness, meanness, and time-wasting qualities that lurk behind some online community interactions, I still have to conclude that it is the only viable option for a geek looking for self-improvement.

Nevertheless, before diving headfirst into community, you’ll need to learn to recognize the potential pitfalls and devise strategies for avoiding them. This could be as simple as unfollowing, unsubscribing, or generally avoiding people who trigger your geek rage or it could involve a more radical approach of taking a periodic hiatus from the online world to recharge your batteries. Failure to do so could lead you down the path to the geek dark side and eventually turn you into one of those curmudgeonly old trolls that lurk on mailing lists waiting for their next unsuspecting newbie victims.

In the spirit of community interaction, I leave you with the following questions for you to ponder and respond to:

1. What are the other positive and negative aspects to geek community?
2. Do you really think community is the fastest way to self-improvement?
3. If you are a believer in community, how do you avoid all the negative aspects?

Popularity: 17% [?]

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.

Popularity: 15% [?]

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% [?]