What’s the secret to being an awesome programmer?

You know the kind of programmer I’m talking about. The ones that kick butt and take names; the ones that seem to know the key commands and APIs for everything; the ones that know how to squeeze every last second of performance out of a piece of code. How do you become that guy?

These people must just have inborn talent right?

Talent

John Nunemaker (the creator of MongoMapper) dispels all myths regarding talent:

It is true. I have no talent. What I do have is a lot of practice. And I am not talking about occasionally dabbling in Ruby on the weekends. I am talking about the kind of practice where I beat code that isn’t working into submission (though often times the code wins).

The kind of practice where all of a sudden I realize that it is 2am and I’m exhausted physically so I should go to bed, but mentally I feel on fire so I let the code have me for another hour or two (I imagine this state to be like a marathon runner or ironman near the end of their race).

The bottom line is that just like a world-class athlete needs to practice for 2 hours a day, if you want to be a world class programmer you need to be regularly practicing as well. The more code you write, the better you get.

In other words, the talent is not necessarily in writing the code itself but (if there is a talent involved), it’s the talent of practicing over and over again. Because if you think about it, it can be difficult to do the same thing over and over again without getting bored. So the real talent is keeping yourself motivated to continue practicing.

Code Katas

The programming world is beginning to realize the value of practice. Dave Thomas of pragprog books (not to be confused with the Wendy’s founder) has created a series of code katas to address the need of structured practice for programmers:

Code Kata is an attempt to bring this element of practice to software development. A kata is an exercise in karate where you repeat a form many, many times, making little improvements in each. The intent behind code kata is similar. Each is a short exercise (perhaps 30 minutes to an hour long). Some involve programming, and can be coded in many different ways. Some are open ended, and involve thinking about the issues behind programming. These are unlikely to have a single correct answer. I add a new kata every week or so. Invest some time in your craft and try them.

Currently, he has listed 21 katas for programming ninjas to practice on. The katas can be completed in any language and are all about getting you to that aha moment where you learn a new way to do something.

I struggle a litle bit with some of the katas because I like to work on things that are practical and it just feels like some of them are not practical. But maybe that’s the point. He wants you to focus on specific task like counting lines of code programmatically rather than building a whole system.

Suck Less Each Year

Jeff Attwood has his own thoughts about how to improve and it mainly involves sucking less each year:

I’ve often thought that sucking less every year is how humble programmers improve. You should be unhappy with code you wrote a year ago. If you aren’t, that means either A) you haven’t learned anything in a year, B) your code can’t be improved, or C) you never revisit old code. All of these are the kiss of death for software developers.

This rings true for me.

It’s almost painful for me to look at old code. All I can see is the ways that it can be improved. I imagine it’s the same with a writer who reads their finished novel. You’re happy that it’s done and people are enjoying it, but you’ve moved on.

The double-edged sword of programming is that there’s always more to practice on and learn…

When 37Signals (the producer of high-quality rails-based web apps) looks to hire, they don’t go to monster.com. Instead they look to the open source community:

When it comes to programmers, we only hire people we know through open source. We think doing anything else is irresponsible. We hired Jamis because we followed his releases and participation in the Ruby community. He excelled in all the areas mentioned above. It wasn’t necessary to rely on secondary factors since we could judge him based on what really matters: the quality of his work.

Hashrocket (another high-end rails shop) is no different according to their Dir of Business Development:

We ask applicants for their github usernames and check their contributions before giving them a phone screening

Their interest in and commitment to open source is obvious. The above companies even give their employees time (on the clock) to contribute back to open source.

But that’s not how it is everywhere…

Welcome to the Enterprise

When we look to the world of enterprise software development, it’s a different story. Maybe this is just my experience as a consultant in that world, but I’ve found that many large enterprises discourage open source contributions if not downright ban them.

