Caffeinated Coder

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?

As I mentioned in this last post, the Austin Alt.NET conference last fall was one of the best conferences that I had ever attended. Nevertheless, I liked the second one in Seattle this last weekend better.

Here are a few reasons why:

1. Alt.NET has finally been defined - There was quite a bit of time spent at the first conference and in the news groups afterwards arguing about fundamental issues like what Alt.NET meant and whether or not the name was too divisive. Although these questions were important to hash out in the beginning, the topic quickly grew stale for me and I certainly didn’t relish the idea of listening to even more debate about it. Apparently I wasn’t the only one that felt this way because the only mention of it was a topic suggestion done in jest about renaming Alt.Net which was promptly greeted by groans and eye rolling. No longer having to deal with this mental baggage meant that there was much more time to focus on substantive technical issues. For example, I was pleasantly surprised when the opening night fishbowl immediately delved into a top notch discussion about whether or not polyglot programming is a desirable industry trend.
2. Open Space Format No Longer an Issue - Another roadblock that caused the first conference to get off to a slow start was the skepticism regarding the Open Space format. While everyone eventually warmed up to this approach, I remember quite a few sarcastic barbs the opening night that were funny but ultimately detracted from the quality of the discussion. The fact that the organizers didn’t really have to waste any time explaining or converting people to the Open Spaces philosophy this time around was another contributing factor to how quickly discussions became productive.
3. Better Mix of Geek Celebrities, Alpha Geeks, and Regular Geeks - Expanding the participant list to 150 and reserving 50 spots for invitation only celebrity geeks was a stroke of genius. The mix at the first conference was great, but the mix at this one was even better. In my opinion, the biggest threat for future conferences in terms of “jumping the shark” would come from altering the number of participants or unique geek ratio too much.
4. Microsoft Employees No Longer on the Defensive - In Austin, I definitely got the sense that Microsoft employees were either walking on eggshells or else (often legitimately) defensive. Since then, I believe that the ALT.NET group has collectively decided that the ideology\movement is ultimately grounded in .NET and thus the purpose of the group is to push Microsoft into improving the current development experience rather than trying to instigate a mass exodus of developers to other platforms. I think this shift in mind set made a huge difference in how productive conversations were and how willing prominent Microsoft employees were to attend. Some of the more notable Microsoft attendees included Scott Guthrie, Scott Hanselman, Phil Haack, Brad Abrams, John Lam, Dustin Campbell, Glenn Block, Howard Dierking, and many more.
5. More Focus on Positive Examples of Microsoft Technologies- Instead of focusing too much on canonical examples of tools and technologies that Alt.NET’ers have traditionally criticized, such as the Entity Framework, Enterprise Library, or SSIS, many of the discussions focused around technologies that are being received more warmly, such as the MVC Framework, IronRuby, IronPython, and F#. Besides demonstrating how scary smart he was by diagramming out some of the internal implementation details of the DLR, John Lam impressed many Alt.NET’ers by mentioning things like his regular IM conversations with the head of the JRuby project or his team’s painstaking efforts to move towards passing 100% of the Ruby community test suite. Phil Haack enjoyed similar kudos for the efforts that he and his MVC team have made to solicit and incorporate community feedback into their product as well as learn from existing MVC frameworks in the industry and even openly release the source code.
6. Leadership - I hesitate to even mention this one because Scott Bellware contributed so much to the first conference and he was so relaxed and agreeable this weekend. But let’s face it, as a conference leader, David Laribee just doesn’t have the same baggage to contend as Scott Bellware, whose publicly confrontational demeanor tends to cause friction at every turn. Despite poking fun at him from time to time on my blog, I respect Bellware and wish he was still blogging, but I have to admit that I’m glad that Laribee took over the organizing reigns for this conference. By the way, be careful about complimenting Laribee on how well the conference was organized or he will try to rope you into helping organize the next one…:-)

So what about a future Part 3 to this conference series?

I heard about 3 different potential follow up Alt.NET conferences this weekend that would take place in Canada, Austin, and possibly Boston. I’m not sure which one will emerge as the next viable option, but I’m definitely going to stay alert for any news.

I don’t know if the next conference will be as good as this one, but the odds are that it will still be much better than the passive, spoon fed material that you can expect from traditional conferences.

I’m currently en route to Seattle to attend my second ALT.NET conference, so I thought I would take the opportunity to organize some pre-conference thoughts.

