Two Banjos At Once: The Blog

Archive for the ‘.’ Category

The Point of the Rails Outreach for Women Workshops

The past week has seen some discussion on the mailing list for a local Ruby Meetup about this weekend’s Rails Outreach for Women workshop. One message from the workshop organizer, requesting a wireless hotspot accessible to Windows users, prompted a strange but revealing departure from the subject when people responded. Those of us lurking on the list didn’t find out who provided the hotspot, but we did find out what other subscribers think is the point of this workshop.

The point of the Rails Outreach for Women workshops

…is not, despite apparently common belief otherwise:

to give participants incredibly detailed information about the Ruby programming language
to give participants deep instruction in computer science topics
to convince participants of the superiority of open source software
to shame users for their reliance on GUI clients
to berate the people Sarah Mei wryly terms “operating system minorities” for using something the rest of us find inconvenient.

The point of the Rails for Women workshop is to make a cultural exchange.

It’s like going to a country where you don’t speak the language. You prepare by learning basic phrases which will help you ask directions to the train station, order food from a restaurant menu, and be polite in that country’s etiquette. You don’t start with the pluperfect tense, historical study of that language’s divergence into regional dialects, or intensive scrutiny of the country’s avant-garde poets. Your goal is to enjoy your trip to that country, and, if you do, you might return and gain more facility in its language.

The stated goal of the Rails for Women workshop to increase gender diversity in the Ruby community by helping women learn Rails. By the end of the workshop, however, what’s happened is a lot more positive and enduring than fifty or sixty people inspecting http://localhost:3000 on their laptops.

image © okhiroyuki

Instead, there’s an exciting, contagious mood of self-confidence in the participants and volunteers. People might not remember how to generate a scaffold the next day, but they will remember that they did it once before–so it can’t be that hard, can it?

Anybody who believes the tech industry is egalitarian should spend time working in it as a non-programmer. Only a few moments on the job as an admin, HR person, marketing person, or designer will quickly reveal how the people in these roles are consigned to the lowest castes in tech companies, while programmers are encouraged to swagger like feudal lords.

Many of the participants in the Rails for Women workshops identify themselves as this sort of tech-but-not-techie, in that they’ve been around the artifacts of programming culture, but not able to make sense of them. Once in the workshop, they handle things like–the command line! Version control! Databases! Maybe at the end of the day they don’t have every concept mastered, but they do have a greater self-regard that is moving to observe. They might go on to volunteer at the next workshop, or even attend a Ruby Meetup. They feel entitled to learn more.

The cultural exchange isn’t one way. As the participants work through the workshop curriculum, they discover where the Rails Way isn’t clear. Install Night is especially revealing: every volunteer helping gets exposed to at least one error message he or she’s never seen before, at least one bewildering installation problem for which no amount of Googling can provide solutions, and at least one nonsensical incompatibility nobody bothered documenting.

The Rails community gains from these frustrations. It gains when a workshop participant points out the inadequacy of a tutorial, README, or wiki page. It gains when installing an upgrade or gem becomes simple. Consider how friendly Rails could be for a programming novice: there’s so little futzing and configuration to do (once past the install hurdle) before you get to see something display in the browser. Why not make the Rails community as accessible?

The San Francisco Rails Outreach for Women Workshops are organized through the SF Ruby Meetup.

A Timeline for Treating Burnout

You’ve reached a state of burnout when:

you can’t socialize after work, or on weekends, because the only thing you’re prepared to do in your state of numbness is to get drunk alone;
you hear about layoffs at your workplace…and are bitterly disappointed you weren’t among the people let go;
you’re riding your bicycle to work, all the while wishing a car would hit you, because then you wouldn’t have to go to work that day.

Photo © americusian

A Timeline for Treating Burnout

0-3 months:

Don’t feel ashamed.
Burnout is common in the tech industry, yet still regarded as some kind of shameful personal weakness rather than a normal human response to irrational working conditions.

Fortunately, some courageous people are starting to discuss burnout openly.
Say “no.”
Stop “learning to say no.” Just do it. Do NOT say “maybe.” People think “maybe” means “yes,” especially when women say it.
Stop volunteering for now.
Yes, there are worthy causes all over relying on volunteer efforts. But when you are in burnout, you are in crisis mode. You might have arrived here by giving away your time and expertise. While it’s certainly flattering to be told a project will fail without your unique, uncompensated work on it, remember that anything depending on a single person is unsustainable.

