A machine-readable resume

Anyone who's known me (professionally) for long knows that I've been a fan of microformats. Note 1 One of my early projects at PayPal was to write component code that used the hCard microformat Note 2 to mark up addresses. This little Easter egg Note 3would allow merchants with repeat customers to add contact information to their systems easily using any the vcard reader plug-ins.

You might be asking why I'm such a fan of microformats - and that's an easy question to answer. Our goal – as designers and developers – must be to make information more readable, Note 4 and more searchable, than it ever has been. A large part of the reason I'm a fan of microformats is the same reason I'm a huge fan of semantic HTML – it's more readable and understandable, not only by people, but by machines as well.

The next question may be "why is that important for resumes". Machines generally lack bias, and bias is a huge issue, especially in evaluation of resumes – you can read more about such bias on my post "What's in a name?" – which is why when friends went to work at LinkedIn, I put the words in their ear that they should use the hResume microformat. Note 5

A few short years ago, the hResume (and its related hCard format) were the only significant efforts in to create an HTML resume that would be a candidate for the Semantic Web. Time moves quickly on the Internet, however, and I should note that the hCard and hResume formats have been 'deprecated' in favor of the new formats – h-card and h-resume – and since Google, Bing, and Yahoo! joined together to create microdata schemas Note 6 you've (almost) had another way to mark up a resume. Granted, the microdata way takes more work because there isn't a format specifically for resumes, you have to cobble it together, but it's fairly easily done, and I'm going to tell you how while also describing how to mark up the data in both hResume and h-resume formats. This approach will give you a resume that's readable by nearly every bot crawling the web.

Getting Started

Note: before you go any further, it is important that you consider how much personal information you post on the web. You certainly need a name and some way for people to contact you, but more than that could put you at risk, and only you can evaluate the degree of risk. You ought also make a plan for re-evaluating that risk periodically.
First, let's think about a resume for a moment. Every resume is basically a combination of personal data and event data. You could think of it in other ways, but that doesn't really make sense. Every job you've ever had is an event organized by your employer, and every educational session you've attended is an event organized by the institution you attended. Once we've figured this out, it's relatively easy to put together a resume.

Now let's start with your code…we'll start with the contact information, which is typically where a resume begins. In order to be as complete as possible, I'm going to use all three formats – the two microformats: hResume and h-resume, and the microdata format, which we'll basically be creating. One small note here - there will be sections that I have marked up using tags that you may wish to replace with other tags; for example, a job description could easily be an ordered or unordered list rather than a paragraph, so feel free to use the tag that best describes the data you're presenting.

