While catching up on long overdue flagged posts to read - I spotted a familiar meme on becoming a better developer – I wrote about Continuous Education almost 2 years and it’s nice to see that this topic keeps reappearing. I’ve updated my bubble graph of the technologies to include those that I’ve used over the last 12 months and have also added training courses and events I’ve attended:
Apart from the foray into WPF development in late 2006 / early 2007 and a little dabbling with Silverlight 1.1 post Mix 07 – I’ve been involved predominantly in the RIA space. It was a bit of a mental shift working on several smaller projects in 2007 as until Christmas 2006, I had been working for the same client, creating a number of products based on a shared platform for almost 2 years.
Another change that’s happened in the last 18 months is that I took on the role of a Technology Coach responsible for the career development and appraisals of a number of developers within Conchango. Performing this function has given me a new perspective Continuous Education; one thing that Agile Methodologies has taught me is the power of a feedback loop – the tighter the feedback loop the greater your ability to inspect and adjust; this can work really well if you know the career aspirations of the people in your team and you have the mechanism (i.e. an iteration) where you can let those people learn and grow.
One topic I've been spending a lot of time thinking about over the last year is "how do you hone a development team into a state of hyperproductivity?" If you assume that the foundation of the team is an Agile process with iterations and a feedback loop (retrospective), what other facets do the team need? At the moment I'm convinced it's confidence or to be more specific, fearlessness, the state of mind you can achieve when you have confidence that you know what you are doing, confidence that you can make a change and you know the impact and ramifications of that change. Team velocity can be severely impaired by the fact that a development team is intimidated by the codebase, either because it is very large, complex or mainly unknown to them – they fear making changes because they don’t know what the cost of that change would be.
Two vectors that I believe helps developers into the fearless state of mind are test coverage and refactoring tools. Empowering the team with Resharper and spending time teaching them how to really use it means that they are suddenly much more in control of the codebase than before; they can easily see the interconnectedness of the code; renaming, moving, deleting cleaning and extending the code has suddenly become a simple if not trivial task. A feature like Resharper's "find usages" give a great hint as the the cost of a change. But the real confidence only comes with good test coverage (integration and / or unit). These two vectors should give them enough confidence to put them in the state of mind that they could be a bit more fearless, which tends to means that in time they start becoming more independent, self managing members of the team – which is when they are truly useful and truly productive. Ben Watson has a nice post called 6 Ways to Increase Your Confidence As You Code.
I also tend to read a lot - I subscribe to around 70 blogs (I use Newsgator Inbox (now free!) and Outlooks' search folders to filter for topics I'm interested - the rest get perused on train journeys), I'm also quite an avid consumer of books, below are the ones I’ve purchased and read in the last 12 months: