Pairing with Junior Developers

A few months ago, I wrote up a piece for mid-level and senior devs about how to usefully pair program with a less-experienced partner. You can find it on the DevMynd blog.

You may also be interested in my article here on my first two months of full-time pairing, written back in the day when I had just started at Pivotal Labs. I’ve been meaning to write a followup for a few years now on the long-term effects of full-time pair programming; I haven’t seen that topic covered in depth elsewhere. I’ve paired for six years now, and I still wouldn’t go back to solo programming.

But in the meantime, please enjoy the piece on mixed-level pairing, and let me know your thoughts.

The FOSDEM Conundrum

Originally published Saturday Jan 31 2015; now updated with Sunday Feb 01’s developments!

My Twitter timeline has been full of Belgium.

I’m in San Francisco, but many of my developer friends are in Brussels for FOSDEM, an annual free software conference with 5000+ attendees, which this year had a Ruby “room” (like a track). Everyone seemed to be having a great time. I saw snapshots of chocolate waffles, beer, and most compelling of all, some distinguished gentlemen wearing lab coats for a joint talk. It looked really fun! I felt the familiar tug of wishing I were there.

Then I saw this:

"My first FOSDEM. Lots of neat things. However, diversity needs a lot of help. ~5K+ caucasian dudes."


And then this:

"how many females are here" "10-15% but they're all girlfriends"  fosdem chat on the bus over. yep, no problems here. none whatsoever

More hmmmmm.

Well…that kind of sucks. Feels a bit like the Ruby community of 2007. Ruby has come a long way, but I suppose not everyone has. But I can deal with this kind of thing. I’ve been changing people’s minds about what programmers look like for years.

Then there was this:

Last year's "Social conduct policy" at FOSDEM


That’s when I knew FOSDEM wasn’t a place for me. The above is what serves as their code of conduct and anti-harassment policy. This wording first appeared at FOSDEM last year (see the third page), and was re-used verbatim this year. Individual rooms, like the Ruby room, were free to have a separate code of conduct if they wanted, but this was the only policy that covered the conference as a whole, or any of its social events.

I was somewhat taken aback. A conference that large with no proper code of conduct? I poked around the FOSDEM site and found nothing further – not even a reference to being “surprised” for the second year in a row. (Apparently it was only in the printed paper program.) Then I turned to Twitter, and I started to understand. Many people discussing this said some version of:

“Isn’t a code of conduct just meaningless paperwork?”

It seems that a real code of conduct is perceived by some folks as a politically-correct exercise that serves no real purpose. Perhaps the FOSDEM organizers felt that way. Honestly, I can see why. I want to explain why I still believe so strongly that all conferences need one.

I’ve been a developer since college, which at this point was a looooong time ago. In my early 20s – well before my speaking days – I went to conferences as an anonymous attendee. At these conferences, I regularly received unwanted and very persistent attention from other attendees. Sometimes from speakers. Sometimes from organizers.

Most of the time it was merely annoying. A few times it was profoundly alienating. But twice, it was absolutely terrifying.

That was harassment – all of it, even at the annoying level. I never reported any of it. Stories I heard from women who had reported similar incidents dissuaded me. When they were told about sexual imagery in slides and aggressive come-ons and being cornered at parties and offensive t-shirts and anonymous ass grabs and that guy who wouldn’t stop following me around, conference organizers just said, “If you’re uncomfortable, you can leave.” Often in combination with, “He says he didn’t, so I can’t do anything.”

20 Years Later…

I don’t get harassed any more. These days, the worst I have to contend with are the assumptions that I’m not technical, or that I’m somebody’s +1. That’s relatively harmless, compared to what I got previously. I’m not sure what caused the shift, but I have a few ideas:

  • I married and had kids relatively young, so that may have removed me from the harassment demographic.
  • Once I started speaking and organizing conferences, maybe I looked less like an easy mark.
  • Perhaps – and this is the one I’d most love to believe – we’ve actually made some progress since the mid-90s. Maybe today, technical conferences are safer for women.

If this last one were true, those folks I talked about above would be right – a code of conduct would be meaningless paperwork, like the terms of service we all pretend to read when we install software.

But when I talk to young women in this field about conferences, they repeat my stories from the 90s back at me. While I have apparently aged out of harassment, women who are in that place right now contend with the same fear, the same dread, and the same fucked-up expectations that I did.

The difference is that now we have tools.

What You Can Do