If you're using the h-resume format, you'll need to wrap all your information in a container with the class h-resume (same if you're using the hResume format), so feel free to use either a DIV tag or a SECTION tag as long as you use hResume and h-resume in the class attribute.

<section class="hResume h-resume">
  [your resume here]
</section>

You will not need this markup if your intention is to only use microdata, because there is no microdata schema for a resume or CV - this only applies to the hResume and h-resume formats. If schemas.org decides to create a resume schema, you could easily add the itemscope and itemtype attributes to this section.

Contact Information

The first section we're going to add to the resume is the contact information. It's typically the first section on any resume, so it's as good a place to start as any. For the microformats the sections will need to be identified and it's a good practice to identify the sections with some sort of header, so we're going to use the pattern where we have a header followed by identified content blocks. Since contact information is fairly simple as a h-card or Person object, I'll just go straight to the code where you'll notice I'm using a mixture of class attributes used by h-card (including contact, p-contact vcard and h-card) Note 7 and itemprop attributes (including name, addressLocality, and addressCountry). Note 8

One other note - I'm using a class name called "clipped" that hides content by using an absolute position and the CSS "clip" property (e.g. .clipped { clip:rect(0 0 0 0); clip:rect(0, 0, 0, 0); position:absolute; }). This approach makes content accessible in a way that setting the "display" property to "none" does not.

<section class="hResume h-resume">
  <section>
    <header>Contact</header>
    <div class="contact p-contact vcard h-card" itemscope="" itemtype="http://schema.org/Person">
    <p class="fn p-name" id="contact-p-name" itemprop="name">[your name]</p>
    <p class="adr p-adr" itemprop="address" itemscope="" itemtype="http://schema.org/PostalAddress">
      <span class="locality p-locality" itemprop="addressLocality">[locality]</span>
      <abbr class="region p-region" itemprop="addressRegion">[region]</abbr>
      <span class="postal-code p-postal-code" itemprop="postalCode">[postal code]</span>
      <abbr class="country-name p-country-name" itemprop="addressCountry">[country code]</abbr>
    </p>
    <p class="email">
      <span class="type clipped">[email type, e.g, "Work" or "Personal"]</span>
      <a class="value u-email" href="mailto:[email address]" itemprop="email">[email]</a>
    </p>
    </div>
  </section>
</section>

If you're wondering why I've included the country name, keep in mind that bots have a difficult time determining context. They could use a language code to guess about where you are, if you have it...but what about people who publish their resumes in a language or for a place other than where they're currently located - they'll want some way to identify where they're located that is not associated with the document language code. Also, note that I've added an ID attribute to the "name" element (identified by the "fn" or "p-name" class and the "name" itemprop) – that will be used later in the code as part of the h-resume format.

Summary or Objective

The next section you may want to include is the "summary" or objective. Why might you want to include a summary? It's basically the tl;dr section for your post. If you're using the hResume or h-resume format, use the class names "summary" and "p-summary", respectively. Something like the following should suffice.

<section>
  <header>Summary</header>
  <p class="summary p-summary">[your summary here]</p>
</section>

Note that this section is not available in the microdata version. An alternative to leaving it out completely is to add it within the Person schema after the email paragraph as a "description" (e.g., <p class="clipped" itemprop="description">[your summary here]</p>); however, doing so may result in information being duplicated by bots reading your resume.

Experience

Now we get to the complex portion - work experience - and I'll try to make it as simple as possible. First, the data needs to be wrapped in the "experience" class for the hResume and h-resume formats and since experience is really an ordered list of events, we're going to be semantic and use the OL tag and since they're events, we're going to add the vcalendar class. This means our experience items are wrapped inside code like this...

  <section>
    <header>Experience</header>
    <div class="experience p-experience">
    <ol class="vcalendar">
      [your experience here]
    </ol>
    </div>
  </section>

This means our work experience - each job - can be wrapped in an event, giving us code like this...

<li class="vevent vcard h-event h-card" itemscope itemtype="http://schema.org/Event">
  <a href="#contact-p-name" class="include"></a>
  <div itemprop="organizer" itemscope="" itemtype="http://schema.org/Organization">
    <p class="org p-org" itemprop="name">[your employer]</p>
    <p class="location p-location" itemprop="address" itemscope="" itemtype="http://schema.org/PostalAddress">
      <span class="adr p-adr">
        <span class="locality p-locality" itemprop="addressLocality">[employer locality]</span>
        <abbr class="region p-region" itemprop="addressRegion" title="[region]">[employer region]</abbr>
      </span>
    </p>
  </div>
  <p class="summary p-summary title p-job-title" itemprop="name">[job title]</p>
  <abbr class="dtstart dt-start" content="[start year]-[start month]" itemprop="startDate" title="[starting date]">[starting date]</abbr> - <abbr class="dtend dt-end" content="[end year]-[end month]" itemprop="endDate" title="[ending date]">[ending date]</abbr>
  <div class="description p-description">
    <p itemprop="description">[job description]</p>
  </div>
</li>

There are a few additional things you'll want to know about this section. First, the readers will strip HTML tags out of properties, so don't worry about any markup you have inside the specified properties; however, they do not alter white space - e.g., line breaks, tabs, and spaces - so keep it to a minimum. Second, there are a couple things to note about the dates - the first is that the content and title values are ISO 8601 format and the second is that the starting date is always required for an event but an ending date is not, which means I can easily use a date range like <abbr class="dtstart dt-start" content="2009-03" itemprop="startDate" title="2015-07-01">July 2014</abbr> - <span class="date-name">Present</span> for a current position. Third, you'll notice the very first element within the event is an anchor tag that uses the ID attribute we created in the contact information as its href with the class attibute "include" – this is how we're using "p-name" data we identified earlier.

If I had a second job with the same employer, common practice is to not list the employer information a second time, but we want to make sure our information is as accurate and complete as possible, so we include it and just use the "clipped" class to hide it, like so.

<li class="vevent vcard h-event h-card" itemscope itemtype="http://schema.org/Event">
  <a href="#contact-p-name" class="include"></a>
  <div class="clipped" itemprop="organizer" itemscope="" itemtype="http://schema.org/Organization">
    <p class="org p-org" itemprop="name">[your employer]</p>
    <p class="location p-location" itemprop="address" itemscope="" itemtype="http://schema.org/PostalAddress">
      <span class="adr p-adr">
        <span class="locality p-locality" itemprop="addressLocality">[employer locality]</span>
        <abbr class="region p-region" itemprop="addressRegion" title="[region]">[employer region]</abbr>
      </span>
    </p>
  </div>
  <p class="summary p-summary title p-job-title" itemprop="name">[job title]</p>
  <abbr class="dtstart dt-start" content="[start year]-[start month]" itemprop="startDate" title="[starting date]">[starting date]</abbr> - <abbr class="dtend dt-end" content="[end year]-[end month]" itemprop="endDate" title="[ending date]">[ending date]</abbr>
  <div class="description p-description">
    <p itemprop="description">[job description]</p>
  </div>
</li>

Education

The next section is typically education. Again, we're going to use the event model to describe this portion of your career. Like the experience section, it needs to be wrapped in section description and is an ordered list, so...

<section>
  <header>Education</header>
  <div class="education p-education">
    <ol class="vcalendar">
      [your education events here]
    </ol>
  </div>
</section>

The name or description should contain a short description of the event. If you're listing a single course, it would be the course name, but if you're listing all the courses leading up to matriculation, list the degree or certificate you earned, like so.

<li class="vevent h-event" itemscope="" itemtype="http://schema.org/Event">
  <div class="summary p-summary vcard h-card" itemprop="organizer" itemscope="" itemtype="http://schema.org/Organization">
    <a class="url fn p-name org p-org" href="http://www.millikin.edu/" itemprop="name">[institution]</a>
    <p class="adr p-adr" itemprop="address" itemscope="" itemtype="http://schema.org/PostalAddress">
      <span class="locality p-locality" itemprop="addressLocality">[locality]</span>
      <abbr class="region p-region" itemprop="addressRegion" title="[region]">[region]</abbr>
    </p>
  </div>
  <abbr class="dtstart dt-start" content="[start year]-[start month]" itemprop="startDate" title="[starting date]">[starting date]</abbr> - <abbr class="dtend dt-end" content="[end year]-[end month]" itemprop="endDate" title="[ending date]">[ending date]</abbr>
  <p class="description p-description" itemprop="name">[degree, program of study, or course name]</p>
</li>

As with the section containing work experience, the bots will strip HTML tags out of properties and leave white space, the dates use ISO 8601 format in the content attribute, and the starting date is required but an ending date is not. Unlike the work experience, we are not including an anchor tag that uses the ID attribute we created in the contact information as its href with the class attibute "include" as the first element – the h-card entry is that of the institution instead.

Skills

The final section I'll cover in detail is the section listing your skills. This section does not use microdata because there isn't currently a schema for skills, with the exception of as a property of the JobPosting schema. There are other sections typically included in a CV, and one of those sections Note 9 is included in the hResume and h-resume formats, but those are not discussed in any detail here.

Because information about skills is typically something for which people generally request additional information, I recommend that you use a table as markup. Use the class name "skills" for the table, this will identify the section, and use the class names "skill" (for hResume) and "p-skill" for h-resume to identify individual skills. I recommend that you add columns to your table to identify when you last used the skill or what your competency level is - the latter is especially use for language skills. This approach would give us something like the following.

<section>
  <header>Skills</header>
  <table class="skills">
    <thead>
      <tr><th>Skill</th><th>Last Used</th></tr>
    </thead>
    <tbody>
      <tr><td class="skill p-skill">AJAX/XmlHttpRequest</td><td>2014</td></tr>
      <tr><td class="skill p-skill">bootstrap</td><td>2014</td></tr>
      <tr><td class="skill p-skill">CSS/CSS3</td><td>2014</td></tr>
      <tr><td class="skill p-skill">cssless</td><td>2014</td></tr>
      <tr><td class="skill p-skill">D3js</td><td>2014</td></tr>
      <tr><td class="skill p-skill">dustjs</td><td>2014</td></tr>
      <tr><td class="skill p-skill">git</td><td>2014</td></tr>
      <tr><td class="skill p-skill">HTML/HTML5</td><td>2014</td></tr>
      <tr><td class="skill p-skill">Java</td><td>2014</td></tr>
      <tr><td class="skill p-skill">JavaScript</td><td>2014</td></tr>
      <tr><td class="skill p-skill">jQuery</td><td>2014</td></tr>
      <tr><td class="skill p-skill">JSON</td><td>2014</td></tr>
      <tr><td class="skill p-skill">nodejs</td><td>2014</td></tr>
      <tr><td class="skill p-skill">Perl</td><td>2014</td></tr>
      <tr><td class="skill p-skill">Splunk</td><td>2014</td></tr>
      <tr><td class="skill p-skill">SVN</td><td>2014</td></tr>
      <tr><td class="skill p-skill">XML-Schema</td><td>2014</td></tr>
      <tr><td class="skill p-skill">XML</td><td>2014</td></tr>
      <tr><td class="skill p-skill">XPath</td><td>2014</td></tr>
      <tr><td class="skill p-skill">YUI</td><td>2014</td></tr>
    </tbody>
  </table>
</section>

Other Sections

Because other sections typically found in a resume – e.g., "publications", "presentations", or "honors and awards" – are events, you may wish to mark them up as microdata or h-event to include them; however, they are not recognized by either resume format at this time.

Progressive Enhancement – Printing and Sorting Data

One final suggestion - by creating not only a browser stylesheet but a print stylesheet as well, you can easily make one resource fit two purposes, and that is easily done using the "@media print" query. Use of the "print" stylesheet enables you to control page breaks and typography for print versions of your resume, as well as giving you the ability to hide elements in the page that might detract from your resume.

You can also extend the functionality embedded in the browser version of your resume using JavaScript to make your resume dynamic. For example, you may wish to use the cjl-scrollabletable.js library to make your skills (or affiliations) table take up less real-estate and also allow the user to sort the data by the different columns.

If you'd like to see how all this works together, feel free to look at a full resume marked up at http://www.cathmhaol.com/resume.htm as an example.

Notes and references

Links in the notes and references list open in a new window

1. A simple way to express meaning on the web in HTML without further complex XML alternatives.
2. A simple, open format for publishing information about people and organizations using a 1:1 representation of the VCARD (RFC 2426) properties and values in HTML.
3. An intentional hidden feature or message in a work such as a computer program, video game, movie, book, or crossword.
4. This concept is the Semantic Web that Tim Berners-Lee has pushed for a number of years, even basing a TED talk around it.
5. The hResume microformat, and its successor – h-resume – is a microformat for publishing resumes and CVs.
6. Microdata schemas are methods used to markup HTML pages in ways recognized by major search providers, and that can also be used for structured data interoperability
7. The specific elements used with the h-resume format, and some simple examples, can be found at http://microformats.org/wiki/h-resume. The h-card format, used to mark up contact information, can be found at http://microformats.org/wiki/h-card.
8. The specific elements used in marking up contact information using microdata can be found at http://schema.org/Person and http://schema.org/PostalAddress.
9. A section listing "affiliations" is recognized by both the hResume and h-resume formats; however, since there is not a microdata resume format, affiliations are contained by the Person schema. As with the "summary" section, you may wish to list affiliations with the Person information; however that may result in duplicate information.

What's in a name?

Women face a number of barriers in science-based endeavors, perhaps more so than in other fields1. This matter is not really even open for debate. What is up for debate is whether or not it's justified and whether or not we will actually do anything about it.

Much debate surrounds the causes of the gender disparity evident in many fields. Some argue that girls and women do not pursue STEM2 educational programs and therefore either show a lack of interest in the topics or aren't generally qualified to pursue the programs. This is, almost certainly in part, due to traditional gender roles, but it cannot be limited to that as the limitations based on traditional gender roles have decreased as time has passed and societal norms have adjusted.

Another portion of the lack of pursuit of STEM programs by women is almost certainly self-inflicted doubts. This can be seen in a (1946) conversation between Einstein (yes, that Einstein), and a South African girl named Tyfanny. In corresponding with her, after she revealed her gender, Einstein said,

I do not mind that you are a girl, but the main thing is that you yourself do not mind. There is no reason for it.3

Einstein recognized, in Tyfanny's words, the self-doubt resulting from generations repeating the societal refrain "you're a girl".

These problems are significant, and we must fight tenaciously to overcome them; however, these facts alone are not enough. These are facts of history - facts that society has dealt with for years and yet, one might argue that while female representation is much lower in STEM-related fields, it is significantly imbalanced in many fields4. Why is this? Why are we not convinced that especially science, technology, engineering, and mathematics are about ideas and not something as trivial as gender? Are we really so blinded to not be convinced that women can think as well as men?

I refuse to believe that it is something in our conscious behavior, and I posit that our bias goes much deeper than we originally thought. Even though we have convinced ourselves that even if the larger populace does not subscribe to a meritocracy those of us in STEM-related fields are well into a meritocracy, we have deceived ourselves.

In what should have been a mind-blowing study written more than a decade ago, Rhea E. Steinpreis, Katie A. Anders, and Dawn Ritzke revealed that both men and women demonstrated gender bias in hiring recommendations.5 The subjects for this particular study were all PhD-level psychologists - people who should recognize that science is about ideas and not gender, people who should recognize trivial and non-trivial information for what it is. In a similar study, written just last year, it was demonstrated that even among science faculty at research-intensive universities, gender biases favor male students.6

What these two studies illuminate is that our gender bias is so thoroughly ingrained that even individuals who are trained to deal directly with data, identifying what is trivial and non-trivial on a daily basis, are incapable of suppressing something as trivial and unreliable as name-based gender bias. Before anyone starts with the 'academia vs. real-world' arguments, a cursory search regarding this topic yields some very interesting anecdotal evidence that supports the same hypothesis.7

We are, like the characters in Shakespeare's Romeo and Juliet, using names as a priori judgments. These two studies also speak volumes about our decision quality, our hiring and staffing policies, our integrity and values, our knowledge about our ability to evaluate people and ourselves, and even our ability to manage diversity.

When otherwise qualified candidates are eliminated from the process based upon their name it's easy to see where a significant portion of the disparity originates. We can work to correct gender stereotypes and eliminate gender roles from early education, we can do a number of things to encourage girls to enjoy and pursue STEM education and programs, we can even build gender-based groups that encourage and promote not just gender balance, but women in the work-force on university and work campuses across the country. None of our efforts to increase education, ban words, or anything of the sort will mean anything until we address eliminating the gender bias that is demonstrated to occur at the first step in any selection process.

Of course, one of the worst parts of this situation is that even though this has been a known issue for more than a decade, we've done nothing to change the situation even though it is incredibly easy. How easy? Here are four simple policies that every organization could adopt with little to no impact to their schedules or bureaucracy, which would alter the landscape significantly:

1. Publicize the existence of gender biases in relation to CV's and resumes and what is being done to compensate for it or correct it.
2. Replace names with unique codes on all CV's and/or resumes that are submitted prior to their being screened.
3. Restrict access to names and codes during the selection process
4. Identify discussion of a candidate's name as especially problematic and a punishable offense

As a bonus, when these policies are introduced, other name-based biases will be reduced or eliminated as well - the most notable are race, nationality, and religion, because when Juliet, in Romeo and Juliet, asks...

What's in a name? That which we call a rose by any other name would smell as sweet.

Romeo and Juliet, Act II, Scene II

...as it turns out, there's more than enough information, and if you don't believe me, just ask Romeo.

Notes and references. Links in the notes and references list open in a new window

1. You can find the research regarding the types of barriers women in science face, published by AAUW in "Why So Few? Women in Science, Technology, Engineering, and Mathematics", at http://www.aauw.org/research/why-so-few/
2. Science, Technology, Engineering, and Mathematics
3. This tidbit is revealed in "Dear Professor Einstein: Albert Einstein’s Letters to and from Children" by Alice Calaprice, along with views on gender's relationship to the study of science that were far ahead of his time - i.e. it doesn't matter.
4. One recent edition of philosophers' sound-bites (Philosophy Bites, by David Edmonds & Nigel Warburton) references 44 males and 8 females - a paltry 15%.
5. The study is called "The Impact of Gender on the Review of the Curricula Vitae of Job Applicants and Tenure Candidates: A National Empirical Study" and you can easily find it online and read it in its entirety - which I recommend.
6. The study is called "Science faculty’s subtle gender biases favor male students", by Corinne A. Moss-Racusin, John F. Dovidio, Victoria L. Brescoll, Mark J. Graham, and Jo Handelsmana. You can read it at http://www.pnas.org/content/109/41/16474.full.pdf+html.
7. In the blog post "I understood gender discrimination once I added 'Mr.' to my resume and landed a job", an individual seeking employment in a non-STEM-related field relates how self-identifying as a male on his CV made a positive change in the response rate to his inquiries.

One last note: If you follow this blog, you might have noticed that I've been missing of late. To offer explanation (not justification or apology) I will say that sometimes personal lives get very busy, we have a temporary shortage of creativity (e.g. writer's block), and we need time to work up the courage to say what we need to say how we need to say it rather than just exclaim "WTF!" and be done with it. For me, it's been a mixture of all of these as I've seen my oldest niece married, contemplated my daughter's education, and ruminated regarding how to address gender disparity in hiring for quite some time, even discussing the policies that will correct this with women in technology companies before writing this post.

