Yet another bookshelf post (prequel)
I’ve been meaning to post a recommended book list for at least a year now, but it seems that every time I’m about to write it, somebody else posts a list. “My” list probably isn’t like anyone else’s list, but I wouldn’t want anyone to think I’m creating the list as a reaction to someone else’s list. I think I’m also going to put some..what do you call it…”effort” into the following posts and do something you’ll rarely see in this blog – real live hyperlinks.
One of the things I emphasize in the senior tester course I teach is that in order to grow, you must have a passion for learning. Courses, seminars, conferences, web articles and blogs can all be leveraged to learn more about software engineering and testing. I love to read technical books and routinely recommend several as being “indispensible reading material” for anyone serious about software quality.
I joked the other day with a colleague of mine about evaluating software engineers by their bookshelf. While in essence, it’s a silly way to assess someone, I got the idea from my college jazz band professor.
I played in one of the top university jazz bands on the west coast. The audition process to get into the top band was lengthy and grueling. The audition was based on ensemble skills, reading, and improvisation. I recall a day when the entire hour allotted for auditions was spent listening to tenor players solo. After each player played, our professor, or “Coach” as we called him, would ask the player some questions about their solo, where they got some of the specific quotes from (in improvisation, “quotes” are phrases borrowed from popular solos, pop culture, etc. I, for example, used a lot of quotes from Dexter Gordon, but also frequently “quoted” the lucky charms theme and the woodpecker laugh). “Coach” would also usually ask who they listened to, and try to get a feel for raw talent as well as potential.
At least once a year during auditions, “Coach” would state that he could save us all a lot of time if he skipped a big portion of the audition and based the bulk of his decision on what was in our record collection (yes, records, I’m old). His point was that you learn a lot about how to play jazz by learning from some of the masters. Barring master classes, the way to learn from jazz masters was to listen to them play, copy them, and use what you learned to develop your own style. I think a lot of this core idea transfers to other areas - and in particular to software engineering. I can tell a lot about what a tester (or developer) knows and is capable of by knowing what they have read. I’m not going to argue that you can’t learn a lot on the job, or that you can’t learn a lot by simply getting more experience, but at some point you will need to find a way to expand your thinking – either through learning new ideas, or just by forming better opinions about the ideas you already have in your head in order to continue to grow in your career. Good books on your bookshelf (broken spines are a big plus) shows me that you care about learning and growing.
In short (hah!), I guess that’s why I put so much emphasis on reading, or the study of testing. I’ll get the booklist up shortly.