4-6 months:

Step away from the screens.
I know I’ll sound like a crank, but I really do believe there’s something physiologically harmful about lengthy exposure to computer monitors, and we burn out more readily when working with them. It’s been established that light shining in our faces affects our circadian rhythms, which is probably why, after hours, days, weeks, of this treatment, you feel as jumbled as you would from the jetlag of a nonstop flight from LAX to Heathrow.

Get away from the TV, the laptop, the iPad, and so on to reset your clock.
Get your house in order.
I’m not using a metaphor–I mean your actual, physical dwelling place. A dirty, cluttered living environment is both a symptom of burnout (you’re too weary to wash the dishes or hang up your clothing) and a contributor to it (your place isn’t relaxing or pleasant to be in). Counter your packrat or slovenly tendencies with some re-education and a fresh, wetted sponge.

7-9 months:

Simplify, simplify.
When a painter reaches an unsatisfying point in her work, she might recharge her enthusiasm by painting with a reduced palette. Removing the burden of choice frees you from yet one more thing to do–and exposes how many of the options posed to us make no difference in how our days proceed. Stop dithering over things which don’t really matter.

You don’t have paint en grisaille, but you must set yourself more confining limits than usual to realize the benefits of this practice. Type “voluntary simplicity” or “minimalist living” into a Web search engine to receive much more information than you really need to start living with less.
Risk being called “unsupportive.”
Many of us, especially women, reached our limits by taking on the burdens of others. We’ve been the caretakers and companions of people who dumped on us…because we let them. For some reason we fear being called “unsupportive” for not concerning ourselves with these people’s endless problems. I’m not talking about being unsympathetic to genuine tragedy, but rather about defending yourself from these vampires.

You know how the flight attendants on commercial flights instruct parents to put on their own oxygen masks before attending to their children’s?

Consider your recovery from burnout just like this scenario–you’re of no help to anyone else until you have your own air supply secured.

10-12 months:

Take on one well-defined project.
By “well-defined,” I mean a project with a start date, a definite list of tasks, and (this is important) an end date. Just as you recover from a physical injury by assuming only gradually heavier duties, you recover from burnout by taking on shorter projects with less complexity, then gradually moving into either longer or more complex projects–so long as you still feel enthusiastic about the work.

Do not join a vaguely defined project. What you need at this stage in your recovery from burnout is reassurance that, however stressful a particular moment can be, that moment passes. Open-ended projects can persuade us that nothing changes, time has stopped, this reality is the only one, and the stressful moments are endless–sending us right back into burnout.
Schedule a regular digital sabbatical.
Get away from the Web, IM, e-mail, RSS, blog, podcasts–all of them. To update Timothy Leary’s slogan, turn off, tune out, and drop in. If you’re so addicted to constant electronic distractions you can’t envision an entire weekend without them, then begin with shorter absences–thirty minutes, an hour, two hours or even twelve.

How have you recovered from burnout?

The jQuery Juggernaut

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

Image © the jQuery Project

New Wave JavaScript

Why jQuery has so many infatuated practitioners:

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

Five minutes with the average JavaScript tutorial will give you, maybe, some prose to recite about objects, data types, and the prototype method. Fifteen minutes–perhaps some acquaintance with the built-in Math object, rarely used in your daily work as a front-end dev. In contrast, five minutes’ reading of an introductory jQuery tutorial will get you to the point of answering that deathless question: how can I apply an onclick highlight color to every other table row?
It’s (mostly) backwards compatible. Since you’re using the hosted version of jQuery from either Google or Microsoft (you are, aren’t you?), you might be anxious that an upgrade to the latest jQuery release will break your carefully wrought scripts of yore. Yet the framework is designed so that new functionality won’t meddle too much with older. Your zesty accordion menus from 2007 will thrill your site visitors for years to come.
It will always be open source. The jQuery project is a member of the Software Freedom Conservancy. It cannot be purchased by any corporation and then sequestered into a proprietary format. You will never have to pay to use .mouseleave() or .fadeIn().
It has an enthusiastic community of plug-in developers. Like as not, you could develop an entire Web project without writing a single line of your own JavaScript. In addition to the plugins hosted on jQuery.com, there are countless scripts and gists on GitHub, and who knows how many others stored on people’s blogs.
It’s not that I advocate avoiding writing your own scripts, but if you’re solving a tediously common problem and you have the typical ridiculous project deadline, you can pull in someone else’s lightbox, autocomplete, or carousel, and move on to the more interesting work you have to do.
Our feedback matters. An amusing test of this happened a couple of years ago, when jQuery.com unveiled a new branding effort. Gone was the tagline “Write less, do more,” replaced by “Be a Javascript Rock Star.” Manga-style graphics supplanted gradients and color blocks.
Reactions tended to the furious, and the jQuery team quickly removed the elements generating so many complaints.

