Technical Job Postings: Know Your Audience

Spotted in a job posting for a technical position:

$Company is a values-based, social change platform that leverages individual and institutional leadership and investment to positively impact local and global communities. $Company pursues multiple, related strategies to promote this mission. From green nonprofit centers to programmatic consulting, donor advised funds to fiscal sponsorship, grants management to risk management and more, $Company gives members of the nonprofit and philanthropic community freedom to focus on the change it wants to see. For more information, please visit www.domain.tld.

A panel from Gary Larson's Far Side comic: What dogs hear blah blah blahI don’t know about you, but my eyes slid right off that description right around the word “leverages.” After investigating $Company more I can see that it’s a very respectable organization with a long history of assisting non-profits, both organizationally and financially. And, yes, if you take the time to play through the buzzword bingo in their description, it does actually tell you that. So…uh…why couldn’t they just tell us that?

When writing up a technical job posting (or any job posting, for that matter), keep your audience in mind. You are going to get better responses to a posting which uses clear, direct language than one which reads like it was written by a marketing intern looking to impress. Frankly, this sort of thing just scares technical people away. They read it and think, “Wow…is the entirety of $Company that stuffy and corporate? Is it one of those places where everyone wears suits and Casual Friday means a polo shirt instead of button-down? No flip-flops? Hrm… There are postings for other companies which sound more my style. I’ll put my effort into applying for those instead.”

In this case, I’d rewrite the description above to make it more casual:

Since $year, $Company has been helping non-profits with organization, logistics and finances, freeing them up to be the change they want to see in the world. There are $number non-profits of all sizes using our tools, including $np1, $np2, and $np3. We’re looking for a socially-minded $position to join our team.

That’s just a first pass and undoubtedly isn’t the best description possible but I’ll wager you a pint of good beer that you read it and found it more appealing than the original. Aside from improving on the stuffy tone, this version accomplishes a few things the first doesn’t:

  • Tells you up front how long $Company has been around, establishing credibility and stability.
  • As a programmer you now know that there are tools to be built. This gives you an idea of what you’d probably be working on. Also, who doesn’t like good tools?
  • Gives you an idea of the extent and nature of the clientele of $Company, helping establish $Company’s identity and philosophies. For instance, if $np1, $np2, and $np3 are all institutions with which you strongly agree then you can be more confident in fitting in at $Company, which is willing to be publicly identified with these institutions.
  • States outright that they’re looking for socially-minded people. If you’re just looking for a paycheck you probably should look elsewhere.

Bottom Line: Never forget that when you write one of these things you’re advertising that job position. Take the same care in audience discovery and wording as you would with any other marketing outreach. Be honest, be direct and use the language your audience expects to hear.

Book Review: “Process Improvement Essentials” by James R. Persse, PhD

tl;dr: A well-written book I’d recommend to all in the IT field who have any interest in working smarter rather than harder to bring their projects in on time, on budget and to customer spec.

Cover of Process Improvement EssentialsProcess Improvement Essentials, written by James R. Persse, PhD, delivers on its title. The field of process improvement is large, detailed and complicated—much more so than I would have expected before reading this book—yet Persse manages to curate, condense and present the topic in a highly effective and approachable manner. Which, I suppose, is to be expected considering the subject matter in question.

One method Persse uses to curate and condense is by limiting his target audience to IT professionals. The entire book is presented from the point of view of improving the quality of IT deliverables in whatever form they may take so, as a techie yourself, you can pick up this book without fear of getting mired in descriptions of processes (billing, accounting, manufacturing, marketing, sales, etc.) in which you may have little direct interest.

The book itself is organized into two sections. The first discusses process improvement in a more general sense and was the part of the book which I most enjoyed. The philosophies of process improvement resonated well with me, however that’s no surprise as I’m already predisposed toward the concept. Persse’s writing is clear, engaging and filled with quotes which struck me enough to write them down. Some examples:

From my experience, technology industries—corporate software, systems development, and operations—have been somewhat immune from the cleansing light of public failure.

Companies that are doing well are rarely motivated to initiate process improvement programs or quality initiatives.

…everything we do should be somehow traceable to satisfying the customer.

After all, if you hire competent people, you should probably get out of their way and let them do their jobs.

