Common Resume Mistakes

I’ve been hiring in the tech industry for the past ten years or so. In that time I’ve looked at hundreds—if not thousands—of resumes from people applying for a variety of positions on my teams. While the positions may differ, the majority of the resumes share the same quality: they stink.

See, here’s the thing: While I’m a hiring manager it’s not the only thing I have to do with my day. There are staff meetings and progress reports and design meetings and scheduling development and any of the myriad of other of tasks which land in the lap of a software engineering manager. By the time I carve out an hour to sift through all of the resumes I’ve received for an open position, the average resume crosses my desk in less than 30 seconds. If you can’t make a good impression in that amount of time then, I’m sorry, but I need to move on. I have too many other constraints on my time.

Therein lies the problem with the average resume: the average part. It doesn’t stand out from the pack. The same words, used in the same way, conveying the same lack of information.

Are you average? No? Then why in the hell is your resume? Let’s fix that…

What follows are tips for how to make your resume stand out from that big, tall stack through which I have to sort every time I have an open req to fill.

  • Don’t get fancy with the design. Unless you’re a graphic designer, please stick with a more traditional formatting for your resume. Anything else is at best jarring for the hiring manager and at worst actively distracting. The most important part of your resume is the content, not the layout. As with any good design, the layout and formatting should take a back seat to the content it supports. It should enhance the content, not be the focus of attention. This means you should probably stick with black on white and use minimal (or no) images. In truth, this will probably help to get your resume more noticed than a tightly designed document. Many companies use online job app services now. Those services require you upload a resume file, which they then—for better or worse—scan for keywords. A beautifully designed ‘Shop job of a resume will not parse. No parsing: no keywords. No keywords: no attention for your resume. You don’t get hired.
  • Order by most important/impressive to least. Remember that 30 second skim I mentioned above? When listing out your experience, your resume is more likely to leave an impression in those few moments if you organize it so the most important or impressive bullet points are at the top of each section. This is where my eye is most likely to alight during my skim so logically I’m most likely to pay attention to things I see here.
  • Do not include a picture of yourself. I cannot recommend against this strongly enough. Your resume is not about how you look. It is about what you can do. Including a headshot removes attention from your accomplishments and places it squarely on that photo of you. Furthermore a resume which includes a headshot puts me, as your hiring manager, in an incredibly awkward position. Suddenly I’m opened up to the possibility of accusations of not hiring you because you’re female or overweight or older or younger or have piercings or appear to follow a particular religion or are of a certain ethnicity… Job seeking is hard enough. Don’t cripple your chances by making the hiring manager feel uncomfortable. Instead, use that room on your resume to tell me more about how great you are.
  • Expect to be Googled and make it easy for your reader. Oh, don’t look so surprised. Yes, people who look at your resume will be Googling both you and any company or organization you list on it. If you recognize this and make it easier on them by including URLs to everything then you’ll leave a very good impression on your reader. Also, if you have any pseudonyms by which you’ve done relevant work (for instance, many in the Open Source community may be better known by a handle than the name on their birth certificate), make sure to mention that name somewhere on your resume. I can’t be impressed by your accomplishments if I can’t find them.
  • Stop being cliché. “People person.” “Team player.” “Responsible.” “Motivated.” “Hard worker.” Stop it. Just stop it. None of these phrases mean anything to a hiring manager. Even if they once did, they’ve since been so diluted that they’ve been washed clean of any meaning. Don’t describe yourself with empty adjectives like everyone else does. Do it by listing all the cool things you’ve done.
  • Be specific. Don’t tell me “Managed a project for a large client.” Tell me what you did—specifically—while managing it and just how large that client was. Tell me what you did and why I should care that you did it. Don’t say, “Organized company events.” That tells me nothing. It could have been a birthday party for a group of five or it could have been the 30th Anniversary Bash for a company of three thousand. Be specific. At no point should your reader be left wondering, “Well, what’s that mean?”
  • Ignore the “only one page” crap. And while we’re on the subject of specificity, don’t leave out details just because you want to keep your resume on a single page. This precept is an archic throwback to the days of analog resumes. Newsflash: we’re digital now. One of the perks of going digital is that no one cares if your resume is more than a page long. Everyone is just going to skim it on their computer or device anyway. Unless someone’s wasteful or inefficient, odds are good that they won’t be printing out your resume until/unless you reach a later stage in the process (like an interview). That said, practice moderation in all things. Just because you now have license to exceed a single page doesn’t mean you need to send a novel. Don’t forget that the hiring manager’s time is at a premium. Don’t waste it. A maximum of a full two pages ought to be plenty of space for you to say what you want without overwhelming the nice person who has to read the thing.
  • Numbers Numbers Numbers. Quantify as much as possible. You didn’t just help land a client. You helped land a $2 million client. You didn’t just improve processes. You streamlined a process which reduced client response time from two days down to four hours, retaining $500K in business and saving an average of $150K in staff costs. This goes hand in hand with the edict to Be Specific. If you currently don’t have numbers then start collecting them.
  • Update early and update often. When I say you should start collecting numbers, I mean you should do it on your resume itself. Most people only update their resumes when they’re about to start a job search, and that’s a mistake. By the time you start editing the file several years could have passed since the last update. That’s several years of memories you now need to dredge. What are the chances you’re going to remember everything you’ve done in that time, let alone numbers associated with your accomplishments? If you answered, “Pretty bad” then you win a gold star. If you want your resume to best reflect your skills and abilities, you should update it frequently to be sure it includes your latest and greatest accomplishments. I have a repeating Remember The Milk task to remind me to update my resume every month (or at least consider doing so).

    Once you hear this tip it’s one of those “duh” moments, but it’s not something most people would usually think of on their own, myself included. I first heard this tip to update your resume regularly from Andy Lester in his excellent book Land the Tech Job You Love. I highly recommend it for all job seekers, technical or otherwise.

  • Save that sucker. You can’t update what you can’t find. Many people end up having to rewrite their entire resume from scratch each time they need to update it because they’ve lost the file for some reason. Do yourself an immense favor: use a version control system for this and all other important files in your life. Version Control: It’s not just for code, dammit. I use and recommend Github for this purpose. Not only is your file safe and backed up, it’s also stored offsite and safe in case of disaster or harddrive crash. Truthfully, what I have is a git repo in a Dropbox directory, so in my case the file is well and truly backed up in several locations.

    Also recommended: if you use Github, shell out the minimal monthly charge for private repositories and use that for your resume. No one wants to get a pull request on their own resume.

