Archive for the ‘work’ Category

Sh*t People Say to Front-end Developers

Posted on: by mejarc 3 Comments
  1. We really don’t need a designer.
  2. What’s an information architect?
  3. Nobody will be looking at this page with a mobile device.
  4. This style guide from 2002 is still good.
  5. We really don’t need localization.
  6. This Excel spreadsheet is our issue tracker. Works great!
  7. Using Flash would make this so much easier!
  8. HTML5 is too risky and experimental.
  9. What’s a validator?
  10. Browser support? All of them, of course.
  11. We really don’t need a copywriter.
  12. Of course our users will sit through this thirty-second auto-play splash video.
  13. We really don’t need JavaScript testing.
  14. The database guy already did the HTML and CSS, so you just have to add a few tweaks.
  15. Of course our users will submit this twenty-question form before seeing our content.
  16. This will be a short project.

Letter to Gino Lee

Dear Gino,

I’d hoped the news was untrue. Surely it was unbelievable: how could you die? You were only forty-nine. You are only forty-nine–I’ll keep using the present tense. You’re still alive to me.

I have vivid memories of you from over ten years ago. There you are, apparently one of the last smokers in California, cupping a cigarette in your hand, trying to keep the wind tunnel outside the Metrius office on Brannan Street from killing your smoke, your characteristic, urbane, thin-man’s slouch a welcome profile in those garish, clumsy, overconfident, dot-com boom years. I remember your voice, deliberate, drawling, as you think aloud, treating every workday as one big Harvard grad seminar. I love the cultivated, wry tone of your e-mails and chat messages, proof that a keyboard doesn’t enforce simplistic language. Your one-line musing about the impact of the Rapture on the scrapbooking industry makes me laugh to this day.

I was too coarse to appreciate that we should’ve taken all the time in the world to talk, deadlines be damned. I know we disagreed when you seemed to think my staying late at the office was so that we could discuss Evelyn Waugh’s The Loved One . I profited from our acquaintance all the same.

From you I’ve learned that so much of our world can be made appealing. Your attitude towards the ugly and poorly designed isn’t snobbish condemnation, but gracious bewilderment: why use bad things? Why make them? You handled fountain pens in a world of dry erase markers.

But I and everybody saddened by this news have to let you go today, arm-in-arm with Miss Thanatogenous. I promise a longer conversation next time.

Tears,
Melanie

Stop arranging developers like the typing pool

A couple weeks into the project, and despite my access to the issue tracking system, the project wiki, and the code repository, I still felt uneasy–there was something I was missing, but since I didn’t know what that was, I couldn’t ask for it. Coffee? Water? Multiple monitors? Appealing snacks? Had all those. I stood above my workspace, and then figured it out:

We were seated all wrong.

All of us on the development team were placed into cubicles arranged into a herringbone pattern pointing to one side of the room. Our faces turned about 25° towards one other person. I became familiar with the backs of many of my co-workers’ heads, since that’s much of what I saw of them all day. It was a bizarre arrangement for the kind of work we expected to do, since it discouraged interaction: you didn’t want to walk up behind someone and tap him or her on the shoulder for just any old thing.

Of course, interruptions are ruinous to developer productivity, but so is
isolation. There was a lot of context missing for me on this project, because it wasn’t available through the commit comments, and asking for it on chat would’ve required my knowing who to ask for what. I was slower to contribute because I couldn’t overhear relevant chitchat and couldn’t catch the eye of the project lead when I had a question, the most urgent one being: why were our workspaces arranged so stupidly?

I envisioned some workmen arriving one morning with a bare sketch of a floor plan in hand, and a general work order: “Build X number of cubicles from this pile of parts.” They weren’t told who’d work in the cubes, nor what was important to us. They acted from assumptions that seemed reasonable, but were still flat-out wrong.

One was that we all needed to have visual contact with one certain thing at one end of the room. Most of us have experience with this kind of arrangement, since it’s how we sat when we attended school. It’s also how clerical workers’ desks were often placed in early open plan offices. Management enjoyed this arrangement, since it permitted easy surveillance of those notorious insubordinates, schoolchildren and women. Placed side-by-side, we have less interaction with our peers, and more with the authority figure at the end of the room. But here in a twenty-first-century cube farm, there was no teacher on a dais to please. Why were we all facing the same way?

