Keith Casey's recent post on a book recommendations got me thinking. I get asked what books I recommend. I whole-heartedly agree with his first recommendation. The Pragmatic Programmer sits on my desk and is often in my laptop bag. I reach for it if I have five minutes and want to flip through something technical without having to load up my Google Reader.
Not on his list is the Passionate Programmer. I highly recommend this book to anyone working in the industry. I've reviewed it on Amazon, feel free to check that out for more information.
But this post isn't about what I recommend, it's what I don't. There are two books that Keith recommends that I no longer recommend off the bat to programmers. PEAA and Refactoring. Both are excellent books, but neither should be read by people starting out.
Why? The books are both excellent. I've read both. I own both. I do recommend them, some of the time. Both are geared toward programmers that already know how to program. Both contain a wealth of information which, in the right hands, can take the development of the reader to the next level.
But they also contain information that can be abused tremendously. For example, Active Record in it's abused, single-world form of ActiveRecord has caused a tremendous about of scaling issues. All because it was a Fowler endorsed method for dealing with data in a database. Developers without an understanding of its limitations started copying what Rails did and in the process mixed business logic and database logic into the same object. What happens when your data needs to be stored in a flat file or a nosql style database? Your business logic is now all tied up in your database and its painful to extract that and retrofit your application to be scalable.
Of course, since you have Refactoring you can fix that. Right? Well, sort of. Patterns and refactoring go hand in hand. Ideally, refactoring code should lead to some more understandable, reusable code; something that's more easily explained to another developer. Patterns fill the bill. Nowhere in Refactoring or Joshua Kerievsky's Refactoring to Patterns will you find anything about pattern hoping. To fix an improper use of ActiveRecord by moving to another pattern, however, you end up doing exactly that.
Couple that with the sweater string issue. We've all had a loose string on a sweater, right? You give it a tug instinctively to get rid of it, and before you know it a hem in gone and the sweater is ruined. Refactoring, in the wrong hands, causes the same thing.
Well, I need to extract this logic out. Next this piece needs to be mutable. I should inject this object so I can replace it out later if I need to. And so on, and so on, ad infinitum.
Both patterns and refactoring are powerful tools, but not in the hands of a novice. Both books should be read, but not when you're starting out. Get your hands on Pragmatic and Passionate, spend some time looking for a mentor to help guide you down the right path. Once you get your feet under you as a programmer, then start learning about the mechanics of patterns and refactoring. Once you're to that point, PEAA and Refactoring are great material.
To bring my blog readers up to speed. I posted this status update earlier in the evening:
Random question: How have I made it this far and not read The Timeless Way of Building yet?
I got this response from Bill Karwin:
I just heard about Christopher Alexander within the last year too. Dunno why I had not heard about him previously, given how much he influenced the OO paradigm. How did you come across him, and what has resonated with you most?
I started to respond, but then Facebook cut me off. They seem to limit the length of comments (once again, for convenience we're giving up control... I seriously think 1,000 characters is barely enough to get started in), but since I control the spigot here and can be as long-winded as I like, I'll post my comment here. Without further adieu...
I've heard of him a lot because of his Pattern Language book, but I'd never heard of this one. Reading the Screw Interface Patterns article on slash7 today got me thinking about it again and I determined to check it out the next time I had a few free minutes.
After dinner tonight, I stopped by the bookstore to check out A Pattern Language. The introduction talks about the Timeless Way of Building as the metabook (my words) of Pattern Language and how they really aren't separable: one provides the context, the other provides the words. Timeless Way was on the shelf next to it, so I picked it up and read the introduction. I was mesmerized. People don't write that eloquently, myself not excluded, any longer.
There was a powerful quote in the first chapter, and one that I find ironic giving the state of design patterns and refactoring in programming.
But though this method [of defining architecture through patterns] is precise, it cannot be used mechanically. Page 12
I couldn't help but think of all of the tools that enable refactoring. How we've tried to reduce patterns into reproducible macros and missed the spirit. It's too bad, really. I think a proper understanding of design patterns, be they of the structure of the code or the interface to it, can lead to much better code.
I ordered a copy tonight (couldn't pass up the $25 savings by having Amazon ship it) and plan on devouring it. I'm sure there'll be plenty of notes on my Readernaut page as I work through it.
I just finished reading Chad Fowler's Passionate Programmer book. It quickly earned a spot as one of my favorite books on the topic of programming and careers. I highly recommend it, and have been tweaking a book review that I'll post up soon, but I wanted to talk about want chapter that stuck out at me. Making the Hang.
The chapter talks about one of Chad's high school jazz buddies, Chris. Chris was a good musician, but he made sure he hung around with all of the guys who were better than he was and would pepper them with questions every chance he got. He called it making the hang. For some reason, this stuck out at me. I couldn't put my finger on it for a few days, and then it hit me. I've been doing this for a long time.
The first hang I made wasn't in the music scene or the technology scene, it was cycling. In particular, competitive mountain bike racing. A few years back I started riding more and more, wound up a regular at the weekly group rides, and finally decided to try my luck at racing. To this day there are few things I enjoy as much as that adrenaline rush you get as you pull up the line at the start of a race.
Starting out, I asked questions of anyone who would humor me. Looking back on it, I can see how Chad thought Chris might be annoying the musicians and I'm surprised I didn't annoy more people with my constant questions about racing. How do you prepare? What's your training like? Do you really think two-a-days work? What about road cycling? Is there any crossover benefit for mountain biking? Maybe we can go for a ride some time?
I was like a walking 20 questions game. But it worked. I not only finished the first race I ever entered, a 100 kilometer race in Juarez, Mexico, I surpassed my goal by over 50 places (was shooting for a top 250 out of more than 1,000 that would finish, and got inside the top 200). I know it's because I was prepared for the race. I'd asked enough questions of enough different people that I knew what to expect. I didn't have to learn the hard way, all I had to do was get my skill up to par.
I kept it up, and the next year I was 46 in a field that was won by the sitting Mexican national champion including winning a personal race within the race, I beat one of the guys who I'd been asking questions of the whole past year at the final sprint. I still had legs after 62 miles of racing to sprint for the line and he couldn't contest it.
It's happened in other parts of my life. When I took up road cycling, I literally learned to make the hang. The first group road ride I ever went on involved me with a group for about 30 minutes of a 90 minute ride followed by a long, solo trip back after I got dropped. By the end of that summer I was hanging with the group the entire ride and even making challenges at some of the sprints along the route.
When I got serious about moving from a hacker to a programmer, I made the hang by joining an open source project. Marcus Baker always had more time than I could expect to answer silly questions and help shape my view on what a programmer ought to do. I'm a TDD guy today explicitly because of those interactions with him.
So what's the moral of this story? I guess "get out there!" Talk to people. Hone those people skills and above all, don't be afraid to be annoying. 9 times out of 10, the person you're "annoying" (in your mind at least) is going to be so flattered that you respect their opinion that they'll spend hours talking to you and answering every last question you have. Don't believe me? Try it some time and tell me if you didn't get anything out it.