The second section of the book is a fairly in-depth overview of three process improvement methodologies: ISO 9000, CMMI, and Six Sigma. While moderately interesting, I recommend initially only skimming this half of the book then returning to it more in depth when/if your team decides to undertake one of the methods detailed here. This half of the book will be valuable both in aiding selection of the best method for your team as well as for basic reference while implementing it.

In a profession fraught with projects which are over budget, overdue or outright canceled more often than they’re successfully concluded, I would recommend that every IT professional pick up and read a copy of this book at least once in their career. Even if they only read the first half, the raised awareness of quality and process can only help improve the overall IT project success record.

At Risk: An Online Service is Sometimes Neither Online Nor Serviceable

404 LOLCAT NOT FOUND by GirlieMac on Flickr, CC BY 2.0The down side of relying upon all these online services is that, well, they’re online services [1]. The sad truth of the internet is that these things disappear all the time, often with little or no notice. Some notable examples:

These are just a few of the innumerable internet services which have either seen their final sunset or been very close to it. Each of these companies had users who relied upon their services, users who were left high and dry when the last staff member leaves the building. And in the end this just didn’t matter. The lights went out and the service disappeared.

This is bad enough for your Average Joe User, but what if your own company relies upon someone else’s API? What if you were one of the companies whose offering depended upon the Google Maps API for Flash only to have it end-of-lifed? Or, say, the Amazon cloud is suddenly unreachable? How would your company fare?

In this interconnected world of ours we are all stronger through the cooperation afforded by public APIs and online services of this kind, however that does not mean we’re allowed to be blind to the risks which we take by doing so. As CTOs, architects, managers and programmers we all need to consider these scenarios and prepare for them in order to minimize the impact on our users. Downtime happens to everyone at some point and is excusable but failure to prepare is not. It’s just stupid.

500 LOLCAT INTERNAL SERVER ERROR by GirlieMac on Flickr, CC BY 2.0When designing your project or service, try to build in some failsafes to prevent a crisis in case an external API or online service becomes unavailable. Fail gracefully, don’t flame out. It could even be as simple as disabling certain pages (or even the entire service, if necessary) when an API can’t be reached. This is a far superior user experience to your users seeing a 404 or 500 status page…

When researching this article I came across the post API Half-lives by Gabriel Weinberg of DuckDuckGo. He has a great list of questions for a team to ask itself when considering APIs and services to use in their projects. Go give it a look then sit down with your team and consider whether you’ve put yourselves at risk and, if so, what you can do about it.

[1] I have taken precautions for each of these services to be sure I do not lose important data. All information is sync’d to multiple locations and, in the case of the photos, backed up in multiple locations as well. [back to reading!]
[2] ArchiveTeam’s raison d’être is swooping in to save at risk data. They do great work and could use your help preserving our fragile digital heritage. Check out their wiki or hop on their IRC channel and say howdy. They’re all rogues with hearts of gold who’ll welcome you with open arms. [back to reading!]

Online Services I Find Worth Paying For