To watch a movie? Or perhaps a more sinister activity?

We have always been at war with SVN

The project never required the Two Minutes Hate–well, as far I could tell. Who would’ve tapped me on the shoulder to let me know?

Thrills! Chills! It’s InstallFest!

Last weekend brought the latest RailsBridge workshop to San Francisco (man, these workshops are really gaining momentum–there’s yet another one already scheduled for December 3-4. And, yup, it’s waitlisted). This time I ventured beyond my usual semi-skilled volunteer roles by offering to help workshop participants install the software required for the workshop. At last I felt comfortable enough with the process of getting Rails up and running that I wanted to assist novice programmers with the heinous chore fascinating challenge. Never thought I could do this–and it was thrilling when I did.

“InstallFest” is the happy-face designation we give the Friday night slog before each Rails for Women workshop. All participants must attend so it can be verified they have the appropriate dev environment set up on their laptops for Saturday’s curriculum. I attended InstallFest myself at the very first workshop over two years ago, and I still remember how frustrating it was for me: what are all these commands? Why do I keep getting error messages? And how come we can’t just install Locomotive or InstantRails and get it over with?

"Railsbridge installfest," by Romy Ilano

I’ll take the last question. Workshop attendees, here’s one reason why we don’t want you just pointing and clicking into a working Rails setup: we’re selfish.

Yeah, you might’ve thought all these volunteers watching over your shoulder as you type a lot of gibberish into a console window were selfless angels propelled by righteous sentiment to help you gain entry to the exclusive community of Rails developers. Well, sure, we are, but fundamentally, we’re…

Rails problem vampires.

Didn’t you notice how exciting we found the error messages in your terminal window? How about when we hopped up and down, shouting about malformed Gemfiles? And when two or more of us elbowed each other to peer at that mystifying line of code on your laptop screen–rake aborted (is that legal?), maybe you suspected.

“Hmmm,” you thought. “These people really want to expose me to all the gears, widgets, and thingamajigs that make up Rails, even if those don’t always work.”

My gosh, you saw through it, didn’t you? Your intuition is valid–at InstallFest you were surrounded by people who wanted to know where the installation process breaks down. You couldn’t even see all of us problem vampires–some were watching from afar, via discussion lists. We yearned to see where the instructions confused you and which of those d*mned Ruby gems didn’t load. We can’t make the installation a point-and-click process: there are technical constraints, for one thing, but more importantly, it would deny us that rich diet of error messages we crave and require.

You won’t need to bring a necklace of garlic or a wooden stake to attend InstallFest again. No, perhaps instead you will volunteer, twice, many times. Gradually, painlessly, unnoticeably…you, too, might also become a Rails problem vampire.

“Gazelles” eat hay, not grass

On Good.is the popular posts today include “15 Percent of Americans Are Now on Food Stamps”. I’ve visited the site twice this Monday, once just after the New York Stock Exchange started trading this morning, and now after the market close, as the story of our dismal economy’s enduring lifelessness makes headlines everywhere. In today’s more optimistic forenoon, I read Tim Fernholz’s “Hunting Gazelles: Figuring Out What Makes Companies—and Jobs—Grow”. Some of the points in that article bugged me then. They really irritate me now.

The post is an interview with scholar Tim Kane, who proposes that new jobs in the U.S. economy come from “gazelles,” quick-moving, fast-growing, young businesses. I don’t quibble with this entirely; I’ve seen how many Bay Area tech businesses seem desperate to hire enough people to support their rapid expansion (though–ahem–not desperate enough to modernize their hiring practices). Yet just after sharing convincing data about the remarkable contribution “gazelles” make to the employment rate, Kane veers into territory more familiar to subscribers to Reason than to Good.is:

Photo by Swamibu

There are real structural impediments to starting a firm…Labor regulations can make it difficult for entrepreneurs to even leave, and difficult for firms to hire more people.

The [Sarbanes-Oxley accounting law] is particularly galling because it seems like its[sic] killing off our IPO industry. Without an IPO or the promise of an IPO on the horizon, why start a tech company?

Alright, where to begin?