Doing the impossible (with Robert's Rule #31 & #32)

This post is not going to be a 'how-to', or an example of critical thought applied to a current topic, but rather a prosaic reflection with career advice mixed in - somewhat like earlier posts.

When I was a young child, we were discussing poetry in primary school and I pulled a book of American poets off the shelf and found It Couldn't Be Done by Edgar A. Guest^[1]. I still recall the note my schoolteacher sent home saying how much the poem reminded her of me, even though I cannot find the note - of course that was quite a number of years ago.

I would not encourage anyone to be excessively optimistic (I would say pollyannaish, but I believe that unfairly associates optimism with feminism), there have been a number of credible studies that demonstrate the benefits of positive thinking^[2]. Yet,  there is something beyond even positive thinking that I feel is crucial to our survival in a corporate environment - an indomitable will. For some, an indomitable will manifests as an "incorruptible patience" or "a destructive pursuit of perfection"^[3]; for others, there are other ways - but they have this in common - they are not skill related and won't be found on the Programmer Competency Matrix^[4] - in fact, it's those times that we're faced with a situation that we know is beyond our bounds that this applies, and it's what made Bert Bell's belief that on any given Sunday any team could beat any other team in the league real. (Robert's Rule #31 - success is about more than skill - is based on that belief.)

A personal story - several years ago I was preparing to fly to California for an in-person interview for a position that I considered a dream job when I found out that my sister, who lived 2000 miles away, was critically ill, and a few hours before I was to leave for my day-long interview, I learned she had died. My grief was beyond anything I had borne before, but I also recognized that the only thing I could do at that point was request PTO and book a flight - and one more day would make little difference in the grief or support that I, or anyone else in my family, could offer.

Even though I knew a rigorous interview process was beyond my bounds in that circumstance, I went and did my best. After I returned home, I contacted my employer and booked a flight, and left the next day. After I secured the job (yes, I did get it), I discovered that some who interviewed me noticed (what they interpreted as) a lack of enthusiasm - several commented to me that interviewing in that situation was something they thought couldn't be done, yet it was done - and well enough to secure the job.

So, here's the lesson I learned that day - if you want something enough and your will is indomitable, you will likely succeed - success is not guaranteed, mind, but very likely.

There was another lesson I learned that day - one that's probably more important
that I carry with me, especially every time I interview a candidate - on any given day we see only a part of a person, and like in jazz, the important bits might be those not heard, so make allowances for what you don't see (Robert's Rule #32).

Or, in the words of Bill (in Bill & Ted's Excellent Adventure), "be excellent to each other".

Notes:

1. If you've never read this poem, do so. I recognize as a (more cynical) adult that it's a bit trite, but it's somewhat uplifting and motivational, and there are times we all need that.
2. The article How the Power of Positive Thinking Won Scientific Credibility is an interesting read regarding the evolution of thought and research in this field, and has links to a number of those studies.
3. These are two traits of a fantastic programmer from Signs that you're a good programmer.
4. http://sijinjoseph.com/programmer-competency-matrix/

No matter how many Novices you add, they'll never equal one Expert (Robert's Rule #16)

[Tweeted 2011-06-01]

One of the typical responses to a project that is behind schedule is to add people to the project with the intent that they will be able to further subdivide the work and develop in parallel, getting the project back on track.

This, of course, is part of the problem in defining software development project timelines using straight developer days or 'man months'. Part of the difficulty lies in the idea that all tasks can be subdivided (hence the concept of the 'mythical man month'). If we apply the idea that all tasks can be subdivided to areas outside of software development, such as pregnancy, then the erroneous conclusions become obvious; after all, we all know that 9 women cannot complete a pregnancy in 1 month.

One of the other, lesser known aspects of Brooks' law is the concept of a 'surgical team' which identifies 'good' developers and 'the rest of the team'. While I won't go into all of Brooks' concepts in detail, this concept deserves special consideration, in part because Brooks estimates that 'good' developers are 5 to 10 times as productive as mediocre developers. In addition, if we factor in the effects of a higher degree of skill on quality we can easily see the error of our ways.

So, next time you're trying to get a product out the door and it's repeatedly behind, remember that not only does it matter how many people you add, no matter how many Novices you add, they'll never equal one Expert (Robert's Rule #16).

You are not your job, you are a person (Robert's Rule #8)

[Tweeted 2011-05-04]

Like many people, I get asked "what do you do" quite often. At times it's been rather difficult to explain to people who "don't get" computers. In fact, one person went so far as to say I didn't really work because I didn't "make" anything. It took me a while to determine that, in his mind, unless you contribute to the production of a physical item in a meaningful way, you aren't really working and you shouldn't get paid. Thankfully, there have never been very many in my circles who have held the same belief.

Another problem I've had in responding to the question is until recently "what do you do" has been a little vague, or imprecise, rather because I've always done several things simultaneously. When I started out in the industry, I was an "Installer". As an Installer, I traveled a region and installed payment systems, trained the users, performed any troubleshooting required, made sure the customers had the supplies they needed, wrote customer service utility software, et cetera, et cetera. After I moved on from that job to client/server development and became a "Systems Programmer". However, 'programmer' jobs were usually more analysis and design than actual development, and then added to that were DBA duties, managerial duties, et cetera, et cetera. When I moved from the client/server environment to the web and became a "ColdFusion Developer" or a "Web Developer", it generally didn't reduce the scope of work much as there were design duties, development duties, network/server administration duties, DBA duties, et cetera, et cetera. Basically, there generally has been more 'et cetera' than distinct role duties.

All of this poses a problem more for existentialists than essentialists, I suppose, so perhaps it's only a problem because of my perspective, but perhaps not

I guess you might say at certain points in my past I've been an Installer-Trainer-CS Representative-Field Engineer-Programmer or Systems Programmer-Data Analyst-DBA-User Interface Designer-Technical Writer-Manager or System Administrator-Web Server Administrator-Programmer-DBA-Web Developer-Web Designer. All of that sounds really complicated and imprecise simultaneously. Besides, I noticed that any time I've been 'between jobs' I've never stopped 'being', so a change in perspective was required and I came to the startling revelation that you are not your job, you are a person (Robert's Rule #8).

As a result, when people ask "what do you do" I no longer respond "I'm a [insert title here]", I generally clarify whether they inquiring in what capacity I'm employed or if they mean something else. If they're inquiring about my work, I say "the majority of my work is as a [insert title here]"; if they mean something else, then I answer their real question to the best of my ability.

There are a few side-effects that I've noticed when verbally recognizing this small truth. First, people generally take a moment to consider what they're asking, which tends to move the conversation quickly out of the in-one-ear-out-the-other chat (that drives me mad) into a realm of real conversation. The second side-effect that I've noticed is that I feel more free to balance work and non-work life. For example, the majority of my "outside-the-home work" may be as a system administrator and that may entail thwarting network attacks, but the majority of my "inside-the-home work" is as a husband and father and in both inside and outside the home I am a person. That means, for example, that there are some meetings I don't take (such as those scheduled during my daughter's bedtime when I'm supposed to be reading her a story or singing a lullaby) and some job opportunities I will never pursue (because they would require me to sacrifice some portion of my humanity).

As far as I can tell, we all have only one life to live. At the end of mine I hope that my wife and daughter say "he was a good man"...anything else just won't do.

When working with rock stars, get your M&Ms ready (Robert's Rule #6)

[Tweeted 2011-05-02]

Most managers I know claim that they would love to have a team of rock stars. Most of the time it's pretty clear that's because a team tends to make a manager look awesome (or not). It makes sense that managers would conclude that a team of rock stars would make the manager look like a rock star as well. Not all teams are comprised of rock stars though, and those that are tend not to maintain cohesion.

For a while I tried to determine why this is the case...why is it that a group of people, especially one where the majority is highly skilled, would spin apart after a period of cohesiveness. Here's what I've discovered: highly skilled people tend to not only be highly skilled but also have their own style, and everyone else's style is not as [insert your descriptor here]...and, simple as that, you find your rock star has become a diva, a word that has connotations beyond the "star" quality that it denotes.

There are two ways I've seen managers react to divas on their team:

• they tighten control as much as they can, making sure the "diva" knows the manager is in charge
• they stay out of the way of the "diva" as much as possible, working behind the scenes to make sure the obstacles are cleared

Having been on both sides of this particular equation, allow me to share the following. Reacting by making sure the diva knows the manager is in charge will backfire. The manager may be in charge, but yanking a dragon's chain seldom ends well. At the very least, the rock star will become miserable and rebel, reducing team morale and in some cases the rebellion has resulted in political intrigue that results in the termination of one or more of the parties. Keep in mind that even as a manager, you're only in charge as long as you're actually employed and have employees reporting to you.

In contrast, one of my best managers, one who dealt with several highly skilled technical people, all with strong personalities, said her formula for success was to hire rock stars and stay out of their way. That she enjoyed the success of a team that delivered solid, feature-rich, complex products ahead of schedule and under budget with extremely low defect rates is a testament to the validity of her approach.

She didn't sweat the small stuff and made sure that her team was rewarded adequately, and most importantly, she made sure that even if she didn't initially understand the reason for a request, she tried to move towards honoring it at the same time that she sought to understand it because, as it turns out, rock stars tend to have very good reasons for seemingly odd-ball requests (one of the most famous examples).

All this led me to Robert's Rule #6: if you want your team to be rock stars, expect a few divas and get those M&Ms ready.

Past performance does not guarantee future value (Robert's Rule #4)

[Tweeted 2011-04-28]

A while ago I was in a job managing a team of software engineers. This team was a mix of people; both in terms of experience and in terms of relationship to the company (i.e. some were full-time employees and some were contractors).

Now, I tend to consider myself more detail-oriented and data driven than the average person, so it made perfect sense to me to relate software features to be developed, and all the project management related data (estimates, dependencies, etc) to my assessment of a developer's skill level and also relate the defects found to the features. In hindsight it was, perhaps, a tad more complicated than it should have been. On the positive side, it gave me quick insight into how effective my assessments were and how likely we (as a team) were to hit our projected development milestones.

One of the problems I faced was when developers took up a different task or a different language. Software development, as a discipline, is fairly straightforward. There are language skills (computer languages are made up of nouns and verbs and have direct and indirect objects just like other languages) and general concepts (like data normalization rules and network/communication protocols) that apply to all feature development, so a good developer is a good developer, right? Usually.

Usually good developers get better, but practice doesn't make perfect and a developer that handles one language with ease may not be able to make the switch to another language. Such was the case when one of the developers on my team attempted the switch from COBOL to an object-oriented language. When he popped the clutch on his paradigm shift (yeah, I started that saying back in '93) his development shuddered like an old car. In a car, if you pop the clutch, you can stomp on the accelerator and rocket off or you could try to coax it along and kill it...I believe that in theory it works the same with people.

This experience led me to conclude that "past performance does not guarantee future value" is just as true for people as for the stock market (Robert's Rule #4). This developer chose to try to coax his development along rather than immersing himself in the new technology. I don't know where his career has taken him in the years since, but it's most likely out of software engineering.

If you pay peanuts, you'll get monkeys as employees (Robert's Rule #2)

[Tweeted 2011-04-26]

One day, as I talked to a CEO-type friend of mine, we discussed salaries. This guy, for whatever faults or adornments his personality may have, is a shrewd businessman. His experience in labor relations and negotiating with unions back in the day has served him well over his career, and while a lot of employers complain about salary and benefit packages making up 60% or more of their operating expenses, my friend made his opinion clear -- if you pay peanuts, you'll get monkeys as employees.

Now, I've happily worn the label code-monkey more than a few times in my life, but I want to project absolutely clarity on this -- we are not talking about a code-monkey here, this is more of the "trained chimp" variety -- you know, as in "a trained chimp could [do x] better than [your insult target]".

Before you go off on some "monkeys don't eat peanuts" tangent, skip it. The metaphor may break down when compared to actual monkeys and actual peanuts...but ignore that for a second. While money breaks down as a motivator (watch Dan Pink's animated lecture), it actually works pretty well as a motivator up to a point where, as Mr. Pink says, you "take it off the table". When you think about it, that pretty clearly coincides with a few other theories, such as the Law of Diminishing Returns or Maslow's Hierarchy of Needs.

One of the things I find interesting around this rule is the idea of outsourcing. If the primary motivation for 'outsourcing' is to find a less expensive workforce rather than utilize some aspect of collective unconscious or first-hand cultural experience/knowledge to improve local market penetration (e.g. in language localization) or implement a 24-hour workday (e.g. to reduce time-to-market for defect resolution or improve customer service), you will get what you seek, because, and let me be clear about this, there is amazing talent outside of [insert your country here]. However, even as ingenuity, hard work, and skill do not recognize borders, neither do apathy and inattention. The bottom line in this regard is this...if you want something built cheaply you can find people to build it cheaply, but in the end what you have is worth less than what you paid.

There are exceptions that prove this rule -- people who are very highly skilled and highly valued by their employer who are receiving peanuts when their monetary compensation is compared to what they would receive from other organizations. In the estimation of these exceptional people, their compensation package is not 'peanuts' -- likely because they receive significant non-monetary compensation (at this point, if you haven't watched Dan Pink's lecture, you really need to watch it).

One of the other things I find interesting around this rule is it's corollary -- if you're getting paid peanuts it's time to determine whether or not you're a monkey. It's likely that I find this interesting because it reflects a pivotal point in my career when an employer, many years ago, tried their best to convince me that I was little more than a trained chimp while I was certain that was untrue (and doubled my salary by changing jobs to prove it). Of course it could have just as easily gone the other way...I could have been little more than a trained chimp fresh from university, and likely was. Diligent practice made me better than I was and, hopefully, that will continue.

Oh, and for what it's worth, no monkeys were harmed in the writing of this post...in fact, no actual monkeys were used in any way.