Books that I’ve Been Reading
- “Clean Code: A Handbook of Agile Software Craftmanship” by Robert Martin
- “The Clean Coder: A Code of Conduct for Professional Programmers” by Robert Martin
- “Domain Driven Design: Tackling Complexity in the Heart of Software” by Eric Evans
- “Working Effectively with Legacy Applications” by Michael Feathers
- “Objects on Rails” by Avdi Grimm
- “The Cucumber Book: Behaviour-Driven Development for Testers and Developers” by Matt Wynne and Aslak Hellesoy
- “Crafting Rails Applications: Expert Practices for Everyday Rails Development” by Jose Valim
- “Rails 3 in Action” by Ryan Bigg and Yehuda Katz
Much like a doctor practices medicine, I practice coding. That isn’t to say I’m an amateur, as I take my profession very seriously. I want to get better at. The above books are a lot to ingest in a short period of time, but I find that reading multiple different sources at the same times helps to better sew the seeds.
This isn’t to say I’m just now picking up software books and reading them. I’ve read plenty of other software related books prior to this recent “binge” – The Pragmatic Programmer, Refactoring, Smalltalk Best Practice Patterns, Test Driven Development, Implementation Patterns, The Rails Way, and several more.
In looking at my pattern of learning, I tend to go the path of assimilating lots of information in short bursts of time; Some times this is triggered by an emerging issue or problem-set, but more often as inspiration and guidance for improvement.
Keeping One Constraint Salient Instead of Ten
“While teaching programming, Matt observed that giving the children the single rule that they shouldn’t have methods longer than 10 lines resulted in the children writing code with SRP, encapsulation, and other positive attributes. Matt argued that beginning with a simple rule that could get you 80% of what you want is likely better than 10 rules that, if followed correctly, could get you 100% of what you want.” – Jay Fields http://blog.jayfields.com/2012/03/when-to-break-apart-your-application.html
The above concept, write software with one constraint, is excellent advice. There is a tremendous amount of literature concerning best practices, methodologies, and principles; all of which can be challenging to internalize.
I can safely say that any methods I’ve ever worked with, or written, that were more than 10 lines were inevitably difficult to test. Or, in the case of my pre-automated testing days – The Dark Days – those long methods were inevitably the cause of the most bugs.
In fact I would wager that the probability of bugs in a method is N log(N) where N is the number of lines in the method. In other words, as the size of a method grows, the probability of bugs grows faster. This is based on experience and conjecture, nothing more.
This single constraint is in tension with reading numerous books…after all how can I hope to possibly internalize all of the information I’ve been reading.
“The TDD community has been recently buzzing with the realization that code becomes more general as tests become more specific, revealing that test-driving code alone will push it to a more appropriate level of abstraction. It is still up to the human(s) at the keyboard to change the class and method names to match.” – Tim Ottinger and Jeff Langr http://pragprog.com/magazines/2011-02/abstraction
In someways, each of the books I’m reading are tests against the mental model that I’ve built up in my 14+ years of programming practice. In many cases, the tests reveal issues in my underlying modus operandi. I work through those ideas and attempt to push towards more general solutions.
Case in point, I recently wrote a small command-line application based on a problem domain that I understand – the Diaspora RPG Cluster Creation rules/algorithm. I used Avdi Grimm’s “Object on Rails” as a general template for what I would do. I wrote about this experience on my personal blog.
By writing my tests, and testing my mental model of “what is programming”, I was able to personally reaffirm that Avdi’s suggestions are in fact a good practice. Namely that small classes, small methods, unit tests, and acceptance tests are all integral for making software flexible and maintainable.
Intelligence and Wisdom
“Intelligence is the ability to learn from your mistakes. Wisdom is the ability to learn from the mistakes of others.” – Anonymous
I don’t work with cutting edge technology, however I do work with yesterday’s cutting edge technology. So I look to the experiences of others and try, as best I can, to apply them to my day to day software practice.
To also best learn from others, I’ve been helping out with the Rails pull requests…examining the code and testing the patches, as well as participating to some small degree in conversations concerning the code.