While I appreciate getting something for free [1] as much as the next person, I’m also very willing to shell out cash for online services which I find both useful and valuable. Here are the ones for which I do (or am willing to) plunk down a few shekels on a monthly or yearly basis:

  • Dropbox: I adore Dropbox. This service has saved my ass more times than I care to remember. While the standard service is free for 2GB I pay to upgrade my account to 50GB. While it’s nice to get all that extra space I’ve found that Dropbox has become such an integral part of my workflow that I would pay anyway just to help guarantee it’s around for a good, long time.
  • Evernote: I spend a lot of time online and most of that is spent reading. Back in the day I would bookmarks articles I enjoyed. Back in the day I would also lose the bookmark file any time I switched computers. I also would never look at the site again. I’d remember, “Oh, I read something about $foo once…” but be unable to locate it in the morass of links. Enter Evernote. With one click of the browser plugin any site, any image, any PDF is slurped into my Evernote account, metatagged, indexed and sync’d to all of my devices. Data is no longer lost and I’m a happy camper who’s able to search and locate whatever I need. The basic service is free and more than adequate for most people but, yet again, this is a service which important to my day to day work and therefore worth it to me to support financially.
  • Netflix: Really, does this one even need an explanation? Probably not but it’ll get one anyway. I haven’t had cable for about twelve years now. I’ve been without a TV for two or three years. My entertainment needs are met via the internet, primarily by Netflix (of which I’ve been a subscriber since 1999). Netflix allows me to indulge my desire for cheesy science fiction programming without having to spend money on DVDs which are just going to take up space in my apartment.
  • Github: Github has rapidly established itself as the go-to distributed version control hub on the internet, particularly among open source advocates. Any repository which is open sourced may be hosted for free and includes a project tracker, issue tracker, etc. It’s a brilliant piece of work for which the Githubbers should receive a great many gold stars. I, however, don’t have any open sourced repositories there quite yet. Instead, I pay a small amount every month for the peace of mind which comes from maintaining important files in my own private version-controlled repositories.
  • Remember The Milk: The most important tip I took away from GTD was, “write it down in a trusted location and get it off your mind so you can focus.” Remember The Milk (aka ‘RTM’) is that trusted location for me. Any time I think of something I want to or should do I immediately grab one of my devices, type in a quick to-do item and sync it up. Since I started doing this over a year ago my productivity and organization has increased greatly while my stress level has mostly dropped. When something doesn’t get done it’s invariably because I failed to use the system correctly (like not looking at it; hrm). For a while RTM syncing from iPhone and iPad required paying for a Pro account (I do not believe this is the case now), which is necessary for me to capture items on the fly. However even if that weren’t the case I still would pay for this service simply for all the good things it has done for my quality of life.
  • Flickr: I used to host my own photo albums. That got to be a drag. Not only that, there were new online services which were doing the same thing but better. At the time I joined Flickr was the hot thing and had yet to be acquired by Yahoo!. The user interface was clean and useful, the features were exactly what I needed. Subscribing for a Pro account got me the organizational features I required. Now my account hosts 1,646 of my photos and am well content to stay with them for the next 1,646 and beyond.
  • Spool: This one’s a newcomer to the online service game, so much so that it’s still in private invitation beta. It’s also the only one on the list which currently does not have a fee option for its service and is entirely free. That said, this service has very rapidly become a vital part of my online workflow. While Instapaper enables users to save articles for offline reading, Spool enables its users to save both articles and videos. These are then synced to my iPad and iPhone. I read/watch them on the Muni, in the pub, while waiting in line… The best part is that I no longer have a browser window crowded with “Aspirational Tabs” for things I’d like to get to some day. Click, add to my Spool, close the tab and get around to reading it later. If Spool adds ‘Send to Evernote’ as an option (‘Send to Twitter’ and ‘Send to Google+’ would be nice as well) then I’m a user for life and will pay for the privilege. As they’re still in beta I have great hopes for these features.
[1] Hellooooo, Google Mail, Google Docs, Google Voice, Skype, Twitter… [back to reading!]

It’s Called Marketing for a Reason

Let’s do a little experiment. The next time you’re in a room full of techies, say something along the lines of, “Hey, how about that marketing department, eh?” Now count the number of people in the room who roll their eyes, snort derisively or start otherwise grumbling about how marketing is evil and clueless and a few other unflattering adjectives.

I used to be in that camp. I used to believe that marketing was nothing but advertising and manipulation, getting gullible people to buy stuff they neither want nor need. Then I worked at an online marketing company for six years and took the time learn what this wacky “Marketing” thing is all about.

While advertising is a large (and the most public) facet of marketing I believe it’s one of the least important. Which isn’t to say it’s not important, just that I personally rank it near the bottom of marketing operations.

A hint to the most important marketing operation is right there in the name: Marketing. Before a marketer can do anything else he needs to determine his market. I offer that this is the single most important operation not only in the marketing department but also in the entire organization. Why?

Your market is composed of your users. It’s the people with whom the sales team closes deals, for whom you put code to editor, for whom the customer service reps pick up the phone. These are, as far as your organization is concerned, The Most Interesting People in the World. Before it lifts a finger it must know not only who these people are but also what they need and how to communicate with them.