I want to live in a world where it’s safe to attend a conference while female – no matter your age, appearance, or community status. That’s not the world we live in now.

The first step seems easy: just acknowledge that this is a problem. Tell the women interested in your conference that you’re aware of the issues, and you’re prepared to take them seriously if something happens. And that’s where a code of conduct comes in. That is, in fact, the whole purpose of a code of conduct. Properly written, it says, “Hey, we know this happens. Here’s what you do when it does.”

And that’s exactly where FOSDEM’s “social conduct policy” fell down.

Last year's "Social conduct policy" at FOSDEM

It starts off with, “We’re surprised to hear this ever happens! In fact, it probably doesn’t.” Then it wraps up with, “But here’s what to do if it does.” That last bit is – sincerely – great. It’s exactly what you want to end with.

But imagine you’ve been harassed previously, and your memory of the experience provokes shame, stigma, and fear. Then you read the first part of this policy, which explicitly disbelieves your lived experience. How likely are you to report an incident, even if one should happen?

William Pietri summed up perfectly how this sounds to harassment survivors: “As people clueless about a problem, we remind you that if you report it to us, we probably won’t believe you.”

The authors of this policy meant well, but they alienated exactly the people they meant to reassure.


A proper code of conduct contains two critical parts: the “yes this happens” part, and the “here’s what you do” part. It must have both to be effective; otherwise, it does more harm than good. The FOSDEM folks did get some private negative feedback last year on their policy, which sadly provoked no change. After this post was published, however, and in response to attendee questions, FOSDEM stated publicly that they now know they need a code of conduct. I sincerely hope this bodes better than last year for change.

Here’s a great example they can start from. Many conferences I’ve been to over the last year have adopted anti-harassment policies based on this.

No Silver Bullet

Harassment is a complicated problem. Codes of conduct are not sufficient to solve it, but they are a necessary first step. We cannot fix a problem we do not acknowledge.

I will no longer consider attending or speaking at an event that does not implement a proper code of conduct. This has been my informal policy for some time, but it seems important now to say it out loud. I don’t imagine my personal declaration is weighty enough to sway conferences towards adopting a real code of conduct, but since I do quite a few conference talks (including this week at RubyConfAU), it will at least contribute to the rising tide.

So, FOSDEM: you can do better. Next year I hope to see a clear anti-harassment policy so I can attend what otherwise looks like an incredible event. And eat one of them OMG CHOCOLATE WAFFLES.



A year ago, I founded Ministry of Velocity to build the consulting company I wanted to work at. Overall, it’s been a good year. I’ve spent roughly half my time pairing with developers at client companies, leveling up their teams. The other half has been longer-term community stuff like conferences, writing, and open source.

In the course of the year, I discovered three interesting things:

First, I really like refactoring large codebases. I’ve gathered that for normal people, these projects are a punishment. But I love looking other people’s code. Usually I learn more about people from their code than the other way around.

Second, the half-and-half mix of project and community work is pretty amazing. It keeps my head in real-life-development-land, while giving me time to reflect and write and work on the community stuff I think is important. I am so, so grateful to be where I am.

Third, running a company is not for me. This was the hardest realization to come by, and the saddest. Right now I’m doing too many things; I would like to do fewer things, but be better at them. And there’s a lifestyle mismatch, too. What the Ministry really needs right now is more time on client work, and less time on community work. Given even just my current commitments, though, that’s not in the cards for me.


The Ministry and I are parting ways. Friday September 12th is my last day. It breaks my heart, but of course they’ll go on without me. Doc Ritezel, my co-founder, is a great developer and also human being, and I look forward to seeing the Ministry continue to grow and thrive without me.


Of course I have them. Come Monday September 15th, I’m delighted to be joining Chicago-based Devmynd Software as Chief Consultant. I’ve known the founders, Brad and JC, for a while now, and I’m excited by how much our philosophies and ways of working overlap. They’ve built a fantastic team that I’m really looking forward to working with.

Logistically speaking, I’m staying in San Francisco, doing consulting, teaching, and writing around here, pretty much like I have been. However, those of you in Chicago will be seeing more of me than you did before.

But not to worry – the Devmynd folks have already issued me the standard California advisories: that a hoodie does not constitute a “real” coat, and that sometimes I won’t want to wear sandals. Which, ha ha ha! Midwesterners are such jokers!

But just in case…maybe when I come out in November, I’ll bring two hoodies.


Programming Is Not Math

