Basic setup

Everyone has at least one GitHub organization under which the official repositories live. Some have more than one organization, each representing a different aspect of the business, however all official repositories are owned by an organization. I suspect this would be the case as it would be horribly awkward to have an important repository owned by a user who may or may not be at the company next year. Also, using an organizational owner for these repositories allows better visibility as to what’s going on with official projects just by looking at the organization.

Several people mentioned that no one is barred from creating their own repositories on GitHub for side projects or other purposes. Creating repositories for company-related work is generally encouraged. If a side project becomes important enough, it can be promoted to an organizational repository.

Developer setup

Companies took a couple of different approaches to submitting code:

• Most indicated that developers clone the organization repository for their product and then work on feature branches within that repository. Changes are pushed to a remote feature branch for review and safe-keeping.
• Some indicated that each developer forks the organization repository and does the work there until it’s ready for merging into the organization repository.
• A couple indicated that they started out with forks and then switched to feature branches on the organization repository due to better transparency and easier workflow.

The general trend is in the direction of feature branches on the organization repository. Since you can send pull requests from one branch to another, you don’t lose the review mechanism.

Submitting code

In the open source world, external contributors submit pull requests when they want to contribute while the maintainers of the project commit directly to the repository. In the corporate world, where everyone may logically be a maintainer for the repository, does it makes sense to have developers send pull requests? The responses were:

• Some required pull requests for all changes.
• Some required pull requests only for changes outside of their responsibility area (i.e., making a change to another team’s repo). Other changes can be submitted directly to the organization repository.
• Some left this up to the developer’s discretion. The developer should know the amount of risk associated with the change and whether or not another set of eyes is useful. The option to submit directly to the repository is always there.

The responsibility for merging in pull requests varied across the responses. Some required the team leads to do the merging, others allowed anyone to do the merging.

Interestingly, some indicated that they start a pull request as soon as a new feature branch is created in order to track work and provide better visibility. That way, there can be a running dialog about the work being done in that branch instead of temporary one at the time of work completion.

Preparing code for submission

A secondary part of this process is how the code must be prepared before being merged in. The accepted practice of squashing commits and rebasing still  remains common across the board though the benefits aren’t clear to everyone. Of those who responded:

• Some required a squash and rebase before a pull request can be merged in.
• Some will merge in a pull request regardless of the makeup of commits.
• Some care about keeping a strict, non-branching history while others do not.

It’s hard to outline any consistent trends in this regard. Whether or not you squash, rebase, or merge is very much a team-specific decision (not an organization-specific one).

What about git-flow?

I didn’t ask this question specifically, but it came up enough. Git-flow[3] is a process for managing changes in Git that was created by Vincent Driessen and accompanied by some Git extensions[4] for managing that flow. The general idea behind git-flow is to have several separate branches that always exist, each for a different purpose: master, develop, feature, release, and hotfix. The process of feature or bug development flows from one branch into another before it’s finally released.

Some of the respondents indicated that they use git-flow in general. Some started out with git-flow and moved away from it. The primary reason for moving away is that the git-flow process is hard to deal with in a continuous (or near-continuous) deployment model. The general feeling is that git-flow works well for products in a more traditional release model, where releases are done once every few weeks, but that this process breaks down considerably when you’re releasing once a day or more.

Conclusion

A lot of people shared a lot of very interesting anecdotes about using GitHub at their companies. As I expected, there’s no one accepted way that people are using GitHub for this purpose. What’s interesting is the range of ways people have chosen to adapt what is essentially an open source workflow for enterprise use. Since GitHub also has GitHub Enterprise, I’m certain that this trend will continue. It will be interesting to see if the feedback from GitHub Enterprise and corporate needs will end up changing the public-facing GitHub in any way.

I’m interested in doing more research about how Git and GitHub in particular are used inside of companies. I’ve yet to see any good research done on whether or not squashing and rebasing is important in the long run, and I think that would be great to figure out. Please feel free to share your experiences in the comments.

References

1. How do you use GitHub at your company? (GitHub Gist)
2. GitHub flow by Scott Chacon (Scott Chacon’s Blog)
3. A successful Git branching model by Vincent Driessen (nvie.com)
4. git-flow Git Extensions (GitHub)

Why vendor prefixes anyway?

The idea behind vendor-prefixed features (both JavaScript and CSS) is quite simple: give browser developers and web developers opportunities to work with as-yet-incompletely-specified features to get feedback. The goal was just. How do browser developers really know if a proposed feature will work if they don’t actually try to build it? Likewise, how do web developers know that a feature is useful if they never have the chance to try and use it? Vendor-prefixed features gave browsers the freedom to implement stuff that might not be quite ready and web developers the chance to give feedback to the browsers regarding these features. It seemed like a win-win situation. So what went wrong?

To a person with a hammer…

There were problems with these vendor-prefixed features. First, browser developers were hanging on to them for far longer than originally anticipated. Firefox had -moz-border-radius from the beginning and it was only officially removed in Firefox 13, a timespan of over 8 years. Vendor-prefixed properties ended up being a playground for browser vendors where any experiment, prototype, or other “not exactly standard” feature could be implemented. After all, it was free to do so and developers should be forewarned by the vendor-prefix that this thing shouldn’t be relied upon.

Web developers, however, saw vendor-prefixed properties more as “the way that browser X is choosing to support this feature” rather than as an experimental extension. That meant web sites started to depend on these experimental features for their functionality or appearance, leading to the creation of tools that would help by pointing out or automatically adding the correct vendor-prefixed version of CSS properties. Lest we forget this mess:

.box {
    background: #1e5799; /* Old browsers */
    background: -moz-linear-gradient(top,  #1e5799 0%, #2989d8 50%, #207cca 51%, #7db9e8 100%); /* FF3.6+ */
    background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#1e5799), color-stop(50%,#2989d8), color-stop(51%,#207cca), color-stop(100%,#7db9e8)); /* Chrome,Safari4+ */
    background: -webkit-linear-gradient(top,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* Chrome10+,Safari5.1+ */
    background: -o-linear-gradient(top,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* Opera 11.10+ */
    background: -ms-linear-gradient(top,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* IE10+ */
    background: linear-gradient(to bottom,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* W3C */
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#1e5799', endColorstr='#7db9e8',GradientType=0 ); /* IE6-9 */
}

And in JavaScript, more and more code ended up looking like this^[1]:

    var vendors = ['ms', 'moz', 'webkit', 'o'];
    for(var x = 0; x < vendors.length && !window.requestAnimationFrame; ++x) {
        window.requestAnimationFrame = window[vendors[x]+'RequestAnimationFrame'];
        window.cancelAnimationFrame = window[vendors[x]+'CancelAnimationFrame'] 
                                   || window[vendors[x]+'CancelRequestAnimationFrame'];
    }

These patterns in CSS and JavaScript indicated that web developers were not treating these features as experimental, but as dependencies they needed for things to work. Browser vendors didn’t do web developers any favors by keeping these features around as long as they did. Certainly, quickly-disappearing vendor-prefixed features would teach web developers not to rely on them.

More recently

The quickly-disappearing theory of vendor-prefixed features also seemed to be incorrect. Internet Explorer 10 introduced some features with a ms extension in the beta version, and then removed the prefixes when the final version was released. This created a lot of confusion amongst web developers as to whether or not ms was necessary to use certain features. Likewise, Chrome had started moving features through vendor-prefixed versions to standard ones much faster than before. Yet, there were still features that lagged far behind, so there’s a mix of webkit prefixed functionality: some that have been around for a while and no one’s quite sure where they’re going (-webkit-appearance) while others moved quickly into a standardized version (webkitIndexedDB).

Due to this confusion, and the desire of browsers to properly support a large number of sites, some Mozilla and Opera considered supporting webkit CSS properties to have better compatibility with the web at large.^[2] There were a lot of opinion pieces about whether or not this was a good thing, but all agreed that vendor prefixes resulted in a massive mess that there was no easy way to clean up.

Goodbye, vendor prefixes!

Blink’s decision to stop creating new vendor-prefixed functionality is the right approach to me. Remember, the whole point of vendor prefixes was to allow browser developers to test implementations and for web developers to give feedback. You don’t need vendor prefixes for that. Blink’s approach is to allow you to turn on certain experimental features through browser settings is something I’m very excited about. Doing so allows browser developers to continue with experimental implementations without the fear that web developers will come to rely on those features. It also gives web developers the opportunity to turn on those features and try them out, with a very clear directive that you cannot rely on your users having this feature enabled, therefore you should not depend on it.

I definitely welcome and look forward to a prefix-free world. We got into such a mess and placed so much cognitive burden on so many people for so long that it may be a crime in certain parts of the universe. Everyone needs the ability to experiment so that the web can continue to develop new functionality, but we all need to be smarter about how we implement and use those features. The Blink approach follows a systems approach that I like: make it difficult for people to do the wrong thing. If other browsers adopt the same approach then we can be assured that the future CSS and JavaScript we write won’t be hampered down by numerous duplicate declarations or annoying feature tests. We can all just go back to what we really want to do: make awesome web experiences without forking our code for every browser.

References

1. requestAnimationFrame() polyfill (GitHub)
2. tl;dr on vendor prefix drama by Chris Coyier (CSS Tricks)

I was recently asked if there’s a way to get the URL of an iframe’s parent page, which is to say, the URL of the page with the <iframe> element. This seems like a simple enough task. For a regular page, you typically get the URL by using window.location. There are also parent to get the window object of the parent page and top to get the window object of the outermost page. You can then use parent.location or top.location to get a URL from the containing page depending on your needs. At least, that’s how you do it when both the iframe page and the containing page are from the same origin.

When the iframe page and containing page are from different origins, then you are completely cut off from the parent.location and top.location. This information is considered unsafe to share across origins. However, that doesn’t mean you can’t find out the URL of the containing page. To do so, you simply need to keep in mind what information the iframe owns and what information it does not.

To start, you should double-check that the page is actually in an iframe, which you can do with this code:

var isInIframe = (parent !== window);

When a page is running inside of an iframe, the parent object is different than the window object. You can still access parent from within an iframe even though you can’t access anything useful on it. This code will never cause an error even when crossing origins.

Once you know you’re in an iframe, you can take advantage of a little-known fact: the HTTP Referer header for a page inside of an iframe is always set to the containing page’s URL. That means a page embedded in an iframe on http://www.nczonline.net will have a Referer header equal to that URL. Knowing this fact, you need only use the oft-forgotten document.referrer property. As the name suggestions, this property contains the value of the Referer header for the given document. So you can get the URL of the iframe’s parent page like this:

function getParentUrl() {
    var isInIframe = (parent !== window),
        parentUrl = null;

    if (isInIframe) {
        parentUrl = document.referrer;
    }

    return parentUrl;
}

While this may look like a security issue, it’s really not. The Referer is already being sent to the server that is serving up the iframe page, so that information is already known by the web application. The document.referrer property is just exposing the information that the server already has. Since the document object is owned by the iframe window, you aren’t crossing the same-origin policy boundary.

Iframes are always a little bit hairy to deal with, especially when you throw JavaScript into the mix. The good news is that there’s usually a way to do something that makes sense and won’t put a user at risk, whether that be through document.referrer cross-document messaging, or some other means.

References

1. Iframes, onload, and document.domain by me (NCZOnline)

@slicknet Do you know the best way to make a <button> that just has an icon accessible? title, aria-label, hidden text?

— Pamela Fox (@pamelafox) March 26, 2013

As tends to happen on Twitter, we fruitlessly exchanged 140 character messages trying to get some resolution before I finally offered to write a blog post explaining my view. Along the way, I discovered that I had misunderstood the original question (yay 140 character responses) and needed to do a little research. And so here it is.

Simple icon buttons

In the beginning, there <input type="image">. Many seem to have forgotten this part of HTML. Early on, web developers wanted to use images as submit buttons rather than the plain submit button and <input type="image"> allowed you to create an image that actually works like a button. Further, this type of image actually announces itself as a button in screen readers. Anytime you want the user to click on something and not navigate to another page, you’re looking for a button, and <input type="image"> gives you a nice compact way of doing that while supporting the same attributes as <img>. For example:

<input type="image" src="email.png" width="14" height="14" alt="Email">

In this case, the major screen readers (JAWS, NVDA, VoiceOver) announce “Email button” in all major browsers, reading the alt text and identifying the image as a button. Part of the reason this pattern isn’t used much anymore is due to the ubiquity of CSS sprites. However, it’s still my favorite pattern, and with a little adjusting, works fine with sprites:

<style>
    .email-btn {
        width: 14px;
        height: 14px;
        background: url(activities.png) 0 -85px no-repeat;
    }
</style>

<input type="image" src="pixel.gif" class="email-btn" alt="Email">

This example uses a single transparent GIF as the src of the image. Doing so allows a background image to be applied and show through via the “email-btn” class. If the thought of having an extra download for an icon button is unpalatable to you, you can also use a data URI representing a single transparent pixel:

data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==

In either case, the major screen readers still announce “Email button” when focus is set to the button, which is exactly what you want.

Using <button>

The <button> element has becomes the element of choice for making non-text buttons in HTML. This makes complete sense because you can put whatever HTML you desire inside and it renders as a button. However, the end result is not the same as with the more traditional approach. First, consider a really simple example:

<button><img src="email.png" width="14" height="14" alt="Email"></button>

This button produces some very different results in different browsers and different screen readers:

• Chrome 25 (Win7/NVDA): “Button”
• Internet Explorer 9 (Win7/NVDA): “Button”
• Firefox 19 (Win7/NVDA): “Email graphic button”
• Chrome 25 (Win7/JAWS): “Email button”
• Internet Explorer 9 (Win7/JAWS): “Email button”
• Firefox 19 (Win7/JAWS): “Email button”
• Chrome 25 (Mac OS X/VoiceOver): “Email button”
• Safari 6 (Mac OS X/VoiceOver): “Button”
• Firefox 19 (Mac OS X/VoiceOver): “Email button”
• Mobile Safari (iOS 6/VoiceOver): “Button”

So basically, using a <button> element introduces a barrier for most screen reader/browser combinations to figure out what the button is doing. It doesn’t matter if the <img> is used more traditionally or with a sprite, you don’t get much information in most places.

You can give screen readers a hint by using the aria-label attribute on the <button> element. Doing so means providing a plain-text label for the button as a whole:

<button aria-label="Email"><img src="email.png" width="14" height="14" alt="Email"></button>

By adding an aria-label, the various screen readers and browsers respond as follows:

• Chrome 25 (Win7/NVDA): “Email button”
• Internet Explorer 9 (Win7/NVDA): “Email button”
• Firefox 19 (Win7/NVDA): “Email graphic button”
• Chrome 25 (Win7/JAWS): “Email Button”
• Internet Explorer 9 (Win7/JAWS): “Email Button”
• Firefox 19 (Win7/JAWS): “Email button”
• Chrome 25 (Mac OS X/VoiceOver): “Email button”
• Safari 6 (Mac OS X/VoiceOver): “Email button”
• Firefox 19 (Mac OS X/VoiceOver): “Email button”
• Mobile Safari (iOS 6/VoiceOver): “Email button”

So now you actually have a nice response from all of the major browsers and screen readers. You can use this same technique regardless of what you place inside of the <button> element.

Font Awesome

Part of what I missed from my original Twitter discussion with Pamela was that she was using Font Awesome^[1]. For the uninitiated, Font Awesome is an icon font that contains numerous common icons for use in HTML. Instead of using separate image files or a sprite that you have to manage, you can use an icon font and reference the relevant icon by using a class name. The icon is inserted via CSS, so it has no negative accessibility concerns. This example is similar to the one Pamela brought up:

<button><span class="icon-envelope"></span></button>

The question is, how do you add descriptive text to this? One way would be to add an aria-label attribute as in the previous section:

<button aria-label="Email"><span class="icon-envelope"></span></button>

Since that always works for <button> elements, that’s the fastest and easiest way forward. The result in various screen readers:

• Chrome 25 (Win7/NVDA): “Email button”
• Internet Explorer 9 (Win7/NVDA): “Email button”
• Firefox 19 (Win7/NVDA): “Email button”
• Chrome 25 (Win7/JAWS): “Email Button”
• Internet Explorer 9 (Win7/JAWS): “Email Button”
• Firefox 19 (Win7/JAWS): “Email button”
• Chrome 25 (Mac OS X/VoiceOver): “Email button”
• Safari 6 (Mac OS X/VoiceOver): “Email button”
• Firefox 19 (Mac OS X/VoiceOver): “Email button”
• Mobile Safari (iOS 6/VoiceOver): “Email button”

I prefer this over the second (and often overused option) of hiding text off screen, in which case you would have code similar to this:

<button><span class="icon-envelope"></span><span class="hide-offscreen">Email</a></button>

The idea here is to position text far off in some direction such that it’s not visible to sighted users but is still read out for screen reader users. I’m not a huge fan of hiding text off screen, primarily because it feels very hacky…a bit like a sleight of hand trick. Additionally, each of the major ways of hiding text off screen comes with some sort of caveat. Using a big negative text-indent doesn’t work well with RTL languages, using a height of 0 means VoiceOver won’t announce the contents, and so on. Jonathan Snook put together a fantastic post^[2] outlining the different approaches and the caveats to each.

The screen readers all end up announcing the same message as when using aria-label.

Do I use hiding text off screen periodically? Yes, but only as a measure of last resort when I’ve exhausted all other possibilities. I would encourage you to do the same.

One final note: don’t use title as your button label. Example:

<button title="Email"><span class="icon-envelope"></span></button>

While it would be ideal if screen readers were able to use this value, the results are very uneven:

• Chrome 25 (Win7/NVDA): “Email button”
• Internet Explorer 9 (Win7/NVDA): “Email button”
• Firefox 19 (Win7/NVDA): “Button email”
• Chrome 25 (Win7/JAWS): “Email Button”
• Internet Explorer 9 (Win7/JAWS): “Email Button”
• Firefox 19 (Win7/JAWS): “Email button”
• Chrome 25 (Mac OS X/VoiceOver): “Button”
• Safari 6 (Mac OS X/VoiceOver): “Button”
• Firefox 19 (Mac OS X/VoiceOver): “Email button”
• Mobile Safari (iOS 6/VoiceOver): “Email button”

Even though the title attribute is helpful for sighted users as a hint, it doesn’t provide any real consistent benefit as far as screenreaders go.

Update (07-April-2013)

As several commenters mentioned, my recommendation results in an empty <button> element. I wasn’t too concerned about that at first, but as I thought about it more and more, the purist in me got a little bit upset. Yes, in an ideal world, you should be able to remove all JavaScript and CSS and the page still make sense. In this case, you’d be left with a button that has no descriptive text whatsoever. That turned my stomach and I went back to the drawing board to try and find a way to have text inside of the <button> element without hiding it offscreen. After some tinkering, here’s what I came up with:

<style>
.btn-label {
    font-size: 0;
    height: 1px;
    overflow: hidden;
    display: block;
}
</style>

<button class="icon-envelope"><span class="btn-label">Email</span></button>

The idea is to have the descriptive text inside of the <button> element while placing the Font Awesome class on the <button> itself. This allows you to modify the inner <span> element separately from the <button>. The <span> is set to be practically invisible by using a font-size of 0, a height of one pixel (to make VoiceOver happy). The rest is used to ensure the <span> never grows any larger.

In all browsers and screenreaders mentioned in this post, the text “Email button” is announced using this pattern. The solution is something that makes the purist side of me very comfortable. You aren’t tempting fate by moving text offscreen yet the <button> element still has text inside of it. You don’t have to use ARIA to provide additional context for screen readers in this case.

Conclusion

I still prefer the old-school <input type="image"> element for creating clickable icons. However, in the case of using an icon font, that really doesn’t work. In that situation, I prefer to use the aria-label attribute to provide additional text for screen readers. Doing so yields the most consistent treatment for buttons across major browsers and screenreaders. I prefer to use some in-line hidden text to ensure the <button> element has actual text inside. As a bonus, you don’t have to worry too much about how position text off screen might affect other parts of the page.

References

1. Font Awesome (GitHub)
2. Hiding content for accessibility by Jonathan Snook (snook.ca)

Mozilla/5.0 (IE 11.0; Windows NT 6.3; Trident/7.0; .NET4.0E; .NET4.0C; rv:11.0) like Gecko

If you’ve read my history of user-agent strings post, then you’re aware of the sinister history of user-agent strings and how browsers try to trick servers into believing that they are other browsers. Internet Explorer 3 actually began the practice by using “Mozilla” in the user-agent string so it would be identified by servers trying to filter for Netscape.

If this user-agent string is the final one (Microsoft hasn’t confirmed or denied this is the user-agent string), then it shows how one can manipulate the user-agent string to get different results. For comparison, here are a few different user-agent strings:

Internet Explorer 10
Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0)

Firefox 19 (Windows 7)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0

Safari 6
Mozilla/5.0 (Macintosh; Intel Mac OS X 1076) AppleWebKit/536.26.17 (KHTML like Gecko) Version/6.0.2 Safari/536.26.17

Chrome 25 (Windows 7)
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.172 Safari/537.22

In the past, it was easy to identify Internet Explorer by searching for the string “MSIE” in the user-agent string. If present, the browser is Internet Explorer. When Gecko was the embedded webview of choice, many simply looked for “Gecko” in the user-agent string to determine if it was a Gecko-powered browser (and therefore likely to behave as Firefox). That approach fell apart when Safari decided to add “like Gecko” into the middle of its user-agent string. Not long ago, WebKit overtook Gecko as the embeddable webview of choice, and so many started looking for “Firefox” in the user-agent string to specifically identify Firefox.

Chrome came along and wanted to be identified as Safari, so it pretty much copied the Safari user-agent string and added a “Chrome” identifier. Simple browser type detection based on user-agent string meant you would need to look for certain tokens in order:

1. If “MSIE” is present, it’s Internet Explorer.
2. Else if “Firefox” is present, it’s Firefox.
3. Else if “Chrome” is present, it’s Chrome.
4. Else if “Safari” is present, it’s Safari.
5. Else if “WebKit” is present, it’s a WebKit-based browser.
6. Else if “Gecko” is present, it’s a Gecko-based browser.

So if the Internet Explorer 11 user-agent string is the final one, it causes some interesting logic to happen in this case. In short, by removing “MSIE” in favor of “IE”, the browser is forcing itself to not be identified as Internet Explorer (step 1). By adding “like Gecko” at the end, it is self-selecting into the category of Gecko-based browsers (step 6).

Gecko- and WebKit-based browsers both are considered to have better standards support than Internet Explorer (generally well-deserved prior to IE10), so tricking servers into identifying IE11 as a Gecko-based browser could mean that the browser can handle the same content (JavaScript, CSS) as Firefox. Of course, that’s usually not the case, especially when it comes to vendor-prefixed functionality. Will IE11 support moz-prefixed functionality?

Is it wise for Internet Explorer 11 to try to hide its identity? I’m sure in some convoluted way it makes sense based on how web applications are serving up different content based on user-agent strings. I still have hope for a day when user-agent strings reflect the actual browser rather than trying to trick servers into serving the correct content, but for now, this is just a continuation of a long, sad browser user-agent lineage.

References

1. IE11 to appear as Firefox to avoid legacy IE CSS (Neowin)

Annual reviews are a reminder that your reputation matters. For most of the year, software engineers don’t care at all what anybody else thinks as long as they’re getting the job done. Then annual reviews come along and we realize we might have rubbed some people the wrong way. I know software engineers who year over year always feel like their review is incorrect and unfair (though I’m sure other occupations have similar issues). What makes it more difficult for software engineers is that we deal so much with code that we sometimes forget how important it is to deal with people. The code isn’t going to give us a negative review so long as it works. Then again, you’re expected to write code that works, so your review only ever reflects when you don’t write code that works.

The rest of the review is based on what people say about you. They are your colleagues and your managers. And you probably didn’t even stop to think about that until around review time. If you’ve ever received a review that has been a complete shock to you, that means you didn’t spend enough time during the year to figure out what kind of the software engineer you want to be known as.

Never be surprised again

It’s been a long time since I had an annual review that surprised me. My last manager even came to expect it from me, as he would usually begin our conversations by saying, “I’m pretty sure you know what this is going to say.” He was right. It was very easy for me to predict what would show up on my annual review for one simple reason: I had already decided what I wanted to show up on the annual review the year before.

This is probably different than the way you’ve ever thought about annual reviews. Most of the time, you meet with your manager and set goals for the next year, and then your annual review is a checkpoint to see if you achieve those goals. Unfortunately, the goals are typically task oriented such as, “learn about Node.js”. It’s relatively easy to see if you’ve achieve those goals. What most people never stop and think about is what you would like to see on your annual review next year.

Stop and think about that. Decide right now what it is that you want your annual review to say next year and then take the steps necessary to make that happen. Keep in mind that your annual review typically reflects your reputation in addition to your technical work. The technical work takes care of itself but the reputation piece is one that you must actively work on.

Your reputation

Do you have any idea what your reputation at work is right now? If not, ask some colleagues that you trust to tell you how they view you as a coworker. Listen closely for adjectives because that’s what makes up your reputation. Then decide, is that a reputation that you want? Or is there one that would serve you better? What kind of a software engineer do you want to be known as?

Do you want to be known as the one who always shows up late and in a bad mood? Do you want to be known as the one who happily takes on complex problems? Do you want to be known as the one who smells badly? All of these things are within your control. You can create the reputation that you want for yourself, it just takes a little bit of planning. Everyone has a professional reputation but not everyone takes the steps to actively evolve that reputation. And believe it or not, as you get more experienced, your reputation starts to matter even more than your actual work.

If you stop and think about it, writing code is something that a lot of people do. You can hire someone cheaply out of college to write code and it may not be as good as an experienced software engineer, but if it’s close enough, that’s usually all you need. So if your programming acumen is the only thing that you focus on, you aren’t improving your position in the company. What matters far more are the soft skills that you have along the way. Do people enjoy working with you? Do you add something over and above your coding skill?

An example

The last time I stopped and thought about the kind of software engineer I wanted to be known as, I came up with a list of things that I wanted people to say about me on my annual review. These things reflected not necessarily what I was already doing, but what I would aspire to do in the next year. The things I wanted people to say about me on my annual review were:

• Nicholas is fun to work with.
• Nicholas cares about the career development of his peers.
• I trust Nicholas to work on important projects.
• If Nicholas is working on something, I know that it will get done correctly.
• Nicholas is capable of learning new things quickly.

This is just a sampling of some of the things I wanted to see on my annual review at different points in time. Note that they all have to do with how others perceive me rather than the quality of the code that I wrote.

Next steps

Once you decide what you’d like to see on your annual review, the next step is to figure out how to make that happen. This is a little bit more difficult than other task-oriented goals because it relies on the opinions of other people. That being said, it’s certainly not impossible. You just need to stop and think about how your actions affect how other people see you.

Take the example of being fun to work with. Why would people say that about you? Well first and foremost, you have to be reliable. That means showing up on time, completing tasks that are assigned to you, and being a good team member. It’s not fun to work with someone who is unreliable. Assuming that you are reliable, then “fun” is achieved by having good relationships with those on your team. That means talking about things other than work, getting to know people outside of the code they write in the job that they do. It could also mean that you’re the one who starts Nerf gun wars or helps to plan team activities. The bottom line is that people enjoy working directly with you and would welcome the chance to do it again in the future.

You can take all of your reputation goals and break them down in that way. Almost all of them are reflections on how you interact with other people. As you go through the year, keep an eye out for interactions that run counter to your goals or strengthen them. For example, if you got into an argument with a colleague, how did that argument resolve? Did you both end up feeling resentful and not wanting to work with the other person? Or were you able to reach an understanding that was mutually beneficial? Any time and interaction doesn’t quite go smoothly, that’s a good time to review your reputation goals and see how that interaction affects them.

Conclusion

Your reputation as a software engineer matters. It’s something that you should actively seek to develop throughout your career because that’s what sets you apart from everyone else who can write the same code that you do. As you get more experienced, your reputation matters more and more, and can be the reason that you either get or miss out on new opportunities. As software engineers, we spend so much time thinking about code that we often neglect personal relationships with our colleagues. Yet our colleagues are the ones who contribute to our annual reviews and ultimately to our success. Watch your interactions with others, try to establish personal relationships with people, and frequently review your reputation goals to see if you’re on track. Hopefully at this time next year, your annual review won’t be such a big surprise.

As so many startup founders know, the path to success consists of unexpected twists and turns, and rarely does anything go the way you plan. And so 18 months after I planned on consulting for 3 months, I was still consulting. The funding hadn’t materialized. It was time to for some soul searching.

Truth be told, though I had fun consulting, it left me feeling unfulfilled. I’ve always enjoyed working on products and never enjoyed hypothetical benchmarking or problem solving. I’ve always loved learning something really cool while working on a product and then sharing that information with the world. That’s what I enjoyed most about working at Yahoo, and I knew that was something I wanted again.

Also, I’ve discovered that my writing and speaking is incredibly important to me. These are more than just adjunct things I do from time to time, they are a vital driving force in my life. I love learning and I love teaching what I’ve learned to others.

Through a series of random interactions, I came to have a conversation with Sam Schillace at Box. If his name looks familiar, it’s because he was part of the team that created Writely (ultimately sold to Google and went on to become Google Docs). We had a really good initial conversation and then several followups.

As so often happens, once you know and like someone at a company, you start to consider working there. I did my due diligence and, after chatting a bit more with Sam, decided that Box would be a good fit.

There were a lot of things that attracted me to Box. First, it’s a small but not tiny company. Before Yahoo, I worked at several companies around this size and always felt that to be my sweet spot. I like working in a place where I can get to know everyone and have a big impact. Second, the company is growing like crazy, so there is a lot of interesting work to do.

But most of all, I’m excited about helping to define and grow a culture of front-end engineering excellence at Box. I’ll be working internally to make Box a hub of great front-end engineering practices and will continue to write and give talks (both related directly to Box and not).

I’m looking forward to this next step in my career and in working with a great group of engineers to make an already kickass product even better. In the short term, I may be a bit quieter than usual as I try to get up to speed at work, but long term you can still expect me to share my thoughts on a regular basis.

For now, I’ve got work to do.

ARIA roles

If you want screen reader users to be aware that a dialog has popped up, then you’ll need to learn a little bit about Accessible Rich Internet Applications (ARIA) roles. ARIA^[1] roles supply additional semantic meaning to HTML elements that allow browsers to communicate with screen readers in a more descriptive way. There are a large number of roles that alter the way screen readers perceive different elements on the page. When it comes to dialogs, there are two of interest: dialog and alertdialog.

In most cases, dialog is the role to use. By setting this as the value of the role attribute on an element, you are informing the browser that the purpose of the element is as a dialog box.

<div id="my-dialog" role="dialog">
    <-- Your dialog code here -->
</div>

When an element with a role of dialog is made visible, the browser tells the screen reader that a new dialog has been opened. That lets the screen reader user recognize that they are no longer in the regular flow of the page.

Dialogs are also expected to have labels. You can specify a label using either the aria-label attribute to indicate the label text or the aria-labelledby attribute to indicate the ID of the element that contains the label. Here are a couple of examples:

<div id="my-dialog" role="dialog" aria-label="New Message">
    <-- Your dialog code here -->
</div>

<div id="my-dialog" role="dialog" aria-labelledby="dialog-title">
    <h3 id="dialog-title">New Message</h3>
    <-- Your dialog code here -->
</div>

In the first example, the aria-label attribute is used to specify a label that is only used by screen readers. You would want to do this when there is no visual label for the dialog. In the second example, the aria-labelledby attribute is used to specify the ID of the element containing the dialog label. Since the dialog has a visual label, it makes sense to reuse that information rather than duplicate it. Screen readers announce the dialog label when the dialog is displayed.

The role of alertdialog is a specialized type of dialog that is designed to get a user’s attention. Think of this as a confirmation dialog when you try to delete something. An alertdialog has very little interactivity. It’s primary purpose is to get the user’s attention so that an action is performed. Compare that to a dialog, which may be an area for the user to enter information, such as writing a new e-mail or instant message.

When an alertdialog is displayed, screen readers look for a description to read. It’s recommended to use the aria-describedby element to specify which text should be read. Similar to aria-labelledby, this attribute is the ID of an element containing the content to read. If aria-describedby is omitted, then the screen reader will attempt to figure out which text represents the description and will often choose the first piece of text content in the element. Here’s an example:

<div id="my-dialog" role="alertdialog" aria-describedby="dialog-desc">
    <p id="dialog-desc">Are you sure you want to delete this message?</p>
    <-- Your dialog code here -->
</div>

This example uses an element to contain the description. Doing so ensures that the correct text will be read when the dialog is displayed.

Even if you omit the extra attributes and just use the appropriate role for your dialogs, the accessibility of the application improves tremendously.

Setting focus to the dialog

The next part of creating an accessible dialog is to manage focus. When a dialog is displayed, the focus should be placed inside of the dialog so users can continue to navigate with the keyboard. Exactly where inside the dialogue focus is set depends largely on the purpose of the dialogue itself. If you have a confirmation dialog with one button to continue in one button to cancel then you may want the default focus to be on the cancel button. If you have a dialog where the user is supposed to enter text, then you may want the focus to be on the text box by default. If you can’t figure out where to set focus, then a good starting point is to set focus to the element representing the dialog.

Since most of the time you will be using a <div> element to represent a dialog, you can’t set focus to it by default. Instead, you’ll need to enable focus on that element by setting the tabIndex property to -1. This allows you to set focus to the element using JavaScript but doesn’t insert the element into the normal tab order. That means users won’t be able to press tab to set focus to the dialog. You can either do this directly in HTML or in JavaScript. For HTML:

<div id="my-dialog" role="dialog" tabindex="-1" aria-labelledby="dialog-title">
    <h3 id="dialog-title">New Message</h3>
    <-- Your dialog code here -->
</div>

For JavaScript:

var div = document.getElementById("my-dialog");
div.tabIndex = -1;
div.focus();

Once tabIndex is set to -1, you can call focus() on the element just like any other focusable element. Then the user is able to press tab to navigate within the dialog.

Trapping focus

Another accessibility issue with dialogs is making sure that focus doesn’t go back outside of the dialog. In many cases, a dialog is considered to be modal and therefore focus shouldn’t be able to escape the dialog. That the dialog is open and pressing tab ends up setting focus behind the dialogue then it’s incredibly difficult for a keyboard user to get back to the dialogue. So, it’s best to prevent that from happening by using a little bit of JavaScript.

The basic idea behind this technique is to use event capturing to listen for the focus event, a technique popularized by Peter-Paul Koch^[2] and now in use by most JavaScript libraries. Since focus doesn’t bubble, you can’t capture it on that side of the event flow. Instead, you can intercept all focus events on the page by using event capturing. Then, you need only determine if the element that received focus is in the dialog or not. If not, set the focus back to the dialog. The code is pretty simple:

document.addEventListener("focus", function(event) {

    var dialog = document.getElementById("my-dialog");

    if (dialogOpen && !dialog.contains(event.target)) {
        event.stopPropagation();
        dialog.focus();
    }

}, true);

This code listens for the focus event on the document so as to intercept all such events before the target element receives them. Assume a dialogOpen variable is set to true when the dialog is open. When a focus event occurs, this function traps the event and checks to see if the dialog is open, and if so, if the element receiving focus is within the dialog. If both conditions are met, then focus is set back to the dialog. This has the effect of looping focus around from the bottom of the dialogue back to the top. The result is that you can’t tab out of the dialog and so it’s a lot harder for a keyboard user to get lost.

If you are using a JavaScript library, chances are that it has a way of delegating the focus event in such a way that you can achieve this same effect. If you need to support Internet Explorer 8 and earlier without a JavaScript library, then use the focusin event instead.

Restoring focus

The last part of the focus puzzle with dialog has to do with restoring focus to the main part of the page when the dialog is closed. The idea is simple: in order to open the dialog, the user probably activated a link or a button. The focus then shifted into the dialog, where the user accomplish some task and then dismissed the dialog. The focus should move back to the link or button that was clicked to open the dialog so that it’s possible to continue navigating the page. This is an often overlooked aspect of dialog in web applications, but it makes a huge difference.

As with the other sections, this requires very little code to work. All browsers support document.activeElement, which is the element that currently has focus. All you need to do is query this value before showing the dialog and then set focus back to that element when the dialog is closed. For example:

var lastFocus = document.activeElement,
    dialog = document.getElementById("my-dialog");

dialog.className = "show";
dialog.focus();

The important part of this code is that it keeps track of the last focused element. That way, all you need to do when the dialog is closed is to set focus back to it:

lastFocus.focus()

In total, this adds to very short lines of code to what you probably have already for your dialog.

Exiting the dialog

The very last piece of the puzzle is to allow the user a quick and easy way to exit the dialog. The best way is to have the Esc key close the dialog. This is the way dialogs work in desktop applications and so it’s very familiar to users. Just listen for the Esc key to be pressed and then exit the dialog, such as:

document.addEventListener("keydown", function(event) {
    if (dialogOpen && event.keyCode == 27) {
        // close the dialog
    }
}, true);

The keyCode value for the Esc key is 27, so you need only look for that during the keydown event. Once received, close the dialog and set focus back to the previously focused element.

Conclusion

As I hope is obvious from this post, it really doesn’t take a lot of extra code to create a dialog that is easily accessible both by screen readers and those who use only a keyboard. For just a few lines of code you can take your users from being incredibly frustrated to being incredibly happy. There are a lot of web applications out there that use pop-up dialogs but very few get all of these pieces correct. Going halfway leads to more frustration than anything else, so I hope this post has inspired you to make your dialogs as accessible as possible.

References

1. WAI-ARIA (W3C)
2. Delegating the focus and blur events by Peter-Paul Koch (Quirksmode)

Online dating

Online dating is basically about supply and demand. There is a supply of single people and they are in demand by other single people. Fair or not, this is frequently set up as women being the supply and the men being the demand. This plays out in real life just as much as an online dating where women get into clubs for free and men have to pay. Men want to go where the women are and so getting the women there first is important.

This was a rude awakening for me the first time I tried online dating. I had been encouraged by a couple of my female friends to sign up and they virtually guaranteed I would be going out on dates immediately. So I filled out my profile and sat back and waited for the e-mails to start flowing in. After a week, without receiving a single e-mail, I wondered what was wrong. After all, they just signed up and immediately were getting 20 or more messages a day. But me? Nothing.

Putting discussions about my desirability or lack thereof aside, what they and I failed to realize is that online dating is a very different experience for men and women. Assuming that a man and a woman are roughly equally attractive and have the same personality, the woman will be contacted far more frequently than the man. In fact, I’ve heard numerous times from female friends that the day they sign up their inbox is flooded with messages. And no matter how many times I’ve tried online dating (handful over the past decade), I can go months without receiving a single message. Why is it that women don’t contact men as much?

The problem is that there is little incentive for women to search for and communicate with men. The demand is coming right to their front door. Surely there is someone worthwhile in the dozens of e-mails waiting in their inbox. Why search for more candidates when resumes are being hand-delivered to you?

Men, on the other hand, have little hope of meeting anyone without actively searching and contacting women. As a man on a dating site, if you sit by and wait for somebody to contact you, you may find weekend after weekend completely free. Additionally, once you do decide to contact women, your message is just one of the dozens that they’re going to see.

Recruiters on LinkedIn are like the men on online dating sites. They are hoping to meet someone to fill a position, and there are a lot of candidates out there. They need to search for and contact potential candidates in the hopes of getting a response. The problem is made a bit more difficult than online dating because not everyone on LinkedIn is actually looking for a job. Despite that difference, the question is the same: How do you make your message stand out from all the others?

Strategies

Men use several strategies for trying to get women to notice and respond to them online. From my female friends, I verified that these are generally the type of messages that they receive. On LinkedIn, if you aren’t a recruiter then you are the supply (equivalent of the women on an online dating site), so I am actually receiving the type of messages that I imagine women receive on dating sites. The thing I find interesting is that many of the dating site techniques are duplicated by recruiters on LinkedIn. See if any of these sound familiar.

Copy-paste

The first is the least amount of effort and also yields the worst return: sending the same message to everyone. You just come up with a really good message that you literally copy and paste into every message that you send to every girl. The plus side of this approach is that you’re not investing a lot of time and effort into an activity that has a very low rate of return. On the minus side is the fact that generic messages will generally get a lower response rate than personal ones, so the onus is on you to contact much more women in order to make up for that.

Messages of this nature look like the following:

Hi there,

I came across your profile and think we would be a great match! I love to surf and go camping, and I think that we would have a lot of fun together. Hope to hear from you soon.

The message seems nice enough but you’ll note that there is nothing personal about it at all. First, you obviously found the profile otherwise you wouldn’t be able to send a message, so that doesn’t really tell you anything. Of course the fact that you’re writing indicates that you think there is a match. There goes the entire first sentence. The next sentence is just about you and doesn’t really reveal much. The last sentence is just a way to wrap up the message.

This is also a favorite tool of recruiters. Since LinkedIn fills in the name of the person being contacted, there typically isn’t a generic greeting as there would be on an online dating site. Still, the basic pattern is the same. Here’s an actual message I received on LinkedIn from a recruiter:

Hi Nicholas C.,

Our team has reviewed your profile and are very impressed by your skills and experience.

We are working on emerging technologies for our next generation products at [redacted]. We are located in the heart of Palo Alto, CA. Amazing offices, super smart people and financially well funded.

Would you be open to speaking with us?

Thank you in advance for your kind reply.

If you look closely, this is almost the exact same e-mail tailored to a professional environment. There is absolutely nothing about the message that is specific to me, my skills, or my experience. Here’s another:

Nicholas C.,

I was reading through your background and I wanted to get in touch. I have two opportunities – one in Palo Alto and one in San Mateo that seem like you would be a fit for. Can you let me know if you are interested in hearing about new opportunities and when might be a good time to chat?

I’m not even convinced this person has any idea what I do let alone what I would like to do for my next job.

Half-hearted

The half-hearted approach is an evolution of copy-paste. Instead of sending the exact same message to everyone, you just change the first line to be more specific to that person. The entire rest of the message is the same for everybody, so you’re not putting in a lot of extra effort, and changing the first sentence (the first one that someone reads) may be enough to get them to read the rest.

Messages using this approach tend to look like this:

Hi SmartGirl456,

I love the hat in your profile picture, very cool. I love to surf and go camping, and I think that we would have a lot of fun together. Hope to hear from you soon.

So the greeting is personalized and the first sentence is plausibly personal. The rest of the message is completely generic and obviously the person who wrote it didn’t want to put much effort into it. Instead of following up with another sentence about hats, the message digresses back into generic boilerplate.

Here’s an actual message I received on LinkedIn:

Hi Nicholas C.,

I saw your profile and I thought you may be interested in a full time Web Performance Engineer Opening we have in our San-Mateo office.
This position will offer the opportunity to work on software that runs one of the largest distributed systems in the world. You will be an integral part of our aggressive growth strategy for creating highly inventive technology solutions for our customers, driving more and more traffic on the Internet. If you want to work on technology problems that are interesting and challenging, then this is the role for you.

Please let me know if you are interested in discussing this opportunity in more detail.

This is a little bit better. The first sentence at least indicates that this recruiter did a cursory examination of my profile. I do talk about Web performance on my profile, so that first sentence is actually relevant to me. The rest of the message is definitely impersonal and just pasted in. As with the purely copy-paste approach, this one leaves me feeling like the recruiter probably sends a very similar e-mail to dozens of people. Here’s another:

Nicholas –

Just stumbled on your profile and will first say … this message is indeed intended to recruit YOU! I tend to be direct …

I work with Tier-1 VCs and early stage startups and I’m working with a company in SF that needs a Lead guy like you. They are a great story … almost profitable and only round of funding. They are going into a major growth phase and need top talent.

Environment is Python, but they don’t require that experience, even for a lead. They also need JS/HTML5/CSS3 and good, solid *people* on the team.

You interested in discussing?

The relevant part of this message is the first sentence. I put on my LinkedIn profile that I only want to be contacted by recruiters that are interested in me specifically (and not me or someone I know – covered later in this post). So he put a personal first sentence and then copied and pasted the rest. There’s nothing about the rest of the message that’s unique to me at all.

Information blast

This approach encapsulates the attitude that the more you know about me, the more you will like me. So instead of mentioning much about the person you’re contacting, the approach is to give you a ton of information about the person writing the message. These e-mails tend to be a little bit longer as they act like many profiles. Here’s an example:

Hi there,

Have you found that special someone yet? I haven’t yet, but I think we might be a good match. I am a recent graduate from business school who just moved to the area from the East Coast. I have a good job and make a good salary. I worked very hard and so when I’m not at work I like to blow off some steam. I love all outdoor sports but don’t mind staying in for a quiet evening either.

I noticed you also like outdoor sports, so I think we would have a good time together. If that sounds interesting to you, that I look forward to speaking with you.

Well, the person who wrote this message gets high grades for proper grammar and spelling, but not much else. This is probably duplicate information from the person’s profile which, if the woman was interested, she would probably go and read it anyway. Even though there’s nothing personal in this message, it has a personal feel to it because the writer is revealing information about himself. The last paragraph is a little bit personal because it mentions something from her profile. However, the likelihood that she got through everything about you (which looks boilerplate) just to get to the one sentence that indicates you’re writing to her specifically is pretty slim.

Here’s one from LinkedIn:

Hi Nicholas C.,

I came across your profile while looking for folks interested in web development. My name is [redacted] and I’m part of the early team at [redacted], a funded startup in Berkeley.

We’re a team of mostly engineers building a discovery service that connects people with entertainment, people and products that appeal specifically to them. Our early tests have been very positive, and we’re gearing up for a product launch this summer.

We recently raised a new round of funding, and we’re growing quickly. Our engineering team has a strong passion for building great software, and based on your experience with Yahoo and your book for Wiley I thought you might be interested in hearing more about our team and opportunities for web development roles.

Please let me know if you’re up for chatting sometime about [redacted].

So I get blasted with information about a company I’ve never heard of before. There is a sentence in the third paragraph that is specific to me and my background, but I never got to that paragraph because the first two were just a blast of information about the company. Here’s another:

Dear Nicholas C.,

You are 3 steps from working at [redacted]! Our recruiting process is “fast” just like our [redacted] [URL redacted] check out our products, email me your resume, and let me know which ONE position fits best, when you can begin working onsite in San Francisco OR Sunnyvale, what is your ability to work legally for any employer in the USA, name several times over the next couple of working days when you can be in a quiet place for a 15 minute conversation with me, I will confirm one time via email to confirm

Our Research & Development team is seeking talented system software developers ALL LEVELS, who are strong in C OR C++ OR Python. We are a Linux / Open Source environment and need programmers to create and support new version one products for the cloud.

This one is a real gem. Not only is there nothing about me personally in this message, but I’m blasted with all kinds of information about the company and the recruiting process and then I’m given a long list of things to do. There’s nothing in this message that even indicates the recruiter read my profile or has any idea what I do.

Once again, if the recipient of the message either on a dating site or on LinkedIn doesn’t feel like you were contacting them specifically, you will likely never hear back.

Or someone you know

This is actually one that doesn’t happen on online dating sites but does happen on LinkedIn quite frequently. The reason it doesn’t happen on dating sites is that everyone knows this isn’t the way to get a date. The approach is to act coy as if you’re not interested in the person who you contacted but rather somebody that they might know. Just to show you how silly this is, here’s what I imagine a message to a woman on a dating site would look like using this approach:

Hi SmartGirl456,

I’m looking for a date this weekend and I was wondering if you or someone you know might want to go out with me? Even if you aren’t interested, judging by your profile, you probably know some other women who are. Can’t wait to hear back from you.

It would be completely preposterous for a man to contact a woman with such a message. Yet, this is incredibly commonplace on LinkedIn. Here’s one that I received:

Hi Nicholas,

I am looking to expand our social web development team at [redacted] and was wondering whether you or someone you may know would be interested in full time or consulting gigs?

I always suspect that this is a passive aggressive way of asking if I would be interested in the job. As if I would say, “Actually, why do you want to speak to my friends? I’m the one that you want!” Here’s another:

Hello,

I am reaching out to obviously [sic] for your specific background or if anyone you may know may be interested in 2 great opportunities here in San Francisco. My company, [redacted], is looking for a Sr. PHP Developer/Front End Engineer and UI/UX Designer Developer for a well funded Green/Sustainable emerging technology company for the [redacted]. Please contact me directly or via email. I will of course share all the details and job descriptions with you. They are looking to meet immediately. Best regards for your help.

This is one of the most insulting type of messages that I’ve received on LinkedIn. If I ever see “or someone you know” in the message, I delete it immediately. I honestly can’t believe recruiters think that would work.

Harassment

Any guy who has spent any amount of time on an online dating site learns pretty quickly that you don’t get anywhere by e-mailing a woman multiple times. If you e-mail once and she doesn’t respond, you don’t send another e-mail asking if she got the previous one. Yes, she got the previous one and she wasn’t interested, so let it go. Yes, it’s personal, she doesn’t like you. She also doesn’t know you, so who really cares? If you’re a man on an online dating site, you must accept that this form of passive rejection will happen frequently. You only solidify that you’re not someone she’s interested in by continuing to pester her.

This is a lesson that recruiters don’t seem to get. When you continue to contact someone who isn’t interested in talking to you, that’s harassment. I can’t tell you how many times I have deleted an e-mail that a recruiter sends only to get a follow-up e-mail in two days asking if I got the previous e-mail. In some cases, I even have received a third e-mail asking if I got the previous two.

I know that in some delusional minds, this might come off as being complementary. Boy, this person thought enough of me to e-mail a second or third time! They must really be interested! But the opposite is true. It tells me that you have no respect for me or my time.

Whether you’re on a dating site or on LinkedIn, if you contact someone and they don’t respond, chances are it’s not because they just didn’t see your message. You are rejected, let it go.

What works?

So after all of that, what actually works? In my various attempts at online dating, the best results that I’ve ever had were with short, personal messages that showed I had actually read through her profile. The most important thing is I made the messages about her and not about me. If she’s interested in me after reading it, she can always go to my profile. So messages such as this tend to go over better:

Hi SmartGirl456,

I love that picture of you at Fenway Park! I’m also from Boston, so I know that this can seem like a strange alternate dimension where sports doesn’t matter so much. Are you still loyal to the hometown favorites even after seven years?

Just about the only mention of me is that I’m also from Boston and that’s just to provide some context for the next couple of sentences. The message might seem simplistic, but it’s intensely personal and about her. Every sentence is related to her in some way in the entire message shows that I actually read your profile. I saw her photo and identified where it was taken, I noticed that she was from Boston, and I also noticed that she has been in California for seven years. In short, I approached her as someone who’s interested in learning more about her to see if we are a match rather than trying to get her to know more about me to see if we’re a match.

While I haven’t received a lot of messages that fit this mold, here’s one that comes close:

Hi Nicholas C.,

[redacted] is looking for a hands on development manager to lead a team of talented software engineers building a cutting edge, fast and interactive Web application that incorporates the best user experience patterns and technologies available.

As I reviewed your profile it appeared to me that you are particularly suited to define and implement a next generation UI architecture while ensuring continued functionality of the existing system.

I would welcome the opportunity to speak with you soon to discuss the possibility of your joining our team.

You can reach me at [redacted] at any time to get the ball rolling or by emailing me at [redacted]

While I think the first paragraph isn’t all that necessary, the second paragraph is really good. It could be tightened up (obviously I know you looked over my profile) but has some really good parts to it. The recruiter clearly you read my profile and understands what’s important to me. He then explained how I could do that at the company and left it at that. Short, to the point, and personal. If I were actually looking for a job, I would consider replying to this type of message.

Notice that I said I would consider replying to this type of message, not that I would. Whether or not I actually respond has to do with what’s going on in my life. Do I have any better opportunities that I’m exploring right now? Do I think the commute is something I can live with? Do I think this is a company I would be happy working for? Writing a good, respectful message gets you into the “maybe” pile, just like it does on an online dating site.

If you are a recruiter, here are a bunch of tips that will get you into the “maybe” pile:

• Start by talking about me. I don’t really care who you are, you’re obviously a recruiter for the company that shows up on your profile. Say something that makes me realize you actually read my profile and understand what I do. Something like, “I noticed you have an expertise in web interface architecture, and that’s something [company name] has a need for right now.”
• Tell me a little about the position. One or two sentences about the position, where it’s located, what their responsibilities are, and how I would be making an impact. That’s about all I need to know to figure out if I have any interest.
• Provide links about the company and position. Rather than pasting in boilerplate information to a message, just provide links to the extra information. If you did a good job describing the positions distinctively, I want to go and read a longer job description as well as read more about the company.
• Your contact info. Give me your e-mail address to contact you if I’m interested. I will not be calling you on the phone so there’s no need to include your phone number.

Just like a message on an online dating site, the goal isn’t to close the deal. The goal is to get the other person interested enough to want to learn more. Keep your messages short and to the point and make sure that they are personal. It takes a little more time than the other approaches, but you will get a much higher rate of return this way.

I know that there are really good recruiters out there, because I’m friends with some of them. The problem is that there are so many bad ones that the good ones end up being looped in with them. If you are a recruiter reading this, please take this as advice to help improve yourself. I would much rather get relevant, respectful messages from recruiters even if I’m not interested at the time then continue to get disrespectful, lazy messages that make me want to never read anything I receive through LinkedIn again.

Unfortunately, sometimes web developers try to get a bit too clever in creating their interfaces. What if I want something to look like a link but act like a button? Then you end up seeing a lot of code that looks like this:

<a href="#" onclick="doSomething()">I'm a button</a>

That code should turn your stomach a little bit. It’s a link that goes nowhere and does nothing. All it does is attach an onclick event handler to give it a purpose. Because the desired appearance for this element currently is link-like, the markup uses a link and JavaScript.

Those who are familiar with ARIA may “fix” the problem by using the following:

<a href="#" role="button" onclick="doSomething()">I'm a button</a>

By setting the ARIA role to button, you’re now telling the browser and screen readers that this link should be interpreted as a button (that does an action on the page) rather than a link (that navigates you away). This has the same problem as the previous code except that you’re trying to trick the browser into treating the link as if it were a button. In reality, it would be most appropriate to just use button:

<button onclick="doSomething()">I'm a button</button>

The markup to use should never be based on the appearance of a UI element. Instead, you should try to figure out the real purpose of that element and use the appropriate markup. You can always style button to look like a link or a link to look like a button, but those are purely visual distinctions that don’t change the action.

If these were the worst sins of web applications that I have seen, I would be pretty happy. However, there is another even more disturbing trend that I’m seeing. Some Web applications are actually trying to create their own buttons by mixing and matching different parts of HTML, CSS, and JavaScript. Here’s an example:

<div tabindex="0" role="button" onclick="doSomething()">I'm a button</div>

This is a valiant attempt at creating a button out of a <div>. By setting the tabindex attribute, the developer has assured that keyboard users can navigate to it by using the tab key. The value of 0 adds the elements into the normal tab order so it can receive focus just like any other link or button without affecting the overall tabbing order. The role informs the browser and screen readers that this element should be treated as a button and the onclick describes the behavior of the button.

To anyone using a mouse, assuming the styling is correct, there is no distinction between this element and an actual button. You move the mouse over and click down and an action happens. If you’re using a keyboard, however, there is a subtle but important difference between this and a regular button: almost all browsers will not fire the click event when the element has focus and the enter key is pressed. Internet Explorer, Chrome, Firefox, and Safari all ignore the enter key in this situation (Opera is the only one that fires click).

The enter key fires the click event when used on links and buttons by default. If you try to create your own button, as in the previous example, the enter key has no effect and therefore the user cannot perform that action.

This horrible pattern is found most frequently in Google products. Perhaps the most ironic usage is in Gmail. When you press the ? key, a dialog pops up showing you available keyboard shortcuts and allowing you to enable more advanced shortcuts.

It looks like the word “Enable” is a link, so you press tab a few times to give it focus and press enter. Nothing happens. Why? Because the link is actually neither a linkage nor a button, it’s a <span>. Here’s the actual code:

<span id=":s7.pl" role="link" class="aoy" tabindex="1">Enable</span>

Almost exactly the problematic pattern mentioned earlier in this post. So basically in order to turn on keyboard shortcuts you need to be able to use a mouse. In fact, many of the buttons on Gmail are made in this way. If not for the keyboard shortcuts it would basically be unusable without a mouse.

Gmail isn’t the only Google site that uses this pattern. It can be found throughout the network of Google sites, including Google Groups and Google Analytics (which also hides focus rectangles). This alone makes Google products incredibly challenging to use for sighted users who don’t use pointing devices.

If you expect the user to interact with something, then you need to use either a link or button. These have the correct behaviors both in terms of getting focus and activating when the enter key is pressed. Links should be used whenever the action is a navigation (changes the URL) and buttons should be used for all other actions. You can easily styled these to create the visual effect that you want, but nothing can replace the accessibility of the native links and buttons.