Take The Red Pill: 8 non-programming books you should probably read

As techies we tend to suffer from a fair bit of professional tunnel vision. Like Neo, often all we see is the code. However there’s an entire world on the other side of the digital rain. A world of managers and users and TPS reports.

In order to do our jobs better we need to take the time to understand some of the other human and business elements with which we must interact. There are many ways to do this but one of the easiest and most efficient is diving into a few choice books.

There are, quite literally [pun intended], countless books which you could pick up to further this education and many of them are very good…if you’re already a business and management wonk. If you’re a hardworking geek who’s just looking to get informed, get a different perspective and use it to do better work then you don’t have time to waste with buzzwords and business jargon.

Lucky for you I’m here with the red pill.

The books below have all proved invaluable to me in my years in software engineering. Most of them are not only easy to read they’re also enjoyable as well, providing an astounding amount of information in a way which isn’t going to send you screaming back to the Matrix.


There is undoubtedly some form of management in place on your project|team|life. You can’t (and probably shouldn’t) avoid it, so you’d best learn to understand it better. It’s not a matter of “know your enemy” since, believe it or not, management is on your side. It’s more a matter of knowing how to understand a different dialect and point of view.

  • The Practice of Management by Peter Drucker
    This is where it all started. Peter Drucker is the Father of Modern Management and this is the book which earned him that title. Since it was originally published in 1954 you’ll find that many of its stories are dated and border on quaint. That said, it’s still stunningly applicable to modern businesses and organizations. I recommend you read the entire thing, but if you just want to sample the contents then have a look at the outline I created when I first read it. (No, I don’t usually do that for books; that’s how special this one is.)
  • Land the Tech Job You Love by Andy Lester
    I know what you’re thinking: “VM, have you thrown a rod? Why is this in the Management section?” Well, lemme tell ya: I’ve yet to find many books which do as good of a job of presenting what’s going through the mind of a hiring tech manager as this one. Andy doesn’t just tell you what to do to land a good tech job. He also tells you why you should do those things. As a tech manager myself I absolutely love the approach which Andy has taken here and wish more applicants had read this book and had the perspective which it provides. I feel so strongly about this that I’ve given away four copies of this book over the past few years and fully intend to give away more. (Full disclosure: Andy is a friend of mine but I had read/loved his book before the friendship.)

Business and Process

Even if you’re working on an open source project there’s still a lot of process and business logic which needs to come into play. Sometimes you can survive without knowing these details. Sometimes you can use a framework without reading the documentation, but you’re setting yourself up for a world of hurt if you do. The same stands for process and business logic. You at least have to skim the documentation to understand the framework within which you’re operating.

  • Rework by Jason Fried and David Heinemeier Hansson
    I don’t care who you are. I don’t care what company or organization you work for. Read This Book. It’s probably the quickest read in this list but it’s also one of the most thought provoking. Rework is a collection of essays based upon posts on Signal vs. Noise, the 37signals blog. Each essay states the 37signals answer to a particular question or need. Since these answers are coming from a 37signals perspective it’s possible (likely) that they won’t apply to your company|organization|project. That’s fine. It’s not important that their answers work for you. What’s important is that you think about the problems they faced and come up with your own answers.
  • Process Improvement Essentials by James R. Persse, PhD
    I’m only halfway through this book and I’m already finding it to be incredibly useful. While I currently have no intentions of implementing CMMI, Six Sigma or any other formal process it’s very thought provoking to read about the problems which these methodologies were created to solve and consider the different ways they could be approached in a software development team. This is another one of those books which is really good for getting the wheels turning, even if you don’t end up rolling down the same path as it takes.
  • Getting Things Done: The Art of Stress-Free Productivity by David Allen
    “GTD? Really? Way to be original.” Yeah, OK, so maybe this one is becoming cliché at this point. I mean, everyone in tech knows about GTD by this point, right? Sure, maybe they do. Still, I’ve read this book three times and get something new out of it each time and not just for my own personal productivity processes. Reading GTD presents me with yet another opportunity to look at the big picture for everything in my life and that includes how my company, team and projects are functioning. While I don’t subscribe to or apply the entire GTD method I still highly value how it helps me step back and think about why I and my team are doing what we are.