Let’s start here: one man’s regulation is another’s unemployment insurance, worker’s compensation, and minimum wage law. Your “structural impediment” is my workplace safety standard, whistleblower protection, and equal opportunity legislation. Think Sarbanes-Oxley is galling? Try having your retirement savings wiped out overnight by corporate fraud.

There’s a stubborn belief in the startup world that it’s 100% self-made, boot-strapped, that the “gazelles” broke away from the encumbrances of the herd and now thrive on the nourishing wild grasses of the entrepreneurial savannah. If this were so, why are there so few, if any, gazelles in places with fewer regulations? Why do tech bubbles form again and again here in the Bay Area?

You could re-read Richard Florida, or you could remember this:

“Gazelles” eat hay, not grass.

Meaning: “gazelles” rely on the infrastructure all of us provide. This isn’t just WiFi, Blue Bottle Coffee, and a spot on the CalTrain bike car. It’s also those “structural impediments” like environmental regulation (can you drink the water out of the tap?), public health initiatives (when’s the last time you worried about polio?), and anti-corruption laws (do you have to bribe someone to launch your product?).

Yes, it’s admirable to watch gazelles leap gracefully to such heights. But let’s not forget the haystacks we shore up to feed them.

Why we’ll stop using ID in our stylesheets

Seemed like everybody was talking about CSSLint a couple of weeks ago. I waited for the hype cycle to slow its rotation, then dutifully visited the online linter to pay my respects.

It didn’t repay them.

“Will hurt your feelings” is CSSLint’s tagline. Heh, heh; I’ve written stylesheets for thirteen years now. What faults could CSSLint find with my CSS?

Plenty, it seemed. Chief among the linter’s nagging judgments was my use of the ID selector in so many rules. Now, what’s so wrong with that? How is it that my practice for all these years is suddenly considered wrong?

I found this blog post proposing that the hip, up-to-date stylesheet of today contains no ID selectors. Intrigued, I posted the link on Talentopoly, where it generated a thread of comments from people who seemed indignant with the premise. Why discard a totally valid technique which can make one’s markup and CSS more succinct?

I think one reason we were so uneasy is that we’ve had to work with so much bad markup and styling written by people with poor understanding of the cascade. The result is overdependence on classes for style rules–a classic example would be a navbar with a couple dozen <a class="navLink"> bloating the markup. Expertly written CSS distinguished itself with terse rules attached to ID’d elements. But if you prohibit that, don’t you end up encouraging that stupid “class”-itis?

Perhaps. CSSLint can’t determine if your style rules rely too much on classes. But you can satisfy the linter’s criteria and also target specific elements without resorting to attaching class attributes to every node in your markup. For instance, you could show off your handling of CSS3 selectors instead.

Like JSLint, CSSLint is a tool based on its makers’ opinions of what constitutes good style. It’s not a validator, but an evaluator: it can suggest improvements (as did earlier linters). Using the linter is like getting the opinion of a haberdasher as to how wide your lapels should be: you’re not obligated to act on his advice, but you might look a little strange alongside your more fashionable peers.

But why has the ID selector fallen into disfavor?

Looking at the explanations on the CSSLint About page, I notice a pronounced concern for portable, modular styling. The linter discourages intensely specific selectors such as IDs and “qualified headers” (h* tags within a cascade, or with class attributes). There seems to be less focus on styling an entire, discrete page, and more on styling blocks of content which may be sent or received in an API. This is a reasonable emphasis: think of all the markup you’ve done in the last year. How much of it was for standalone pages? And HTML5 prods us to think of Web content in articles or sections, each with its own h1–our markup and styling are scraps, not whole cloth. It’s efficient to make them fit with others.

Well, so what–it’s just between CSSLint and you, right? No. A less obvious reason for abandoning the ID selector is so that your style rules pass CSSLint when somebody else submits your CSS to it. And this will happen. In a profession with no licensing and very little certification, front-end developers have few means of convincing potential clients that we know what we say we do. If our clients had the skill to inspect our CSS for quality, they’d probably wouldn’t need to hire us to write CSS for them. Tools like CSSLint, despite their basis in subjective opinions of good practice, reassure these clients: they know you’re following certain rules if you pass. They want the work you do for them to be rule-following and interchangeable, not idiosyncratic and difficult to reuse. Yes, a lot of terrible CSS can pass CSSLint–just as it can pass the W3C validator. That’s no reason to avoid using it.

