What is it that sets apart a top-notch IT executive from others of his calling? To my mind, one mark of today’s true professional, especially at the senior executive level, is to be deeply familiar with the seminal books in his or her field. The dilemma for an IT professional, though, comes from the ongoing and increasing flood of books to choose from, and trying to figure out how to walk the fine line between focus on the intensely tactical and focus on higher-level concepts and ideas.

The tactical books do have their place on your shelf, actually, and it would be a mistake to ignore them simply because you’ve moved beyond daily application of your development, configuration, and technical trouble-shooting skills: judicious selection and absorbing of nuts-and-bolts techniques and new approaches will keep your insight into technology and its possibilities fresh.

I started in IT as a developer, and I remain fascinated by the endless possibilities and techniques of the world of software. In the last decade or two, though, I’ve become even more intrigued by a metalayer above the more tactical concerns. True to my ongoing insistence that the biggest challenges in IT aren’t purely technical, I am ever more convinced that the greatest difficulties are presented by “psychology of IT” issues: the human factors in how software and systems are conceived, built, tested, deployed, maintained, and eventually decommissioned.  Here are just a smattering of the eternal, non-technical questions that go far beyond the computer language du jour or the latest hot methodology:

• How do teams actually create and complete information technology projects? What works, what fails, and why?
• Why are some software developers ten times as productive as others?
• Why do some software teams gel and others don’t?
• Why do small companies with very few resources often beat out large, well-funded efforts in the marketplace?
• How technical should managers be?

So starting with this post, let’s embark on a multi-part survey of the groundbreaking, timeless books on such issues. I’m going to pick what I consider to be the top three books from each decade, starting with the 70s.  Each of them deserves not only a place on your bookshelf, but to be read and reread every few years. And contrary to what one might think, their insights remain not only valid after all these years, but have become all the stronger by having been confirmed by the history of the industry since their publication.

• Weinberg, The Psychology of Computer Programming (1971)

Weinberg opens with, “This book has only one major purpose—to trigger the beginning of a new field of study: computer programming as a human activity…. If our experiences are any indication, each [software developer] could be functioning more efficiently, if he and his manager can learn to look upon [him] as a human being, rather than as another one of the machines.”  This book was especially groundbreaking by addressing software development as both an individual and a team effort. Remarkably readable and full of anecdotal examples, it covers virtually every human aspect of the software development “sausage factory”: team formation, individual contributions, goal setting, leadership, estimating.  Weinberg’s “Silver Anniversary” edition of this book contains annotations and commentary for each chapter, reflecting on similarities and differences to today’s environments.

• Brooks, The Mythical Man-Month (1975)

I’ve said it before: if there’s one single book that every IT professional should read, it’s this one. Brooks’ foreword presents it as a “belated answer to Tom Watson’s probing questions as to why programming is hard to manage.”  Brooks’ writing brims with key universal concepts that can be unfortunately non-intuitive to people outside the field, but which ring familiar to any long-time IT practitioner. The titular essay introduces the concept of the “mythical man-month”, his adage that “adding manpower to a late software project makes it even later.” But there’s much more, such as “plan to throw one away”, where Brooks points out that the “first system built is barely usable; … there is no alternative but to start again.” I can’t say enough about this book. As with the Weinberg book, the anniversary edition now being sold includes extra material: Brooks’ later (1986), equally seminal essay, “No Silver Bullets” (see my post on this: “No Silver Bullets. Really!“), as well as some added chapters that revisit the assumptions of the first edition.

• Weizenbaum, Computer Power and Human Reason (1976)

Ultimately, this is a book about the limits of computers and software. Weizenbaum, a noted computer scientist in the early days of Artificial Intelligence research, wrote a program called ELIZA, featuring a script that “enabled it to parody the responses of a nondirective psychotherapist in an initial psychiatric interview.”  In other words, his test subjects would converse with a software program that emulated a therapist. Weizenbaum became horrified by how many people forgot that this was “just” a machine they were talking to, and that the dialog was really just an illusion. Many insisted, to his amazement and despite his explanations, that the computer actually understood them.

IT professionals today can be just as swept away, to a fault, with the potential ultimate power of software and systems as Weizenbaum describes.  I’m inspired and reinvigorated every time I read his sobering, methodical discussion of the nature of programming, the limits of its scope, and the need to consider the social implications of technical projects.

