Google, can we talk?

The following is an edited screenshot of my Google Account profile:

My Google account profile

Google, my dear, do you see all of those email addresses listed there? Each and every one of them was not only added to my profile by me, I also took the time to verify with you that each of them is really, honestly, and truly mine and that I wanted them associated with my Google account. You know they’re associated with my account. I know they’re associated with my account. We are in blessed agreement on this point.

Google, my love, you are amazing. You can take my search terms and return a billion results plus relevant advertisements in a blink of an eye. Truly, you are the pinnacle of data association and retrieval.

Google, my pet, so why is it when someone sends me a Google Docs invitation–to one of those emails which we agree are associated with my Google account, by the way–why is it you won’t allow me to access the doc despite my being logged into my Google account? Why are you incapable of performing the (as appears from your users’ perspective) relatively simple lookup to confirm that the address to which the invite was sent is in fact associated with the account which is logged in? Why can you not also do that in the blink of an eye?

Google, my beloved, you have had a very long time to fix this very irritating and, to be honest, quite large usability bug. What’s the hold up? Frankly, people are saying some rather unsavoury things about you. Things like, “Google is an advertising company, not a product company, and therefore it doesn’t care about its users or usability.” Is that true, Google?

Because Google, my sweet, it certainly seems that way from where I’m sitting.

Thanks for the talk. I hope it helped you, because you’re certainly not helping me right now.

Adding a Slack network to your znc IRC bouncer

Slack is taking the online world by storm. Most everyone I know in technology is a member of at least one Slack teams, and it’s not rare to find people who are a member of ten or more Slacks.

My personal opinion of Slack is indifference. It’s pretty much just IRC with a fancy new paint job. I love IRC, so that element of the Slack service appeals to me greatly. However…that paint job…no. There’s just too much going on there. Too many gifs. Too many emoji. It’s very distracting.

Add to that distraction the burden of having yet another damn chat client on my desktop. IRC, Hangouts, Skype, iMessage, Twitter… It’s just too much.

Thankfully, Slack offers an IRC gateway, allowing you to escape that loud and distracting paint job while you also reduce the number of chat clients you need open. You can either connect to Slack directly using your IRC client of choice or–if you want scrollback from when you’re offline–you can set it up on your IRC bouncer. The latter is the option I pursued. As it was rather a pain in the ass, I’ve captured the steps below so you don’t have to suffer the same headaches I did.

CAVEAT: I use znc as my bouncer (installed on a Digital Ocean droplet), the webadmin interface to znc for all admin tasks, and Textual on OS X for my IRC client. All information below is presented in the context of this software.

Setup on the znc side

  1. If they haven’t done so yet, please ask your Slack administrator/team owner to enable the IRC gateway.
  2. Once that’s done, access your account gateway page. It’s available at http://$TEAMNAME.slack.com/account/gateways. You’ll need this information for the next steps.
  3. Log into the znc web admin interface, edit the user which will be connecting to Slack, then click “Add” in the Network box. The full click path for this is Manage Users > Edit (next to selected user) > Add (in Network box).
  4. Most fields on the Add Network form are what you’d expect, but there are a couple of potential snags…
    • The network name must be alphanumeric and cannot contain any spaces. If you receive the following error, check the network name for invalid characters: "Invalid network name. It should be alphanumeric. Not to be confused with server name
    • The server address should be entered in the following format:
      $TEAMNAME.irc.slack.com +6667 $PASSWORD_FROM_GATEWAY_PAGE
      The + is important because it denotes that SSL should be used. Slack doesn’t allow unencrypted connections.
  5. That should be it. Save the form, then move on to setting up your IRC client.

Setup on the Textual (v5.0) side

  1. Open the interface for adding a new server: Server > Add Server
  2. Name the connection whatever makes most sense for you.
  3. Enter the address of your znc bouncer in the Server Address field.
  4. Check the “Connect Securely” box since, again, Slack doesn’t allow unencrypted connections.
  5. Enter your znc user password in the “Server Password” field.
  6. Select the “Identity” option (in the left side-bar in Textual v5.0).
  7. Enter your Slack nickname in the “Nickname” field.
  8. For “Username”, enter your znc username, a slash, then the Network Name you selected when adding the new network in znc: $USERNAME/$NETWORK_NAME
  9. For “Personal Password,” enter the password from the Slack account gateway page.
  10. Save the new server to the client.

Theoretically, you can now connect. The client will automatically find all of the channels to which you were already subscribed on Slack. You may need to tweak a few more options to make it suit your tastes, but the hard part is now done.

Program Like a Pixar Story Artist

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

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

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

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

Staff Quality Deserves the Same Care as Software Quality

The Wikipedia definition of Continuous Integration (aka CI):

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

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

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

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

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

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

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

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

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

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

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

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

Rant: I Am Not a Cat Herder

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

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

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

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

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

Technical Job Postings: Know Your Audience

Spotted in a job posting for a technical position:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Online Services I Find Worth Paying For

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

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

It’s Called Marketing for a Reason

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

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

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

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

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

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

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

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

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

Rethinking Education Requirements in Tech Job Postings

A few days ago I posted this tweet:

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

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

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

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

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

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

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

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

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

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

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