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.
What It’s Not
As you’d expect from such a short book, it’s a fast read, but at the same time, it’s a book that’s going to merit re-reading. If you’ve been working as a developer for long enough, you will remember the era of 1000+ page programming books that were mostly filler, usually with pages and pages of screenshots of dialog boxes showing you exactly which buttons you needed to click in what sequence to complete the wizard to create an MFC application. This is not that.
What It Is
This book digs into the higher-level thinking that a modern software developer needs to be fluent in (the book’s subtitle is "Be More Than Just a Code Monkey"). For example, the first chapter discusses using prototypes to explore project ideas. On the surface, this hardly seems worth writing down, but my experience is that far too many developers don’t have a well-considered way to actually do that (and I think that it’s sometimes made worse by clients who once skimmed an article on The Lean Startup, get excited about the idea of a ‘Minimum Viable Product’ and come to us wanting what they call an "MVP" but that would take a team of 5 a year to produce.)
Brown uses an unconventional format for the book — chapters are mostly in the form of a narrative in which you (the reader) are the main character in a brief drama involving the development problem that he’s covering. One nice thing about his approach is that by making it a narrative, it becomes natural to have the characters discuss the various tradeoffs that need to be balanced as a problem is explored and a design evolves out of that exploration as their understanding grows.
Too many software books are like the cooking segments on early morning talk shows — the chef comes in, points at some bowls of ingredients before dumping them into a pan while the host jokes around, and then, through the magic of television, they reach under the counter and pull out an already cooked and perfectly presented finished dish. With both cooking and developing software, the interesting (and hard!) part is that stuff in the middle where you’re at least a little confused, things aren’t going the way you expect them to, and you need a way to get to the desired end state, whether that’s because of good intuition, experience, or having learned from a good guide.
That’s pretty much how the book functions — there’s an especially good chapter that walks through a senior developer guiding a colleague through the process of solving a problem that comes with a great deal of ambiguity and sample test data that’s of unknown usefulness (in other words, as realistic a problem as you’ll find ). I’ve seen too many developers in situations like these go quickly into ‘thrash mode’, relying on frantic effort instead of calmly proceeding through steps like walking through a problem by hand on paper before jumping into coding, or tackling reasonably small subproblems first, and building on those to implement the larger-scale solution.
…Left as an Exercise For the Reader
Each chapter except the last one ("The Future of Software Development") ends with a set of ‘Recommendations and reminders’ and ‘Questions and exercises’ for the reader that strike me as unusual because it’s exceedingly rare for me to encounter something like that and do more than skim past them while nodding my head.
As for there being no recommendations after that last chapter on the future of software development (in which the author extends the story format into the near future to demonstrate his dream AI-assisted development system), I guess the recommendation from me is that we should spend time building that future in a meaningful way and start breaking away from cryptic text-based tools that have only changed cosmetically in the last 40-50 years.
This is definitely a book that I’d recommend, especially to some of the young developers I’ve met coming out of computer science programs that have trained them in chapter and verse of whatever language they’ve used for instruction, and given a description of an algorithm can maybe implement it cleverly, but when presented with a real problem affecting users aren’t sure how to dig in and make something that works.
I’ll probably read it again right away (but more slowly), and will probably pull it off the shelf for a refresher every year or two.
Image via Or Hiltch
