I’ve just been reading a post by Jeremy Miller called Evolution of a Developer (in regards to DI/IoC) (I’ll wait here while you go and read it). I started to comment on the post but decided to add my thoughts here instead.
Jeremy talks about the chasm from step 1 to step 2 and makes the following observation:
I think the leap from #1 to #2 is huge chasm that many developers will fail to cross in their careers, but every following transition becomes easier.
I wanted to add my observations about this (and expand the context slightly) from personal experience…
I think the step from 1 to 2 is such a chasm because it requires so many things to be in place before it can occur. The developer has to want to do things better, they must be open to the opportunities to make things better and they need to be in an environment that makes taking this leap as pain free as possible. If the developer really wants to change, the best thing for them is to start using a container as soon as possible, it accelerates understanding and acceptance while (generally) reducing pain.
I think there are 4 broad categories of developer that start down this path (and not all of them make the leap – some are quite content on their side of the chasm):
1. The Hacker
The hacker usually has no respect for his code (or his workmates) and is solely focussede on just getting it done. Hackers will generally never rise above creating a big ball of mud without a significant investment of time an effort from the team around them. A lot of the hackers I have seen started out developing web applications using scripting languages (like PHP or ASP – often self taught) and migrated to .NET without understanding that it is a paradigm shift they are making, not just a language change.
There is no easy way to help hackers evolve – they are focussed on just getting it done, no matter the cost. I think that large amounts of pair-programming + reducing the ceremony as much as possible is the key with these developers, if you can appeal to their sense of pride in getting something done and getting it done fast, you may just win them over.
2. The Ostrich
The ostrich is similar to the hacker in that he will generally never rise above creating a big ball of mud. The key difference being that rather than not caring, like the hacker, the ostrich lacks the motivation to do better so places his head in the sand and carries on as normal. This lack of motivation can be caused by the atmosphere of the team or the situation the developer is working in – the code has won, the developers are beaten down and simply push the mud around (back up the hill?) because trying to do any different seems hopeless.
If it is only a single developer that lacks motivation, you can treat them much the same as a hacker (although you will need to understand their motivating factors). If the issue of motivation lies with the team, the problem is much harder to address and often requires a combination of new blood + a new project to motivate the developers and get them to a place where they can see that things can be better.
3. The Blind Man
The “blind man” is one of those developers who does the best with what he knows, but doesn’t know that there are better ways of doing things. I think there are less developers around like this now because the .NET community has grown significantly in the past few years (I used to be one of these developers).
Sometimes the blind man will eventually stumble into the light, but more often than not it requires a gentle shove in the right direction. I “saw the light” when someone sent me an email with a to JetBrains OmeaReader and their OPML (thanks AP / JD). Reading blogs will not make you a better developer, but it opens your mind to the opportunities that are out there and makes takign the leap a lot easier.
4. The Natural Developer
These are the guys who just seem to “get it”. If they aren’t using DI / IoC right now, send them a link and they’ll be all over it tomorrow.
From my perspective…
I went from having a vague idea of the concepts of DI / IoC to building a web application using MonoRail / Castle Windsor / NHibernate. It hurt some, but at the end of the day my understanding increased exponentially by jumping from step 2 to 4 (and now I’m starting to understand step 5). I would attribute a lot of my initial understanding and desire to take the leap to reading blogs of guys like Jeremy Miller and Ayende Rahien, but at the end of the day you have to want it.
If you have the opportunity – take the leap!