Be More Than Just A Code Monkey
I wrote this book because I believe the shift away from “programmer as coding specialist” is inevitable. If that’s true, then our entire field will need to prepare itself for the not-so-distant future where “programmer as skilled solver of ordinary human problems” becomes the norm.
— Gregory T. Brown
I picked up this deceptively slender (~115 pages) book after reading an article about it on the O’Reilly site a week or so ago that said “it’s sort of like The Pragmatic Programmer for a new generation.” Given how important that book’s been for me as a developer (it’s in my periodic re-read pile, along with Code Complete, the GoF Design Patterns book and Knuth’s Literate Programming), it didn’t take much thinking before ordering a copy.
Gathering requirements for software development projects has always been a difficult process, and has veered through various methodologies like waterfall and agile. Regardless of the methodology, though, there are certain pitfalls to deciding and describing just what an application should do that can result in projects stumbling or failing. Requirements fractalization, focus on little used details, or lack of developer and stakeholder involvement can all actively harm the best architecture.
At the moment, I’m sitting at a gate at Newark Airport, waiting to board an extremely delayed flight that will take me to the South by Southwest Interactive festival in Austin, TX, where I’ll be speaking on a panel discussing estimating software projects (“Project Estimation: 3 Firms Light Up the Dark Art”, March 7th, 5PM in the San Jacinto Ballroom). I figured that I’d use this unexpected idle time to capture some of the points that I hope I’ll be able to make.