# (0) 20 Apr 2017, 12:02PM: Penguicon, Orwell, ETAOINSHRDLU, and Being Important:
When I was eight or nine years old, I think my parents went through a chunk of "how do we support this weird kid?" planning and work. Around this time I remember coming across a book my parents had acquired, something like How To Deal With Your Gifted Child, the kind of book that has 70 pages of large-print line art-illustrated stories to read to your kid and discuss with them, followed by 40 pages of smaller-print nonfiction prose meant just for the adults. I read the whole thing, of course. Pretty hard to prevent a kid who loves reading from reading the whole book and finding use and joy where she can.
Another one of the paperbacks that made its way into our house around this time was about word puzzles, trivia about English, neologisms, and so on -- it had something to do with Mensa, I think. This is how I learned that the twelve most common letters in the English language are, in order, ETAOINSHRDLU.
Also I remember being given a collection of modern British short fiction and essays, for use in a supplemental tutorial or something -- this is how I read my first George Orwell, his essay "Shooting an Elephant", and my first D.H. Lawrence, his short story "The Rocking-Horse Winner", and my first taste of how truly dark Roald Dahl could get, "The Great Automatic Grammatisator".
The advice on dealing with myself, as a gifted child, helped some -- I got it into my head that an aversion to doing things that I wasn't already good at would be harmful, for instance, even if I couldn't prevent acquiring a bit of it anyway. Everyone who comes out of childhood has scorch and stretch marks. I'm glad I got an early start on Dahl, Lawrence, and Orwell, warning me about technology's effect on art, obsession's effect on childhood, and imperalism's effect on the oppressor, respectively. And though ETAOINSHRDLU caused me to regard "Wheel of Fortune" the way many programmers feel about Sudoku -- that it presents problems to humans that properly ought to be solved by computers -- and thus be a bit of a funless jerk for a while about a TV show that provides pleasure to many people, it's has proven useful in countless games of Hangman, and in an inadvertent audience participation moment during a play I saw in Manchester in 2014.
There's a bit in Sherlock Holmes: A Working Hypothesis where a lecturer, solving a Hangman-style puzzle and mocking the audience for our wrong answers, says something about the likelihood of the next letter. I blurted out something like "E, then T, then A, because the twelve most common letters in the corpus of English-language writing, in order, are ETAOINSHRDLU". The speaker teased me occasionally for the rest of the act, and I later learned that several other audience members inferred that I must be a castmember, a plant.
More and more frequently I find that other people in my communities treat me as though I must be one of the cast, not one of the audience. As though I am important. One way of looking at impostor syndrome is that it looks at two people with the same characteristics and pasts and treats one as less important, always the audience and never the cast, solely because it's the self. The How to Deal book had stories about kids who got swelled heads, and stories about kids who never believed they were good enough. "Shooting an Elephant" said: once you're in the cast, you have to follow the script or there'll be hell to pay. And ETAOINSHRDLU has long represented to me the power of double-checking whether something really is random, and finding patterns, and sharing them with others, empowering us. Which can break a kind of fourth wall between watching and acting.
In a little over a week, I'm a guest of honor at Penguicon, and one of my sessions will be a reprise of my LibrePlanet 2017 keynote, "Lessons, Myths, and Lenses: What I Wish I'd Known in 1998" (description, video, in-progress transcript). I'll give the audience a menu of topics and they'll select the ones I talk about, and the order. It'll be massively different from the LibrePlanet version because the audience will choose different topics or a different order, barring deliberate collusion. One reason I'm doing my Guest Of Honor talk this way is because there is too much to say, and this way each story or insight has a fighting chance to get said. But another is that I have given written-in-advance keynote speeches enough times before that it's in danger of becoming a habit, a local maximum. And -- perhaps this does not speak well of me -- I think this particular audience participation method also provides a release valve for the pressure of being the Important one in the room. Instead of performing as a cast of one, I turn everyone into a plant.
To close out, my favorite chunk of Orwell, the ending of "Some Thoughts on the Common Toad":
At any rate, spring is here, even in London N.1, and they can't stop you enjoying it. This is a satisfying reflection. How many a time have I stood watching the toads mating, or a pair of hares having a boxing match in the young corn, and thought of all the important persons who would stop me enjoying this if they could. But luckily they can't. So long as you are not actually ill, hungry, frightened or immured in a prison or a holiday camp, Spring is still Spring. The atom bombs are piling up in the factories, the police are prowling through the cities, the lies are streaming from the loudspeakers, but the earth is still going round the sun, and neither the dictators nor the bureaucrats, deeply as they disapprove of the process, are able to prevent it.
# (2) 17 Apr 2017, 09:15AM: Alternate Questions:
Is it still in vogue for US tech companies to ask quantitative estimation/implausible-problem questions like "how many phone booths/piano tuners are there in Manhattan?" in hiring interviews, particularly for programming-related jobs? Fog Creek asked me one of those in 2005. There was even a book, How Would You Move Mount Fuji?: Microsoft's Cult of the Puzzle -- How the World's Smartest Companies Select the Most Creative Thinkers.* How many companies are still into that?**
I ask because I came up with a couple you could use, maybe for a digital humanities kind of position:
- How many people, throughout history, have actually been named "Flee-From-Sin"? I feel like you see this as a jokey Puritan first name in books like Good Omens or the Baroque Cycle, but was it a name that some non-negligible number of people actually had?
- Out of all the people currently within New York City limits, have more of them written a sonnet or a dating profile? What's the ratio?
* That's right, two subtitles. That's how you know you're getting a lot for your $16.00 MSRP.
** It's hard to tell these things sometimes even if you listen to lots of people discuss hiring and recruiting. "Five Worlds" and its decade-later ramifications apply to work culture, not just software development methodology. Stripe's engineering interview aims to "simulate the engineering work you'd do day-to-day" (link via Julia Evans) so I think you can expect your interviewer won't show up wearing a question-mark costume and screeching, "Riddle me this, Batman!" This software engineer, who's just been through scads of hiring interviews, doesn't mention puzzle questions. This level of detail ain't exactly on the "How to Become a Computer Programmer" page in the Occupational Outlook Handbook from the US Department of Labor -- but then again we already knew that the assessment vacuum in software engineering skills is a huge problem.
# (1) 07 Apr 2017, 03:36PM: Inclusive-Or: Hospitality in Bug Tracking:
Lindsey Kuper asked:
I’m interested in hearing about [open source software] projects that have successfully adopted an "only insiders use the issue tracker" approach. For instance, a project might have a mailing list where users discuss bugs in an unstructured way, and project insiders distill those discussions into bug reports to be entered into the issue tracker. Where does this approach succeed, and where does it fail? How can projects that operate this way effectively communicate their expectations to non-insider users, especially those users who might be more accustomed to using issue trackers directly?
More recently, Jillian C. York wrote:
...sick of "just file a bug with us through github!" You realize that's offputting to your average users, right?
If you want actual, average users to submit bugs, you know what you have to do: You have to use email. Sorry, but it's true.
Oh, and that goes especially for high-risk users. Give them easy ways to talk to you. You know who you are, devs.
Both Kuper and York get at: How do we open source maintainers get the bug reports we need, in a way that works for us and for our users?
My short answer is that open source projects should have centralized bug trackers that are as easy as possible to work in as an expert user, and that they should find automated ways to accept bug reports from less structured and less expert sources. I'll discuss some examples and then some general principles.
Dreamwidth: Dreamwidth takes support questions via a customer support interface. The volunteers and paid staff answering those questions sometimes find that a support request reveals a bug, and then file it in GitHub on the customer's behalf, then tell her when it's fixed. (Each support request has a private section that only Support can see, which makes it easier to track the connection between Support requests and GitHub issues, and Support regulars tend to have enough ambient awareness of both Support and GitHub traffic to speak up when relevant issues crop up or get closed.) Dreamwidth users and developers who are comfortable using the GitHub issue tracker are welcomed if they want to file bugs there directly instead.
Dreamwidth also has a non-GitHub interface for feature suggestions: the suggestions form is the preferred interface for people to suggest new features for Dreamwidth. Users post their suggestions into a queue and a maintainer chooses whether to turn that suggestion into a post for open discussion in the dw-suggestions community, or whether to bounce it straight into GitHub (e.g., for an uncontroversial request to whitelist a new site for media embedding or add a new site for easy cross-site user linking, or at the maintainer's prerogative). Once a maintainer has turned a suggestion into a post, other users use an interface familiar to them (Dreamwidth itself) to discuss whether they want the feature. Then, if they and the maintainer come to consensus and approve it, the maintainer adds a ticket for it to GitHub. That moderation step has been a bottleneck in the past, and the process of moving a suggestion into GitHub also hasn't yet been automated.
Since discussion about site changes needs to include users who aren't developers, Dreamwidth maintainers prefer that people use the suggestions form; experienced developers sometimes start conversations in GitHub, but the norm (at least the official norm) is to use dw-suggestions; I think the occasional GitHub comment suffices for redirecting these discussions.
Zulip: We use GitHub issues. The Zulip installations hosted by Kandra Labs (the for-profit company that stewards the open source project) also have a "Send feedback" button in one of the upper corners of the Zulip web user interface. Clicking this opens a private message conversation with feedback-at-zulip.com, which users used more heavily when the product was younger. (We also used to have a nice setup where we could actually send you replies in-Zulip, and may bring that back in the future.)
I often see Tim Abbott and other maintainers noticing problems that new users/customers are having and, while helping them (via the zulip-devel mailing list, via the Zuliping-about-Zulip chat at chat.zulip.org, or in person), opening GitHub issues about the issue, as the next step towards a long-term fix. But -- as with the Dreamwidth example -- it is also fine for people who are used to filing bug reports or feature requests directly to go ahead and file them in GitHub. And if Tim et alia know that the person they're helping has that skill and probably has the time to write up a quick issue, then the maintainers will likely say, "hey would you mind filing that in GitHub?"
We sometimes hold live office hours at chat.zulip.org. At yesterday's office hour, Tim set up a discussion topic named "warts" and said,
I think another good topic is to just have folks list the things that feel like they're some of our uglier/messier parts of the UI that should be getting attention. We can use this topic to collect them :).
Several people spoke up about little irritations, and we ended up filing and fixing multiple issues. One of Zulip's lead developers, Steve Howell, reflected: "As many bug reports as we get normally, asking for 'warts' seems to empower customers to report stuff that might not be considered bugs, or just empower them to speak up more." I'd also point out that some people feel more comfortable responding to an invitation in a synchronous conversation than initiating an asynchronous one -- plus, there's the power of personal invitation to consider.
As user uptake goes up, I hope we'll also have more of a presence on Twitter, IRC, and Stack Overflow in order to engage people who are asking questions there and help them there, and get proto-bug reports from those platforms to transform into GitHub issues. We already use our Twitter integration to help -- if someone mentions Zulip in a public Tweet, a bot tells us about it in our developers' livechat, so we can log into our Twitter account and reply to them.
MediaWiki and Wikimedia: Wikipedia editors and other contributors have a lot of places they communicate about the sites themselves, such as the technical-issues subforum of English Wikipedia's "Village Pump", and similar community-conversation pages within other Wikipedias, Wikivoyages, etc. Under my leadership, the team within Wikimedia Foundation's engineering department that liaised with the larger Wikimedia community grew more systematic about working with those Wikimedia spaces where users were saying things that were proto-bug reports. We got more systematic about listening for those complaints, filing them as bugs in the public bug tracker, and keeping in touch with those reporters as bugs progressed -- and building a kind of ambassador community to further that kind of information dissemination. (I don't know how well that worked out; I think we built a better social infrastructure for people who were already doing that kind of volunteer work ad hoc, but I don't know whether we succeeded in recruiting more people to do it, and I haven't kept a close eye on how that's gone in the years since I left.)
We also worked to make it easy for people to report bugs into the main bug tracker. The Bugzilla installation we had for most of the time that I was at Wikimedia had two bug reporting forms: a "simple" submission form that we pointed most people to, with far fewer fields, and an "advanced" form that Wikimedia-experienced developers used. They've moved to Phabricator now, and I don't know whether they've replicated that kind of two-lane approach.
A closed-source example: FogBugz. When I was at Fog Creek Software doing sales and customer support, we used FogBugz as our internal bug tracker (to manage TODOs for our products,* and as our customer relationship manager). Emails into the relevant email addresses landed in FogBugz, so it was easy for me to reply directly to help requests that I could fix myself, and easy for me to note "this customer support request demonstrates a bug we need to fix" and turn it into a bug report, or open a related issue for that bug report. If I recall correctly, I could even set the visibility of the issue so the customer could see it and its progress (unusual, since almost all our issue-tracking was private and visible only within the company).
An interface example: Debian. Debian lets you report bugs via email and via the command-line reportbug program. As the "how to use BTS" guide says,
some spam messages managed to send mails to -done addresses. Those are usually easily caught, and given that everything can get reverted easily it's not that troublesome. The package maintainers usually notice those and react to them, as do the BTS admins regularly.
The BTS admins also have the possibility to block some senders from working on the bug tracking system in case they deliberately do malicious things.
But being open and inviting everyone to work on bugs totally outweighs the troubles that sometimes pop up because of misuse of the control bot.
And that leads us to:
General guidelines: Dreamwidth, Zulip, MediaWiki, and Debian don't discourage people from filing bug reports in the official central bug tracker. Even someone quite new to a particular codebase/project can file a very helpful and clear bug report, after all, as long as they know the general skill of filing a good bug report. Rather, I think the philosophy is what you might find in hospitable activism in general: meet people where they are, and provide a means for them to conveniently start the conversation in a time, place, and manner that's more comfortable for them. For a lot of people, that means email, or the product itself.
Failure modes can include:
- a disconnect among the different "places" such that the central bug tracker is a black hole and nothing gets reported back to the more accessible place or the original reporter
- a feeling of elitism where only special important people are allowed to even comment in the main bug tracker
- bottlenecks such that it seems like there's a non-bug-tracker way to report a question or suggestion but that process has creaked to a halt and is silently blocking momentum
- bottlenecks in bug triage
- brusque reaction at the stage where the bug report gets to the central bug tracker (e.g., "oh that's a duplicate; CLOSE" without explanation or thanks), which jars the user (who's expecting more explicit friendliness) and which the user perceives as hostile
Whether or not you choose to increase the number of interfaces you enable for bug reporting, it's worth improving the user experience for people reporting bugs into your main bug tracker. Tedious, lots-of-fields issue tracker templates and UIs decrease throughput, even for skilled bug reporters who simply aren't used to the particular codebase/project they're currently trying to file an issue about. So we should make that easier. You can provide an easy web form, as Wikimedia did via the simplified Bugzilla form, or an email or in-application route, as Debian does.
And FLOSS projects oughta do what the Accumulo folks did for Kuper, too, saying, "I can file that bug for you." We can be inclusive-or rather than exclusive-or about it, you know? That's how I figure it.
* Those products were CityDesk, Copilot, and FogBugz -- this was before Kiln, Stack Overflow, Trello, and Glitch.
Thanks to Lindsey Kuper and Jillian C. York for sparking this post, and thanks to azurelunatic for making sure I got Dreamwidth details right.
# (2) 07 Apr 2017, 09:08AM: Changing How I Deal With Those Humiliating Teenage Memories:
When I was in high school in Lodi, California, I worked on the school newspaper. It came out every two weeks; we gave it to the printer on Tuesday night or early Wednesday, I think, and we received and distributed it on Friday. So there was a deadline night every other Tuesday. For dinner, our tradition was to order calzones from a particular Italian place in Lodi; they didn't deliver, so one of the students who could drive would drive their car to go get the food.
One night I was the one who collected people's orders and made the call. But I lived in Stockton, some distance from Lodi. When finding the restaurant's phone number in the phone book, I absentmindedly chose the Stockton location and placed our order with the wrong restaurant. Catie* drove to the Lodi restaurant came back from her drive very unhappy and empty-handed; there wasn't time to go all the way to Stockton back and still hit the deadline for the printer, so we didn't get dinner that night.
Later that week, maybe the next day in the journalism room during lunchtime, I was about to go to the cafeteria, maybe to get my own lunch, but definitely also to get Catie's as well (she paid for her own lunch, it wasn't completely feudal). I think someone else said they could do it, but I still remember Catie snapping: "Hari can get me a burrito."
(Everyone at my high school newspaper called me by a shortened version of my last name, pronounced "Hairy". My journalism teacher called everyone by their last names, and had a devil of a time with mine, so on the third or fifth day of class my freshman year, I offered this solution. I have lost track of everyone I knew through that paper but I bet most of them would still think of me as Hari. I feel as though I ought to be embarrassed by this, or as though I should have been, but this is one of the ways social obliviousness protected me, for which I'm grateful.)
This happened twenty years ago and I still remember it. I especially remember it when I am taking care to order food from the restaurant location I intend, as I did last night.
The memory still has the power to wash chagrin over me. I can see why it does. I wasn't diligent about checking a detail, and so some of my team went hungry for a night,** and at least one of them was still irritated with me the next day. I feel a lot more embarrassed about that than I do about a nickname that didn't hurt anyone but me.
Several years ago, when I thought about this or similar past mistakes, I'd flush with feeling, humiliation coursing through me. I would subvocalize my self-loathing. Stupid.
Then I matured a bit, and my response changed. When I felt that rush of humiliation, I'd try to actively say, I love you, Sumana, and send myself some compassion. It helped me avoid going into a complete spiral of self-loathing, but it didn't stop the memories from coming back, unbidden, every so often.
Then I got enough distance to look back and see patterns. I grew to be different enough from teenage Sumana that I could see what she needed to learn -- like asking for help, resourcefulness, organization, resilience, dealing with failure. I'm better at those things than she was. And I can see ways that the people around me could have made better choices, too. I tried to make little moral lessons out of those still-piercing memories. As the saying goes, good judgment comes from experience, and experience comes from bad judgment.
But all of these approaches assume the pain of the memory is a problem to be solved. Today I'm going to try to lay that aside. What if I just accept and experience that pain? This is what I'm feeling right now. And then this too shall pass; I always do move on to thinking about something else, empirically. Maybe I will just keep on occasionally remembering this and feeling bad about it, maybe on the last day of my life I will remember this thing and feel bad, and that's okay.
* Not her real name.
** You know what, actually, we probably could have figured out a way to get some food that night anyway if we'd thought about it, call someone's parents or something.
# 05 Apr 2017, 05:49PM: The Rumpelstiltskin Fallacy:
I sometimes sum up the lesson of a liberal arts education as: socially constructed things are real, too. And you are not immune from their effects, no matter how smart you are or whether you've noticed that something's a social construction. It's not like Rumpelstiltskin, where once you've named the thing it has no power over you. In fact, approximately zero problems are like that; saying "well this looks like a ____ situation" is insufficient to fix it.
And consequently, socially constructed things are worth studying and working on and using and fixing and spending energy on.
# (1) 04 Apr 2017, 12:37PM: How to Teach And Include Volunteers who Write Poor Patches:
You help run an open source software community, and you've successfully signalled that you're open to new contributors, including people who aren't professional software engineers. And you've already got an easy developer setup process and great test coverage so it's easy for new people to get up and running fast. Great!
Some of the volunteers who join you are less-skilled programmers, and they're submitting pull requests/patches that need a lot of review and reworking before you can merge them.
How do you improve these volunteers' work, help them do productive things for the project, and encourage and include them?
My suggestions for you fall into three categories: helping them
improve their code, dealing with the poor-quality pull requests
themselves, and redirecting their energies to improve the project in other ways.
Teaching them to improve their code
- Collect and suggest relevant learning resources, like certain talk recordings or freely available articles/exercises (e.g. The Architecture of Open Source Applications), and ask them to come back after they've watched/read/done them. Example: Zulip's collection.
- If developers have trouble writing good comments and commit messages, or diving into the codebase to find relevant files and commits, point them to my blog post "On the scientific method and usable history". It explains why it's important to do that, and gives them pointers.
- Ask more experienced contributors to pair program with them, both as leader and as follower. Here are a few tools to help.
- Run live coding exercises, over chat or video, where an experienced developer speaks aloud as she writes a bugfix, including all the little steps like searching for related commits, setting up and running tests, etc. This enables newer developers to learn a lot of tips that help them work faster and write higher-quality code. I've done this at Wikimedia with live video and we use Zulip for a live text approach (see Alicja Raszkowska's transcript and notes of one such session).
- If a big problem with their submissions is poor English writing skills, run some English tutoring sessions.
Dealing with poor patches themselves
Using their knowledge and curiosity to improve the project in other ways
This list is absolutely not the be-all and end-all for this topic; I'd like to know what approaches others use.
- Ask these developers to write "discovery reports". They're already user-testing your developer onboarding process; ask them for their experiences, so you can find and fix pain points.
- Ask them to run through some manual testing (example manual testing guide from Zulip), and to tell you how long certain kinds of tests took, so you can get bug reports and improve the docs.
- Ask them to teach about your project in their communities -- to develop learning and presentation materials and speak at meetups. You may have just found your most enthusiastic marketer.
Thanks to Noah Swartz for starting a conversation at Maintainerati that spurred me to write this post.
# 03 Apr 2017, 12:41PM: A Small Language Note:
I try not to say "don't get discouraged," because to me that sounds like telling someone not to cry or telling someone to calm down. It's a way of saying "stop feeling what you're feeling." Instead, I try to acknowledge that something is discouraging but also -- if the other person's ready to hear it -- that we can come back from that: your feelings are legitimate, and here are some ways to work with them.