Hopefully these tips will help improve the chances of your resume turning heads the next time you’re looking for a new job. Good hunting!

Managers: It is NEVER OK to be a jerk

Earlier today I had a conversation with a friend. She had just been chewed out by her manager. It seems my friend had let a typo slip into some copy. Normally a typo wouldn’t be that big of a deal, but this one was in the price for an item. Customers saw the typo’d price, contacted people to make a purchase and were disappointed to learn that the price was incorrect. They complained to the manager. He took it out on my friend and her coworker. I believe the phrase my friend used was something about being glad she’d managed not to cry when her manager was yelling at them.

From where I stand, there is nothing correct in the way this incident was handled. There is never a good reason to be a jerk. There is never a good reason to bring an employee to the brink of tears. And, because it bears repeating: There is never a good reason to be a jerk.

While I’m not familiar with the intimate details of the situation in question, I’m going to hazard a guess at a healthier, more professional and more productive way to approach it…

  • Be open with your customers. Unless you’ve cornered some freaky market about which the rest of us have no knowledge, your customers are human. If an error is discovered, openly and honestly notify them and apologize for it (even if they haven’t approached you about the error). They will understand that mistakes happen and appreciate you proactively approaching them about it. Odds are they’ll forget about the error or, if they remember it at all, it will be with a positive feeling thanks to how you handled it.
  • Figure out how the error occurred. A harmful typo got into the wild? A product flaw? Site crashed? Complaining about it and attacking people does not fix the problem. Instead, channel your energy and the energy of your team into locating when, where and how the error crept in and how it was allowed to be exposed to the customers. THIS DOES NOT MEAN FIND SOMEONE TO BLAME. By looking to point fingers and assign blame you make everyone uncomfortable and set up barriers to people revealing errors in the future. While, yes, a human made the error that does not mean (s)he is to blame for it. If there is proof that the error was a willful effort by someone to cause damage then, yes, there is blame. But otherwise it’s just what it is: an error. An error which can be prevented. To whit…
  • Set up a process to prevent the error. Even something as “simple” as writing and publishing copy involves a complicated set of processes and procedures. If there is an error then odds are good that the problem is not with the person but with those processes. Fix that so that the error will not happen again.