What the Web industry could learn from my Tower Records jobs

Minimum wage. A good chance you’d have to work until after midnight on New Year’s Eve, and then at 8:30 AM on New Year’s Day (happened to me). Boring, unglamorous duties. Dealing with clueless, irritating, or just plain drunk customers. So what was it about working at Tower that makes us former employees so nostalgic about it?

There’s a lively group on Facebook just for veterans of the San Francisco store at Bay and Columbus. The wall refreshes almost daily with someone’s anecdote, relevant link, or “whatever happened to…?” query. I don’t remember my stints working at Tower stores as nonstop fun, but I share these people’s eagerness to talk about it, decades after the experience. What was so magical, then?

  • People really shine when they’re allowed to specialize. Russ Solomon’s most impressive innovation with Tower Records was to stock a few copies of many titles, in many music genres, rather than stock a lot of copies of a few titles in only, say, rock ‘n’ roll. Customers came to believe that a recording didn’t exist if it wasn’t in stock at Tower. The huge inventories meant that Tower stores ballooned into multi-story, multi-department shrines to music retailing, staffed by people with deep knowledge of particular genres.

At the Tower store in Washington D.C. we had the king of the soul music department upstairs, a nebbishy white guy with years of data on singers, musicians, and producers committed to memory. Downstairs in Imports we had Neal, who pored over record company newsletters to sift out which nearly unobtainable European releases he could order for the store. Both of these guys had a number of fans among the customers, who would seek them out as kind of personal shoppers. Nobody ever suggested moving these guys to other departments, so they could get more acquainted with other kinds of music.

In the Web industry we’ve come to dismiss specialties for creating “silos.” We demand that people “cross-train,” “take responsibility for the full stack,” as if specializing creates some kind of weakness. But whose customers seek out the generalists on the team?

  • Money isn’t everything… Wages at Tower were lousy. You started at minimum wage, and obtained tiny raises at infrequent intervals. There wasn’t much room for negotiation: if you didn’t like the arrangement, tough–there was a waiting list of people eager to take your place. So what was the draw?

On the job at Tower D.C. Photo by Madeleine Morrissey.

At Tower we felt we could be ourselves. We could wear pretty much anything, style our hair any way, talk passionately about the music, books, or movies we really cared about–we didn’t have to pull back to fit in with someone’s idea of the workplace’s culture.

  • …But it is something. As grateful as we were to Tower for providing us such a cool, accepting workplace, none of us would’ve worked there “for equity.” For one thing, a lot of us were deep into other non-paying pursuits like playing in obscure bands or writing terrible poetry, and to pull our attention away from these tasks Russ Solomon et al. had to pay cash. For another, working at Tower involved–work. Employees were still required to do things we thought boring, stupid, uncool, and beneath our adolescent dignity. Compensation was a motivator.

  • Working part-time is okay. Many of us at Tower were still university students. May through August, hey, pile on the hours…and come September, not so much. Rather than deal with massive attrition every fall, Tower managers adjusted schedules to fit employees’ lives (not vice versa). There were sufficient full-time employees to staff the less desirable weekday shifts. Nobody was accused of lacking “passion” or “commitment” for requesting a part-time schedule, nor demoted when it was obtained.

  • Company culture must reflect the people currently working there. When first opened in 1967, the Tower San Francisco store at Columbus and Bay had groovy, Summer of Lovin’ employees who probably said things like “Deep!” and “Far out!” without irony. Twenty years later, it was staffed by edgy kids in leather and Mohawks who slapped a video of Woodstock in the store VCR to watch for laughs. Had Tower insisted on keeping its original flavor of tie-dyed mellow, it would’ve repelled prospective hires with fresher ideas about music.

It’s common in Web companies to whine of “growing pains,” which usually turn out to be resistance from earlier employees to requests for working space, documentation, and professionalism from newer ones. By this point, the company is radically different from what it was at its founding, so why retain that atmosphere?

  • Even companies that do these things can still fail… Tower dwindled into bankruptcy by 2006, undone by online music sales. It did scramble to build a Web presence, but there was little to deter customers from buying instead at Amazon or iTunes–after all, where was the personal touch of people like Neal?

  • …but this is no reason to avoid trying them out.

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.