Do you know your market? Have you ever thought to ask? If not then I strongly suggest the next thing you do after you read this post is schedule a lunch or coffee outing with someone from your Marketing team to do a little learnin’. An understanding of the people for whom you’re writing software will lead to better decisions about design and features, more successful services, better roll-outs… In short, it will make for a more successful project. Not knowing your market means you’re not in sync with the rest of the organization. You’ll waste time adding features which no one will use. You’ll design interfaces which will confuse and frustrate. Sales won’t sell, customer service will be overwhelmed with requests and you’ll have to go back and fix it. No one wants that.

It’s possible that you may already have a pretty decent idea of who the users of your software are and for that I heartily applaud you. However I still recommend you take an hour to have that lunch with someone from Marketing to discuss it. As much as you know you can always learn more. Getting a different perspective on your market can only do good for you, your product and your organization. Furthermore you’ll gain a deeper understanding of the operation of the organization and where you fit in it. And let’s not forget that there are two people sitting at that lunch table. Forging a relationship with Marketing helps expand the horizons of both teams and enables the entire organization to be more successful.

Or, to put it into Marketing Speak, embracing a best practice of increasing interdepartmental face-time to leverage a holistic and synergistic approach to market knowledge can increase the core competency of the enterprise for greater return on investment, mindshare and thought leadership.

OK, so maybe sometimes marketing can be a little bit evil.

Rethinking Education Requirements in Tech Job Postings

A few days ago I posted this tweet:

My tweet was prompted by seeing a constant stream of job postings containing lines such as the following (taken from actual postings on craigslist:

  • BSCS or equivalent industry experience
  • Hold a BS or higher degree (or equivalent) in Computer Science/Engineering or related field
  • BS degree in Computer Science, Engineering or equivalent
  • Degree in computer science or similar
  • Four-year degree or Masters in an analytical or technical field (e.g. Economics, Computer Science, Mathematics, Statistics, or Finance)

Between my experiences as a tech manager and participating in open source communities I’ve met a lot of incredibly talented programmers. A few have CS degrees; most have degrees which have nothing whatsoever to do with computer science; some have no college degree to their name at all. Of the most talented and skilled programmers I know the majority are in this last group: they hold no degree and yet *gasp* they are absolutely brilliant. Unfortunately I’ve seen some very good people be discounted (and typically therefore not hired) because they lacked what some on the hiring committees deemed “a proper education.” This inevitably meant that the candidate did not have a degree in computer science or—even more unforgivable—did not have a degree at all.

Since I do know so many excellent and self-educated programmers I found myself becoming exceedingly annoyed on their behalf at these requirements. When the annoyance reached a head I blew off steam by way of the tweet, crying “elitism”.[1]

In the time since the tweet was posted I’ve simmered down a bit and started to think things through a bit more clearly. I came up with a question:

What, really, is the purpose of an education requirement for a tech job posting?

Photo by Flickr user mag3737, Creative Commons BY-NC-SAFrom what I can tell, an education requirement is shorthand for a minimum level of knowledge. “You must be this high to ride this ride.” The expectation is that if a programmer has a degree in computer science she knows data structures and recursion and how to solve the Tower of Hanoi in Java. However I see this as redundant data, at best. The same information is going to be readily apparent from skimming the applicant’s resume and code sample. Seeing a degree listed on an applicant’s resume does not excuse me, as a hiring manager, from reading the remainder of the document.

In addition there is an entire raft of vital skills which aren’t taught in most computer science degree programs. Using source control. Writing tests. Working on a team.[2] I’m sorry to say, but if I see a resume from a new compsci grad I assume he does not know how to do these things. Unless he has experience coding outside of the classroom I’m likely to set his resume aside in preference to the applicant with no degree but with open source experience, who has worked on a team and contributed code which has seen the light of day. I don’t care much for towers—Hanoi, ivory or otherwise; I care about results and that’s not something you can determine from the one line in a resume stating, “Bachelors of Science, Computer Science, Wossamotta University (2003).” It’s all those other lines which matter.

There are definitely times when having a degree requirement makes sense. I don’t mean to imply that they should be entirely banished from tech job postings. However I do believe that we, as an industry, need to put as much thought and care into our job postings as our code design. We would never stand for bullshit requirements for our code. We should not stand for them in our job postings either.

[1]: I admit “bigotry” was a close second but wasn’t chosen due to its intensely negative baggage. “Elitism” is only slightly negative in comparison.[Back to reading!]

[2]: Andy Lester has a great presentation discussing what schools are missing in their CS curricula. [Back to reading!]

Email Overload? Reclaim Your Inbox, Don’t Banish It

I recently read two articles while riding the bus[1]. The first one was in Forbes Magazine. Thierry Breton, the CEO of Atos Global, has decreed that since he “believes that only 20 out of every 200 emails received by his staff every day turn out to be important,” within eighteen months the use of email will be eradicated company wide, replacing it with social media, phone calls and in person meetings.

Contrast this with the second article I read, Don’t blame the information for your bad habits, an interview with Clay Johnson by Mac Slocum in the O’Reilly Radar. Clay states that “[w]e don’t need to manage the information. We need to manage the consumption of it.” According to his new book The Information Diet, just as a binge eater cannot blame the food he eats a person suffering from the poorly-named “Information Overload” cannot blame the information.

To some extent I agree with both of these men. Excessive information (including email) is a danger to productivity. It diverts attention, derails trains of thought and increases stress. However, considering Mr. Breton’s concern over the reported high level of distraction caused by reading unnecessary email messages, I’m rather surprised at the alternatives being proposed. While unnecessary emails are distracting, I find it difficult to believe they are more so than social networking, phone calls or meetings (which we all know I believe can be improved). These routes of communication all tend to be highly impromptu and interuptive. Rather than improve the signal to noise ratio of the emails sent within Atos Global (or the email handling of the employees), he instead blames the email itself and chooses to cut off the service. I dunno… I just feel this may be one of those “Farewell bathwater! Baby? What baby?” sort of situations.

I agree with Clay Johnson: email is not to blame here. Rather than taking the somewhat drastic move of banning email, perhaps Atos Global would first consider applying these suggestions:

  1. Eliminate or filter most automated messages. We all get them. Output reports from cron, record update notifications from the CRM software, escalation warnings for issues on projects we haven’t worked on for months. These emails either need to stop or should be filtered out of inboxes.
  2. Refactor internal aliases and/or mailing lists. I mean refactor in its most technical sense here. Like code, so often the contents of these things evolve over the years. Cruft accumulates and is never cleaned up, leading to a lot of unnecessary emails. Each internal alias and mailing list membership should be examined. What is the purpose of the list? Remove any recipient who does not contribute to that purpose. Don’t forget to run some tests to be sure you haven’t broken anything (removed someone you shouldn’t have, for example).
  3. Suggest new internal email handling policies. Request that each staff member change his or her email client settings, downloading email only twice a day and disabling any desktop/taskbar/etc. notifications. This is a tough one as people get very attached to their personal workflows, but these relatively small changes can lead to a lot more undisturbed contiguous moments in everyone’s day. You can always find some technology which enforces it but, really, that’s a bit too Big Brother-y for my tastes. My preference would be some form of firm but gentle social engineering, starting with telling everyone precisely why they are being asked to make the changes requested. The people with whom you work are incredibly intelligent and they’re adults. Treat them that way and most of them will see the good sense in the suggested changes.
  4. Selectively change communication media. Thierry Breton is correct: email is not always the right tool for the job. What sort of information is being exchanged via email at your organization? Do an email survey and try to categorize the communication that’s happening. Would any categories be better suited to a different medium? Could those long emails explaining the database architecture perhaps be written into the wiki instead? That “anyone for lunch?” message to the team would undoubtedly be better on the IRC channel, wouldn’t it? Perhaps the company could roll out Google Docs rather than emailing around a Word file for document collaboration.

You’d be surprised just how far you can get with these changes. I keep my own inbox at or hovering just above zero thanks to some of these suggestions. I got 99 problems but an inbox ain’t one.

If anyone has tried any of them at their company or on their project I’d love to hear about it in the comments. I’d be particularly interested if you have any metrics you could share.

[1] Using Spool, a new online app which is changing my online reading habits for the better. Think Instapaper but better (for instance: offline viewing of videos). No, they didn’t ask me to say this. I honestly do love and use the service. 🙂 [Back to Reading!]

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!]