ALT.NET in a Nutshell (at least by my reckoning)

Alt.NET is a nascent, loosely organized ideology that started as a vibrant blogosphere reaction to this post by David Laribee and has since evolved into a number of conferences, user group meetings, and mailing list discussions.

Alt.NET conversations I’ve followed tend to focus on…

• Shifting the emphasis away from the latest and greatest API and towards a discussion of sound principles and practices that transcend specific technologies.
• Shunning “Demoware” and visual designers that offer quick, flashy functionality at the expense of long-term maintainability.
• Taking a “best of breed” approach to tools and frameworks and frequently looking to the open source community or competing vendors rather than the traditional Microsoft fare to enhance the .NET development experience.
• Fostering a healthy debate regarding the best way to develop software, thus shifting learning away from a vendor-centric, how-to learning experience toward a more interactive dialog.

The canonical example of an Alt.NET view of the world is the vocal criticism by many in this community of the Entity Framework. Most Alt.NET’ers prefer open source ORM alternatives, such as NHibernate or Ibatis.NET, because unlike the Entity Framework they follow the principal of persistence ignorance, which removes database dependencies from the code thus allowing business objects to be tested more easily and cheaply. While this position may seem like common sense to many, it is considered “Alternative” to most because it challenges the default behavior of many executives and mainstream developers who are more comfortable with following Microsoft’s lead on all technical issues.

If you want more information on the question of “What is Alt.NET?”, I recommend reading this short MSDN article by Jeremy Miller . If you have some free slots in your podcasting queue now that lawn-mowing season has started, then I also recommend the Hanselminutes episode with David Laribee or the recent DNR episode with Laribee and Jeremy Miller. You can also read about some of my own impressions of the first conference in Austin along with a humorous pictoral retort that I put together in response to some of the public criticisms of the conference being too elitist.

Why am I in the cheap seats?

A quick glance at the participants list reveals a high number of well-known speakers, authors, tool creators, and bloggers. I was a little bit star-struck by being surrounded by such a high concentration of geek fame during the last conference and this time around the participant list is even more impressive. I would consider this group to occupy the box seats in my little sports event analogy and I’m not even close to being there. In fact the guards would probably beat me mercilessly if I even deigned to stare wistfully at this section for too long.

Next comes the middle seats. These are the ones occupied by the B-List bloggers and dedicated open source contributors. I hadn’t heard of many in this group before, but was duly impressed last time with their extensive experience with topics that I only had a cursory knowledge of, such as Domain Driven Design, Behavior Driven Development, DSL’s, IoC Containers, MVC Frameworks, and Mocking containers. Unfortunately, I’m not in this group either.

That leaves the cheap seats. That is where those of us who are seasoned developers and agree with the alt.net principles, but have little experience with most of the tools and practices discussed at the event sit. Last time I mostly just shut up, listened, and tried to learn a few things while sitting in this section. Although lurkers are not generally appreciated at an open spaces event like this, I was at least comforted by the thought that I might eventually help spread the good word to my fellow Joe-developers back in the trenches.

I’m afraid I am destined to sit in the same section this time around. I’ll do my best to be a more active participant in conversations, but realistically I still don’t have enough experience with most of the popular ALT.NET tools and concepts to shed my lurker ways just yet. So, if you see a little unobtrusive speck high up in the nose bleed section of the conference, that is probably me.

What am I hoping to gain from the cheap seats of the conference?

1. Feel more stupid than I do now - My primary professional growth strategy so far has been to surround myself with really smart people in hopes that I will learn something by osmosis. I’m pretty sure this will be one of those situations. One unfortunate side effect of this approach is that I am perpetually humbled, which makes it really difficult to bask in the glow of a good old fashioned geek superiority complex. However, it is a small price to pay for all the fancy new developer tricks I learn.
2. Improve my criteria for evaluating tools and products - The one thing that prevents this type of gathering from devolving into a geek popularity contest based on which tools you use is the genuine attempt by most of the participants to define somewhat objective criteria by which to judge technology. For example, if I explain to my coworkers that we should use NHibernate instead of the Entity Framework and or the MVC Framework instead of WebForms, then I want to be able to articulate that these products are inherently more testable, which will help us modify our applications more quickly and with less risk. This type of approach tends to hold much more sway in the IT world than the old standby “all the cool kids are using it” argument.
3. Explore the development landscape - The .NET open source community may be relatively young and small compared to the Java community, but it nevertheless represents an overwhelmingly enormous amount of information for one person to sift through. When you throw on top of that the deluge of technologies being released by Microsoft as well as all of the relevant competing vendor products, then there is simply no way to adequately survey the development landscape other than through a sharing of ideas by passionate developers with diverse experiences in conferences like this.
4. Finally meet people I know - Huh? It sounds weird, but in the last year I’ve corresponded with a large number of people through blogging and tweeting. It seems that most of them will be in attendance this weekend. The small, open space format of this conference is ideal for making and strengthening professional contacts and becoming more engaged with the developer community. While google is still my fallback research tool of choice, I’ve been amazed at how valuable the daily conversations I have over email, twitter, and blog comment sections with like-minded developers all over the world can be. Hopefully this weekend will help me begin to tune into and use the developer community even more effectively.

