Learn To Teach Programming – Software Carpentry

Today, post PyCon conference, I spent the entire day immersed in an incredibly dynamic and educational workshop by Software CarpentryLearn to Teach Programming“.  I’m going to do a mix of dumping my notes in a play-by-play fashion with possible sidebars for commenting on what I experienced personally so that I have a record of this to look back on as I move forward with Ascend Project planning and execution.

Meet Your Neighbours

The event started off, as they always do, with a go-round of people introducing themselves in short form.  As we started taking turns our teacher, Greg Wilson, asked for the person who just spoke to tap the next person to speak before sitting down.  This proved to be our first of many small applications of the science behind learning and how it can play out in real life.  While it apparently takes a room of kindergarten children 3 reminders to do this extra step during intros, it took this room of ~25 adults 14 requests before we mostly started doing so without prompting from Greg.  By the way, during the intros I learned about Dames Making Games which I can now add to my mental list of awesome women-in-tech groups and if you’re reading this and are in Toronto, check them out!

Teaching Is Performance

It raises your adrenaline, brings out your nervousness, and it’s something you need to work at. A few quick tips from Greg on preparing for your ‘performance’ as teacher: always bring cough drops, and figure out what your ‘tell’ is.  Like with poker, everyone has at least on thing they do when they are nervous.  I suspect for me its likely that my ‘tell’ is talking fast and/or having trouble not smiling too much (at least in poker, it is).  This was our first introduction to how we should be reflective about our teaching – even go so far as to record yourself if you can’t get honest feedback from people around you – so that you can spot these things about your manner and work on adjusting them to ‘perform’ teaching in a more confident and reliable manner.

Improv came up as a way to work on this where you can get feedback on how you perform and also learn to keep other people engaged.  I used to do improv when I was an awkward teenager and didn’t feel like I was a superstar at it but I wonder what it could be like now that I have more confidence.  I’ll be looking for classes in SF to try it out.  What’s there to lose?

Why Don’t We Teach In Teams?

Greg pointed out how teaching, unlike music and comedy, is such a solo activity.  Musicians typically build up their experience and skills by playing with others.  The best comedians by and large spent a significant amount of time in some sort of comedy troupe before striking out on their own as a stand-up or as major film stars.  Teachers though?  Often alone in their classrooms and if my partner is an example of the ‘norm’, definitely alone while grading and preparing lessons.  This is something worth exploring: what could teaching be like for the teacher if there was team teaching?  What could we do with more feedback, more often, and with someone helping us track measurable progress towards our goals as agents inspiring learning?  Finland has an excellent system of teacher feedback and peer/mentoring for their educators.  Teacher’s college is harder to get into there than medical school (not sure that’s a good thing, but it’s what Greg told us).

Key Points About Teaching & Learning

  • People have two kinds of memory layers – short and long term – and short term memory (which is what we are working with in classroom environments) can hold ~7 items +/- 2 so really we should aim for 5 in order to teach to our students’ capacity


  • We have to balance on/off time – we lose some time switching between tasks or concepts in the teaching but working with memory limitations as mentioned above, we must let people take breaks to reset & refresh


  • Avg person can take in info for about 45 minutes before their attention wanes from exhaustion.  For me, this is more like 30 minutes. Hearing this from Greg reminds me that I want to propose that all meetings I’m involved with at work move the default length to 30 minutes and that we have a set of rules for how to deal with ‘overage’.  Either email or mailing list post, etherpad, set up a follow-up meeting, or make a proposal and request feedback so that we are not taking an hour because we *have* an hour.


  • Apparently the military has a lot of research and effective solutions for human performance.  Greg mentioned being at a naval academy and the grad students he was lecturing to dropped into doing pushups when a bell sounded on the hour.  This sounds like a great practice for anyone trying to learn and be engaged with others – get your blood pumping and change your position.  Reminds me to get that automated rest-taking app running on my laptop again and to actually pay attention to it for a while instead of dismissing over and over.


  • Continuous ‘flow’ – oh that elusive state for programmers.  There was some sort of quote about coffee but I missed the first part, the gist was that when we are immersed in something and truly engaged we can override that 45 minute intake limitation from before but if we do more than pause (without switching contexts) we could end up breaking flow and it takes at least 5-10 minutes to get back into it. This is key for people who work in environments full of distractions and interruptions. I’ve been thinking a lot about this one lately as I’d like to work on breaking my very unproductive cycle of checking IRC and email in a loop as though I am event-driven.  I need to make times to get into ‘flow’ and do bigger tasks with more focus.


  • A sidebar of the distraction mention was the fact that, in programming, syntax can be the distraction. That is, errors in.  When you get stuck trying to figure out where your semi-colon or indentation is off you break out of ‘flow’. In a language/framework like Scratch this is not possible as the blocks cannot be dragged and dropped into any order that creates errors except in ways that are related to logic and program flow – worth stopping to think about (and keeping you in your engagement ‘flow’)


  • There are roughly three types of minds out there to work with in teaching: a) Novice b) Competent c) Expert.  The Novice doesn’t know what they don’t know so the most important thing to do when trying to teach a Novice is to make sure their mental model of the concept you are teaching is correct.  This is to become a lot of the focus in the rest of the day – methods of determining if our concept is getting across correctly.  The Expert is such because they have more connections between all the facts they know about the concept/skill and so they can leap from point A to point J in one move where it takes a Competent mind all the dots in between – executed well, but with thought and intention – to complete them.  It is *as hard* to get Novices to become Competent as it is to get Experts to see the concept they are trying to teach as a Competent person does.  Think about something you might be and Expert at and see if you can tell what steps you assume other people will know.


  • Another key point about the Expert is the idea of reflection. Being able to reflect on your skill is huge for honing it.  An example would be how I went to a hockey skating workshop where they video taped us skating our fastest and when I saw that video, saw how knock-kneed I was and how my internal map that I was using wide leg strokes did not actually look like that in the tape I was a) horrified but also b) it’s a reminder of how far I have to go and how much more work I need to do in order to reach a higher level of expertise, such as that reflected to me by the instructors.

Accepting Feedback and Critique