Why You Can’t Hire a Front-end Developer

Posted on: by mejarc 1 Comment

So much for that depressing unemployment rate, all those people supposedly looking for work–you might be muttering–why is it I can’t get someone to do that HTML/CSS/JavaScript project?

Why You Can’t Hire a Front-end Developer

  1. You want only full-time, salaried employees. I admit my bias as a freelancer on this one, and, frankly, I’m mystified why restricting your development team to only full-timers exerts such an attraction, especially for mid- to senior level roles. Why not use freelancers, part-time employees, job sharing teams, or a combination of all these? I welcome your discussion in the comments.
  2. Your requirements are out of whack. To be fair, I think this isn’t as pronounced a problem as it was a few years ago; maybe it’s the growing acceptance of MVC frameworks which has made it obvious just what a front-end dev does.

    But if you’re requiring someone “expert” in the full Web stack, interaction design, logo creation, QA, server administration, social media, copywriting, etc., then be prepared to talk to a lot of candidates who are either lying about their credentials, or with uselessly shallow capabilities in these vastly different skills.

  3. You’re only considering young, white guys to be suitable candidates. In the United States, it’s illegal to discriminate in hiring for these qualities, but hiring entities evade the law by masking their narrow preferences in phrases like “recent grad” and “good cultural fit.”

    I admit confusion on why a recent grad is so desirable as a front-end developer, since university curricula are rarely as up-to-date as the knowledge an experienced Web dev would acquire from real-life projects; again, I welcome your explanations in the comments.

  4. It’s too obvious you’re a slave driver. The organizer at one of the tech Meetups here in the Bay Area takes a moment at the start of every meeting to read job postings employers send to him, hoping to interest the attendees in applying. One evening he read a post requesting a developer who would commit to working “60-70 hours a week.”

    We sat quietly for a moment. Then one attendee remarked,”Raise your hands if you’re interested in working ’60-70 hours a week’!”

    All of us laughed. Nobody raised hands. And, I suspect, nobody answered this job posting. That employer lost out on a room full of fifty or more potential hires.

    Not persuaded? Here’s something to consider: there’s a reason why a book titled The Four-Hour Workweek was a bestseller, and one titled The Sixty-Hour Workweek was not.

  5. You’re trying to cram a tech team into an entirely different kind of organization. A telling symptom of this kind of cultural disconnect is a policy requiring all employees, even tech workers, to use the same operating system, e-mail client, Web browser, and so on. A related problem is trying to graft a front-end specialty onto what had flourished, or at least endured, as a server-side team. The results in both cases include confusing job requirements, unsatisfying interview questions, irrelevant performance criteria, and low interest in your project from experienced front-end developers.
  6. You and your people don’t seem to get out much. Are you physically present at any local tech gatherings? Anybody on your team a participant in a Meetup, a BarCamp, a *DevHouse? Anyone there have an active GitHub account?

    When I don’t see much evidence of these extracurricular activities, I assume your team is exhausted from working too much. Who wants to join that?

  7. Your benefits aren’t, well, all that beneficial. If you really want to hire extra-special people, go beyond the clichés of foosball tables and Friday keg parties.Do you offer matching 401(k) funds? Cover your employees’ health insurance premiums? What kinds of paid leave do you offer both parents and the childfree?

    At the very least, re-examine your paid vacation leave policy. If it’s the dismal U.S. standard of “two weeks” (really just ten working days) a year, it’s not enticing anyone who has a choice of workplaces.

  8. You’re requiring onsite work, but your office environment is terrible. I remember my interview at a big, then-prestigious Web company a few years back. I don’t remember any of the interview questions, nor even my interviewers; all I remember about this company are the dispiriting rows of beige cubicles, the glaring fluorescent lighting, the looming, low drop ceiling, the smell of the microwaved burritos employees were eating at their desks, the complete absence of natural light and airflow, and my recurring thought: Man, oh man, I can’t wait to get out of this place.

    If memory serves, I think I actually ended the interview early–there was no way I was going to be interested in working for this company. Rule of thumb: if you’re requiring people to work in what looks like a set for The Office or a Dilbert cartoon, please call in a design consultant for a revision.

How did you hire a front-end developer?

Where is San Francisco?

Posted on: by mejarc 1 Comment

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?