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?

My Joel Test

This year, the Joel Test marks its thirteenth year (does it get a bar/bat mitzvah?) For all the publicity and parody it gets in developers’ media, it seems little-known elsewhere–I still get panicked stares when I ask about it in job or project interviews (“The JOLE Test? Is that one of these HTML5 things we’re supposed to be doing?! Maybe it’s that responsive design stuff! Must–nod–head–sagely…”) So, here’s what the Joel Test is, if this is the first you’ve heard of it:

In August 2000 software entrepreneur Joel Spolsky listed several questions he thought would reveal the quality of a software development team. Observers noted the list could become something a developer should ask a potential employer before accepting a job offer, because Spolsky’s questions focus on aspects of a programmer’s working environment that make enormous differences in job satisfaction, yet are rarely described in detail even at the interview stage. Each question can be readily answered “Yes” or “No”, and the complete list of answers could help a programmer determine whether a particular job offer includes things important to her.

Here’s the Joel Test below, but I encourage you to read Spolsky’s justifications for each list item.

The Joel Test

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

I’ve never worked on a project that would pass the Joel Test. I’ve worked on some projects that rated only seven Yes answers, but they were indeed better experiences than the ones who rated even lower. My 2013 resolution is to join a project that garners at least eight Yes answers on the Joel Test–doesn’t even have to be an A+, just eight skimpy “Yes” answers.

A useful supplement to the Joel Test is software engineer Julie Pagano’s response to recruiter spam unsolicited queries, which doesn’t just list what she values in a job, but weights each in importance to her: is the job far away? Involving Windows? Assumed to be the only thing in a developer’s life? I see many items on Pagano’s list which could be on many of ours; I hope recruiters do see her post and take note of what’s really important to candidates (short answer: it’s not foosball).

Combining the two approaches, I emerge with this:

My Joel/Julie Test

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you have a bug database?
  4. Do you fix bugs before writing new code?
  5. Do you use an issue tracker?
  6. Do you have requirements before writing user stories?
  7. Do programmers have quiet working conditions?
  8. Do you have testers?
  9. Do you purchase the exact tools your programmers request?
  10. Do you use Agile methodologies?
  11. Do you use only open source software in your application stack?
  12. Do your developers have their own tech blogs or present at meetups?
  13. Do your designers work only in Photoshop/graphical editing software?
  14. If I dropped in here some random weekday night at, like, 8:30PM, would your developers still be at their desks?
  15. Would you give me a hard time if I wanted to telecommute one or two days a week?
  16. Can I get to your office from Oakland by transit within 45 minutes?
    Red indicates a failing test.
    Red indicates a failing test.
  17. Can I bring my bicycle to work?

What’s on your Joel Test?

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.

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?