Mistakes happen. It’s a part of life and therefore a part of business. Embrace them and learn from them. Don’t pillory your people. Don’t be a jerk.

Increasing the Role of OSCON in Community Education

I recently returned from OSCON. It was, as usual, brilliant. My talk—a part of Business Leadership Day—was well-received, which is always validating. As I perused this year’s schedule I was pleasantly surprised by the number of community-related[1] talks. Nine! Nine talks about community!

My first thought was, “Attention to community! My, but isn’t this an encouraging trend!” This is, of course, an assumption. One data point does not a trend make.

But twelve of them might.

I delved into the OSCON schedules as far back as I could easily access them: 2001. The 2000 and 1999 schedules are undoubtedly available somewhere but seeking them out became a game of diminishing returns so I’ve set them aside.

My results can be found in this Google Spreadsheet, but in summary:

As you can see, the first several years tracked contain no community-related sessions whatsoever. Things pick up a little with a single session in 2005 but then take a large leap to five sessions in 2006. 2007 was lackluster, with only two sessions. But then! 2008! Eleven! Wow… Could it be that Open Source is starting to publicly recognize the value of strengthening its communities? Oh, wait…no, no it’s not. Or at least not consistently, judging by 2009-2011. The community-related sessions in these three years together totalled those in 2008 alone. And then we get to 2012. I exclaim again: Nine sessions! It’s no 2008 but it’s still fairly impressive.

That said, there is definitely not a trend here. But wouldn’t it be nice if there were?

One of the greatest strengths of Open Source is the communities which form to create and support the technologies. While the technologies themselves are undoubtedly very important the communities which build them have been given short shrift. Only 2.875% of all of the talks in this year’s OSCON [2] were at all related with community issues. Considering the undeniable importance of people and community to the success of any Open Source project it would be great to see this percentage start to creep up over the next few years.

Nota Bene: None of this is meant to diminish the work of the people at the Community Leadership Summit, which meets each year immediately before OSCON. It’s a valuable asset to Open Source, but typically it’s attended by those who already understand the importance of community. It necessary to reach a broader audience.

What I would like to see is a gradual increase in community-related sessions at OSCON itself (which by design receives a far higher attendance than CLS) to help raise awareness. Lately there has been a lot of attention given to the importance of things like Codes of Conduct for conferences. I would like to see that attention to the human side of Open Source to get more traction beyond the confines of conference administration, reaching into the communities themselves. OSCON is where Open Source comes to play and to learn, to see and be seen. When a large chunk of the community is lodged within your doors it seems the perfect opportunity to teach those people the meaning of the human side of the community of which they’re a part.

You’re never going to have strong, diverse communities if you don’t start educating everyone what a strong, diverse community is. I wholeheartedly applaud OSCON’s efforts to do so in 2012 and I hope that it continues to carry the flag and leads the charge with more even attention to community matters in future schedules.


Footnotes
[1] By “community-related” I mean talks about building and strengthening communities, not those simply about personnel or project management. [back to reading]

[2] This percentage will, in fact, be smaller. It does not include the sessions from the Education track, which don’t appear on the 2012 OSCON schedule menu. [back to reading]

Program Like a Pixar Story Artist

A friend recently tweeted a list of story basics from Pixar Story Artist Emma Coats. These basics are some of the story-writing guidelines Emma has learned from her colleagues and they’re pure gold for writers.

As I was reading the list I was struck by just how many of the items on her list–with just a little modification–apply to programming as well. It’s all creative work. It’s all writing.

