is sometimes the scariest damn thing on the internet.

Whether it’s a conference talk submission, a pull request, or a project bid, every time I have to deal with one of those, I go into deer-in-the-headlights mode for a while. And 90% of the time, I don’t say a word about it.

Like a lot of people who work in this intersection of women in tech and open-source community-building¹, I end up thinking a lot about impostor syndrome. And while I put time and thought into helping other people with their impostor issues, either formally as a teacher or just as a friend who’s there to tell them that no, they — YOU — don’t actually suck, I’m really, really insistent on hiding my own.

The thing is, while faking confidence is useful and sometimes absolutely necessary, it doesn’t actually help when impostor syndrome is all about the inner voice that’s so busy telling you otherwise.

There’s a lot of value in saying: Hell yes, putting yourself out there is scary. And we’re all afraid that we’re going to be caught in some really public n00bish mistake. And it’s totally normal for pretty much everyone to feel that way (even if they do always try to hide it).

And then hitting the button anyway.

While I’m at it, check out an awesome set of slides from Dreamwidth co-founder Denise Paolucci:

I’m not doing a formal WP10 party because it’s a previously scheduled game day and annual inauguration of the grill, and those two things are sacred.

Instead, I awarded my barbarian with a new piece of equipment, as seen above.

Democratizing Shield: This heavy steel shield bears the sigil of Mulletweg, and can only be borne by warriors dedicated to access for all to Press their Words, however profound or bullshitty they my be¹. Once per encounter, as a free action, it can be used to cast GPL, whereupon all enemies will cease battle and argue in blog comments for the following three days. Caster must pass an arcana check to determine if she is entangled in her own GPL argument.

DM is gonna kill me.

I don’t give two hoots what you do with any of the design or code you find here.

Actually, I do. I hope you take it and use it, uncredited, on a super commercial website and get wicked rich off it. I hope you use it at work and your boss is impressed and you get a big promotion. I hope it helps you design a website and that website impresses somebody you think is super hot and you get married and have smart, chill babies. I hope you use the code in a blog post you write elsewhere and that website gets way more popular and awesome than this one.

And it goes on from there. Every word is about the spirit of the thing, not just the fine print. Oh, yeah.

All good spring days to have, but somehow I think making them all happen at once is sci-fi stuff.

This song is Copyrighted in U.S., under Seal of Copyright # 154085, for a period of 28 years, and anybody caught singin it without our permission, will be mighty good friends of ourn, cause we don’t give a dern. Publish it. Write it. Sing it. Swing to it. Yodel it. We wrote it, that’s all we wanted to do.

Sass actually makes it really easy to do this, at least if you use the default .scss format. All valid css files are also scss files; you can just take your css file, change the file extension to .scss, and start throwing around variables and functions and all that Sassy stuff. But while it’s easy to get a project rolling that way, it leaves something to be desired organization-wise.

One of the very cool things about Sass is that it assumes that you’ll work with multiple files (partials, in Sass-speak) and compile them into one at the end; renaming the big stylesheet and working from there like I’d been doing still left me searching through a lot of lines of code to find what I needed. Ideally, I’d have a file for menu styles, a file for media styles, and so on. Even better, I’d be able to drop in a file of my own favorite mix-ins without recreating them for each project. I always set up my color schemes first thing, my base fonts and line heights, set up clearfixes and assistive text the way I want them, set up common styles for borders and boxes and the like; the values change, but what I’m styling has a lot of the same structure from project to project. (That one’s not included in the repo, but I’d love to hear about other people’s favorites.)

So to make more lazy level up my own practice, I finally took the time to make all this into a properly organized repo. Y’all can grab it here: https://github.com/sabreuse/sassy_s

A couple of notes:

• sassy_s is just a refactoring of the stylesheet — not a complete starter theme. It’s designed to work with a copy of _s, not replace it.
• I’ve provided links to a couple of beginning Sass tutorials, and a couple of inline examples, but there are lots of great resources out there for installing and using Sass. If you have Sass questions, they’re the place to start.
• The sass --watch command will overwrite your style.css with every change. Start with a fresh copy of Underscores and copy over your style.css header first. Don’t add this to a theme you’ve already made (unless you’ve got it under version control!)
• If you’ve heard that you can’t use Sass if your end-users don’t run Ruby on their servers, fear not! In almost all cases, you should be running Ruby and Sass on your development machine, then exporting your Sass to a normal CSS file. It’ll run just as well as any other theme.

Sloppy Sam is a hobbyist, who has been coding PHP off and on for a few months. One morning, she gets an idea for a new feature for Drupal core. She begins by searching the issue to see if something like it exists already and, finding it does not, posts a new issue with a general description of her idea. She then opens her IRC window and asks in #drupal, “Hey, folks! I had an idea for a new feature for core that [brief summary]. What do you think about this? [link]“

via Diaries of a Core Maintainer #6: A tale of two developers | webchick.net.

I have a feeling this is a post I’ll be coming back to often.

I’m not much for unboxing shots, but this the box the Raspberry Pi came in, next to a normal-sized laptop for scale.

The house has working doors for the HDMI and ethernet ports. This amuses me way more than it probably should.

Tiny computer installed in tiny ranch house. The doors are cute and all, but the hinged lid is actually the part I’m most proud of. Most of the Lego cases I looked at are either permanently bricked-in, or have a lid you have to pop off, which for me usually means rebuilding half the structure.

Working!

I didn’t do so hot with the daily logging part, but the rest turned out pretty well:

• I contributed code to WordPress 3.4 and 3.5, and I’m busy thinking about what I can do for 3.6.
• I was named a Recent Rockstar for the 3.4 release, and you know I saved screenshots of the credits screen.
• I was invited to the first WordPress Community Summit, which was an incredible honor and a bit of a life-changer.
• I gave my first conference talk at WordCamp Raleigh, about making the move from being a committed user or dev to being a community contributor — and including all kinds of roles in “contributor”.
• Outside of WP-land, I was selected to attend the Ada Initiative’s AdaCamp DC conference. Between that and the Summit, I had two conferences this year that really expanded my views on what we do in open source and open culture, how our communities can make a foundation for that work, and my own place as a part of all that.

Looking ahead to 2013, I’m looking toward a mix of stepping up technical skills and turning everything I did last year into stuff that benefits people other than just me:

• This is the year I really, seriously, learn JavaScript. Not just cute bits of DOM manipulation, but the stuff you build apps with. Turns out it’s a really cool language.
• I want to speak more. I want to polish up the community stuff, and also add at least one technical subject to the list of subjects I can talk about.
• Release more code in public. Whether it’s paid or free, the fact is that I do better work when it’s not just hidden away in the back end of a single site.
• Find a team, part 1. I don’t yet know what form this will take: whether it means looking for a job or redirecting my freelance work toward bigger projects with distributed teams, but I do know that solo projects are limited projects compared to what I can do with good partners.
• Find a team, part 2. As an outgrowth of the Community Summit, a new WordPress Community Outreach team was founded, and we’ll be starting up in the new year. Don’t worry — I’ll still be working on core code and reviews, but the Community team is an amazing mix of all the empowerment and outreach and learning ideas that drew me in to Open Source in the first place… of course I’m all over that!
• Blog more. Duh. Maybe I’ll try logging some of my contributions.