We spent some time talking about critique. In architecture, art, music, and many other disciplines there is a built-in system for critique.  It helps the student to build up their sense of self, to know their strengths and weaknesses.  We do not always have this in teaching.  In our workshop, Greg had people write down one piece of positive and one negative feedback on two sticky notes (yellow for positive, pink for negative) and he asked us to put them on a piece of paper at the front of the room before we headed out on our first break (just over an hour of instruction had occurred).  When we returned we discussed what the anonymous feedback had provided Greg with and what he could actually work on in the moment vs. what was useful for later.  He mentioned doing this, and letting it be anonymous, was a great way to build trust with your students. Also we talked about how to get better at accepting feedback, working with it, not letting it paralyze you or derail your lesson.

One of the key takeaways for me here was the idea that the most senior leader/teacher should model this for others.  Show that you can hear feedback, both good and negative (hopefully constructive), and be able to move forward without crumbling under the pressure.  While I’m nervous about feedback, I will do my best to ‘fake it till I make it’ on this point because it’s definitely more important to correct course and create a better experience for students than to be proud and lose their interest and especially, trust.

Concept Maps

Our next major concept was the concept map.  This is a way to help yourself understand what you are trying to teach. It’s also a way to check yourself for the 7 items +/- 2 factor. If you have more than 5 main concepts in the concept map, it’s time to evaluate it for what can be put aside for now or what can become the next lesson.  The concept map can also be shared with students as a way to make sure everyone is on the same page or at least starting with the same page.  Greg recommended handing out a printout of the concept map so that students could doodle and expand it in ways he might not have thought of.

We learned how the concept map should never be used for grading.  It’s mostly a tool for the teacher to know if they have managed to get across the mental model well enough for the novice to reflect back a matching map and feel comfortable moving on to the next concept. It’s also a way of preventing the “blank screen” where students can be frozen trying to come up with what to put down (in programming or in writing) and having a scaffolding there in the form of map, or hints, any form of guidance can basically jump start the student and hold their hand until they need less and less of it to self-start, self-direct, and truly *learn* autonomously.

We did an exercise where we drew up concept maps for how to teach a for loop.  This was my first time doing a concept map and it was hard.  Definitely will take practice and likely some more reading/looking at other concept maps to drive home the concept for myself.

concept map explaining a for loop
This is an attempt to map out the concepts required to understand a for loop – note we went over 5 items

Key points from Greg:

  • Make your concept map look ‘cheap’ so that people aren’t afraid to give you honest feedback
  • Write and share maps with each other – try this with your team at work on a project you’re starting – you might see that others have a *very* different sense of what is being attempted
  • Try not to need things in your concept map that you will “explain later” – if you can’t explain it now you’re going to disrupt the ‘flow’ of maximizing the short term memory limits
  • Transfer your map into a list of bullet points as it will help you put the most important concepts first
  • Think of concept mapping like couples dances. You both want to be doing the same dance or there will be a lot of bruised shins :)

Sticky Notes as Invaluable Teaching Tool

We used sticky notes at several points in this workshop.  While we only had two colours today, Greg recommends three colours to be used as follows:

  • Green:  Students can put this up in a visible place when they have completed the exercise currently being done
  • Yellow: Students can put this up when they have a question.  Also this is a great tool for ensuring more participation in the classroom setting.  Some people talk more than others, there are definitely certain types of people who take up more space, and the deal with the yellow stickies was: You get two, when you ask a question put one aside.  Another question?  Put the other aside.  Now you have no more questions until EVERYONE in the class has used at least one of their yellow stickies.
  • Red:  Students can pop this up in a visible place when they need help on something.  This is great for two reasons: 1) the student can keep *trying* instead of worrying about holding a hand up and waiting for eye contact with a teacher and 2) the student can request help without drawing too much attention to themselves.  This is great for classes with people who might have learned it’s best not to speak up, ask questions, or draw attention to themselves out of fear and/or shame.

Know Your End Goal

This probably shouldn’t have *blown my mind* but it did.  It’s so obvious yet I’ve never once designed curriculum with this approach. You can bet that’s all changed now.  Here’s the key point:


Ya.  It’s maybe obvious.  You want to make sure the students leave knowing what you intended to teach them?  Well, figure out how you’re going to measure that success *first*, then build your lesson up to that.  “They understand the for loop” is not enough.  Be specific.  Have a multiple choice question that tests the output of a for loop and gives 3 plausible answers and one right answer.  Use this to check if you are teaching well – their failure to choose the right question is your failure to teach the concept correctly.  This doesn’t have to be for actual grading (unless you want to grade yourself). Think of this like Test Driven Development for curriculum.  Teach to the goal.  You will develop lessons faster and more efficiently.  Your learners will appreciate it.  They can tell when they are learning vs. having a lecturer do a brain dump on them that goes nowhere in particular.  Backwards design works.  Greg’s book plug related to this section:  “Seeing Like a State

Another tip?  Create one or more user profiles for your lesson.  In our workshop we created Dawn: 15 year old girl who is good at science and math, learning programming in a one-day workshop. Then we did an exercise in crafting a question that would confirm if we had successfully taught how functions work to her.

We learned about Allison Elliott Tew‘s work and about “Concept Inventory” which is a way to use common mistakes in mental modeling to create multiple choice questions where the incorrect answers can help you understand *how* someone has misunderstood the concept you are trying to teach.  Multiple choice is great because it’s quick to get you an assessment (teacher grading time).

Peer Instruction

Related to multiple-choice as test of understanding is Peer Instruction.  This is a method that uses a multiple choice question in a really interesting, and engaging fashion.

Developed by Eric Mazur in the 1990′s this method expects students to have done some pre-work on the material before coming to class so that the entirety of the lesson can be used to compare and correct conceptual maps and understanding of the material.  It goes like this (at least Greg’s interpretation – it differs in Wikipedia as to how Eric designed it):

  1. Provide a multiple choice question based on the pre-work content.  Ensure 3 plausible answers and one correct
  2. Students select and *commit* to an answer (there is not yet software for this, though there are clickers) – you can also ask people to hold up the number of fingers for their choice and have classroom helpers count
  3. If everyone picks the right answer you can move on but otherwise you ask people to talk in groups with their neighbours to examine each other’s choices and what the correct answer might be and why.  This is great for having people explain their mental model/map
  4. Vote again and have students commit to the answer
  5. Instruction reveals the answer as well as perhaps a single sentence explaining why
  6. Groups discuss again, this time they can explore their understanding with the correct answer alongside people who, likely, had the correct model