Story Code
#2: You gotta keep in mind what’s interesting to you as an audience, not what’s fun to do as a writer. They can be v. different. You gotta keep in mind what’s interesting to you as a user, not what’s fun to do as a coder. They can be very different.
#4: Once upon a time there was ___. Every day, ___. One day ___. Because of that, ___. Because of that, ___. Until finally ___. In order to ___ as a ___ I want to ___. Given ___ when ___ then ___.
#5: Simplify. Focus. Combine characters. Hop over detours. You’ll feel like you’re losing valuable stuff but it sets you free. Simplify. Focus. DRY it up. Hop over detours. You’ll feel like you’re losing valuable stuff but it sets you free.
#6: What is your character good at, comfortable with? Throw the polar opposite at them. Challenge them. How do they deal? What are you good at, comfortable with? Throw yourself at the polar opposite. Challenge yourself. How do you deal?
#7: Come up with your ending before you figure out your middle. Seriously. Endings are hard, get yours working up front. Come up with your test before you figure out your method. Seriously. Passing tests are hard, get yours working up front.
#8: Finish your story, let go even if it’s not perfect. In an ideal world you have both, but move on. Do better next time. Ship your code, let go even if it’s not perfect. In an ideal world you have both, but move on. Do better next time.
#10: Pull apart the stories you like. What you like in them is a part of you; you’ve got to recognize it before you can use it. Pull apart the code you like. What you like in it is valuable; you’ve got to recognize it before you can use it.
#11: Putting it on paper lets you start fixing it. If it stays in your head, a perfect idea, you’ll never share it with anyone. Put it ‘on paper’ lets you start fixing it. If it stays in your head, a perfect idea, you’ll never share it with anyone.
#13: Give your characters opinions. Passive/malleable might seem likable to you as you write, but it’s poison to the audience. Be careful with your users’ options. Abundant options may seem good to you as you code, but it’s poison to the product usability.
#16: What are the stakes? Give us reason to root for the character. What happens if they don’t succeed? Stack the odds against. What are the stakes? Know the reason for the feature. What happens if it doesn’t work? Handle this gracefully.
#17: No work is ever wasted. If it’s not working, let go and move on – it’ll come back around to be useful later. No work is ever wasted. If it’s not working, let go and move on – it’ll come back around to be useful later.
#18: You have to know yourself: the difference between doing your best & fussing. Story is testing, not refining. You have to know yourself: the difference between doing your best and fussing. Coding is iterative.
#19: Coincidences to get characters into trouble are great; coincidences to get them out of it are cheating. A hack to get the test to pass is great; a hack which ends up in production is cheating.
#20: Exercise: take the building blocks of a movie you dislike. How d’you rearrange them into what you DO like? Exercise: take the building blocks of some code you dislike. How would you rearrange them into what you DO like?
#21: You gotta identify with your situation/characters, can’t just write ‘cool’. What would make YOU act that way? You gotta identify with your users; you can’t just code ‘cool’. What would make YOU use this feature?
#22: What’s the essence of your story? Most economical telling of it? If you know that, you can build out from there. What’s the essence of your feature? Most economical coding of it? If you know that, you can build out from there.

Look at the world around you and what people in other fields are doing and you’ll be amazed at the lessons they can teach you.

Open Source: Why Can’t We Just Make It Easy On New Contributors?

As an Open Source advocate I’m frequently asked to which projects I contribute. My answer is typically, “None right now.” Why is that? There are a few reasons but they mostly boil down to:

  • As someone who does not code often (or enjoy it immensely) I do not feel welcome.
  • It’s an opaque process.

For now I’ll set aside the first reason to focus on the second: the process is opaque.

From my point of view, there is absolutely no excuse for this. Wikis, CMSs and cheap hosting all make it abundantly simple to offer plentiful guidance to new contributors, yet somehow that guidance is rarely provided. New contributors must delve and divine and guess and pester in order to figure out where to start. It’s almost as though the community does this intentionally as a sort of rite of passage for new members. “If you can figure this out then you’re smart enough to become One Of Us.” This is incredibly arrogant and exclusionist.