In conclusion, I’m obviously excited about this weekend, despite my relatively lowly status on the ALT.NET food chain.

If you’re new to ALT.NET, I highly recommend attending one of the upcoming conferences or joining one the main mailing list to find out for yourself what all they hype is about.

I remember reading the eXtreme Programming Core Practices several years ago and smirking when I got to the practice that called for regular 40 hour work weeks for programmers.

Like many of my fellow developers, I saw overtime as a geek badge of honor and felt pride at having enough stamina to regularly work 60-80 hours a week on my death march project.

Although I occasionally received half-hearted warnings from management to slow my pace down in order to avoid burn-out, the underlying message from above was clearly that my willingness to work long hours made me an exemplary employee and that overtime was one of the surest paths to professional growth and advancement.

While I may have agreed with the XP practice of capping the work week at 40 hours in theory, my traditional geek machismo prevented me from accepting it as anything other than a naive and idealistic goal that would probably never be gain widespread acceptance in corporate America.

That was then.

Now, when given a choice, I rarely opt to work overtime for my employer (at least not directly according to my task list). I would never hesitate to work extra hours prior to a release or due to unexpected production problems, but I now view anything more frequent than that as a serious problem and even as a potential reason to start looking for another job.

Why the dramatic change in attitude?

Here are some reasons that finally caused me to stop seeing overtime as a heroic effort and start seeing it as a destructive practice that is a sign of a seriously broken process within an IT organization.

1. Lost Opportunity Costs in Professional Growth - Once I completed a handful of large projects in my career, the opportunities I saw for professional growth started coming more and more from external sources outside of my job. While I  still learn plenty during the day by observing my co-workers and attempting to solve common problems in novel ways, I often feel that my skills grow faster outside of work through reading, writing, presenting, social networking, and pet projects. It is sometimes tempting to spend 10 extra hours a week clearing the items from my daily TO DO list, but I believe that I am accomplishing much more for my professional career by devoting those hours to catching up on my RSS feeds, working my way through my tech book reading list, or exploring new programming languages instead.
2. Increased Professional Risk from Lack of Diversification - Everyone knows that diversification is the key to managing financial risk, but few people seem to apply this principal to their professional careers. Most developer shops are relatively limited when it comes to the number of technologies and problem domains they deal with. If you want to diversify your resume without job hopping every year, then it makes sense to actively seek out technology experiences that are different from the ones you use in your day job. By this reasoning, working overtime will increase your professional risk by reinforcing skills you already have whereas working on open source or pet projects that require you to learn new skills will mitigate your professional risk and make you more marketable should you ever decide to leave your current job.
3. Decreased Professional Passion - To paraphrase Jean-Paul Boodhoo, the best fuel for professional growth is always a developer’s joy and passion for his or her craft. I find it much easier to sustain this passion when I am allowed free reign to follow my curiosity. Work doesn’t usually allow for this type of unstructured exploration, but free time does.
4. Lost Productivity - Overtime work is highly susceptible to the law of diminishing returns. Spending long hours on the same tasks in a high stress environment leads to fatigue, which in turn leads to producing poorer quality work at a slower pace. When you factor in the time it takes to find and fix bugs and design flaws produced by overly tired developers, the net gain for twenty hours a week of overtime probably drops down to only a few hours while at the same time greatly increasing the risk to the project. Overtime just doesn’t yield the results promised by management Gantt Charts which provide an oversimplified view of the software development process by only measuring the quantity of the hours spent on tasks without also taking into consideration the quality of the time.
5. Poor Code Quality - Besides being more likely to miss obvious errors, developers who are under pressure and fatigued are far more likely to cut corners and engage in shallow thinking when it comes to design solutions. Besides driving up the long term cost of a project by making it more difficult to maintain, code quality issues can put the whole project or even business at risk by introducing critical errors and undermining customer confidence and loyalty.
6. Lost Personal Revenue - If you are a salaried employee and your are concerned with maximizing your personal income, then you should read this post by Max Pool where he points out that you are almost always financially better off to focus your time across multiple revenue streams rather than allowing your time to be sucked up by one job through excessive overtime.
7. The Usual Personal Reasons - These are all the usual things that workaholics neglect until it is too late, such as family, friends, health, and entertainment. Although I think they are among the most important reasons, many of us seem to have blind spots when it comes to these issues due to cultural biases so I chose to focus on other more novel arguments about overtime in this post instead. Nevertheless, these are some of the most compelling reasons to question any work schedule that consistently includes overtime.