And when they look to hire, they’re definitely not checking out a potential candidate’s github. When they hire, more often than not, they are looking for corporate experience with specific languages (C#, VB.NET, SQL) and specific tools (VS.NET, VSS, VSTS).

So why do we have these differences? The reason is cultural. Once you dive into a technical ghetto, you are diving into the culture that comes with it. Let’s dig into two specific cultures and see what we find.

The Rails Way

First, we have the Rails developer. Rails developers use open source all the time:

• Ruby on Rails itself is open source.
• For testing, they use Rspec and Cucumber.
• As an IDE, many use VIM.
• As a test web server, they use Mongrel.
• For source control, they use git.
• For a database, they use mysql.

In other words, Github is their friend.

And so it’s no wonder that a Rails developer would value open source contributions. It’s how they move the ball forward in their industry. When they look to hire, they will look for the best open source contributors because they live and breathe in that world.

Hail to Microsoft the One True Source

In contrast, we have the .NET developer. The .NET developer is strongly encouraged to get all of their tools from Microsoft. Pretty much all of their tools can come from one source:

• Their programming languages come from Microsoft
• Their OS comes from Microsoft
• Their IDE comes from Microsoft
• Their source control comes from Microsoft
• Their DB comes from Microsoft
• Their testing tools come from Microsoft
• Their ORM layer comes from Microsoft

And to many enterprises, this is comforting and may be reason why enterprises skew toward Microsoft developers. They want to have a vendor to call when something doesn’t work. They want to have a warranty so that when something blows up they’re not trying to get a hold of a lone developer in their basement.

Best Tools for The Job

But all of this uniformity comes with a price. That price is innovation.

Because Microsoft is so locked into the enterprise, it’s difficult for them to innovate. They have a large base to support so they can’t just try out something new. They have to be fully committed to a new feature and backward compatibility and therefore must move very, very slowly.

This probably explains why most innovations don’t come out of Microsoft or Microsoft developers. Who invented the testing frameworks that we know and love? Who invented git, HAML and SASS?

The other insidious aspect of being a Microsoft developer is that you don’t always get to use the best tool for the job. Instead you use the Microsoft-approved version.  Would you like to use nUnit for your tests? Sorry, MS Test is now built-in and is the Microsoft approved way so that’s what you’ll be using (even though it’s not quite as good)…

End Game

So what is the outcome of the open source divide? Basically Microsoft will continue to own the enterprise and Rails/Open Source will continue to own web startups. Innovations will come from the Rails/Open Source world and slowly be integrated and homogenized into the Microsoft world.

I just don’t see the open source divide closing any time soon.

One problem with being an ASP.NET developer is that it seems like the Ruby guys get all the cool toys first. I mean not only do they get all the great presentational goo like HAML and SASS, but they get all the fun testing frameworks too.

Gotta Love the Cucumber

And as testing frameworks go, there is something pretty awesome about Cucumber which is all about tying your specs to your tests.

I love the idea of documenting exactly what I’m going to build and then checking it off a list. There’s a great sense of progress.

For those of you that aren’t familiar with the awesome cucumber framework in the Rails world, the best way is to show you an example.

Step 1: Write A Feature

Here is what a feature definition looks like in cucumber:

Photo Credits: Ryan Bates’ Cucumber Screencast

If it doesn’t look like code, that’s because it really isn’t. It’s very much like writing normal language sentences that even a business analyst could understand. The idea is that you write your specs following the Gherkin syntax (note the Given/When/Then) and you tie that to tests in code.

Step 2: Tie it to Code

So we have a spec, then you tie it to code with regular expressions. For example,

Then /^I should see "(.+)"$/ do |text|
  response_body.should =~ Regexp.new(Regexp.escape(text))
end

Notice how the “text” from the feature gets passed into the testing code. So the same testing code can be reused for multiple features.

Step 3: Code Until Green

Now that your specs are tied to your test code, you simply write your actual code until all of your specs are green (ie – complete).

The nice thing is that you can see exactly where your project is at any moment. Have you completed 20% of the spec? 90% of the spec? Just run your tests to find out.

What about for the ASP.NET Crowd?

This is all good for those hippie Rail programmers, but what about for the more practical enterprise .NET programmer?

Enter SpecFlow. SpecFlow is a clone of Cucumber for the .NET world. Can’t you tell from its much more professional sounding name? It’s enterprise-friendly!

You can get started with SpecFlow in five easy steps:

1. Download the installer from their site – they have versions for VS.NET 2008 and 2010.
2. Start a new solution, add a reference to TechTalk.SpecFlow.dll, and add a new SpecFlowFeature file (this template will be added to Visual Studio by step 1).
3. Define your features in natural language using Given/When/Then Syntax
4. Add a new SpecFlowStepDefinition file. In here, you will write the code that is tied to your features based on specialized attributes (note I’m using Watin to automate IE):

   [Given(@"I have viewed the login page")]
           public void GivenIHaveViewedTheLoginPage()
           {
               var browser = new IE();
               browser.GoTo("http://localhost:2529/TestSite/Login.aspx");
               Assert.That(browser.Title, Is.EqualTo("Welcome!"));
           }

5. Build your solution and SpecFlow will automatically generate nUnit tests for you. Run your tests and behold your progress.

Just the Beginning…

This is just the beginning of what can be done with SpecFlow, but I hope it whets your appetite enough to try it out. And if you’re dying for other examples a few others have posted some details on this topic as well:

• http://derans.blogspot.com/2010/04/coding-dojo-xp-part-1-tdd-bdd-with.html
• http://blog.stevensanderson.com/2010/03/03/behavior-driven-development-bdd-with-specflow-and-aspnet-mvc/