Why aren’t you using jQuery?

Blog Action Day 2010: Water

Yesterday I opened the fridge at home, and was astonished to find these:

1.5 Liters of Bottled Water

Fifteen, even ten, years ago, these items would be unremarkable in my kitchen. I might’ve even remembered purchasing them, rather than regarding them as puzzling stowaways. But thanks to the Web, I’m now enlightened to these harmless-looking bottles’ sinister nature. Each is a crystalline vessel of needless expense, inefficient resource usage, and toxic compounds . So how did they end up in my house?

Each bottle is an artifact from a conference. Each is the result of a conference organizer’s good intentions and relatively enlightened self interest. The original notion seemed to be concern for conference attendees’ physical comfort (“Keep hydrated through those long days of sitting in chilly, darkened meeting rooms! Here, take a bottle of water…”), combined with greater awareness of the ruinous health consequences of drinking soda, and the practices of corporate branding, to create the now ordinary half-liter water bottle such as you see here, and such as you probably have lurking in your own refrigerator.

How is this a problem? We got something for free, right?

Uh, no. We’re paying for it, whether we drink this water or not.

We’re paying for:

The delivery of so many single-serving bottles full of what is often just tap water
The janitors necessary to remove these used-only-once water bottles from conference rooms and wastebaskets
The energy inputs required to recycle these bottles, if that’s even available. (To that conference’s credit, one of these party favors used 100% recycled plastic for its bottle)
The landfill space required to bury these bottles when recycling isn’t supported

And we’re missing a great opportunity for tech conferences to be as innovative as they claim to be in their publicity. Want to be truly “disruptive, or “2.0,” or “the future”? Hand conference attendees collapsible steel cups with the conference logo printed on them, and point the way to the drinking fountains.

I doubt we will notice anything missing from our fridges.

So long, Vox.com

We were so proud. It was through such a vale of tears that we, the engineering group at Six Apart, traveled to get to that wonderful point at which Vox.com, the world’s niftiest hosted blogging service (prove to me it wasn’t), went live.

All those hours of mandatory overtime. All those foosball games and trips to the office coffeemaker. All that back-and-forth between the Perl dudes, the JavaScript kids, the CSS ladies, and the visual design goddesses. All those fake blog posts made on the testing server (weary of typing “lorem ipsum,” I resorted to scraping content from Hungarian Wikipedia pages, which provided nice long strings to test word-wrap in layouts). All, it seems now, for naught.

Vox.com will go offline on Sept. 30, 2010. It had been withering for years; I know my posts to my own Vox blog dropped off in frequency around 2008. When I did post, most of the comments I received were obvious spam, not filtered by the server (of all the great ideas we put into this product, why not something like Akismet?) What’s left of Vox now seems like one of those grotesque, abandoned amusement parks you’ll see in dystopian sci-fi movies: a brightly colored playground that somehow feels menacing. Are those zombies hiding behind the Ferris wheel?

Vox-er Patty Mitchell captures how this apparently necessary closing is more than releasing a domain name:

The loss is one of community and connection. That was the magic of Vox. The way this platform used to make it so easy to post with different privacy levels and to share our lives as we chose with friends, families and even…gasp!…strangers. The magic was in how trust was built and how sometimes those “strangers” became our real friends over the course of time and circumstances.

Why this? How could such an easy-to-use, attractive, AJAX-charged product not contend successfully with old-style clunkers like Blogspot and WordPress?

Chris Balz, one of Vox’s JavaScript maestros, has this insight:

Vox finds its home with the NPR set and similar demographics. Yet with a shrinking middle class, the audience for these types of ventures is smaller and not as spendy. So “social” went almost wholly to brief “status” messages and not to Vox’s social blogging.

In both Patty’s and Chris’s remarks are hints of what I think the real problem for Vox was. That problem was the rapid expansion of Facebook’s popularity outside its original niche user population of affluent college students. When we were building Vox, the refrain seemed to be, “let’s build a blogging service for grown-ups.” And–I don’t just believe, I know–we succeeded. For a time. For a rather short time…until the Baby Boomers, the Gen Xers, the parents of Millennials all turned to Facebook, despite that service’s apparent disdain for such uncool olds.