This teaching technique was proven in 1989 but is still widely unused (esp. in MOOCs). Greg told us that he can usually do about 10 of these types of questions in a 1 hour class.  We did an example of one in the workshop to test out the method and it was a lively exercise.  This was also an opportunity for Greg to help us notice how noise in the room helps a teacher determine when a good time is to check in, continue the lesson, or make sure people aren’t stuck.  Active, engaged learning is boisterous and noticeably relaxed.  Quiet can mean focus, and then as people complete the exercise you can hear some discussions start up as those who are done talk with each other about the exercise.  I look forward to getting a bit of expertise at this level of listening and was impressed by Greg’s skills in classroom energy level reading.

F*ck It, I’m Outta Here

I have several more pages of notes but it’s getting late and this is a long post. There’s one more part of the workshop that I’d like to write about:  The moment when you decided you didn’t want to learn something anymore.

This is a really great piece of advice for teachers.  Greg started by saying that he used to ask students what motivated them to learn, what great experience in learning they had so he could tap into that motivation as a teacher.  Now?  He asks people what DE-motivated them.  You get a lot out of people this way.  Ask someone (or think of your own experiences): “What was something you were curious about, working on, getting into, and what happened that made you say ‘f*ck it’ and drop it? If you could go back in time what would you change?”.

For my example I spoke about returning to gym class at 12 years of age after recovering for many months from a very physically traumatic incident where I was hit by a car while on my bike (15 bones broken, 6 months in a wheelchair).  Being immobilized *and* being a pre-teen caused me to put on a fair amount of weight and I was no longer very physically active or able.  I also had yet-to-be-diagnosed asthma.  Not only did I have to endure a gym class where those with natural talents were help up while the rest of us were discarded but I also continued to fail tremendously at getting more than a “Participation” certificate(! Every other result got a very nice badge) for the Canada Fitness Test.

My “F*ck it” moment was when I got so frustrated with never getting a badge that I stole someone’s gold badge when no one was watching.  I also ended up eschewing all sports and athletic pursuits for many years if there was any hint of tryouts or actual talent needed.  Years later, at 29, I taught myself how to run by using a couch-to-10K program that did repetitions of running and walking in order to build up endurance.  Not only did I succeed at that but I learned to *love* running and feeling healthier in my body.  If I could go back in time I would become a Physical Education teacher and make sure every kid in my class knew that it’s not about natural talent at anything. It’s about setting achievable goals for yourself and comparing your results against your OWN RESULTS.  Never mind some test, and other kids. We’re all very different but no one should be denied a sense of accomplishment.  It’s what keeps you coming back to learn & build on what you’ve learned.

Badges awarded to Canada Fitness Test Participants
The coveted badges.


Now Go Read More: Keep Learning How to Teach

It was an amazing day.  I have more notes to transcribe for myself but I think I’ve managed to capture the major concepts I learned today that will all be invaluable in my work on Ascend and beyond. Greg is an experienced, passionate, driven teacher and his enthusiasm for *knowing* what works in education is contagious.  I want to be a better scientist and educator too. The Software Carpentry movement is picking up momentum.  Look for workshops, blog posts, and opportunities to participate in a town near you.   See their site for up to date information and also check out their materials page for additional resources.  I’ve got a few new books to read on the plane home tomorrow.

Ascend Project Kickoff

Last year I approached Debbie Cohen, our C-level People person, and made a proposal.  With all these Hacker School/Dev Boot Camp/Hackbright accelerator programs popping up, I had an idea to create an open source version and specifically target participants who come from underemployed, LGBTQ, Latin@, and African American populations – aka: people who are terribly underrepresented in tech but also very much more so in Open Source. The idea was that instead of people paying to come learn to become developers in the capitalist, Startup-focused, feeding-frenzy the Silicon Valley promotes we could instead seed other towns, other communities with open source and create an in-depth technical contribution training program that more mirrored the experience I had with Dave Humphrey at Seneca College. Imagine my surprise when Debbie clearly, and without hesitation said to me “Great idea! Do it!”.  I’ve been building up to something that is more sizeable through running local events, hack meetups, participating in community building in several ways so I saw this proposal as the next step for me, as an organizer.  This time I’m going to do something that is bigger than what I could do alone. I will have Christie Koehler working with me as well as several community building team members in advising and mentoring roles.

The populations I want us to reach out to have resulted in certain adjustments to the typical setup of those for-profit accelerators which I see as being key to the potential success of our cohorts. Attendees in the Ascend Project will benefit from taking this course in the following ways, which are intended to remove many barriers to participation in Open Source:

  •  a $50 per day honorarium will be provided to encourage regular attendance and help ensure participants can afford to focus on being present to learn & develop
  • laptops will be provided to use during the course and upon completion, graduates will get to keep theirs
  • food (breakfast and lunch) will be provided every day
  • where needed, childcare stipends are available to participants who need additional care in order to put in the time this course will request of them
  • transit passes for the whole 6 weeks

The purpose here is to not only acknowledge that we know we’re missing people in our open source communities but that we’re willing to put our money and time where our mouths are to go and explicitly invite people who like to solve problems to come and see what it is like to get to just focus on learning, developing, fixing a bug, getting hooked, being a part of a bigger community with a mission for global good.  I see this as a solid way to counter the manner in which many of these populations are pushed away from participation in computer science and open source contributions.

We can’t expect every person who might be a strong, longtime, and impactful contributor to Open Source to find us based on passion alone.  That leaves all the systemic issues in society to decide for us who gets here.  If we can remove some barriers and provide an environment where participants in a program get a chance to feel confident, trusted, strong, and *wanted* then we can see how that might blossom their abilities to learn and contribute to an open source project that has a ton of pathways for potential input and impact.

The project is currently still in the kickoff phase so this is the first public post.  Mostly I’m braindumping, trying to work backwards from September when the course will start, and getting my head around who will do what so we get everything ready in time.  I’ve got a budget for the first pilot, which will take place in Portland, OR in the Fall of 2014, and it’s almost approved.  Next up I will be designing the curriculum while Christie works on partnerships locally in preparation for our call for applications.  We’ll be doing our best to reach far outside the typical degrees of separation to get word out and to attract applicants.  I’ll be in Portland next week to meet with local orgs and gather information on where we can promote the project.

