Posts Tagged ‘developers’

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?

Ada Lovelace Day (#ALD13): Anca Mosoiu

Erika and I entered the wrong door at first, learning only by the flash displayed on the walls that we were in the tattoo parlor, not the conference room where we’d meet our client. Once within the appealing 1920s store front adjacent, we met a serenely smiling young woman welcoming us to Tech Liminal, Oakland’s first co-working spot. The space was so newly opened a fan blasted on “High” to disperse paint fumes. The décor was a mix of sleek tech and East Bay thrift; we felt right at home. Met the client, concluded our business, finished the project–and I kept returning to Tech Liminal.

I came to evenings about jQuery, Python, and WordPress. I watched a fascinating presentation about the Internet as used in Iran and Estonia. During the Occupy Oakland hurly-burly just a few blocks away, I went to a Meet-up all the same, even if a police helicopter felt obliged to follow me as I rode up Alice Street on my bicycle. When the Indiegogo campaign for Tech Liminal’s move to swanky downtown digs started, I didn’t hesitate to contribute.

Heck, yeah. Anything to help Anca Mosoiu.

Let me tell you a little about Oakland, California. We’re just across a bay from San Francisco, we’re about a third its size, and about half its population. News stories about Oaklanders tend to paint us as fearful crime victims picking through the rubble of a de-industrialized wasteland, California’s Detroit. In the last three or four years, though, Oakland’s received some positive attention for its lively restaurant scene and its (relatively) less overpriced real estate. The hipsters have conspicuously moved in. Oakland! San Francisco’s Brooklyn!

Those of us who’d been living here all along already knew this, of course. I wasn’t the only one who’d given SF life a good try, but came to Oakland to stay. We knew Oakland had wonderful qualities–redwood forests in the hills, reusable factory buildings on the waterfront, and inventive people all over town.

But what matters is what we did, which, for most of us, was pretty much nothing.

Anca had the courage, vision, and stamina to stand apart. She didn’t want to recreate the self-absorbed SF tech scene. She studied who works in tech in Oakland, and found a group distinct from the lookalike bros blathering about this month’s trendy JavaScript framework in South Park: people who work for small businesses. People who maintain blogs for their churches or non-profit agencies. People concerned about maintaining content in multiple character sets. People who are performers or artists, and need a higher level of digital literacy to promote their work. Oakland people.

I’ll never know how discouraged Anca felt as she struggled to establish a tech business not just in Oakland, but in the depths of the Great Recession. I’ll never know if she ever doubted her vision of Tech Liminal as community center, as more than rental space. One of Anca’s most admirable qualities is her steady, reassuring unflappability. Around someone like that you feel sure the future’s going to be fine. Maybe it won’t be slick, maybe it won’t rain VC money, maybe it’ll be next door to a tattoo parlor. But it’ll bring in other people, their energy and ideas, and soon enough the whole thing has greater momentum than a skateboard flying down Keller Avenue.

Thank you, Anca.

Getting on stage at HTML5 Dev Conf

My friend Bill Fisher did me a big favor back in January.

“I had lunch with Dave Nugent of the HTML5 Developer Conference, and mentioned you as a possible speaker. Go on and contact him with the subject of your presentation!”

Gee, thanks, Bill! Uh, I think…

At that moment my career as presenter had included a couple of CSS workshops and my fifth-grade monologue about Pre-Cambrian fossils. When I pinged Dave, it was in a state of great anxiety: I wasn’t a performer. I didn’t know how to sing, do magic tricks, impressions. I sure as heck didn’t know, really, how to give a technical presentation to a room full of developers who’d paid to see me do something besides fall into shrieking glossolalia.

My crash course in technical presenting

Adapt to your own needs:

  • Read about presenting in general
  • Read about technical presentation in particular

    Those starting this process today can gain from Rebecca Grenier’s How I Wrote my First Technical Presentation as well.

  • Start fussing over slides

    I thought I’d go all Reveal or Prezy at this, you know, HTML5 conference, but I realized that of all the burdens to assume on the way to presenting, learning new software shouldn’t be among them. I barely knew Keynote as it was. I found an appealing presentation theme with a Saul Bass-like aesthetic, and built my slides around this Jet Age motif. It helped that the theme’s graphics included a bird silhouette–great for a presentation about Twitter Bootstrap.

    Now, what about the slides’ wording?

    And how to display code samples?

    • Jim Weirich: Presenting Code. How to put code text into a Keynote presentation.
    • Rebecca Murphey: On Choosing a Syntax Highlighting Scheme for Your Next Presentation. Most presenters choose dark color schemes for code samples these days, so Murphey seems a contrarian. Still, I was convinced by her discussion when watching some other presenters at the same conference–I could barely see the text in the comfortably lit rooms. I’m glad I used Ben Alman’s dark text/light background theme for my own slides.
  • Rehearse

    I rehearsed at least one section of my presentation every day for about a month. I had some transitions between Sublime Text, Chrome, and Keynote which I knew would be even more challenging when I was nervous, so I emphasized working on those.

    Bleeta listens patiently

    Bleeta listens patiently

    One tip that intrigued me was to mirror displays when I connected to a projector, so that switching between the various applications would be a lot easier.

    I rehearsed both with presenter’s notes visible and with them hidden–I wanted my patter mostly committed to memory.

    When I felt really comfortable with my presentation, I rented a conference room at TechLiminal and rehearsed in front of obliging superstar Angel Inokon. If you follow only one scrap of the advice I’m listing here, do something like this. Not only did it help to have an experienced presenter like Angel critique my rehearsal, I really gained from dealing with the projector and the strange world of mirrored displays.

  • Prepare the laptop for presentation

    An hour or two before I got on stage, I:

    • Went to iCal > Preferences > Advanced, and checked Turn off alarms
    • Closed email
    • Opened window groups in Chrome displaying the URLs for each section of my presentation
    • Saved all Web pages locally. There was, unusually, WiFi in the hotel meeting room, but I didn’t want to rely on it.
    • In Sublime Text, switched the color scheme to “Cowboy,” so that the live code would match the colors of the samples I’d put in my slides.

    When I connected to the projector, I made sure to choose “Mirror displays.” One thing I didn’t do was check that my laptop display was the correct resolution! As a result, I couldn’t see scrollbars on the distorted, oversized laptop display when I was doing a code demo–not a catastrophe, but not what you need on top of everything else.

  • Prepare one’s self for presentation

    I:

    • Wore something fun. In my case this was a 1970s-vintage Hawaiian-print ao dai. I figured I’d complement the bold graphics in my slides.
      Photo by Ellis Kim, https://twitter.com/ellisk01/

      Photo by Ellis Kim

    • Brought my own dongle to connect to the projector. So glad I did this–there weren’t any at the podium when I got there.
    • Remembered I’d done scarier things than give this presentation. I’d done a front walkover on the balance beam. I’d made a phone call to a curt Berlin cafe proprietor after only two semesters of German. I’d danced Argentine tango in front of one hundred people who confused the dance form with chacha. Forty minutes of word-jazz about Twitter Bootstrap? Piece of cake.

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: 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: 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.