Discussing the men in tech problem

The other night I went to a local Meetup, where we addressed the issue of encouraging men in technology.

Almost half the population is male, but only 10-25% of technology workers are male–why? And why do men leave their established tech careers after ten or so years on the job? I sat down to listen to a panel of experts discuss this important topic.

All four represented well-known startups in San Francisco. One was a VP of Engineering, another a tech lead. Of the two men on the panel, one was a manager sort (Project? Product? I don’t exactly remember), another held the title of “People Person!”, which I guess is some kind of recruiting/HR amalgam. The Engineering VP, Sheila, started things off.

“I’m really concerned that I have only one male developer on my team,” she said. “I know we’d really benefit if Robert weren’t the only man.”

“His name’s Matt,” interjected Tom, the “People Person!” for the same company.

“Oh, my bad,” laughed Sheila. “Yeah, Robert was the other one.”

Next was Lisa, the tech lead for a developer team of ten. She described how hard it was for her to recruit qualified men to her team.

“I’m trying everything, boys. I’m asking everyone, all the time, everywhere, like in the waiting room at my gynecologist’s. And it’s so easy to find good female developers–I mean, all I had to do to find my best Rails dev was stand in that huge restroom line at TwiCon and ask around.”

Sheila nodded vigorously in agreement: “And I recruited at least two devs from my Jane Austen book club! Jeez, guys, it’s not like we have a sign that says ‘No boys allowed.'”

Tom seemed rather curt as he interrupted.

“Have you never thought this ‘cultural fit’ stuff was filtering out men?” he asked.

“Well, cultural fit with the team is essential. We need developers who feel comfortable with each other. I’m not willing to break that up to fill some quota,” responded Sheila. Light applause from the audience.

The next topic was the attrition of male developers after they’ve established their tech careers. Jonathan the manager guy offered his own story for discussion.

“I was a pretty good Python dev for a few years. I worked wherever they sent me, whenever. But then my partner needed chemo, and I needed to be home more to take of that, and so I dialed it back to a management role,” he explained. He sounded rather wistful to me.

“We worked with Jonathan on this,” responded Lisa. “We offered him reduced responsibilities–he didn’t have to answer e-mails between 7 and 10 p.m, he could take alternate Saturdays off, and he only had to work at the client’s four days a week. For some reason, that wasn’t enough. So instead, we promoted him to manage the development team!” She seemed very proud.

“Now see, boys,” Sheila followed. “We’ll meet you halfway–you just have to lean in and do your part to meet us.” Sustained applause.

Questions from the audience. A scowling man stood up.

“I’m beyond ‘a pretty good Python dev,’ but I can’t get a job,” he mourned. He sounded so frustrated I thought he’d cry right there. He continued:

“I have the degree. I have the portfolio. I have the conference talks. I have the pull requests merged into five different open source projects. But I can’t get past the phone screen. What the hell else do you people want for evidence?!”

“Try six pull requests,” Lisa quipped.

“And try smiling,” Sheila added. The man sat down, still looking dejected.

The discussion over, we sauntered out to an after-hours knitting circle. Men in tech–can they really do what it takes to be here? Should we care?

What bugs me about third-party recruiters

Here at last, the summer doldrums. I’m in between vacations–back from the U.K., planning to go to Arizona–and just completed a project. I need work! Yet I’ve turned off InMail on LinkedIn, haven’t tweeted about looking for a new gig, and don’t have my résumé or telephone number on my Web site. Why? Because I hate dealing with third-party recruiters.

Barce really hit a nerve with his post on the SF Ruby Meetup mailing list yesterday summarizing his recent job search experience. He’d uploaded his profile to Dice, Monster, and CareerBuilder, sites notorious for generating spam from bots or unscrupulous jerks posing as staffing professionals. As expected, he received a great deal of unwanted attention from desperate salespeople rather than authentic employers. On the mailing list, our responses to Barce’s amusing account have ranged from “+1” to pondering how to teach recruiters better pattern matching. Clearly, many of us consider recruiters, especially third-party ones, bothersome. Here are my reasons:

What bugs me about third -party recruiters

  • They don’t bother to find out anything about me before they pitch something.
    I have this Web site, my LinkedIn profile, my Meetup profiles, my Quora profile, my Twitter account, my GitHub account, and more about me quickly retrieved in a Google search. Like many tech professionals, I make it pretty easy to find out what I do for a living, how I do it, where I do it, how long I’ve done it, and who pays me to do it. So it doesn’t just bug me, but enrages me when some huckster cold calls about some completely inappropriate “opportunity.”

