Posts Tagged ‘developers’

The ultimate responsive design challenge

Well, if nothing convinces you to take responsive Web design seriously, consider this: there are now approximately eight thousand special people poised to use your application. Eight thousand select, elite, affluent, early-adopter people, eager to purchase something new, something you can offer just to them. Eight thousand people who probably influence eight thousand others, and so on.

Eight thousand Google Glass users.

Think about it: does your application’s interface really scale down to the size of an average person’s eyeball? If you tore your hair out over the task of making a mobile version of your site usable and attractive, you’re probably tempted to ignore the vast problem of responsively designing for Google Glass for as long as you can. This would be a mistake, for it’s a great opportunity for a clever designer. You’ll be the toast of the Web, widely cited as an innovator, if you come up with any workable solution to this problem.

The main difficulty, of course, is deciding which areas of content to display first. Given the device’s extremely limited screen width, you’ll probably want to use infinite scrolling. User objections to this construct will most likely be fewer than in other contexts, since it’s by verbal commands, rather than hand-cramping mousing or touch events, that scrolling proceeds in Google Glass. Determining how to order your content is really the task of a prose or copywriting expert, but here are a few tips:

  • Require logins immediately. You want to make sure that you’re serving this interface only to registered users, people who have real commitment to your application. Otherwise, you’ll just get some tire-kickers who won’t pay for anything, and the expense you incurred developing this Google Glass layout won’t be justified.
  • Use short, punchy sentences, not long paragraphs. Google Glass users have just seconds to glance at your content, before they return to interrupted tasks like family dinners, driving on freeways, and sleeping. Take a hint from current presentation slide style: use short words, preferably with four letters, in all uppercase letters. Use slang and abbreviations liberally to save space and to communicate your point efficiently.

  • Add visual stimulus to keep your users engaged. At random moments, animate portions of the screen without requiring user input. Give the user a rest from the trying job of reading prose by strobing the display’s colors, or reversing light for dark values.

  • Take advantage of Google Glass’s audio output. Which of your users won’t like to hear uninterrupted background music as they scroll your content? You could even imitate the wildly popular practice of playing intermittent system announcements, which most of us are familiar with from calling service lines. Remember, as fashion-forward as Google Glass users are, they’ll still be reassured by your adopting familiar techniques from older media to help them navigate this exciting new technology.

Google Glass builds on technology devised in 1960s West Germany.

Google Glass builds on technology devised in 1960s West Germany.

2013: the year we stop using PSDs

Posted on: by mejarc 2 Comments

Today I’m deep into preparing my slides for the HTML5 Developer Conference. Topic: “Making Peace with Twitter Bootstrap.” I have forty-odd minutes to soothe everybody’s ills with this ubiquitous framework. Since it’s a developer’s conference, I’ll emphasize solutions for people like you and I: front-endy things about SASS and Bower and whatnot. This will be the reasonable-sounding part of the presentation. Then, in real time, I’ll fight the temptation to disintegrate into full-on rant mode.

Here’s what I’ll try to say with terse, politely worded slides, rather than foaming at the mouth:

No more PSDs.

Stop it with the goddamn PSDs already. Fer Chrissakes, it’s the year 2013. High time to stop pretending to simulate Web applications with twenty-three-year-old image editing software.

Okay, so you’re a visual type, and you like to sketch your ideas in Photoshop? Fine. But for the same reason you don’t hand a page torn out of your Moleskine to your developer, you shouldn’t hand her a freakin’ PSD either: both formats communicate very little about what you intend for the application interface.

As Mule Design Studio puts it,

A PSD is a painting of a website.

If your interface links to framework stylesheets, and your application’s stylesheet bristles with !important rules overriding those styles, it’s a definite sign your project isn’t using the framework’s styles effectively. There are a couple of sources for this problem: 1) a developer not understanding how to use CSS selector specificity to create new styles; and 2) a design completely, totally detached from what the framework offers.

