Unisex Swag Shirts Are Harming Your Community

"Shirts! We've got your t-shirts right here!"

Except we don't.

No one is entitled to freebies. But let's talk about why we're fond of giving free shirts to (presumably) well-paid people anyway.

I'm a community manager & community builder. When it comes to software, "community" can feel like an abstraction. What does "community" even mean, right?

A community is comprised of people who share an attribute that's important to them, that feels distinct from those who don't have it in common, and which is tied to a sense of personal identity.

"I live in San Francisco" is a statement of geographical fact; whereas "I am a San Franciscan" reflects an aspect of my identity. My sense of belonging to something that will outlast me. My passion & loyalties. San Francisco is my community. I feel this way about other things, too. Ruby community has its flaws, but it's a community I am invested in long-term regardless of what else I'm doing.

"What does this have to do with t-shirts?" you might be wondering.

Let's circle back to the question of why the heck we give away swag shirts. Some reasons:

  • We need people's passive help in getting the project or brand known better.
  • We want people to associate the project or brand with being cool, whether anyone knows anything else about it whatsoever.
  • We want people to feel appreciated, and feel that others are being treated well too.
  • We hope people feel proud to wear our logo; proud to be associated with it.
  • We intend that when someone sees a crowd full of people wearing the shirt, that they'll feel they're missing out and be excited to go do something about it.
  • We intend that it'll ultimately lead to questions, usage, contributions, and personal identification.

Every time someone walks away with a shirt that doesn't fit them right, or there's no shirt to fit them at all, that's a lose-lose situation for us all.

  • A failure to elicit help bolstering the image of the project or brand.
  • A thoughtless decision that looks decidedly uncool.
  • Showing due appreciation to some, while disregarding others who equally deserve appreciation.
  • Implicitly communicating that some people needn't take interest in what we're building.
  • Making people feel they're missing out, then reinforcing the accuracy of that conclusion.

It is possible to build software community without caring about swag shirt inclusivity; but it makes that mission unnecessarily harder.

UPDATE: In the next post I'll be going into details of what swag shirt inclusivity entails. For now, here's a nice writeup about gender-inclusive shirts. Swag shirt inclusivity goes beyond gender considerations, but it's a solid start.

Yep, this stuff takes effort to do well. But it serves a community-builder's mission.

If we’re trying to bring more women and men into coding, start by listening to young learners in their…

If we're trying to bring more women and men into coding, start by listening to young learners in their own words. These have shared useful insights, for instance. Understanding what drives their interest is critical, not just as future coders themselves (we hope!) but also as reps for a future cohort of consumers for tech products that speak to their interests/needs.

Young coders: ideas for change

Seven teenagers talk about how they got into coding and their thoughts on the future

Good news for me: co-organizing Railsbridge Outreach Workshop for Women #34 is going swimmingly thanks…

Good news for me: co-organizing Railsbridge Outreach Workshop for Women #34 is going swimmingly thanks to +Amy L. & +Tina Lee. We rock as a team. Tina and I are discovering that the Railsbridge community has done a bang-up job of documenting what we need.

Good news for you: that makes two events for April! The frontend intro workshop with HTML/CSS/JavaScript is on 4/21 at +Twilio, then we're giving the backend intro workshop with Ruby on Rails on 4/28 at +Twitter.

Sign up ASAP. Don't be intimidated by the wait list. A lot of people get moved up before the big day.

RailsBridge Workshop for Women #34 - April 27-28, 2012

Friday, April 27th 5:30-8:30pm: Software Install Fest (REQUIRED) Saturday, April 28th 9:30am-4:30pm: Workshop 5pm: After-party for volunteers & attendees IMPORTANTPlease read to the bottom of ...

Great networking opportunity during O’Reilly’s Fluent Conference in San Francisco

Meta-meetup! CodeChix, Black Girls Code, Confident Coding, Girl Geek Dinners, among other tech women's projects/meetups. I've put out the word to the Railsbridge, Women Who Code, and PyLadies organizers in hopes that they'll also get on that evening's roster.

Although the meetup is a tie-in to the Fluent conference, it's open RSVP.