I remember two phone conversations I had in August 2005. One was with an engineering manager desperate to hire a front-end dev. The product was unfamiliar but intriguing to me, and I already knew one of the engineers. Everything sounded great except the commute–it would’ve taken me two or even three hours’ travel each way. Sorry, no dice. So I was more enthusiastic about my second phone call, to a recruiter for a blogging software company. I wouldn’t know anybody there, and the product was not fully defined, but the commute was reasonable. I took that project.

Yes, the first conversation was with Facebook, and my second, with Six Apart, about Vox. I’ve asked myself, “What if…?” ever since.

HTML5 Forms: browsers get jetpacks

Self-identified standardista Estelle Weyl enlivened a recent HTML5 Meetup with her summary of the neat stuff we could use if only everybody used, say, the latest version of Opera.

How many lines of JavaScript have you written to enforce a pattern on user input? To set focus on a certain form element? To mark input required, and bark at the user who doesn’t supply it? How about offering a calendar pop-up for a date picker? Between HTML5 and CSS3, there are new options for markup–no scripting necessary!–which handle these scenarios.

Well, that’s the promise, anyway. It’s nice to hear the future is nigh; it somewhat offsets the discouragement you’ll feel when you obtain the latest statistics on how many Web users continue to use terrible software such as Internet Explorer.

Carefree living post-IE 6

Hearing about nifty HTML5 wonders at present feels a lot like watching those filmstrips about “life in the year 2000 A.D.!” when I was a kid: substitute attributes like “placeholder” and “datetime-local” for “flying cars” and “robot servants” to update to the latest shiny, optimistic vision.

Yet it’s not we shouldn’t use HTML5 forms–we’ll just have to prop them up with JavaScript crutches, until the browsers of Tomorrowland are in common usage.

Note: Estelle’s presentation might be expanded for SXSW 2011.

Review: Getting Real

by 37signals

Title: Getting Real: The smarter, faster, easier way to build a successful web application

Authors: 37signals

Pros:

Concise, clearly written, commonsensical advice
Available in print, e-book, and Web formats

Cons:

One of those classics everybody knows about but few have read
Less applicable to design projects
Generates pessimism when colleagues and clients refuse to follow even the most accessible suggestions

In a perfect world, books like Getting Real would not exist.

In a perfect world, Web development projects would proceed logically–everybody involved would work towards the same project goals, and none would be thwarted in her or his work. Nobody would have to write or verbalize obvious points such as that meetings are toxic, or that pinging your development staff a zillion times a day slows progress. But this is not a perfect world, and Web development is often performed in an atmosphere of childish illogic. So we have 37signals to thank for reminding us of these simple concepts.

With its content organized into one- or two-page sections, Getting Real is easily completed in a just few pomodoros. The book format follows that of the Web site–if you’re hesitant to pay for this material, you may peruse all of it for free online. This easy access is one of the most puzzling and frustrating aspects of the Getting Real phenomenon for me: why, if the advice in this book is so clear and so readily available, are people not using it?

I can only guess that tech teams prefer to retain habits that make their work miserable, expensive, and late. Any ideas? What do you think?

Random thoughts about the Rails Outreach workshop

part of the RailsBridge Open Workshops Project

It’s the Monday I didn’t expect to see, the Monday after the latest Rails for Women workshop. Two months ago I agreed to step up my volunteer commitment to these workshops. Instead of my usual lurking at the registration table, or lunchtime KP duty, this workshop saw me promoted to Assistant Organizer. Suddenly I became acquainted with the million little tasks that the Sarahs (Allen and Mei) and super-volunteer Ilén Zazueta-Hall had taken on so graciously before. It was like planning a big church wedding, or Thanksgiving dinner for fifty–and praise be that the remarkable Amy Chen was the event’s other organizer. Thanks to her and all the wonderful people who said “Yes!” to volunteering for this event, I am upright, even verbal today, and not reduced to Jell-o from all the pressure.

I spent Install Night and Workshop Day scooting around the workshop space, so my impressions of the event are scattered and incoherent:

* Little touches such as the bicycle racks sponsor Pivotal Labs provides inside its offices, as well as its location near several mass transit stops, said much about how positively different this workshop would be.