User-centric software development is a big thing for me. I mean, if what you’re working on doesn’t have users then…uh…why the hell are you doing it? Software without users is just a technical étude. If you’re not listening to your users then, I’m sorry, but your project will fail. Maybe not today and maybe not dramatically but it will fail nevertheless.

John McCarthy once said:

Program designers have a tendency to think of the users as idiots who need to be controlled. They should rather think of their program as a servant, whose master, the user, should be able to control it.

The books below help to shift away from this controlling mindset into a more productive one of cooperation and assistance.

  • Delivering Happiness by Tony Hsieh
    Tony Hsieh is not a writer, he’s an entrepreneur. This book reads like it was written by one of your coworkers while you two were sitting at the pub. It’s conversational, anecdotal and entirely infectious in its enthusiasm for building one of the most successful and user-centric companies on the internet, Zappos. Tony takes you through the entire roller coaster ride which was the evolution of Zappos, including the decision to focus entirely upon customer satisfaction. It’s incredibly interesting reading out the philosophical and business reasons for making this move. It’s also very inspiring to see the open and honest manner with which Tony handles the discussion.
  • Design of Everyday Things by Donald Norman
    While Design of Everyday Things has nothing whatsoever to do with software design, after reading it you’ll find that it has absolutely everything to do with software design. You will never look at a set of instructions, a UI widget, an API the same way again. You will also never again feel like a moron for pulling instead of pushing when trying to walk through a door (&!%#@* inaccurate affordances).


Be it API documentation, a commit log message or a lengthy soapbox session on the listserv, communication is a critical skill for techies. And one which is lamentably neglected. For this section I have but one suggestion…

  • The Elements of Style by William Strunk, Jr. and E. B. White
    I don’t care whether you’re a grammar snob or not (I am), you need to know what’s contained in this book. Feel free to break the rules if you need or want but please do us all the favor of knowing that there are rules before you do so. Seriously. I mean, there’s a reason why this book has been in continuous publication since 1918: it’s English as she is spoke. Knowledge of what’s contained between its covers ensures you’ll be better equipped to communicate with everyone with whom you interact, from CEO to six year-old nephew. Improved communication skills will get you as far in this world as being able to make Ruby on Rails sit up and beg. The combination of the two? You’d be a force with which to be reckoned.

There certainly are other books which I could add to this list, but these are the eight which are currently at the top of my list. Have any you think should be here? Put ’em in the comments!

It’s About Needs.

Cards I’ve been doing various bits of writing lately, both for my blogs and for other purposes. This morning I was sitting at a cafe, scrawling ideas in my notebook, and decided I needed to take a step back and follow the oft-mentioned advice of “one card, one idea, arrange, write.”

“I need some index cards!” declared my Front Brain.

“No, you don’t need index cards,” interrupted my Back Brain, “you need small bits of paper large enough for capturing ideas and easy to arrange. There is more than one way to do it.

“Oh…yeah, I guess you’re right,” Front Brain conceded.

This internal dialog—aided by knowledge gained by working in a printshop for five years during college—led me to the independent printer down the street. $2.00 later and I have a stack of around eight hundred small bits of paper, perfect for my purposes and cheaper than index cards. As an extra bonus the printer made two bucks on something which he otherwise would have chucked into recycling. I’m happy, the printer is happy and nary an index card is in sight.

“If I had asked people what they wanted, they would have said faster horses.”
― Henry Ford

We in the tech industry are in the business of fulfilling needs. Accounting needs to process expense reports more quickly. IT needs log monitoring and notifications for potential issues. Your grandparents need to see pictures of their new great grandchild. I need to buy a four pound bag of cat food every month.

Please note: These needs are not “Logon to internal financial system integrated with payroll processor,” or “Implement Nagios or Splunk” or “Teach grandparents to use email so they can view Flickr links” or “Order cat food through Amazon Subscriptions.” These are all very valid implementation options but they’re not needs.

It’s so easy to get caught up in expectations and experiences, jumping straight to a possible implementation rather than slowing down and taking a moment to look at the bigger picture. Let’s take my index card problem as an example. What I initially said to myself:

Darn, but there has to be an easier way to organize these thoughts.

Conventional wisdom (and an army of high school English Comp teachers) says that the response to the problem of thought organization is “index cards.” However that answer doesn’t take into consideration my personal constraints:

  1. Minimal expense
  2. Minimal material waste
  3. Minimal space usage

Would index cards have met these needs? Yes, they would have. That said, my local-printer-supplied option meets those needs even better. These cards are cheaper, would otherwise have been scrapped, and are smaller than commercial index cards. As a user, I am much more “delighted” (an adjective which I deplore but which I must admit applies here). I am now much more likely to use these cards because I am happier with the end product.

The key to generating this “delight” (I still hate that word) was not my prior knowledge of printshop operations though that was, admittedly, helpful for the final product. No, the key was knowing to ask myself, “Yes, but what are you really trying to accomplish?” and then surveying the potential options.

For the record: getting to the root of user needs is not usually as simple as having them answer a single question. There are very good reasons why there are people who do nothing but determine user needs. That said, the question is important enough for everyone on a team to keep it in mind throughout the design and development process. If at any point you cannot answer the questions “What?” and “Why?” then you should circle the wagons and start the process of getting these matters clarified. You’ll be doing the team a favor. Nothing is as effective as a team that understands not only what they’re trying to produce but, most importantly, why they are trying to do it.

Unsuck Your Meeting

Yeah, that’s right: your meetings suck. Don’t deny it. No, don’t you dare even try to deny it. Can you seriously look me in the eye and tell me that you enjoy going to meetings? That you aren’t sitting there with a glazed look in your eyes as you mull your lunch options or that optimization that was interrupted for this Momentous Event or whether you remembered to set a new season pass on your TiVo or, really, anything aside from the purported meeting topic? Can you? No, I didn’t think so.

In truth I don’t buy into the whole meetings are toxic thing. That’s rather a generalization, wouldn’t you say? Meetings in general aren’t toxic. SHIT[1] meetings are.

  • Selfish.
    “Well, I’ve kinda been sitting on this project and I’m not ready to move forward on it but people are starting to talk so if I bring everyone together for a meeting then it’ll look like I’m making progress. Brilliant!” The best part is that a selfish CYA meeting begets yet more selfish CYA meetings as everyone’s schedule is pushed back in order to attend them. Genius!
  • Haphazard.
    Everyone knows that a free range meeting is the most responsible choice, right? A meeting that’s allowed to live out its natural life scratching at and chasing after random topics rather than being cooped up in a specific agenda is the best sort of meeting, isn’t it?
  • Informational.
    Ooh, here’s an idea! Let’s get everyone into a room for sixty or even ninety minutes every week just so they can feel uncomfortable trying to verbalize nebulous but considerable progress in front of their peers for two minutes and then zone out for the remainder of the time! Or, even better, collect the team so you can give a dramatic reading of the text you really should have posted to the wiki! Man, everyone’s gonna love that. And what a great use of time!
  • Tardy.
    My personal favorite use of company time: calling a meeting for, say, 10am then not starting it until 10:15. Similarly: calling a meeting for 10am and then not notifying the attendees until 10:15 that the meeting needs to be rescheduled.

It’s easy to see why your meetings suck when so many of them share these characteristics. It boggles the mind why businesses allow this sort of shoddy practice to continue, especially considering the expense that these meetings reflect both in lost productivity and in basic employee compensation simply for the time to attend them.

The sad fact is that it is so very easy to avoid SHIT meetings yet disturbingly few people make an effort to do so. Here are some of the criteria I use to make sure my meetings don’t go to SHIT:

  1. Don’t have a meeting at all.
    Do I need to communicate some information? Rather than interrupting everyone’s workflow by collecting them into a room I’d prefer to send the information via email. Or, better yet, write up the information in the $project_tracker since five’ll get you ten it belongs there anyway. May as well get it into the tracker immediately so there are no excuses later when the information goes AWOL. You can then easily email a link to the information in order to call attention to it to the team.

    For this approach to work you need to foster a culture which does not abuse email[2]. Once you’ve reduced the inbox noise and drek everyone needs to understand that (s)he is responsible for the information sent via that channel.

  2. Have an agenda and stick to it, dammit.
    Each meeting ought to have a purpose, a goal, a question which needs answering. If you’re thinking of scheduling a meeting and you can’t express the goal of the meeting in fifty words or less then perhaps you’re not really ready to have a meeting yet.

    An unfocused meeting is an inefficient meeting. Ideally you would send a brief agenda along with the meeting invitation so everyone knows what they’re getting into. This allows people to prepare (if necessary) so the question can be answered and the meeting completed as quickly as possible. Which leads me to the next point…

  3. Start on time, end early.
    If you’re running the meeting, get there early to be sure everything is set up. If you’re attending it, arrive on time. Regardless, everyone is expected to come prepared and the meeting always starts exactly on time. Failure to do so is disrespecting the valuable time of every person in the room[3].

    Because you have an agenda you know exactly what the meeting is meant to accomplish. If that goal is met then do not sit around simply because you have the room booked for an entire hour. Recap the meeting so everyone understands what was decided and then let ’em get the heck out of there. Everyone will be happy: the attendees will think you’re super swell for ending the meeting early and you’ll have what you need.

  4. Recap Recap Recap.
    This was briefly mentioned in the prior point but is important enough to call out on its own. At the end of the meeting it is paramount that someone (ideally the person who called the meeting) recap the decisions and action items which were generated. You’d be surprised how often you do this and have someone in the room be startled out of their daydream to say, “Wait…what? That’s not what we decided…” Everyone must end the meeting on the same page. They don’t need to agree with what’s written on that page, they just need to be on it and know that they’re on it. In addition, anyone in the room who has action items as a result of the meeting needs to confirm that they’re aware of this fact and are ready, willing and able to undertake the assigned tasks.

While there are many other methods and details which could be applied for unsucking your meeting these are the ones which will get you the most bang for your buck and which apply to most every meeting. Applying them to your team’s meetings will improve productivity and, most importantly, make you all much happier people.

[1] Contrived and excessively vulgar acronym? Guilty as charged. Still, a spade is a spade and meetings like this truly are shit. [back to reading!]
[2] Proper care and feeding of a healthy email inbox is an entire post in itself, but suffice it to say that the signal to noise ratio in the average email inbox could bear more than a little improvement. [back to reading!]
[3] Unsatisfactory excuses for arriving to a meeting late: another meeting ran late (stand up, politely excuse yourself and leave), on the phone (send to VM or set call duration expectations at the start), just slipped your mind (really? your time management skills and tools are that bad?). OK excuses: system/service crisis (all hands on deck; screw meetings), family emergency (always more important), zombie attack (Re: Your Brains). Regardless of the reason, you must find a way to notify at least one other attendee that you are going to be late. Email, IM, IRC, SMS, phone call, send a message via the office dog. It doesn’t matter how you do it just do it. Don’t be so arrogant as to expect everyone to seek you out retrieve you for the meeting. From housekeeper on up to CEO, the time of the other meeting attendees is as important as yours else the company wouldn’t be paying them to be there in the first place. Do not disrespect them by thinking otherwise. [back to reading!]