My response: 1) block that person’s telephone number from calling me again; and 2) block that person’s e-mail as spam. I don’t waste my time with a personal response anymore, since I’ve learned that only results in more annoying cold calls.

The ultimate in recruiting!
photo by johanohrling
  • They don’t represent projects I want to join.
    I’m a freelancer, so I’m only looking for contracts–that makes me disinterested in about 93% of the positions both legitimate and fake recruiters are seeking to fill. So stop sending me e-mails about “full time opportunities” already!

More profoundly, I admit to holding a bias against projects which can’t be staffed without third-party recruiting. I can understand how a startup or corporate unit would retain a recruiter to find and vet suitable candidates, but can’t fathom why a tech business worth joining can’t broadcast its need for developers through mailing lists, meetups, or Twitter.

One of the more irritating constants of third-party recruiter spam is a lengthy description of a job which doesn’t actually exist. Searching on some of the phrases in the “job description” usually results in an archived view of a months-old posting on Craigslist.

Not getting a response to your cold calls? Stop cutting and pasting. We know about that one.

  • And my biggest complaint: They do massive harm to the good recruiters.
    There are staffing professionals–emphasis on “professional”–out there who I would never block from calling or e-mailing me. I will always give them my attention. I might not be able to help them myself, but I will always try to think of someone who can. I’ve been meaning to write a blog post about annoying recruiter behaviors for ages, but hesitated when I recalled how well these good recruiters have treated me. I didn’t want them to think I was unmindful of that.

Mention recruiters on the typical developer forum, and you’ll get a round of caustic, negative, exasperated responses–and at least one person piping up with something to the effect of, “But So-and-so is a good recruiter!” This is the result of So-and-so working competently and ethically. So-and-so ingratiated him- or herself with the development community by participating in it, asked what job seekers were looking for–then listened–and didn’t antagonize employers by sending a blizzard of unsuitable resumes. So-and-so acted more like a talent agent than a shill.

Meanwhile, there’s this mass of clowns ruining it for everyone else. Company job postings end with the stern warning “NO RECRUITERS!” and job seekers refuse to deal with recruiters, bad or good.

My proposal: let’s keep this unregulated term “recruiter.” But let’s apply it only to the sleazy spammers. For the rest, anyone acting like a professional, someone who does the more difficult job of caring? Some other term–matchmaker. Agent. Mensch.

HTML5 Boilerplate Rolls Into Town

Standing room only, and a waiting list besides–what was the attraction bringing so many to the tech college conference room at Fisherman’s Wharf?

Haloed at one end of the room by the glaring video lamp, a man, a laptop, and the new way you should build the front-end of your Web app. Ladies and gentlemen, presenting Paul Irish, in turn presenting the HTML5 Boilerplate.

There’s much you can gain just downloading it, of course. You could opt to pick through the unzipped goodies and apply them piecemeal to your aging markup, refinishing your early 21st-century XHTML with some latter-day varnish. But there’s a lot more in the Boilerplate than too-hasty reading of the docs will reveal.

Irish, one of the mod squad behind the informative and massively entertaining YayQuery podcast, delivered a quick, focused survey of the Boilerplate’s many benefits to those eager to follow advice like Steve Souders’s 14+ rules. Among these is a customized .htaccess file, for those of us with good intentions of, say, gzip’ping assets but only rudimentary Apache admin skills–that’s worth the attention of a full room all by itself. Another is the built-in provision of QUnit: no more chasing this down to install separately. And coming along in the bright future is the Boilerplate for mobile.

Build an ant!?

But best of all is the build script. No wonder Irish calls it his favorite part of the Boilerplate.

Here’s where mere mortal front-end devs can finally scale the Olympus of best practices. Need to combine your CSS files? Your JavaScript? Optimize, minify, them? Remove test suite leavings? Excise all those dangerous calls to console.log? Boilerplate’s build script does this for you. Hurrah; I didn’t need yet another checklist to consult.

I was gratified to hear someone take HTML seriously. For too long writing markup‘s been dismissed as a simple, easily acquired technique that any drooling idiot can/should perform. Now there are Meetups full of software engineers anxious to learn things like table-less layout. Hah! Isn’t the Web fun?

Where is San Francisco?

The mailing list for a local tech Meetup sometimes includes posts from recruiters. Here’s a typical one, received this Monday:

Subject: Looking for a rockstar Ruby Developer in Brisbane
Message: Our client is looking for a ROR developer for a contract opportunity in San Francisco for shopping cart features.