Applicants will go through several steps before we whittle down to our final 20.  There will be an expectation that they can complete the highest level of a free, online Javascript course and the Mozilla PDX office will hold drop ins with computers available to help applicants have the time to do this with the right equipment and a mentor or two nearby.  Following that stage, we’ll ask for an essay or video that briefly describes a ‘hard’ problem the person had to solve, if they were successful what worked and if not what didn’t.  Staying away from specific, alienating technology language seems key here. We need problem solvers and self-starters, not people who know syntax (yet).  That group will then be the pool from which the final participants will be selected from, with specific ratio targets for populations that I mentioned earlier.

The first session, as a pilot, will have certain ‘training wheels’ on it. Mozilla has a great space in Portland.  Portland has a wonderfully large open source community I fully expect to tap into for networking and partnerships.  We’ll be using this first pilot as a way to test the participant selection process and the curriculum itself.  I really want to be setting people up for success.  This is measured by committing at least one patch to production code (in any area of Firefox) before the end of the course.  Our first course will focus on Mozmill automated testing because we can get our participants to that level of success with independently-written JS tests for several of the Firefox products.

Following Portland we’ll be reviewing, updating, improving, and then taking the next pilot to New Orleans in January of 2015 where we can test “what happens if we don’t have an office, a large community already in place?” with our tightened up selection process and curriculum.  The two pilots should give us lots to go on for how to scale up an initiative like this going forward and hopefully it can become something that happens more frequently, with more teachers, and in many more places (like in some of our Firefox OS launch markets).

That’s the gist for now.  I’ll be posting more frequently as we hit milestones in the project and also am happy to take people up on offers to review curriculum.

Why I was part of creating a thing called TransTech(SF)

Last night I helped hold the third local meetup of trans and genderqueer people who are interested in getting together to hack on our projects. This is the third event since the amazing Trans*H4CK  Hackathon (the first one of its kind!) that took place in October 2013.

When I heard through the grapevine that there was going to be a trans-focused, trans-organized, local hackathon I was beside myself.  Finally I would get the combination of identity and technology in one space that I have been dreaming of since going back to school as a mature student in 2004-5 in order to get a degree in Software Development.  My lofty goals in going back to school can easily be summarized in two ways: 1. I wanted to get a better job than being a brunch chef or a non-profit artist-run center, contract employee with no job security or dental benefits and 2. I hoped that whatever I could learn about technology and software would become tools I could bring back to my queer/trans/genderqueer/arts community and help anyone who wanted it at whatever level they ask for.  This has come to mean hosting websites for people, helping build websites for people and small orgs, and also doing some random consulting. It has also led, funny enough, to a certain amount of fixing people’s computers.  That’s nothing I learned in school, it’s just something I seem to have the right combination of lucky and chutzpah to try — ratio of success lies at about 85-90% so far (some things are unfixable, by me at least).

Anyway, I got into tech and got through a grueling 4 years of school with all its associated stresses.  No need to go into details because I finished that thing AND I got a pretty amazing job right out the gate.  Health benefits (specifically the much-needed dental)?  Check.  Ability to help my communities with tech stuff?  Yes….ish.

Turns out it’s not that easy to still be people’s go-to for tech help when you start working more-than-fulltime at a fast-paced company. Also when you move across the country from the majority of your closest friends and aquaintance community.  I made that decision though because I wanted to take the opportunity that existed for me to come here, to SF, and be in the heart of it all.  Little did I know at the time I was walking on stage at a very precarious time (that’s a whole other post).

Skip forward.  I’m lucky enough to have one woman (self-identified to me as a feminist on our first meeting) on my team of 8 people.  So I think tech is pretty awesome. Then she leaves, goes to another team.  Then I go to my first PyCon and swim in a sea of homogenous men I don’t know.  Then I meet a handful of really exciting people who put the words “Queer” and “Tech” on a scrap of paper for a DIY session in the basement of that hotel in Atlanta, 2009.  That is one of the *big* moments.  It’s when I started, with that group of people, to promote teaching Python to women. Based on the success of RailsBridge‘s workshops teaching Ruby on Rails to women (I went to one, Ruby and Rails are not my thing for now) and also the Boston Python Workshop which did a lot of the groundwork for adapting the RailsBridge-style weekend material to a Python version, I ended up starting PyStar with a few people. Our goal was similar:  make it possible for more women to feel comfortable learning Python in a non alpha-male space.  We had a few workshops in SF and Mountain View (Mozilla office space was easy to get and use for weekend workshops). There were groups creating workshops in Philadelphia (still, to this day, the most active city for this project) and in Minneapolis.  I even threw one together in Paris for a night when I was living there for 3 weeks and working from the Paris Mozilla office.

I’m sharing this with you, reader, because this is the backdrop for what comes next.  For me, teaching women to code was…OK.  Don’t get me wrong – it’s important work and I’m glad it’s happening.  For me though, I still felt kind of lonely.  Since the majority of attendees were middle/upper class, young, heterosexual women I wasn’t really connecting on the levels that I do with people who share other similar identities and life experiences with me.  Or at least ones I am more familiar with, if not my own.

I got a bit disheartened by organizing events that I no longer felt I truly connected with and I took some time to try and figure out how to best spend my time and how to be the activist I wanted to be.  Enter GeekFeminism, having several of the people I met through that hired on at Mozilla, PyCon drastically improving its ratio of women attendees (speakers, still being improved), and meeting Leanne.  Over the past couple of years, again keeping it short, I’ve managed to go to conferences and meet lots of people and dream big with them. The LGBT lunches at Grace Hopper have been fascinating.  Getting to attend AdaCamp – huge boost.  Finding people and connecting with them on all the things that are big problems we want to be a part of solving — the one is often comes down to is “How do we get more diversity in tech?”.

At Mozilla I end up making that a second full-time job that is not what I am paid to do (working on that).  Instead I got discretionary funding that I could use to help leverage women in open source which eventually grew into supporting anything with diverse populations that were not prominent or numerically well-represented in open source.  This looked like me being able to offer up the Mozilla office(s) if and when I could be there to hold the space.  It looked like being able to sponsor a variety of events with amounts less than $2k who were promoting, retaining, or otherwise engaging people in tech & open source more specifically.

