Tuesday, January 19, 2010

The difference between a great developer and an average one is 6 hours

I explained in my intro post that I was using this blog to immerse myself in the new wave of technologies.  In this article I want to shed some more light on what the primary driver behind this was.

Until a couple of years ago I was very comfortable with the current .NET technologies of the day - ASP.NET 2.0, ASP.NET Ajax, WinForms... and a bunch of tools and libraries that shipped within that ecosystem.  I would probably go so far as to put myself out as being an expert (whatever that means) at using them to build stuff.  Then one by one, new components shipped and I somehow stopped staying at the leading edge of the curve - .NET 3, .NET 4, Silverlight, WPF, and a bunch of agile practices that came with them.  The way we build stuff changed too and so new arts and disciplines came to support that - PowerShell, TDD, DI, MS Build and the list goes on.

Let's just say that, during that period, when given a choice between sleeping and staying ahead of the curve... I chose to sleep.

The most important result of all that was not that I cannot use these new technologies, it's more about the level of comfort that I have with them.  Probably the thing that I liked best about what I had before was the ability that I had to create a high quality base application in a very short space of time.

This meant that I could fire up Visual Studio, create a blank solution, and in under 6 hours I could have something which:

  • Was housed in a source control system
  • Could successfully build as part of a CI process
  • Used best practices for cross cutting concerns such as configuration, logging and security
  • Used high quality third party libraries where they were needed to add value
  • Had a good consistent approach to naming and design guidelines for things such as namespaces and classes
So in under 6 hours, I had an architecture that I was very comfortable with; I knew that I could extend it, deploy it, customize it, and generally do what I liked with it.

At the time I remember lamenting how long it would take other developers to get to a good, consistent base such as this.  You might assign a developer a task and when you came back a week or two later they hardly had anything resembling something which had evolved from anything resembling modern software.

Getting to your high quality base should be the sharpest tool in your toolkit.  And until you can get to that point, it should be the main focus for your Coding Katas.  

So that's the aim for me this year and that's the journey that I hope that this blog will document.  Base app, best practices, 6 hours!


  1. Are you saying that because you aren't playing with the latest tech that using stuff you already know is quicker to build that base?
    If so, there are often advancements e.g. between ASP.NET 2.0 and ASP.NET 4.0 that actually will improve your releases becuase they have features you'd have to build in ASP.NET 2.0.

    Getting comfortable with a tech doesn't happen over night and yes usually means losing sleep out of hours or getting personal development time to explore the tech.
    I've worked on projects where they have 4 weeks up front to settle on the tech and get comfortable with it also. In some of those cases we dumped the new tech because we couldn't get comfy with it and slid back to something we did know.

    Sometimes tech gets pushed regardless of whether its' actually needed ;-)

  2. Thanks JT... I agree with everything that you've said. What I guess I'm alluding to is that I haven't sat back and properly evaluated my base setup to work out what to keep of the old stuff and what to throw out and replace.

    I'm going to follow this up with a post which gives a more concrete example of what I mean, but think of it this way...

    If you are going in to a client and they want you to start them doing MOSS custom development - I bet that you'd have enough "patterns and practices" in your toolbox that you'd get most of the plumbing sorted out in the first day (presuming that you had the environment already there).

    Because of your experience, and knowledge of how to do things, you can get the framework out of the way very quickly. Then you can move on to working on the meaty problems such as what they actually need built.