* If you’re organizing something like this, do whatever you can in advance, because inevitably something else will become more urgent at showtime. You can’t wing it for an event with this many people and projectors.

* Speaking of projectors, I regretted not having a volunteer dedicated just to A/V. There was too much last-minute scrambling for adapters, though our gracious hosts at Pivotal Labs had what seemed like the world’s most complete inventory of them. You know how I said something would come up right at the last minute? Count on the projectors to provide that drama.

* At the beginning of the workshop, I mentioned how thrilled I was that so many of the participants had little or no programming experience. I am totally sincere about that–of all the good things this workshop brings about, what I’m most proud of is that we offered an event which was friendly to newcomers. Wouldn’t it be great to see something like this for JavaScript or Django?

* I loved having the company of Mary, Sharon, and Michael as the workshop was underway. I never got to the gibbering-to-myself stage of frenzy because they handled so many things. It was kinda spooky how many things just got done–magically, invisibly.

* Everybody who cleaned up at the end has raised the standard for all other events at Pivotal Labs. By 5PM the place sparkled. I hope the Pivots liked it this morning.

What was your experience of the Rails Outreach Workshop?

Ada Lovelace Day: The Sarahs

There’s a bumper sticker you’ll see a lot around northern California: “Be the change that you want to see.” I’m not usually persuaded by the greeting-card pithiness of bumper sticker slogans, but this one, for some reason, sticks with me. I’m alert to opportunities to be the change that I want to see–my impulse has elements of rebellion left over from my punk rock past–and I admire people who have also chosen to do things differently, to be the change.

In April 2009 two programmers attended the Golden Gate Ruby conference. While there, they learned many things about Ruby programming they sought to, and, regrettably, some they didn’t. For this was the conference which included Matt Aimonetti’s infamously tasteless CouchDB + Ruby: Perform Like a Pr0n Star presentation. While attending this and other presentations, the two programmers looked around and started counting all the attendees who were women. This was an easy task–including themselves, only seven women attended this conference.

Were it me, or many of us, I would’ve left the conference disappointed by that ratio–and then done nothing else. But these two programmers were the super Sarahs: Sarah Allen and Sarah Mei, and the matter didn’t rest there. No, not with their experience in both the tech industry and community development. Want to see more female Ruby programmers? Well, then, make some!

And so on June 13, 2009 a mob of us would-be Rubyists were seated in the very nice conference rooms of Orange Labs, fumbling through developing a basic application in RoR, pushing it to Github, and admiring our handiwork on Heroku. Assisting us were the most solicitous, patient, and caring volunteers ever, nearly all of them men.

The one-day introductory course had enrolled its maximum. Even before this day had finished the Sarahs and the volunteers had to plan another. Not only had they identified a common need, but they had met it so graciously that many of us aspired to be one of those cool volunteers ourselves some day.

And so, one year later, the local Ruby Meetups have more women attending every time, some even as presenters. One year from now I hope we won’t even have to do this kind of census. But to get there we have to be the change we want to see–and it’s great the Sarahs have shown us how to do that.

12+ People I Owe

So here’s a pretty satisfying thought experiment/daydream: if uncountable buckets of money suddenly landed in your bank account one morning, who would you invite to share the windfall? Just in case this happens to Yours Truly, I’m writing up a list of people who devised things which made my professional life easier over the years, so that I can compensate them appropriately before I retire to a villa in Tuscany.

This villa is absolutely positioned. Photo by Maney Digital

12+ People I Owe

Jesse Ruderman, for the Web Dev bookmarklets
Felix Ritter, for View Formatted Source. Yes, Firebug has assumed its function, but I’m nostalgic for the day this add-on removed tons of guesswork from my project.
Eric Meyer, for his Reset CSS, which introduced us to a sparkling world clean of browser defaults
Joe Hewitt, Rob Campbell, et al., for Firebug
Mike Buckley and Lorne Markham, for Pixel Perfect
Kevin Freitas, for MeasureIt
Lorenzo Colitti and Philip Chee, for FlashBlock
Alex Sirota, for ColorZilla
James Anderson, for Leechblock

Who will receive your gratitude?

Two Banjos At Once: The Blog

Archive for the ‘.’ Category

The Point of the Rails Outreach for Women Workshops

The point of the Rails Outreach for Women workshops

The point of the Rails for Women workshop is to make a cultural exchange.

A Timeline for Treating Burnout