The next time, I’ll be on to the key books of the 80s. I’ve already picked the books I tentatively plan to write about, but I welcome your suggestions.

Lagniappe:

Here are a couple of books that didn’t quite fit in my theme and chosen time frame, but which are still worthy of mention:

• Thomas Kuhn, The Structure of Scientific Revolutions (1962)

Nobel Prize-winning physicist Steven Weinberg wrote that this book “has had a wider influence than any other book on the history of science.”  This book is not about information technology directly, but its influence has been monumental across all scientific disciplines, and it is a book that any technologist should know well.

• Ted Nelson, Computer Lib/Dream Machines (1974)

This was a self-published book in the early 70s, by influential industry visionary Ted Nelson, the man who coined the term “hypertext.” It’s probably different from just about any book you’ve ever read.

Just a quick, personal post this time: I was recently interviewed by CIO Magazine on the topic of “How CIOs Can Stay Tech-Savvy“.  Since (as is normal) only a portion of my conversation with the reporter actually made it into the article, I thought I’d expand briefly on the topic here.

My remarks were two-fold, consistent with what I’ve written before on this all-important topic:

• It’s critical for the IT executive to “keep his or her hand in” by doing some hands-on work and experimentation with new technologies
• Your purpose in doing this hands-on work is not to become a viable technical resource in the area, but rather to get some deeper understanding than you’d obtain by just reading an article or two.

As mentioned in the article, I estimate that I spend 5-10 hours a month doing this kind of hands-on dabbling, sometimes with more success than others.  Let’s look at the kinds of things I do, large and small:

• Obviously, I administer my home network (four machines running three different operating systems, plus other home networking devices) and provide advice to neighbors and friends.
• I administer my blog, including configuration, changing WordPress templates, and even custom-coding PHP callbacks at times.
• I also actively seek out “early adopter” opportunities with new technologies, or technologies that are simply new to me.  I currently have four virtual machines that are launchable on my Mac: Ubuntu, Fedora 11, Windows 7, and Windows Vista.
• I have an ongoing Javascript dev project I work on that analyzes my iTunes music library and helps me identify gaps in metadata and lyrics, so that these can be corrected. That Javascript also dumps all the lyrics in my music library out into XML, to get them out of the proprietary world of iTunes.
• At the beginning of each year, I list out the technologies I’d like to delve into more deeply that year, in terms of reading and experimenting.  This list is based purely on what has intrigued me as I’ve scanned blogs, feeds, and Twitter. For 2009, my list included Amazon EC2 and S3, Ruby, Heroku, and CouchDB.  I’ve not gone as far as I’d hoped with a couple of these, but hey, 2010 will have a list too.
• In a given year, I might do some coding in Javascript, Perl, PHP, and Ruby. Admittedly, I usually need to look quite a bit of stuff up, but that’s mostly a factor of doing this only an hour or two a week.

As I emphasized in my remarks for the article, the point here is not to become a player on the field. I’ll never be as skilled in any of these technologies as the people I’d hope to hire with that expertise, should the need arise.  And that’s a good thing: the temptation is always there, particularly for someone who rose up through the developer ranks, to micromanage.  But at the senior executive level, it’s far more important that you stay focused on process improvement and strategy than on nuts-and-bolts techniques. Any of the experimenting I describe above should be viewed as self-education and a hobby, not a serious endeavor.

But you can bet that my self-education practice lends me a deeper insight into any of these technologies than if I’d sat back and simply read magazine articles on them. And oddly, I’m one of the few senior IT executives I know who still do this sort of thing. Granted, it will always feel to me like it’s too little, but not doing it at all is, well, not an option.

I don’t want this to be just another post about Twitter, the current hot trend of the Internet.  Rather, I’d like to relate this new Twitter fad to a long-planned important topic here.

Specifically, what can we in technology do to keep current and stay up-to-speed on our various areas of interest and expertise? There’s more out there than any of us can learn, and new technologies come along all the time.  Truly staying current, at a reasonable depth level, would be a more-than-full-time job.

Here’s how I’ve come to grips with that basic reality. These remarks are most relevant to the executive level, but to some extent they apply across the spectrum of roles in IT.