(If you're one of the Saturday frontend Railsbridge students in search of followup education, take note of the workshops calendar for Fluent. 20% off with coupon code, ahem.)

Kimberly Bryant originally shared this post:

Great networking opportunity during O'Reilly's Fluent Conference in San Francisco

Women's Communities Meetup: Fluent 2012 - O'Reilly Conferences, May 29 - 31, 2012, San Francisco, CA

If you're a woman looking for like-minded communities to join, c'mon down to our meetup on Wednesday evening. In addition to great networking, you'll hear lightning pitches from groups, companies, and...

Email validation is harder than you think.

I got asked recently about email validation: is "+" valid?

Yes, the plus sign is a legal character in an email address. Though even if it were not, you'd do well to accept that character since it's used by millions of Gmail users:

Many surprising characters are legal in an email address. Pretty much everybody gets email validation wrong.

If you still want to take a shot at evaluate the correctness of an email address string, at least do it with library that uses a parser and has attempted (nevertheless imperfectly) the difficult task of complying with all the relevant RFCs. For example:

“What Next” resources for RailsGirls grads in San Francisco


p>In an average month, San Francisco's SOMA neighborhood is host to more than 30 workshops, classes, and study groups that are:

  • specifically for women to learn programming, maintain ongoing study, and enter the profession;
  • provided by professional programmers, who teach and mentor for the sheer darned pleasure of sharing what they know and expanding the community; and
  • all of it either completely free or else low-cost (with up to 100% scholarships available for the latter, as needed)

And thosre are just the ones about the principal languages of the Rails stack: Ruby, HTML, CSS, and JavaScript.

Yes, 30 events per month that meet all of those criteria.

So many opportunities to see, do, learn, teach, lead, mentor.

This weekend I had the pleasure of volunteering at yet another of these local events. RailsGirls held its second workshop in San Francisco; another organization easing into this vibrant mix. Welcome, RailsGirls grads! Here's a couple slides introducing you to the abundance of local answers to "What's next?" I hope we'll get to see you again, soon, at several of 'em.

UPDATE: Fixed the hashtag. Added 2 more resources.

Submitting commits to official Ruby & Rails documentation

Done! Submitted my very first commit for the official Ruby documentation.

Patting myself on the back for having spotted the error. It was over 2 months old — surprising for a standard library like URI::HTTP. So I second-guessed myself initially.

Surely that doc gets scrutinized by hundreds of people daily. Surely someone else would have spotted it ages ago, if it were done incorrectly. Surely I just haven't heard about some fancy new syntactical construct. Surely the fact that the example doesn't work for me is because I must've done something incorrectly. Surely.

That voice in the back of the head is noise from imposter syndrome. Shut up, you.

Doubt like this depends too on believing that those who have contributed to Ruby are infallible. A mythbuster, for me and for you:

$ cd ruby-official-repo $ git log | grep -ic "typo" 842

Trust your instinct. Verify. Make better things happen. Commit.

Last month I also made a first commit for the official Rails documentation, and — hooray! — it was accepted. Though not without a brief facepalm moment when I accidentally submitted a big bunch of other people's commits with it. Luckily, the railsdocs repository is maintained separately from the Rails codebase. So it was a quick fix by doing git reset --HARD on master branch then the documentation maintainers and I each did a git push -f on our respective repos, and rebased my branch's commit back in. Voila, solved.

It's a good example of where Git is a big win for contributor, maintainers, and collaborators. It is also a good example of how wins like these are made easiest when developers are required to submit to an upstream via a branch rather than on top of master.

So, summary: I can now put "Rails documentation contributor" on the résumé, and hopefully soon will be able to put "Ruby documentation contributor" on it too. Don't worry; even though I'm a cool kid now, I still want to hang out with you.

UPDATE: Mission accomplished. What fun.

Learn HTTP (and a lot of other useful webdev topics) at Confident Coding III

I'm speaking October 21st at Confident Coding III ("Everything Else You Need to Know"), an all-day web technology education conference for women and friends. We'll be at Microsoft's San Francisco offices at Market & Powell. Join us for a fun day of learning about developer tools, automation, HTTP, the commandline, and more. Really useful stuff. Come!

(Pssst. Women still earn 77% of what men do. Use discount code EQUALITY to register at 77% price.)

Updated: Here's the slides for "Full Stack & Full Circle: What the Heck Happens In an HTTP Request-Response Cycle"

Git “corrupt patch” when staging

In an ideal world, you could check out any arbitrary commit and it's pass all tests, and have no bits of code trailing along that belong to another feature/issue. Line-by-line staging is how I first got religion where Git was concerned. Judicious use of it truly makes ideal commits feasible. Ahhh. Truly a Cool Git Trick.

But there's a bug. Maybe you've seen it. Periodically, seemingly at random, attempting to stage or unstage a line results in an patch error such as "Applying patch failed with return value 128. Error: fatal: corrupt patch at line 12". Don't believe it.

The bug originates with Git-Gui, which doesn't know how to stage a line when the file doesn't end with a trailing newline (EOF). It's been a known problem since at least 2010 and it's a bug that's still around today.

Add the trailing newline. Solved.

P.S. Want to learn about staging lines with Git? Check out "Splitting up commits the easy way" by Peter Savage. GitX(L) and SourceTree both support this workflow really well, and (ironically) are much nicer GUIs overall. SourceTree, by the way, doesn't show this bug. GitX(L) does. Bah humbug.

PS1 transformation

Being able to edit PS1 (the shell prompt) was an eye-opener and productivity transform. My prompt has, among much fancier things, two newlines prefixed on to it, plus colorization to make the prompt stand out from the command it's receiving. I cannot emphasize enough how much this changed my ability to catch errors and reliably connect them to the command that generated 'em. I'm a better programmer for having discovered that one small detail that PS1 is customizable.