When I learned to program, back when dinosaurs walked the earth and the internet had no cats, there was an idea: if you were good at math, you’d be good at programming. I was great at math as a kid, but perhaps because I didn’t like it much, no one steered me towards programming. I came to it accidentally, in college, when I took an elective programming class because it fit my schedule.

So my first programming language was Fortran, an abbreviation of “Formula Translation.” As you might expect from the name, the projects in the class were exciting things like estimating the area under a curve using rectangles, like you see in the diagram below.

The Riemann Sum.

The Riemann Sum. Thanks to H.J. Keisler.

Doing Riemann sums in Fortran is about as math-oriented an introduction to programming as you can get.

And I loved it. SO MUCH!

That same quarter, I was taking my first Japanese class. Towards the end of the term, when I was getting ready to change my major to computer science because PROGRAMMING FUCK YEAH, I thought briefly about how similar the two classes felt. In both cases, I was coming into a culture I didn’t understand or feel part of. I was learning the mechanics of communicating, while at the same time trying to gain enough cultural knowledge to feel at ease.

But I knew – and everyone knew – that programming was like math. So clearly, I was good at Fortran because I was good at math.

Now, almost twenty years later, Read more »

What Your Conference Proposal Is Missing

As a developer, doing talks at tech conferences is great for lots of reasons: boosting your career, promoting your company, and getting more excitement into other parts of your life. As an introvert, though, the best perk as far as I’m concerned is the stream of people who come up and talk to me. No more awkward unstructured break time!

I’ve done almost 30 conference talks since 2009, but I still remember how hard it was to figure out at first. The biggest mystery in the whole process, for me, was responding to a Call For Proposals (CFP).

When a conference has an open CFP, even if you’ve thought of some topics you want to talk about, it’s not obvious how you translate that into a title, an abstract, and a description. I’ll talk about those three here. Sadly, I still have no idea how to write a speaker bio, so you’re still on your own for that. Read more »

Why You Should Never Use MongoDB

Disclaimer: I do not build database engines. I build web applications. I run 4-6 different projects every year, so I build a lot of web applications. I see apps with different requirements and different data storage needs. I’ve deployed most of the data stores you’ve heard about, and a few that you probably haven’t.

I’ve picked the wrong one a few times. This is a story about one of those times — why we picked it originally, how we discovered it was wrong, and how we recovered. It all happened on an open source project called Diaspora. Read more »

How To Prevent Inappropriate Presentations

This weekend there was another inappropriate presentation at a technology conference. This is sadly not a new phenomenon. But in my work with RailsBridge over the last four years, I have found the secret to preventing these types of talks.
Read more »

How Diaspora Connects Users

Note: this is the first in a series of technical posts about Diaspora’s software architecture and code, and is a slightly modified version of the original on the Diaspora blog. If you have topics you’d like to see covered in future installments, please let me know.

A single installation of the Diaspora software is called a pod. The Diaspora distributed network is made up of hundreds of these pods, each with a set of users – sometimes just one on an individual pod, sometimes tens of thousands on a community pod. Each pod is run by a different person or organization. But no matter what pod you sign up on, you can connect with users on any other pod.

When you have friends on different pods, your stream seamlessly mixes updates from remote friends with updates from friends on your pod. In this way Diaspora is a distributed social network that resembles, from the user’s perspective, a centralized social network.
Read more »

CruiseControl.rb and RubyGems 1.5.2

Diaspora uses CruiseControl.rb to run our continuous integration server. CC.rb is on Rails 2.3, but the applications it’s building are on Rails 3, which means I occasionally run into … weirdness.

Last week, for example, I wanted to speed up our builds by upgrading Bundler to 1.0.10 and RubyGems to 1.5.2. Because of the new partial caching of the dependency graph, the upgrades shaved two whole minutes off the build locally, and I wanted to get that on CI.
Read more »

Running Cucumber Features Without a Display

I’ve been helping out with the Diaspora project, an open source social network that gives you control over your own data.

When I first started poking around the codebase a few months ago, they’d just started writing a few cucumber selenium integration tests – which of course I want to encourage! – but they weren’t running them on their continuous integration box. And if you aren’t running them on CI, you can’t really call them tests…

It’s not that the developers were lazy; it’s just that Diaspora’s CI box is an ubuntu server instance that doesn’t even have xwindows. There’s no way to attach a display, and without a display, a browser won’t run. So how can you run selenium features that have to actually open a browser window and click on stuff?
Read more »