• If you don’t work at the nuts-and-bolts level with a given technology for 8 or 10 or 12 hours a day, you’re really just a dabbler anyway. Don’t delude yourself that you know a technology at the detailed level just because you have read a few articles or a book on it.
• Embrace that certain unavoidable level of dilettantism. Work on understanding what a technology can accomplish, how it relates to the bigger picture of architectures and business value, and how it differentiates itself from other players in that game.
• Recognize that the skill you really need most of all is “just in time” learning. I took a headhunter call a few months back from a company that was looking for a seasoned senior technology executive, but they were adamant that the person have coded and deployed Ruby on Rails applications for three or more years.  And sure, wouldn’t that be great: but there are high-quality executives out there who understand technology at a deeper, bigger-picture level, and can pick up the Ruby nuances in a matter of a few weeks.  And, judging from the other professed needs and gaps of that company, they should have been deemphasizing the specific technologies and searching much more for that big-picture guy or gal.
• As an executive, don’t worry about learning a technology at other than the conceptual level unless and until it becomes relevant to your business needs and goals. That said, you do need to stay current, at a conceptual level, with ever-shifting technologies.

So, there’s a lot out there, and it can be overwhelming. If you want to stay in the game at this level, you can’t just throw up your hands and not keep learning.  So how do you amass that concept-level understanding, then?  My pre-Twitter ways of drinking from the technology firehose involved spending a great deal of time doing the following:

• Subscribe to email newsletters.  Read, follow links.
• Find relevant web sites with content targeted to my interests. Read, follow links.
• Read white papers and technical journals
• Read blogs, follow links
• Use RSS to target my interest areas. Read, follow links.
• Experiment with various technologies (at a light level) on my own

I’m not stopping any of those activities, particularly the all-important last one.  However, I’ve come to realize that there aren’t any really good sherpas out there for this ongoing battle, no effective way of whittling down the massive input stream into just what I need.  So even though there’s nothing wrong with any or all of these above activities, the trouble was that the whole day can go by while I do that.  In other words, those approaches are just not sustainable for a busy executive.

Enter Twitter. Once you get past the common knee-jerk reaction (e.g., why do I care to hear what people had for breakfast?), and actually use it for a few weeks, you realize that it has some unexpected advantages:

• Probably 90% of Twitter users produce little more than drivel. But, you don’t need to follow any of those 90%.
• Messages, by virtue of the 140-character limit, are pithier, hence more scannable. Brevity is the soul of twit. (I can’t be the first person to say that).
• Topic areas are more findable, prunable, and groupable, leading to an incredible and still-growing abundance of Twitter utilities and after-market products to help people divide, search, conquer.
• Twitter, used properly, is much less subject to the incursion of advertising (or pure inanity) that plagues nearly everything else on the net: you can (and should) customize the people you follow for maximum utility. It’s so much easier to simply unfollow someone who turns out to be a spammer or a fool than it is to, say, unsubscribe from a typical email blast stream. It’s your action that does the unfollowing, not theirs.

“Mindcasting” is the term that I find most applicable to Twitter. Through Twitter, I get to tap into the minds of people I find useful, people who are willing to share, via this new medium, their perspective and interests. Those whose tweets prove interesting and useful, I keep following. Those who don’t, get dropped, and that’s OK. Via Twitter, I get to establish and hone the membership of my own private Algonquin Round Table, as it were, of fascinating interlocutors.  It’s more granular than relying on RSS, in my view, in that it’s more targeted and more bite-sized. I can trust the people I follow to give me quality links to read. I can see whom those people are following, and extend my circle to include those folks as well.  As a result of this daily honing and pruning, I get a much higher “signal to noise” ratio in my reading, thanks to my Twitter stream.  And lo and behold, very little of that stream ever relates to people’s breakfasts.

I’ll avoid going into detail about the frailty of Twitter’s offering, operationally (see links below about the infamous “fail whale“, other than to gently point out what should be obvious: that they need a different level of IT management if they are to continue to scale.

You’re all welcome to follow me, if you so choose, on Twitter here.

Lagniappe:
Useful articles on the Twitter phenomenon:

• “Twitter sucks, so change your friends,”
• “Forget the Fail Whale: Twitter Jumps the Shark“
• “On Twitter, mindcasting is the new lifecasting”
• “OMG! Shut up about Twitter already“
• “Brave New World of Digital Intimacy“
• “Twitter Explained In 267 Seconds“