One of the events I ended up directing money towards was Trans*H4CK because, as I mentioned at the start – I was so frickin’ excited that this was going to happen and I wanted to help it happen.  I reached out to Kortney and offered money, asked if (while I was planning to attend regardless) I could talk for 5 minutes about open source. I did that.  I went and talked and gave my, now usual, talk about why open source is important (think: View Source on webpages and how you might have benefited from being able to do that).  Then I hacked on stuff and met people and generally soaked up what it felt like to be in a space where I felt seen, whole, and just surrounded by people who were also being seen.  We exist, in numbers more than the one or two at your day job! What a fun weekend.

Then I wondered – why just one weekend?  This was in the Bay Area and while a handful of people traveled to the event most were local.  In the style of user groups and meetups, why not continue to have a monthly get-together of this particular blend of nerdgeektransgenderqueer fabulousness?  I proposed this to Kortney, offered up the Mozilla SF space to hold it, got food for the attendees, and we had one in November that was probably attended by about 20 people.  Pretty sweet.  There was a lot more socializing than actual hacking but that happens when people are still so new to getting to be around each other.  With the success of that, I wanted to hold more but I think the holiday period got in the way so the next one I helped put on, this time at the Double Union maker space, was February 18th, 2014.  It being closer to my house and not at the office I rarely go to anyway was awesome, btw. Also I bought snacks with my own money to bring. That night I thought: we need a regular night – say, the third Tuesday of every month, so that it can be something people just *know* is on and can show up to. No need for invites, mailouts, or headcount – keep it simple. I proposed this to the people at the meetup, and thought this was generally agreed upon.

With that in mind, and with a pretty busy schedule coming up, I wanted to get the March date on the Double Union calendar sooner rather than later so a couple of weeks ago I reached out to the membership list asking if the Tuesday night circuit class would be up for sharing the space with another trans hacking night (as that was the best date for me, as the organizer).  They were open to it and all seemed fine but another email thread started up about whether or not the trans hacking nights would be trans-only or not (if they should, even).  This is something, btw, that the TransTech community participants will be chatting more about so as to determine what guidelines and priorities to have when choosing space or setting up meetings. In that thread Kortney expressed concern about not being able to make the date and I said that I was trying to set up the every-third-Tuesday nights, as discussed at the February meeting.  No further response came and I went ahead with booking it (circuit group moved to another night to give us the whole space, thanks!) and setting up an invite.  Double Union still doesn’t publicize their address so the invite was needed to have a way to reach people who said they would attend.  My goal was to use this next meetup to set up open communication tools that could be used by any member of this nascent “we get together and hack on stuff with other trans/genderqueer people” community.  So we did that.

Last night I was at Double Union with some others and I set up a mailing list, a wiki, and IRC channel, and a Twitter account.  I shared all the admin/login details with the others because this isn’t *my* thing. This is, to the best of my knowledge and experience in open source, how we start communities that are as free of bottlenecks on getting things done as possible.  Then I put that information out there.  The goals, again, are to have spaces where trans and genderqueer people who are in technology (or want to learn to be) can meetup to work on their projects or even work on each other’s projects.  I hope we’ll also get to work on projects that help our communities, for example I’m trying to figure out how to help Homomobiles get an app as it drives me nuts to see people using Uber and Lyft when we have this opportunity to put even a sliver of our collective queer and trans money back to a queer and trans organization and help grow it.

All that to say:  There’s always room for lots of ways to bring people together. This is my expression of how I do it.  Mozilla, while being my employer, does not dictate what I do with my spare time and yet I am fortunate in being able to book our office space(s) when available for events.

I’m being told on Facebook and Twitter that this is stealing, that I’m stepping on Kortney’s toes and please believe me, I tried to do everything I could to avoid that. I intentionally sought another name out of respect for the way that I see Kortney branding and promoting Trans*H4CK and how he is doing great things with that.  I see TransCode (teaching coding), Trans*H4CK (hackathons and speaker series), and then TransTech (local community building, mentor/mentee finding, getting things done in a room with people you have that certain connection with) as all being part of the building blocks for continuing a trajectory of making and taking up space in technology for those of us who are outsiders, underrepresented, or just plain want to put our efforts into working with other social justice activists in building trans & genderqueer focused space.

If you’re in the Bay Area and want to know about meetups, be part of shaping this community, or otherwise lurk about to see what might grab your interest down the road then please follow us on Twitter and/or join our mailing list: https://mailman-mail5.webfaction.com/listinfo/transtech-discuss

Let’s support each other in always leveling up.






I’m looking at you, Gift Horse

a wall of snack food, mostly sugarey
I have to avoid this. All. Day. Which turns into “avoid the office”.

I’m going to say something that might be controversial, or hard to understand for some folks but it’s getting to the point where I’m starting to stay away from the office more than I’d like to so here goes:

The snacks. The never-ending supply that I would *never* eat otherwise. That I would not go to a corner store and purchase. I really wish they were gone. I wish that we, people who all make salaries above that needed for living decently, were accountable for buying and bringing in our own snacks as we chose. Keep them at your desk, share with nearby co-workers, I would love to see this. It would be so much better for me if the only things we had in the kitchen were fruit and veg. Milk for coffee, sure.

When I first started working for Mozilla, as a working class grew up broke kid, I was floored by all the free stuff & free food. I lived off it as an intern to save money. I appreciated it. It made me feel cared for. Now it’s like a trap. A constant test of my ability to make “good” decisions for myself 250 times a day. Often I fail. Failure makes me stay away from the office as an attempt to cope. Staying away from the office causes loss of connection with you all.

I suspect there might be feelings of being ‘punished’ if the snacks were less abundant (or even gone) because we’re used to all these ‘perks’ in our tech offices. It’s not something most offices (outside of tech industry) have and I would encourage a perspective shift towards accountability, recognizing the privileges we *already* have even without free all-day snacks, and thinking about what it means if some people have to choose to stay away.  Considering the origin of these snacks is from a startup mentality where workers were expected to be pulling really long hours without getting up, out, or going home.  Is that really what we want to promote and call a perk?

My Imaginary Sabbatical

My partner has been granted a very well deserved year-long sabbatical starting in late May and that got me thinking about what my days would look like if I had a small sabbatical.  Fortunately Mozilla’s offices will be closing over the winter holidays so I’ll have about 2 weeks to enact this plan.

  1. Run in the morning (if rained out, yoga) every other morning
  2. Spanish lessons
  3. Take the dogs for a 3-4 mile hike on non-run days, otherwise the usual 45 min loop
  4. Practice stickhandling skills
  5. Play Guitar & Ukelele
  6. Dog training & games
  7. Cook a new recipe for dinner
  8. Work on an interesting web project (I have several in half-finished states, would like to FINISH one)  OR
  9. Play cards/Catan/some new game

