A visit to Hacker School

In July, I was privileged to visit Hacker School as part of their Open Source week. Hacker School is an amazing place, where hackers from all walks of life work together to level up as programmers. It reminded me of all the good things about grad school. I really loved the atmosphere.

During Open Source Week, students’ goal is to submit their first patch to an existing Open Source project. A wide variety of projects were chosen by the students.

I gave a talk on getting started in Open Source, and then myself and two of my Mozilla colleagues helped some students get started on some Mozilla projects. At the end of the week, the organizers gathered together a list of what the students had contributed on our projects. I’d like to share those contributions with you. They include patches, pull requests, and filed bugs.

That’s a lot of contributions, right there.


Part of the reason the school is so successful, in my view, is the encouraging and non-judgemental atmosphere.  They have two rules about communication:

  1. No “Well-actually”.  This is that thing where we, as geeks, feel the need to correct one another to the nth degree.
  2. No feigned surprise.  That’s saying things like “I can’t believe you’ve never heard of Richard Stallman!”

The skill range of students varies from self-taught in the last six months, to several years’ experience, to PhD students on summer vacation.  But everyone works side by side, productively and enthusiastically.

Calls to action

I learned a lot from my day at Hacker School, and it inspired me to issue these calls to action:

  1. Coders: If you’re thinking about applying to Hacker School, do it.  It’s a truly amazing place.  Applications are open for the fall batch.
  2. Hackers: Nominate people (including yourself!) to be a Hacker School resident, working alongside students for a couple of weeks.
  3. Tech companies: consider sponsoring the next batch of students.
  4. Mozillians: we should sponsor and run and be involved with more hackathons on Mozilla. projects.  We should host Hackdays where we get brand new contributors involved with our projects.  I propose we do this at existing Open Source conferences, get-togethers, and MozCamps, and at informal hackathons wherever the opportunity presents itself.


I’d like to thank Nick Bergson-Shilcock, David Albert, Sonali Sridhar, Thomas Ballinger, and Alan O’Donnell for running Hacker School and hosting us, and Etsy, 37signals, and Yammer for their sponsorship of the school. And of course, I’d like to thank the students for being awesome, and for their contributions!

The dark craft of engineering management

VM Brasseur and I had a chat about what it means to be an engineering manager, as a follow up to her excellent talk on the subject at Open Source Bridge.  I promised her I would put my (lengthy, rambling) thoughts into an essay of sorts, so here it is.

“Management is the art of getting things done through people.”
This is a nice pithy quote, but I prefer my version:

“Management is the craft of enabling people to get things done.”
Yes, it’s less grammatical.  Sue me.

Why is management a craft?

It’s a craft for the same reasons engineering is a craft.  You can read all the books you want on something but crafts are learned by getting your hands in it and getting them dirty.  Crafts have rough edges, and shortcuts, and rules of thumb, and things that are held together with duct tape.  The product of craft is something useful and pleasing.

(Art to me is a good deal purer: more about aesthetics and making a statement than it is about making a thing.  Craft suits my analogy much better.)

Why enabling people to get things done?

Engineers, in general, know their jobs, to a greater or lesser extent.  My job, as an engineering manager, is to make their jobs easier.

What do engineers value?  This is of course going to be a sweeping generalization, but I’m going to resort to quoting Dan Pink: Mastery, autonomy, and purpose.


Mastery has all kinds of implications.  As a manager, my job is to enable engineers to achieve and maintain mastery.  This means helping them to be good at and get better at their jobs.  Enabling them to ship stuff they are passionate about.  To learn the skills they need to do that.  To work alongside others who they can teach and learn from.  To have the right tools to do their jobs.


Autonomy is the key to scaling yourself as an engineering manager.  As an engineer, I hate nothing more than being micromanaged.  As an engineering manager, my job is to communicate the goals and where we want to get to, and work with you to determine how we’re going to get there.  Then I’m going to leave you the hell alone to get stuff done.

The two most important things I do as a manager are in this section.
The first is to act as a BS umbrella for my people.  This means going to meetings, fighting my way through the uncertainty, and coming up with clear goals for the team.  I am the wall that stands between bureaucracy and engineers.  This is also the most stressful part of my job.

The second is in 1:1s.  While I talk to my remote, distributed team all day every day in IRC as needed, this is the sacrosanct time each week where we get to talk.  There are three questions that make up the core of the 1:1:

  • How is everything going?  This is an opportunity for any venting, and lets the engineer set the direction of the conversation.
  • What are you going to do next?  Here, as a manager, I can help clarify priorities, and suggest next steps if the person is blocked.
  • What do you need? This can be anything from political wrangling to hardware.  I will do my best to get them what they need.

In Vicky’s talk she talked about getting all your ducks in a row.  In my view, the advantage of empowering your engineers with autonomy is that you get self-organizing ducks.

The key thing to remember with autonomy is this: Hire people you can trust, and then trust them to do their best.


This is key to being a good manager, because you’re providing the purpose.  You help engineers work out what the goals should be, prioritize them, clarify requirements, and make sure everybody has a clear thing they are working towards.  Clarity of purpose is a powerful motivator.  Dealing with uncertainty is yet another roadblock you remove from the path of your team.

Why is management fun?  Why should I become a manager?

Don’t become an engineering manager because you want power – that’s the worst possible reason.  A manager is a servant to their team.  Become a manager if you want to serve.  Become a manager if you want to work on many things at once.  Becoming a manager helps you become a fulcrum for the engineering lever, and that’s a remarkably awesome place to be.