If I was going to offer one piece of advice to anyone aspiring to be a top class software developer* (apart from writing lots of code) it would be to read books. Not just any books though, books written by masters.
Experience often counts for little in software development. If you’ve spent your whole career in the same shop with little exposure to other languages or people outside your organisation it’s quite possible that some 21 year old upstart with a copy of Clean Code under his or her arm will wipe the floor with you when it comes to effectively writing and maintaining software.
Granted, working with good or even great developers will mean a lot will rub off on you. I’ve learnt countless lessons from the people I’ve worked with, but if I look around me people are no older than 30 at most with an average of around 5 years developing software in probably no more than 3 different organisations.
People like Martin Fowler, Eric Gamma, Kent Beck, Robert C Martin, Craig Larman and Michael Feathers have been at it for 25 years or more and in that time have slowly built up the kind of reputation you only get from regularly being right.
Also granted, blogs are are an invaluable resource, but are rarely little more then a meme in someone’s head and give you nothing like the deep contextual insight you can get from a well written book. There is also little to assure you that the author is anymore likely to have a better idea than yourself. Believe me when I say there are many people blogging who rarely live up to the practices they preach and are no more or less likely than you to know the right or wrong way of doing something.
I have learnt a lot from both colleagues and blogs, but both pale to what I’ve learnt from the books I’ve read. I can comfortably say there is no way I would be where I am today without them and I strongly believe it will earn you more money. When you think of all the things you could do to try and put more folding stuff in you’re back pocket it’s a relatively simple win!
I’ve been inspired to write this after reading Eric Evans Domain Driven Design which has gone right into my top 5 books of all time. Why is it so good? It’s not because Eric has necessarily been born with some supernatural instinct for writing great software or that Domain Driven Design is going to save the planet. It’s because it’s full of the lessons that Eric has learnt in his long and illustrious career, carefully woven into a highly readable narrative. There’s nothing particularly new here. Like all the great books I’ve read it is no more than a distillation of the practices in the industry which through time have proven to be the most effective. I remember Martin Fowler once saying that people often asked him what would be the future of software development. His answer was that to see the future you only have to look to the past.
Below is a list of the books which significantly changed the way I think and work more than any other’s I’ve read. No doubt you’ve heard of them all already and are on a list of books to read in the back of your mind somewhere and I’m sure there are plenty of others that had as significant an impact on people as these have on me. However I think few will argue that any of these books do not deserve their place on this list. All I can say is get on and read them if you haven’t already.
Refactoring: Improving the Design of Existing Code by Martin Fowler
Domain Driven Design: Tackling Conplexity in the Heart of Software by Eric Evans
Working Effectively with Legacy Code by Micheal Feathers
Agile Software Development: Principles, Patterns and Practices by Robert C Martin
Clean Code: A Handbook of Agile Software Crafstmanship by Robert C Martin
xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros
Lean Software Development by Mary and Tom Poppendieck
The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer by Jeffry LIker
*I am in no way professing to be a top class developer 
I attended Software Craftsmanship 2009 at the BBC last week. It was a one day event with three streams. Below are some of my thoughts on the sessions I attended.
Pitfalls in Test Authoring
John Daniels & Dave Cleal
John and Dave presented some examples of testing practices (good and bad) with the intention we would discuss them in small groups and then come up with our own examples. A very enjoyable session with some interesting results (a lot of people felt it was OK to hit the DB in a unit test and there was clearly a lot different interpretations of what constituted poorly-defined tests). Most amusingly everyone disagreed with one practice Dave presented where he was testing a sequence of events (multiple assertions) in one test which was rather the opposite of his intention! I had put forward a session on “Test Smells” which got shamefully rejected so with Gojko were able to come up with a crap load of our own examples (see xUnit Test Patterns for some examples) .
Keith Braithwaite ran two sessions:
Three Paradigms: Taking An Extreme Position on Code Style in a Safe Environment
e.g. “remove all setters and getters”, “remove all conditional statements, and then remove them from where you’ve hidden them”. This would have been better if he’d handed out the code examples pre-conf as most people spent the first 15-20 minutes getting the fekker working, but a fun and worthwhile exercise nonetheless. Keith is clearly a man of high standards (“any language with curly braces makes you stupid”) and whilst I admire this I have much bigger issues than “pointless DTO objects” to refactor…
TDD As If You Meant It
Thankfully this was a little less challenging then the previous session, but a fantastic exercise in TDD discipline. We were given the task of identifying whether a “Go” piece was “captureable” (surrounded on more than 2 sides by opposing pieces) TDD style following rigorous rules. There were some really interesting results and a lot of people really struggled not to try and solve the problem that was in their heads rather than doing the simplest thing possible to get the test to pass. Most people found that being really disciplined resulted in the creation of a lot less objects holding state and instead more functional style. Gojko has done a brilliant write up on his experiences here.
Open Spaces
The first session, instigated by Matt Wynne was to address a particular issue he’s having where the problem domain has outgrown the current architecture and how he could enable it to evolve. It seemed the real problem (as is often the case) was communication channels and standards within the team. There were some interesting discussions on how team dynamics and the history of the context are significant in the solution. There was agreement that, if all else, pair programming was essential to spread best practices.
The second open space proposed by David Laing was the ever topical subject of how to deal with technical debt. Essentially it felt there were two approaches:
- Raise it with the business and explain it in a way they will understand (use analogies, act it out as a soap opera, cover the wall in technical debt cards until they sit up and notice).
- Just get on and do it (you wouldn’t tell a guy building your house to only dig half the foundations as it would be cheaper/quicker and he wouldn’t do it so why should we?). Follow the mantras of don’t live with broken windows and the Boy Scout rule
There are of course many other issues in play and again, pair programming was highlighted as invaluable in spreading good practice. David has written about his thoughts here
Overall it was a fantastic day and really refreshing to focus on the development skills rather than the infinitely more floaty process-oriented “Agile” practices. I look forward to next year. Well done Jason Gorman and all the guys involved in the organisation.
