Blog by Sumana Harihareswara, Changeset founder

06 Oct 2013, 12:00 p.m.

What They Don't Know

Hi, reader. I wrote this in 2013 and it's now more than five years old. So it may be very out of date; the world, and I, have changed a lot since I wrote it! I'm keeping this up for historical archive purposes, but the me of today may 100% disagree with what I said then. I rarely edit posts after publishing them, but if I do, I usually leave a note in italics to mark the edit and the reason. If this post is particularly offensive or breaches someone's privacy, please contact me.

Or: you are an expert if you can save people time.

Late in 2011, I found out that one of my colleagues, a whip-smart and infinitely organized administrator, wanted to know more about how the engineering side of Wikimedia works. So I started teaching her. Every month, we talked for about an hour. She asked me about some activity from the monthly report and I explained what we're doing and why, often using analogies. She loved it and felt far more connected to what her other colleagues were doing.

She's not at Wikimedia anymore, so I have tried doing it as a Wikimania presentation and continuing the tradition with other WMFers who were interested. So far I've done a lot of one-off "What the fudge does Wikimedia engineering do" sessions for incoming folks, mostly non-engineers coming into the Foundation's other departments.

Two lessons from that experience:

  1. Sure, continuing mentorship relationships are awesome. But don't discount the value of a few limited teaching sessions.
  2. I have about three approaches to teaching this stuff: Historical (What has happened since we started in 2001?), Experiential (What happens under the hood when you go to en.wikipedia.org in your browser, and who's in charge of what parts?), and Organizational (Who are the eight directorates in WMF engineering, and who are other important Wikimedia tech institutions, and who does what?). I want to get better at the historical mode, which means learning what happened in what order between 2001 and 2011; right now I do the org-chart mode quite well, and the experiential mode well except for talking about load-balancing and caching.

I wish I'd kept good notes of all the questions people have asked during these sessions. Some of them:

  • What is a parser?
  • What is LAMP?
  • What is MySQL? What is a database?
  • What is Apache?
  • What does "open source" really mean?
  • How can it be that so many talented programmers are only in their twenties?
  • What is the role of the Engineering Community Team?
  • What do the people in the MediaWiki core team do?
  • What is Subversion, what is Git, and why did we switch?
  • Do all the Wikimedia sites run on MediaWiki?
  • How can we do what we do with so little staff?
  • What's with this Lua thing?
  • Why has it taken so long to write the Visual Editor? (This question led me to sketch out a blog post we published.)
  • What is a "virtualized hosted development environment" (Labs)?
  • Why did we have to switch to IPv6 and why was that hard?
  • What is an API?
  • What is HipHop and why would we use it?
  • Why did we work on a specialized Wiki Loves Monuments app?
  • What are the Universal Language Selector and Milkshake?
  • What is Swift?
  • What is the difference between the E2 (Editor Engagement) and E3 (Editor Engagement Experiments) teams, and what do they do? (We partially fixed this by rearranging and renaming the teams to Core and Growth.)
  • What is HTTPS? How does SSL work?
  • What kind of security problems could a web-based application have? Do we have worse problems because we're open source?
  • What does a product manager do?
  • Why don't we provide automatic translation from and to different language Wikipedias?
  • What is Wikidata?
  • Is Wikipedia Zero just for Wikipedia, or also the sibling sites?
  • How do we consult with hundreds of different wiki communities when building and rolling out our software, especially when we don't speak their language?

I have just started at Hacker School, a place designed to help everyone learn. That means making people feel comfortable with saying "I don't know". I've benefited countless times from this, because if no one's going to belittle me for not knowing something, I feel safer asking and learning. I didn't realize how much I would also get to teach! When everyone feels safe saying "What does that mean?" then I get to help more people learn more things. I've explained, among other things:

  • what Markdown is, and why you would use it
  • what screen-scraping is, and why APIs would be better
  • how I use git
  • what unit tests are, and why you would add automated testing to your project
  • dozens of opportunities to reuse, integrate with, or improve Wikimedia data and software
  • a bunch of Unix command-line tips, such as control-R for interactive search of bash history
  • the sordid history of ReiserFS
  • why Nvidia drivers are the classic example of "proprietary stuff that's not in the Linux kernel but that you might want to use so some distributions carry it"
It's super amazing when you teach someone a skill or a perspective that changes them. I feel so lucky that I am an expert, i.e., someone who can save other people time. It is a form of hospitality.