Why can’t we just make it easy on people? Why can’t we spend a few hours writing some documentation and tutorials up front, guiding newbies along the community-accepted path of contribution? Long time contributors may find the concept of spoon-feeding new members offensive but doing so will not only bring in more people to the fold it will also raise the quality of the contributions from the get-go.

To demonstrate how a project can make it easier for new contributors I’m going to use the Perl project. This is not because it’s such a bad example of how to do things (it’s pretty good, really) but because I’m fond of Perl and want to make some suggestions on how to make it even better. Also, I know that the Perl community is generally friendly and open to ideas on improving community involvement. That said, most of the suggestions are more generally applicable to all Open Source projects.

First of all, kudos to Perl for having a dedicated Get Involved link very prominently displayed there at the top of every page of Perl.org! This visibility is a testament to the importance of contributions and contributors to the Perl community. Involvement is key for them and they put it front and center, right where it deserves to be.

However after that things get less obvious. The site is clean and well-designed, which is a pleasant change from many project pages, but this page is essentially just a list of bullet points with no context or meaning. For instance, what would I as a new contributor be expected to do with the Bugs, testing and reviews section? Is this for reporting bugs (yes) or fixing them (not so much) or…? What is meant by “testing?” Since I pay attention to happenings in the Perl community I know that this means automatically reporting test results to the imminently cool and useful CPAN Testers when I install new CPAN modules, but what if I were entirely new to the Perl world? I may think that “testing” implies a lot more hands-on work, perhaps testing new commits to the core language. It’s not obvious and it really should be.

The tagline of this page is Whatever your skill set or level you can get involved… While I believe this must be true, speaking as a mostly-non-coder this page does not make it obvious how I could get involved with the Perl project. Are there simple bugs I could fix (and if so, how)? Maybe documentation that needs writing/editing? How about project management? Ticket review? Marketing? Event organization? Donations? Not only are these subjects a good way to capture the less technical users and supporters of your project, they’re also a brilliant way for the new coding contributors to get a feel for the project and up to speed on the processes it uses.

Here’s a quick and dirty first draft of a version of this page which would be more useful to new contributors:

Whatever your skill set or level you can get involved…

Community

Some say CPAN is the strength and heart of Perl, but they’re wrong. The people are the heart of Perl.

Getting Started

Ready to dive in? Here’s how to do it!

Everyone
  • Contributor FAQ Every project has those questions which come up repeatedly. Collect them and their answers to help remove the barrier to entry.
  • An overview of the processes used for Perl. Link to another page. Key for everyone to know the steps in the process, not only so they’ll know what to expect but also so they’ll know better what language to use when asking for help.
  • Where to go for help. While this should be an element of every bullet point here, it also should be aggregated on a single page for ease of use. Broken down by subject. Include names whenever possible (mentors would be awesome and heroic). New contributors are more likely to ask for help if it’s obvious there’s a real person at the other end.
  • Where to find the documentation. Link to another page. List every form of docs that exist. Keeping all this in one place drastically reduces frustration for new contributors.
  • Where to find the code. Link to another page. Not just where to find it, but how to get a copy and, if you wish to commit, how you’d go about doing that (including expected code style).
Non-Coding
  • Review and rate – the CPAN modules you use.
  • Send automatic reports to CPAN testers every time you install a new module.
  • Review trouble tickets. Link to a page describing the process, requirements and expectations for reviewing project trouble tickets. Ideally will include a link to a list of tickets in need of review.
  • Write or edit documentation. Link to a page describing the process, requirements and expectations for writing or editing project documentation. Ideally will include a link to a list of documentation tickets.
  • Translate documentation. Link to a page describing the process, requirements and expectations for translating project documentation. Ideally will include a link to a list of translation tickets.
  • Organize or Volunteer at an event. Calendar/list of events (locations and dates), assistance required and whom to contact for more information.
  • Donate. Link to a donation page and/or page detailing whom to contact to give a donation.
  • Have another idea how you could help? Contact us! Link to the correct contact information.
CPAN
  • Best Practices for coding for CPAN.
  • How to report a bug for a CPAN module.
  • How to contribute a fix for a CPAN module.
  • How to contribute a new CPAN module.
  • Contacting CPAN module maintainers and what to do if they don’t respond.