If you are convinced about the evils of chronic overtime but don’t know how to break out of your current overtime cycle at work, then meditate on the following two concepts:

1. Time Should Be Fixed, but Features Should Always Be in Flux - If a customer went into a store and put more items in their shopping cart than they had money for, then they would reasonably expect to have to put a few items back while checking out. This is exactly how it should work in software, but the reality is often that customers naturally have a very difficult time connecting their feature requests to a real cost because IT departments have traditionally been so willing to hide the extra cost through overtime. Agile iteration planning and planning poker does a great job of addressing this issue by having developers assign a relative point cost to each feature, tracking an average velocity of points completed each week, and then only allowing customers to choose enough features to equal the velocity points in any given iteration. Besides providing a much more realistic expectation of what can be accomplished in an iteration, this approach emphasizes that developer time is a fixed resource and that feature requests must be variable based on continual assessment and reprioritization.
2. A Large Number of Proposed Project Features are Unnecessary and even Harmful to the Project - It is amazing how many "must-have" features suddenly become unimportant when a project is time-boxed and resource-boxed in an effective way. I’ve actually seen overall  product quality and customer satisfaction increase in these circumstances because it helps focus stakeholders on what is essential about a project and aids them in more easily spotting bloatware features that would otherwise delay implementation, increase cost, and hinder usability without returning discernible value.

Sometimes you just can’t change the way your processes work or management thinks, but you can always change your own attitude by resisting self-imposed or peer pressure to work overtime. I’m guessing that the majority of overtime is not officially mandated, but rather manipulated through subtle peer pressure. If that is the case, just say no.

If your goal is constantly to maximize your own professional growth, then you’ll be surprised at how much respect you can still win without playing the overtime game. For example, who do you think is going to get noticed more, someone who closes a few more issue in the bug tracking system, or someone who is able to introduce a new concept, process, tool, or technology to the group because of work done in their spare time?

In conclusion, the next time the opportunity for overtime arises, ask yourself if you are really maximizing your professional growth or if you are just focusing too much on short term job goals and not enough on long term career goals .

Don’t worry, I’m not going to join the growing ranks of developers with false claims of responsibility for the the Alt.NET pursefight blog (i.e. Bil Simser, Donald Belcham, Derik Whittaker, Sergio Pereira, Tom Openorth, David Woods, and Kyle Baley) .

My confession is way more shocking.

The more astute among you have noticed that D’Arcy Lussier has shown signs of instability and even mental illness lately. Who can forget the now infamous post that featured many Paint.NET atrocities that are now banned in most civilized nations?

The reason for this disturbing behavior is simple.

His entire blog has been an elaborate hoax that I invented while freebasing experimental, synthetically engineered, black-market coffee beans during a mind-numbing HR meeting one day.

Yes, I have been ghost writing the 50 plus posts a day for years under the guise of a batcrap crazy Canadian to keep up this charade. I even went as far as to hire a homeless guy who I found mumbling to himself on a street corner to impersonate this fictitious D’Arcy character of mine at various User Group meetings and conferences to lend credence to my misguided prank.

But no more…

Due to the recent addition to my family, I’ve decided to expose my blogging sins and turn full control of the blog over to the homeless guy, Burt. For those of you who actually do like D’Arcy’s blog, I’m sure that Burt will be able to maintain the quality of the content that you have grown accustomed to in between his frequent drinking binges.

Forgive me dear readers and may God have mercy on my soul for the havoc I have wreaked on the blogosphere with this cruel practical joke.