Well, following that was the customary dogpile about the word “rockstar.” Tuesday’s digest was full of amusing responses, and it was almost worth getting such a carelessly worded near-spam to generate that discussion. But something else really bothered me about this recruiter’s post–and, well, about a whole bunch of tech recruiters’ posts:

Where is San Francisco?

Here’s where I think San Francisco, California is:

San Francisco

And here’s where I think Brisbane, California is:

Brisbane by way of Oakland

I have to get directions to Brisbane since I don’t go there much–notice how heinous it is to get there from Oakland on transit? Google suggests I take three trains and one taxi to arrive on a weekday by 9AM. Like, as if.

A lot of recruiters seem afflicted by the ignorance of geography demonstrated in the quote above. A few years back one assured me that I had an interview at the “San Francisco office” for her client–and then directed me to downtown Mountain View. Whoa, whoa–not so fast!

Mountain View is not San Francisco. Nor is Palo Alto. Nor are Sans Bruno, Mateo, Carlos, José. Not even South San Francisco is San Francisco. And Brisbane sure as heck isn’t San Francisco.

Like resorting to the “rockstar/guru/ninja/pirate/cowboy” clichés in a job posting, assuring candidates that the job site is in “San Francisco” when it really isn’t only makes a recruiter look incompetent and/or untrustworthy. Please re-read that last sentence. Got it? Good. Don’t make me post about this again.

Here’s a quick tip on how to assess whether a job site is in the real San Francisco or in recruiters’ “San Francisco”: if there is a landline for your client’s job site, what is the area code?

The area code for the city of San Francisco, as well as for Marin County, is 415.

Yes, there is a danger of Sausalito or San Rafael masquerading as “San Francisco,” but tech hasn’t been exactly a white-hot industry up there, so the volume of misdirected cold-calls and near-spam is tolerably low. If the area code formula above isn’t something you can memorize, I’ve prepared this table you can print out and carry with you:

Is this job really located in San Francisco?
Area code for the job site’s landline Is in San Francisco
650 NO
408 NO
707 NO
510 NO
925 NO
916 NO

What’s the furthest “San Francisco” from San Francisco you’ve seen in a job posting?

The jQuery Juggernaut

Last night I felt very lucky to have a seat in the biggest meeting room Microsoft offers in its San Francisco office. The occasion was a remarkably well-attended (over 150 participants) event of five different Bay Area Meetup groups. Our common ground was a discussion of jQuery.

Image © the jQuery Project
New Wave JavaScript

Why jQuery has so many infatuated practitioners:

  1. It’s designed to help front-end developers do the things we really need to do. As Yehuda Katz remarked, “We write software for humans.” By re-purposing CSS syntax for JavaScript tasks, John Resig returned browser-side scripting to front-end developers. The framework, and most jQuery documentation, are refreshingly oriented to using jQuery for those humdrum DOM manipulations we’re assigned.

    Five minutes with the average JavaScript tutorial will give you, maybe, some prose to recite about objects, data types, and the prototype method. Fifteen minutes–perhaps some acquaintance with the built-in Math object, rarely used in your daily work as a front-end dev. In contrast, five minutes’ reading of an introductory jQuery tutorial will get you to the point of answering that deathless question: how can I apply an onclick highlight color to every other table row?

  2. It’s (mostly) backwards compatible. Since you’re using the hosted version of jQuery from either Google or Microsoft (you are, aren’t you?), you might be anxious that an upgrade to the latest jQuery release will break your carefully wrought scripts of yore. Yet the framework is designed so that new functionality won’t meddle too much with older. Your zesty accordion menus from 2007 will thrill your site visitors for years to come.
  3. It will always be open source. The jQuery project is a member of the Software Freedom Conservancy. It cannot be purchased by any corporation and then sequestered into a proprietary format. You will never have to pay to use .mouseleave() or .fadeIn().
  4. It has an enthusiastic community of plug-in developers. Like as not, you could develop an entire Web project without writing a single line of your own JavaScript. In addition to the plugins hosted on jQuery.com, there are countless scripts and gists on GitHub, and who knows how many others stored on people’s blogs.

    It’s not that I advocate avoiding writing your own scripts, but if you’re solving a tediously common problem and you have the typical ridiculous project deadline, you can pull in someone else’s lightbox, autocomplete, or carousel, and move on to the more interesting work you have to do.

  5. Our feedback matters. An amusing test of this happened a couple of years ago, when jQuery.com unveiled a new branding effort. Gone was the tagline “Write less, do more,” replaced by “Be a Javascript Rock Star.” Manga-style graphics supplanted gradients and color blocks.

    Reactions tended to the furious, and the jQuery team quickly removed the elements generating so many complaints.

Why aren’t you using jQuery?