Core

Perl6

Want to learn more about Perl6? Have a look over here! Anticipate the question rather than forcing it to be asked or searched for.

Again, this is just a quick pass at a possible Contributors page, but as a non-contributor it’s much more inviting than the current, sparse version. I can easily look at this and see my options and the methods for performing them.

Granted, there is a lot of organization and writing which would need to be done for a page like this to work. Believe me, I know it’s not easy getting all these ducks in a row. That said, I strongly believe that any project which goes through the steps necessary to make it much easier for new contributors to join will find its quality and reputation improving by leaps and bounds. It’s an effort very much worth making.

Staff Quality Deserves the Same Care as Software Quality

The Wikipedia definition of Continuous Integration (aka CI):

Continuous Integration aims to improve the quality of software…by replacing the traditional practice of applying quality control after completing all development.

The CI gurus in the audience will hopefully forgive me for criminally over-simplifying, but the process basically boils down to:

  • Commit early, commit often.
  • Automate tests, build and deployment.
  • You break it? You fix it. RIGHT NOW.

The key motivator in CI is right there in the definition: quality. Rather than waiting for the end of the production cycle to do all of the testing you do it in smaller increments throughout the project. The sooner you locate and correct potential issues the higher the quality of the finished product. This approach is proven for developing software, so why aren’t we also doing it when developing staff?

A typical methodology for managing professional development for a technical staff member is much more old school waterfall in nature:

Yearly review and feedback
  set yearly goals
    procrastination until just before next yearly review
      race to complete goals
        verification of goals in yearly review
repeat

OK, perhaps that was a somewhat snarky summary but I think we all recognize it as Standard Operating Procedure. How, really, does this process help anyone? No, don’t answer that; I’ll answer it for you: IT DOESN’T. By the time you get to the annual review, any sort of feedback is so much water under the bridge and far from actionable. Yearly professional development goals are reduced to the effectiveness of an open book midterm: crammed in at the last moment and generating a good grade but with no lasting value, either for employee, team or company.

Instead we should be approaching staff development and management with an approach incorporating the ideas of accepted software development methods like Agile and Continuous Integration:

  • Agile Professional Development:
    • Employee review cycles should be short sprints of a matter of weeks rather than months.
    • Professional development goals should be attainable and meaningful, each subsequent goal building upon the ones which came before.
    • Meetings for checking progress and providing feedback should be frequent, brief and informal. They also should be open, honest and egalitarian (managers need feedback as much as anyone).
  • Continuous Staff Integration:
    • New knowledge and skills gained through professional development should be committed back to the trunk (the team) for integration.
    • Staff development should be automated through empowerment, support, policy and culture rather than dictated by managerial fiat.
    • Notification of potential issues should be immediate and methods of correction should ideally be evident and obvious.

There are, of course, some potential drawbacks in rolling out a staff development process of this sort. The current “waterfall” model has been the standard for a great many years and has become ingrained in the operating manuals for many companies, affecting the ways budgets are written, compensation packages are structured, Human Resources offices are run, etc. It’s difficult to overcome this sort of institutional momentum.

In addition, this process has the potential to impose a hefty burden on tech managerial staff. The impact of yearly reviews for each staff member can be severe enough on a manager’s time. Without proper planning an agile and continuously integrated professional development method could become a fulltime job in its own right.

These drawbacks are not inconsiderable but they’re also solvable and worth the time to do so. It will take a lot of planning to be sure this process is rolled out in a way which makes the most sense for your organization, but as with any worthwhile change (say, to using Agile and a rapid release cycle), if done mindfully the benefits reaped more than repay the effort.

Rant: I Am Not a Cat Herder

Cat Herding image CC-BY courtesy of carterse on Flickr; click to view originalIt’s a no-brainer. It’ll happen. If I were the betting kind I’d lay good money on it. Any time I’m mingling at some social event (cocktail party, BBQ, conference hallway track or pub outing, etc.) there will be at least one conversation which proceeds thusly:

Them: So, what do you do?
Me: Oh, I’m a software engineering manager.
Them: Ah! You herd cats! <insert self-satisfied chuckle at their oh-so-original witticism>

My typical response is to grit my teeth, smile wanly and change the subject. But ya know what? I don’t think I’m going to do that anymore. I’m rather fed up with the all-too-common misconception that managing software engineers is as chaotic and fruitless as wrangling a passel of felines. Seriously, if you’re a dev manager who describes his/her job as “Cat Herder” then just get the hell out of the business now. You don’t respect your staff and you’ve entirely missed the point of your job.

At no point in the management process should there be anything resembling “herding.” If your team requires herding then the problem is not the typically independent and outspoken nature of the software developers that comprise it. The problem is you. You don’t know how to be a manager. Communication, negotiation, mentoring, prioritization, leadership… These are the skills of a successful dev manager. Failure to learn, employ and constantly improve these skills leads to a team full of cats, loose cannons, powder kegs, prima donnas…choose your favorite negative descriptor.

It’s possible to learn these skills but only if you realize that it’s necessary. A good first step toward that is to stop implying your staff are unmanageable by calling them cats. Respect them as the intelligent people that they are, listen to what they have to say and clearly communicate the direction the company needs them to go and why. You’ll find that what you end up with looks a lot more like a functional and efficient team than cantankerous felines.

Book Review: “The Information Diet” by Clay Johnson from O’Reilly Media

Book cover for The Information Diet

“Much as a poor diet gives us a variety of diseases, poor information diets give us new forms of ignorance—ignorance that comes not from a lack of information, but from overconsumption of it, and sicknesses and delusions that don’t affect the underinformed but the hyperinformed and the well educated.”

This is the general thesis of The Information Diet, a new book by Clay A. Johnson, published by O’Reilly Media. In it Johnson explores the state of information production and consumption in our society, how he perceives it has changed (for the worse), the cultural, emotional and neurological reasons why this is the case, what may happen if the pattern continues unabated, and how we can work to reverse the trend.

The analogy of information as food is maintained throughout the work. I knew this going into it and anticipated the comparison would wear thin rather quickly. Aside from being personally bored by the first chapter—which summarizes the history of food industrialization and the obesity epidemic, subjects into which I’ve delved for years—the analogy works surprisingly well for the entirety of the book. Through this strong parallel to such a well-covered and -publicized public health issue Johnson is able to engage the attention and sympathies of the reader more or less immediately.

Unlike many of the more conventional “diet” books on the market, The Information Diet does not spend most of its pages on a detailed plan you could follow to reduce your intake of junk information. Johnson does, of course, give some tips on how to do this, but most of them are summed up in his Pollan-esque statement of “Consume deliberately. Take in information over affirmation.” Instead, the majority of the book is concerned with the dangers of our current information diets. It is, to maintain the food metaphor, more manifesto than menu. Those of you who read the title then pick up this book hoping to see detailed steps to achieve Inbox Zero may be disappointed on that front. However, if you’re looking for motivation to make a more fundamental shift in your attitude toward information intake you may have come to the right place.

I am myself someone who already keeps her inbox hovering at or just above zero, who regularly scrubs her RSS subscriptions of feeds which were added more for whim than value and who filters her Twitter and Google+ to raise the signal to noise ratio. In this way I’m not really the appropriate audience for this book. I am the choir to Johnson’s preacher.

However there’s a stronger reason why I am not the audience for this book: I am neither political nor activist. The final chapter of the book is pure manifesto, enlisting reader assistance in using their newly-reformed information diets to effect governmental and political change. Considering the author’s background his concern with changing government is no surprise, however I admit that I was as turned off by it as I am by most other forms of activist outreach (political or otherwise). This isn’t Johnson’s fault. It’s my own hang up.

To be entirely clear: this is a good book. It’s well-researched, well-written and covers topics with which I believe more people should be familiar. It’s a good book, just not good for me personally. I recommend that anyone with an interest in any form of information consumption pick up a copy and make up their own minds.

Disclaimer: I received my copy of this book for free via the O’Reilly Blogger Review Program.

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.