I’ll be trying my best to follow that agenda for 2 weeks straight and I expect to feel a sense of accomplishment in several areas of interest by the end of it.

Adding more Beta releases to the train

In March of 2011 we shipped Firefox 4 and moved to a rapid release with 6 weeks on each of Nightly, Aurora, and Beta channels prior to shipping a new major version of Firefox Desktop and Mobile to our users. Both Nightly and Aurora channels were getting builds & updates nightly (breakage notwithstanding) while Beta builds were still a highly managed, hands-on release product that shipped once per week, giving 6 builds in all unless there were additional last-minute landings  (typically critical security or 3rd party plugin/addon issues) requiring a beta 7 or, rarely, 8 prior to building our release candidate for that version.

Go to build by or before Tuesday EOD Pacific time, builds would be pushed to beta channel as soon as QA signed off which could be Friday morning or sometimes Thursday afternoons if done early.
Go to build by or before Tuesday EOD Pacific time, builds would be pushed to beta channel as soon as QA signed off which could be Friday morning or sometimes Thursday afternoons if done early.

This is the model we followed up until Firefox 23.  Starting in Firefox 15 we had the ability to perform silent, background updating which meant that we could push more updates to releases without causing update fatigue. Release Management, Release Engineering, QA, Stability, Support hashed out what it would take to move to a system where Beta builds are done on a nightly, automated manner.  We dubbed this a Rapid Beta model and as work from all teams has been done toward that goal we have managed to get a handle on where the bottlenecks are which impeding the complete automation of pushing out the most recent Beta code to our 10 million Beta users.

The reason it is to our advantage to get more builds to Beta users is because at 1/10th of our general release population, the faster we can get fixes (especially crash fixes or speculative fixes for compatibility and addon/plugin breakage) to our users, the sooner we can collect much-needed data that can verify the quality of our impending final build.  With the previous model, fixes missing a beta train meant that much more risk was added to the landing and typically we throttled the landing of all but the most serious security and usability patches back after the 4th beta meaning sometimes developers (and release managers) would be forced to make more pressured decisions about whether something could make a release or have to wait 8 more weeks to be in the next train.

QA did work to pare down on the manual testing needed for sign-off, Release Engineering put together a fabulous Ship-It web interface that Release Management could use to request builds in a more hands-off way to make the processes around starting & monitoring a new beta build much less time intensive.  Socorro work was done to make it possible to match crash data to build IDs so that we could technically support nightly Beta builds and see stability data in useful ways. Once all this work was in place we took a leap of faith and started releasing twice as many Beta builds in weeks 2-5 of the cycle for Firefox 23.

    First and last week still have one beta, weeks 2-5 have two builds per week where one is built on Monday shipping by Wednesday and the other build starts Thursday and ships by end of day Friday.
First and last week still have one beta, weeks 2-5 have two builds per week where one is built on Monday shipping by Wednesday and the other build starts Thursday and ships by end of day Friday.

This new model has had two full releases now, Firefox 23 & 24.  The feedback so far has been quite positive.  Release Engineering has been minimally called upon when the shipping app interface hit glitches, but those are mostly ironed out now.  QA is turning around their sign off of Firefox Desktop within approximately 24 hours and according to them their bug fix verification rates are going up with this new model in part because the smaller changes per Beta allow them to focus more.  They’ve also had an intern and have had their remote testers team gain additional resources, but the switch to more frequent Betas has apparently gone quite smoothly for them.  From a Release Management perspective, the tracking & landing of fixes on Beta is going much better since we now have less panic & stress on landings at the beginning of each week.  With one Beta getting kicked off on Mondays we start the week with something to start evaluating mid-week and then we continue to pick up fixes as developers start their week in order to get another build for feedback gathered over the weekend.

We're moving away from spikes of landings near the end of the Beta cycle now that we have more Betas for people to land in.
We’re moving away from spikes of landings near the end of the Beta cycle now that we have more Betas for people to land in.

Though the data is a little rough right now (I’m dreaming of a pushlog DB), the numbers so far look like we’re doing a good job of spreading out the landings over the course of the cycle, still tapering off at the end:

Landings are more evenly spread out in a week.
Landings are more evenly spread out in a week.

While at the same time, our overall tracking average remains stable and our tracked bugs fixed rate has been holding over 90% per release for the past 3 releases:

Tracking bugs fixed over unfixed Screen Shot 2013-10-17 at 5.55.12 PMScreen Shot 2013-10-17 at 5.57.07 PM Tracked to fixed percentage









Along with these improvements to getting features, regression & crash fixes to our users sooner with more automation and hands-off processes, we’ve been getting a lot out of the fact that we now have people who are full time sheriffs of the tree.  Ryan VanderMeulen and Ed Morley are doing a lot of the heavy lifting keeping uplifts in order and landing frequently as well as monitoring the trees for breakage.  Having managed trees, as well as team trees for active development is likely responsible for our tracking+/fix ratio on mozilla-central improving over time.

Finally, what’s most important from this experiment and what we consider to be the biggest win so far is that this new beta model helps release drivers over the whole cycle make decisions about uplifts with less concern about timing, and more focus on overall risk to product. Having more Beta builds means not having to make rash decisions because of scarcity.  We will continue to collect data and monitor our progress as well as work towards automated, nightly Beta builds since that would get us crash feedback on a more granular level but for now I see this current progress as a huge step forward for the stability and quality of our releases. Neither of the last two releases had to be followed by dot releases for anything we could have prevented.  Our Beta audience size holds strong, confirming that background updates are doing their job.  Next up we’ll be looking at potentially moving to a slightly longer, and overlapping Beta cycle while shortening time on Aurora – but that’s another post for another time.


Contribution opportunity: Early Feedback Community Release Manager

I’ve been in Release Management for 1.8 years now and in that time we’ve grown from one overworked Release Manager to a team of 4 where we can start to split out responsibilities, cover more ground on a particular channel, and also…breathe a bit. With some of the team moving focus over to Firefox OS, we’ve opened up a great opportunity for a Mozillian to help Release Management drive Firefox Desktop & Mobile releases.

