The vast majority of candidates I speak to answer my question of “What good development-related books have you read lately?” with something along the lines of “I haven’t read much lately” followed by any number of rationalizations for their lack of drive for self-improvement.
Reading is important, folks. Not just blog reading, but diving into good books written by good authors. I’m working on updating my list of what I consider to be essential books for developers at different levels to glom on to. My list is based heavily off of the Contrux Reading Ladder. I figure Steve McConnell probably knows a thing or two about what to read — although that list is old and includes nothing on agile methodologies, so I’m adding in some of what I think are critical works from that area.
I’m also including a few things from Sam Gentile’s .NET list. Sam’s list has a bunch of terrific content on it, but is very different from McConnell’s list. McConnell’s list is all about the broad fundamentals of development. Sam’s is all about the nitty-gritty of .NET specifics.
I’ve come around to the idea of two categories of books: general development and technology specific things. I think books from the latter list tend to last a shorter timespan than those from the first, perhaps as little as a year or two. Hiller’s Advanced SharePoint Services Solutions book is a critical read for someone working in SharePoint 2003, but we’re now past that and on to SharePoint 2007 (MOSS, or my loving nickname “PITA”.)
You need those technology-specific books to get over short-term hurdles: getting up to speed on a technology, figuring out how to solve particular problems for a project or two. The general fundamentals are just as critical, perhaps even more so.
Grokking out Wagner’s Effective C# ensures you’ll be doing your C# development properly and avoiding some subtle pitfalls. Whacking the contents of Agile Principles, Patterns, and Practices in C# into your head means you’ll be approaching your design from the right angle. Sleeping on Code Complete until it melds into your subconcious ensures you’ll think about construction as you’re doing your coding. Devouring some classics like Programming Pearls, The Practice of Programming, or Conceptual Blockbusting helps guarantee that you’re looking carefully at how you approach your software. Then go read Peopleware and figure out how to improve the envrionment you’re working in.
Not reading? Get to it. No excuses. If you’re not reading, then you’re not, uh, reading.
4 comments:
I'm amazed a how few of my co-workers actually read (even blogs let alone books). I truly believe that you're either progressing or regressing. Another big point is soft skills - far too often we focus so much on the technical skills (both general and tech specific) and neglect to read anything about improving our people skills and effectiveness/efficiency.
You're absolutely right about soft skills, Dave, and I need to start assembling some material around that topic.
A co-worker recommended "The Invisible Employee" and I've liked Ricardo Semler's "Maverick." I'd sure appreciate any soft skills books readers might recommend!
This is kinda interesting, as I'm gonna be out job hunting in the next 6 - 12 months, and I'm mildy apprehensive about it.
My case is a little different -- I read a lot of technical books, but generally never get past the 1/2way mark on most of them.
There's a few "grass roots" exceptions I've read the whole way through -- such as the enitre Pragmatic series, and a couple of Head First books.
But a large chunk of others I get about 1/2way, get the general overview of what they're talking about, and then stick it into the "read it when I need that technique / technology" part of my mental bookshelf.
How would you respond to this kind of candidate throughout your process?
Cheers
Marty
Marty: At least you're making an effort -- but the question is are you putting down the book at the halfway point after you've grokked anything important from it?
Superficial knowledge of a topic is often even more dangerous than no knowledge, depending on how you use that knowledge. Do you use the knowledge as exposure to topics you know you need to dig further in to, or do you use it in an attempt to have a facade of expertise?
I had an interview with a supposedly senior-level .NET fellow. He was like a brittle crust of ice: a bit of knowledge which quickly broke into billions of pieces after one sharp poke.
Post a Comment