Want to drive Web developers insane really fast? Require them to cram Twitter Bootstrap, ZURB Foundation, or pretty much any CSS framework into a design dictated by PSD. In this workflow the designers and developers never discussed nor established viewport breakpoints, element widths, line heights, and such ahead of the design and development process, and fashioning something resembling the Photoshop comp out of pre-built components becomes an exercise in crazy-making CSS stunts. Meanwhile, the really necessary work of creating responsive design goes undone–what really happens is more like Reactive Design, when somebody glimpses how awful the interface looks like on somebody’s phablet, and then there’s a mad scramble fifteen minutes before the client meeting to patch over the rough spots hoping nobody notices.

My freelance rate is by the hour, and this kind of unanticipated rush developing can be lucrative. But it enrages me instead, because it’s entirely unnecessary. These days a Web design is properly devised in markup and CSS. Don’t like the associated learning curve to do this by hand*? Then use any of the following alternatives to Photoshop:

  1. Adobe Edge Reflow. Even Adobe wants you to stop delivering paintings of Web sites.

  2. Easel. Design for the browser–in the browser!

  3. Jetstrap. Get rid of that whingeing front-end developer and make the interface yourself.

Why are you still designing Web applications in Photoshop?

* A link to a design blog post from over three years ago.

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?

Sh*t People Say to Front-end Developers

Posted on: by mejarc 4 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.

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.

Why there’s always a waiting list for the RailsBridge outreach workshops

Seemingly moments after the announcement on Meetup–maybe it’s really as long as three hours–about the latest RailsBridge outreach workshop, there’s a waiting list of women really, really interested in attending, but just a hair too late in registering. Why are these workshops such hot tickets? After all, they’re just a few austere hours spent hunched over laptops learning the rudiments of programming with Rails–the instructors are volunteers from the local Ruby community, the venue is a generous sponsor’s office, and the participants don’t even pay tuition. What’s the draw?

  • Women want to get behind keyboards. There are many women-only tech industry events. However, most of these are mixer/networking occasions, not hands-on programming fiestas. They’re great for meeting people in potentially useful categories–ever notice how many recruiters are female?–but less beneficial if the question you’re mulling is better answered pair-programming with a Terminal window open.

The RailsBridge workshops offer women events that are “less talk, more rock”: each attendee uses her own laptop to create her own Rails application. People do bond over the several, often frustrating, moments of the workshop’s evening-and-a-day, so the networking component is present as well.


RailsBridge at Pivotal Labs. Photo by railsbridge


  • Attendees know they won’t get bullied, no matter their level of expertise. Each workshop announcement notes that total newcomers to the Rails framework–and to programming in general–are welcome. The tone of the workshop’s announcement makes it clear that attendees may ask questions, or even admit to confusion, without being shamed or mocked or otherwise treated as low-status.

Sudo make me a sandwich
photo by king-edward

One benefit of the all- or nearly all-woman format is avoiding that chest-beating, alpha geek braggadocio some men feel strangely compelled to perform at technical gatherings. It’s a behavior that bewilders women–is this true aggression, or bluffing?–and usually serves to shut us out while we try to figure out an appropriate response. The RailsBridge workshops are delightfully free of this nonsense.


  • The event’s time commitments are obvious and reasonable. Here in the Bay Area we have many opportunities for group programming–there’s a Hack Night, a Hack Day, a Hackathon, a CodeFest, always, somewhere. But some of these events don’t seem to have set hours, or if they do, they’re demanding a big chunk of a weekday night. Since most women, even the childfree, work a “second shift” maintaining our households, we’re not really free after our paying jobs to go to events with ambiguous starting and ending times. And if we’re trying to rise early the next day to get kids to school and/or ourselves to a morning workout, weeknights are out of the question. The RailsBridge workshops always have the format of a Friday evening devoted to installing the required software, followed by Saturday’s workshop. Though participants may forsake some weekend revelry, it’s less burdensome to the average woman’s schedule.

  • The event has a defined agenda. It’s nice to see programming events promoted as “newbie-friendly,” or “all levels welcome”–but they’re still intimidating to attend when you’re a novice, don’t consider yourself a “hacker,” and you have no personal project to “show off” as “disruptive” or whatever adolescent adjective is being overused this month. The RailsBridge attendees feel encouraged because they know in advance how the workshop proceeds and what everybody will be doing. They don’t have to arrive with anything besides their laptops.

The next San Francisco RailsBridge Outreach Workshop for Women is October 21-22, 2011. And, yes, there is a waiting list.

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 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?

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?