We’re looking for someone committed to learning the deepest, darkest secrets of release management who has a few hours a week consistently available to work with us by helping gather early feedback on our Nightly channel (aka mozilla-central or ‘trunk’).  This very fabulous volunteer would get mentoring on tools, process, and build up awareness of risk needed for shipping software to 400 million users, starting at the earliest stage in development. On our Nightly/trunk channel there can be over 3000 changes in the 6 week development cycle and you’d be the primary person calling out potentially critical issues so they are less likely to cause pain to the user-facing release channels with larger audiences.

A long time back, in a post about developing community IT positions, mrz recalled a post where I stated that to have successful integration of community volunteers with paid staff in an organization there has to be time dedicated to working with that community member that is included in an employees hours so that the experience can be positive for both parties.  It can’t just be “off the side of the desk” for the employee because that creates the risk of burnt out which can lead to communication irregularities with the volunteer and make them feel unneeded.  For this community release manager position I will be able to put my time where my mouth is and dedicate hours in my week to actively shape and guide this community Release Manager in order to ensure they get the skills needed while we get the quality improvements in our product.

So here goes with an “official” call for help, come get in on the excitement with us.


  • Are familiar and interested in distributed development tools (version control, bug tracker) typically used in an open source project of size (remember when I said 400 million users? Ya, it’s not a small code base)
  • Want to learn (or already know) how to identify critical issues in a pool of bugs filed against a code base that branches every 6 weeks
  • Have worked in open source, or are extremely enthusiastic about learning how to do things in the open with a very diverse, global community of passionate contributors
  • Can demonstrate facility with public communications (do you blog, tweet, have a presence online with an audience?)
  • Will be part of the team that drives what goes in to final Firefox releases
  • Learn to coordinate across functional teams (security, support, engineering, quality assurance, marketing, localization)
  • Have an opportunity to develop tools & work with us to improve existing release processes and build your portfolio/resume


  • Mentor and guide your learning in how to ship a massive, open source software project under a brand that’s comparable to major for-profit technology companies (read: we’re competitive but we’re doing it for different end goals)
  • Teach you how to triage bugs and work with engineers to uncover issues and develop your intuition and decision making skills when weighing security/stability concerns with what’s best for our users
  • On-site time with Mozillians outside of Summits & work weeks – access to engineers, project managers, and other functional teams – get real world experience in how to work cross-functionally
  • Invitations to local work weeks where you can learn how to take leadership on ways to improve pre-release quality and stability that improve our Firefox Desktop/Mobile releases
  • provide references, t-shirts, and sometimes cupcakes :)

I’ll be posting this around and looking to chat with people either in person (if you’re in the Bay Area) or over vidyo. The best part is you can be anywhere in the world – we’ll figure out how to work with your schedule to ensure you get the guidance and mentoring you’re looking for.

Look forward to hearing from you! Let’s roll up our sleeves and make Firefox even better for our users!



Planning a Summit is hard, let’s go shopping

Hello fellow Mozillians (and curious onlookers)!

In a couple of days you will, en-masse, get your first peek at the high level agenda of the 3 day MegaMozillaFest you’ll be cannon-balling into this coming October. As someone who feels very fortunate to have been part of the planning processes (more multiple threads than you can shake a stick at) I thought I’d take some time during my layover en-route to Toronto and fill you in on what got us here in the hopes that:

  • I can shine light on how much hard work and sincerity went into the organization so that participants can get a lot out of this experience
  • You can see how many different voices and teams come together to plan an event at this scale
  • You’ll become as excited as I am (or close) for the journey we’re about to go on together this fall

It started, for me, back in June when 70 ‘delegates’ were brought together at the Mozilla Paris office to begin the conversations that were intended to bubble up the big issues and tensions that our community needs to address at Summit.

Wait.  It started before that.

For delegates going to the Paris Planning Assembly, we were asked to go out and interview people in our ‘functional areas’ and query them about the story of how they got engaged with Mozilla, what they perceived our challenges and opportunities to be, and where they see Mozilla going in the next 10-15 years.  I reached out to our Homozilla list, WoMoz, and also to the Firefox Team – a nice, diverse group of people to try and drag up some feedback to bring.

Sidebar:  We often get asked to seek feedback from others in preparation and most recently I did this for a TRIBE workshop. From doing those interviews in person I now plan to commit to doing all sorts of info-gatherings in person/vidyo rather than over email.  It’s too easy to send out an email blast and then just pick up what comes back to you. I get so much more from talking with a person face-to-face (video chat counts) and as you’ll see later in the post about Summit planning, it’s important to go a little further trying to encourage feedback than just a one-way missive over email that can be easily ignored or missed.


I got less feedback from people than I would want or expect.  It’s a part of our culture to be cycling rapidly on our work and that results in a general air of being overwhelmed and too busy to do anything out of the usual routine so I largely attribute the low response rate to that. For my part I could have framed the questions differently, reached out to individual people instead of group lists, held a vidyo ‘office hours’ to talk with people in person, and followed up more (ie: nagging, a RelMan’s #1 skill).

Minimal feedback aside, I went to Paris feeling very much like I could bring a certain voice to the discussions as someone who wears many hats in our organization and who’s been involved with the project since 2006.  Also, as a former unpaid contributor, intern, then full time hire I can imagine some of the realities of what it’s like in the shoes of many  Mozillians.

I’ve already written a bit about what happened at the Paris Summit Planning and how it impacted me so I’ll sum up by sharing that when we left Paris the “what’s next?” action was that we each put our names to one of 5 groups where we could be called upon later for ideas/session planning/accountability for that area: People, Process, Product, Strategy, Purpose

Those groups then got turned into three track themes and were assigned two track leads who would work with Steering Committee members on refining the sessions for each as well as with the other delegates from Paris who had signed up to be accountable for those topics.  The entire breakdown of this process is handily in a wiki page, but here’s the high level of who’s involved so you know who I’ve been working with for the past month or so:

  • Purpose & Strategy – Track Leads: myself and Michelle Thorne, Steering Committee: Mitchell Baker and Mark Surman
  • Products & Technology – Track Leads: Dave Herman and David Ascher, Steering Committee: Jay Sullivan and Brendan Eich
  • People & Process – Track Leads: Michael Coates and Zbigniew Braniecki (Gandalf), Steering Committee: Debbie Cohen and Jim Cook

The above listed people, along with Dino Anderson and Dia Bondi (and then a whole host of people behind the scenes like Kate, Mardi, and outside contractors) shepherded us through the last month while we did 3 iterations on an agenda in order to get the results you’ll all see this Tuesday.  We held a TON of meetings with each other, in our small Track groups, and with our body of delegates from Paris. In our group, Purpose and Strategy, we kept circling back to the Nature of Mozilla (NoM) and how to best transmit that message so it can be held as the core of every Mozillian’s understanding of who we are, why we are, and what we do.  We’d have to ask ourselves: Do our sessions have NoM aspects to them?  If not, this isn’t the time.  The very core of what makes us Mozillian is the key to this experience because it’s at the heart of how we will move into the future with our new projects as well as continuing to properly steer our existing ships in the waters of the open web.

During this process of multiple hour-long or more meetings each week with some serious thinkers & planners at Mozilla, several things happened for me:

  • I worried sometimes that we had become too narrow, that as such a small group we weren’t getting enough input, yet at the same time I saw new, and very engaged people at the table taking on leadership roles and bringing up strong points. I had to trust that this part of the planning process (similar to with the Paris planning) was for the best and that we’d get the right pieces cobbled together – always with the larger group who will attend & participate in the final product foremost in our minds.
  • It was reinforced for me many times over how it is for me to participate in meetings that are over 30 minutes long. I’m really going to need to work on that for my own professional development and opportunities in the future.  I’m most definitely open to suggestions on how I can ‘game’ my own self to be better at meetings. In TRIBE we learned about the forms of listening and I’ve been aware of/practiced active listening for 2 decades but there’s something about meetings – the group factor, the agendas, getting off topic.  Perhaps some training in facilitation might help understand this area better.
  • At the beginning of our meetings Dino asked all the Track Leads to speak a little about how we work best and I stated that I always prefer *doing* and am at my best with a list of clear steps to take. While I still enjoy talking/dreaming big, at the end of a rousing brainstorming I need that list of “now what?” and it had better be clear what is expected from me next. This planning process was definitely done in a way that met & exceeded my needs in that area. I applaud all the people who are at the top of the accountability chain for the Summit on their skillful communications and guidance throughout the last few months.
  • I felt incredibly fortunate to be a part of the creation of this next milestone in our shared Mozilla experience.  We were *creating* a journey for (almost) all Mozillians to share.  Having these touchstones within a project is so important. Being at the table to dream up and then turn into actuality the plan for complete engagement, alignment, and inspiration of what will get us all to the next billion web users is a heady task and I truly believe we’re very much on the right track to providing a creative and engaging space in October that will change all of your lives in good ways.

At the end of our last agenda review, I was filled with excitement about our schedule:  Science & Culture Fairs, lots of Open Sessions, something called ‘Speedgeeking’ which I suspect will be like lightning talks, and then the overall story we’re going to learn about but also build into over 3 days. I’m sad that I’m missing almost 2/3 of Summit due to a prior commitment to the Grace Hopper Conference Open Source Day but I’ll join many of you on Saturday evening in Toronto and go deep Sunday so I can get the most out of it.

I hope this explanation of the process helps you understand how many people put in a lot of time to create what you’ll be participating in.  Please join us with an open heart to the goals of this gathering – whichever location you end up in – know that we brought in as many of your voices as we could, that we want more than anything for you to get as excited about Mozilla’s future as we’ve been while dreaming about how we’re all going to build it together, aligned and re-energized.  See you in October!


Women Hacking Glass – First SF community meetup

I’ve created an event for the first meeting of Women Hacking Glass in SF at the Mozilla public space.

Since I posted in G+ a few weeks ago things got busy and I didn’t have time to lean on Google like I’d planned to ask for hardware but then a pair of Glass practically fell in my lap when a coworker decided he didn’t want to be an Explorer any more so I wrangled a ‘donation’ to get his Glass in order to use them for community hacking with other women in the Bay Area.  I’m curious to see how the first meetup goes – what will we be able to create?  What kinds of feedback will we provide to the GDK developers who are working on the first version of a release?  What kinds of barriers will we hit with Mirror API?  I look forward to learning about everyone’s hopes and dreams for this exciting hardware and finding ways to hack our way to making them a reality.

Copy from the event invite:

Are you interested in learning how to make apps for Google Glass?  Don’t have the access to the hardware?

Come out to Mozilla SF and meet with other Glass Hacking gals to experiment with Android Studio, creating simple apps, getting access to Mirror API, and trying out your hacks on an actual pair of Glass that will be made available during WHG meetups for testing on.  Since there are very few people out there with the hardware, and few of those early adopter/explorers are women let’s work together to increase the numbers of women getting in on the ground floor for development (as well as being able to provide feedback to Google GDK developers) on this revolutionary new hardware.

There is a small (non-refundable) fee to prevent no-shows from taking up space – all money generated from this event will be donated to Mozilla Foundation via http://www.mozilla.org/donate

Prepare ahead of time:

* Have a google account

* Read https://developers.google.com/glass/quickstart/index and do as much of the pre-installation of tools/IDE that you can

* Think about your first app and what you want to learn to build

* Dream big, show up

For people who are interested in applying pressure to Google and showing them there are women interested in developing for Glass (the current Glass Developers group is easily 95% male) – go to http://www.google.com/glass/start/how-to-get-one/ and submit your request anyway, even though they say the waitlist is full.  My coworker can’t be the only person returning his pair and I trust Google will open more spots when they see a lot of interest.

Challenge: No more new clothes for one year

I need a place to record that on July 2nd I purchased the pieces for a tuxedo and took my lady out to the opera. At that point, and even before then, I’ve been realizing that I have _enough_ clothes, shoes, jackets, socks, underwear. There is nothing that I _need_ or am missing in my sartorial life. I’d like to spend less frivolously. I’d like to not contribute to the sweatshops that make a lot of our off-the-rack clothes. I miss thrifting outfits and I should really support the good causes that run thrift stores. For those reasons and others, I am going to try and make it one year without purchasing any more new clothing. I’ll unsubscribe from some of my favourite haunts so as to not get taunted by sales and new items. I think it won’t be that hard but we’ll see. July 2, 2013 was the last time I purchased a new clothing item. One year, here we go.