# (2) 15 Oct 2017, 01:35PM: Cleveland Visit:
I'm visiting Cleveland, Ohio this coming weekend, in case you live there or have suggestions for things I ought to do.
(One proximate cause of this is that, through the Python community, I've met multiple nice people who are organizing or championing PyCon North America in Cleveland in 2018 and 2019, and who will show me around a bit. Another is the United Airlines rep who, while trying to reroute us on our solar eclipse trip, said, "The only place in the United States I can get you tonight is Cleveland" which sounds more like a Call to Adventure than most bad travel news does.)
I'm particularly interested in hiking, walking tours, live folk and
rock music, history (especially political, social, and science and engineering history), pair programming, and trains. I'll be there Friday October 20th through Sunday October 22nd. I'm also open to giving a talk or two while in Cleveland. Feel free to leave comments on this post -- the spam filter is rather aggressive but I'll fish things out regularly!
# (0) 11 Oct 2017, 11:13AM: Hello City Limits, I See Your Sign, Left Your Dystopia Way Behind:
A joking-around conversation from a recent conference, from memory and condensed.
A: "I saw the eclipse in Nashville."
B: "Oh I'm from Nashville!"
A: "Oh cool! Did you see it there too!"
B: "No, I didn't, I don't live there anymore."
A: "So you're from Nashville. Do you play an instrument? Are you a musician?"
B: "No, I'm not."
A: "Is that why you had to leave? Is there some age by which the Machine sends you a notification that you have to choose an Instrument and perform at the Audition?"
C: "I'm imagining that scene from A Wrinkle in Time, the street of identical houses, everyone in a row on the sidewalk, with their guitars."
A:"Playing 'Wonderwall', all at the same time. And you show up at the Audition, like, 'I'm Divergent, I'm not gonna choose an Instrument, I'm leaving!'"
B: "This is actually a little too real."
(You may also enjoy Randomized Dystopia, a.k.a. Assorted Abrogations.)
# 02 Oct 2017, 04:45PM: Code Review, Forwards And Back:
This Friday, at PyGotham, Jason Owen and I are co-presenting "Code Review, Forwards and Back". This is not a standard technical conference talk. It's a 25-minute play, basically a one-act.
The setting: an office conference room. The characters: a developer, who's written a chunk of new Python code, and a team lead, who's about to review it. You'll see the code. It's not great.
What happens if the reviewer waves it through, or lets conflict aversion get the best of them? What if the reviewer says it should be "better" but doesn't articulate how? What if the review is abrasive, or nitpicky, or laid-back? What if the reviewer rewrites the code right there and then? And if we fast-forward to the same team years later, how has this code reviewing style affected the quality and evolution of the codebase, and the team's culture, skill and sustainability?
See a fast-paced montage of ways things can go. Recognize patterns from your past and present. Learn scripts for phrasing criticism constructively. And laugh.
Or, to put it another way, it's Run Lola Run but about code review.
I was getting advice about this from a friend who's both an actor-playwright and a senior developer, and I may as well tell you what I told him, about why I want to do this. I have artistic and educational reasons.
Artistically: it's frustrating to me that there's such a limited range in how we persuade and teach each other in sessions at technical conferences. Most commonly I see conferences with lots of lectures, panel discussions, and live tool demonstrations. Those aren't very interactive, and so I welcome conferences who bring some variety into the mix on the axis of interactivity, such as hands-on workshops and trainings, and birds-of-a-feather discussion sessions. But also, we could be learning a lot more about spectacle from the giant field of endeavor that is all about entertaining people who are watching you perform on a stage.* We encapsulate wisdom as, e.g., songs and cartoons whose entertainment value helps us value and retain their lessons; Jason and I are interested in seeing how theater can do things a lecture can't do, can be like a demo of behavior, while talking about tech.
And educationally: especially when it comes to the emotionally fraught art of code review, the medium of theater seems like a promising way to encourage empathy in the viewer. Code review is a moment of great vulnerability, an opportunity for courage and healthy conflict. We only know ways to be if we can imagine them. Jason and I hope this play illustrates a few ways we can be.
So we're preparing that. I hope it goes all right.
* No actual stage in the conference room where we'll be performing. But, you know. Figurative stage.
# 21 Sep 2017, 08:16AM: A Misheard Moxy Früvous Lyric, Corrected:
Sometime around 1999 or 2001, I first heard "King of Spain" by Moxy Früvous. The UC Berkeley a cappella group DeCadence performed it during one of their lunchtime concerts near Sather Gate. (Four out of five weekdays one of the a cappella groups would do a noon concert -- DeCadence, Artists in Resonance, the Men's Octet, the California Golden Overtones -- and I caught as many of them as I could.) And then Steve Shipman introduced me to more of their songs and albums -- it was Bargainville, which ends with that haunting a cappella "Gulf War Song", that I was listening to on September 10, 2001.
In 2014 it came to light that band member Jian Ghomeshi had a fairly sordid history, and for a while I couldn't listen. Now I seem to have the ability to listen again; that change I don't have as much insight into as I'd like.
Just now Leonard and I were singing bits of "King of Spain" to each other; he sang:
Lord, it looked good on me
I said "What?!" Because back around 2000 and through all the years to the present, I heard those lyrics as:
Lord of the good ennui
So for the entire time I've been with Leonard, he and I have interpreted that song slightly differently. He heard the narrator figuratively wearing royalty like clothing, like a fashion statement, which connects to the silk he mentions in the next line, and which logically connects to the garment swap later in the song. Through my mondegreen, I heard an emphasis on the narrator's malaise and boredom (a reason for the prince-and-pauper swap) and a connection to the literal meaning of an additional French loanword, laissez-faire, that he uses later.
A quick web search tells me that Leonard's version is the consensus, that to join intersubjective reality I would let go of "Lord of the good ennui". I shall bury it here, with due ceremony. Goodbye, old mondegreen friend! You were a lot of fun.
# 18 Sep 2017, 01:35PM: Supporting Int 1696-2017 for Source Code Transparency in New York City:
The principle at stake in California v. Johnson: due process requires that we be able to examine the evidence used to convict someone. Kern County got a $200,000+ grant and started using closed-source software to perform a new kind of DNA testing for criminal forensics. You are not allowed to audit the software to check for bugs, but the company founder will fly in and testify in court to say he attests to the validity of the results it finds. Uh, no, we need to check, and the ACLU and EFF have just filed amici curiae* briefs before California's Court of Appeal for the Fifth District, saying so.
As I've written and even testified, we need more auditability, transparency, and security in software governments use in laboratories and field tests. Heck, we need it in software governments use to make decisions more generally -- lotteries for visas, school assignments, parole and prison sentencing, and so on.
So I was delighted to learn of bill Int 1696-2017, currently before New York City's City Council. Summary:
This bill would require agencies that use algorithms or other automated processing methods that target services, impose penalties, or police persons to publish the source code used for such processing. It would also require agencies to accept user-submitted data sets that can be processed by the agencies' algorithms and provide the outputs to the user.
I applaud James Vacca, chair of the council's Committee on Technology, for introducing and sponsoring this bill, and for citing/shouting out to danah boyd, Kate Crawford, and Cathy O'Neil as people whose work has shaped this legislation. The New York Times says: "As a committee chairman, he plans to convene hearings before he leaves office in December." I'm looking forward to attending those hearings.
If you live in New York City, you can contact your councilmember and suggest they cosponsor this bill. If you live elsewhere, consider telling your local elected officials that they oughta introduce legislation like this. When writing or calling, if you're a programmer or other technology expert, say so -- our voice matters.
I have more links in the algorithmictransparency tag on Pinboard.
* Many years ago, Seth Schoen made me an illustration that we still have somewhere. Reconstructed from memory:
[one smiling stick figure, male, near a courthouse] Sum amicus curiae.
[one smiling stick figure, female, near a courthouse] Sum amica curiae.
[many smiling stick figures of various genders, near a courthouse] Sumus amici curiae.
[one stick figure, male, holding a finger to his mouth as though shushing you, near a courthouse] Tacit! Sum inimicus curiae!
Edited Tuesday Sept. 19th to add: The Committee on Technology is holding a public hearing to discuss Int 1696-2017 on Monday, October 16th.
# 18 Sep 2017, 11:01AM: On Noticing That Your Project Is Draining Your Soul:
I was talking with a fellow consultant about what to do if you have a gig getting you down. Especially when you realize that the client isn't being helpful, and there's a bunch of learning curves that are exhausting you, and you still have several weeks to go.
In my master's in tech management coursework, I learned the lens that thriving is a function of a person times their environment. I think those of us who are used to trying harder, overcoming obstacles, etc. can be -- kind of out of self-protective instinct -- bad at noticing "this environment is so crappy it makes it systematically hard for me to achieve and thrive". Especially with short-term projects. At first, things like "I feel tired" or "ugh, new thing, I don't want to learn this and be bad at it (at first)" and "I'm worried that person doesn't like me" or "they missed the email/meeting/call and now it's harder to execute the plan" are identical to problems that we are reasonably sure we can overcome. Maybe we notice patterns about what's not working but think: I can take initiative to solve this, myself, or with my few allies.
The data points accumulate and we chat with other people and, in the process, learn more data points and shape our data points into narratives and thus discover: this is a bad environment, structurally. But by the time we really figure out the effect a short-term project is having on us, it's supposedly the home stretch.
I'm looking back at gigs that I found draining, where, eventually, I had this realization, although I have never quite framed it this way before now. On some level I realized that I could not succeed by my own standard in these projects/workplaces, because there was so much arrayed against me (e.g., turf war, a generally low level of skill in modern engineering practices, lack of mission coherence, low urgency among stakeholders) that I could not do the things that it is kind of a basic expression of my professional self/competence to do.*
So I had to change what it was I aimed to achieve. For example, I've had a gig where I was running my head into the wall constantly trying to bring better practices to a project. I finally talked with an old hand at the organization and learned the institutional reasons this was practically impossible, why I would not be able to overcome the tectonic forces at play and get the deeper conflicts to resolve any faster. So we changed what I was trying to do. Running a daily standup meeting, by itself, is a thing I can do to bring value. I changed my expectations, and made mental notes about the pain points and the patterns, because I could not fix them right away, but I can use those experiences to give better advice to other people later.
An editor recently told me that, in growing as an editor, he'd needed to cultivate his sense of boredom. He needed to listen to that voice inside him that said this is boring me -- and isn't that funny? Parents and teachers tell us not to complain about being bored -- "only boring people are bored", or -- attributed to Sydney Wood -- An educated man is one who can entertain a new idea, another person, or himself. But pain is a signal, boredom is a signal, aversion and exhaustion are signals. Thriving is a function of a person times their environment.
Also, the other day I read "Living Fiction, Storybook Lives" (which has spoilers for Nicola Griffith's excellent novel Slow River).
How come I spent many years living a rather squalid existence... yet managed to find my way out, to the quite staid and respectable life I have now, when others in the same situation never escaped? In the course of writing the book, I found that the answer to my question was that the question itself was not valid: people are never in the same situation.
It takes substantial introspection and comparison to figure out: what kind of situation am I in, both externally and internally? Is it one where I will be able to move the needle? It gets easier over time, I think, and easier if I take vacations so I can have a fresh perspective when I come back, share my stories with others and listen to their stories, and practice mindfulness meditation so I am better at noticing things (including my own reactions). Maybe "wisdom" is what feels like the ability to X-ray a messy blobby thing and see the structures inside, see the joints that can bend and the bones that can't. In some ways, my own motivation and mindfulness are like that for me -- I need to recognize the full truth of the situation I'm in, internally and externally, to see what needs changing, to see how I might act.
The thing that gets me down most, on exhausting projects, is the meta-fear that nothing will improve, that I am stuck. When I realize that, I try to attend to that feeling of stuckness. Sometimes the answer is in the problem.
* As Alexandra Erin discusses, regarding her political commentary via Twitter threads: "I do the work I do on here because I feel called to it. For the non-religious, I mean: I have a knack for it and I find meaning in it."
# 07 Sep 2017, 09:43AM: In Black:
Grabbing a book to read, thought I was grabbing Johnny Cash's autobiography, was actually grabbing Jonathan Zittrain's The Future Of The Internet And How To Stop It.
I'd like to code a rainbow every day
And tell y'all it's 200 OK
But cyberspace is crying out: the commons we shall lack
Till we steal it back
: Comedy Reading
# 05 Sep 2017, 03:38PM: From Conversation:
A few recent thoughts.
- The power of "instead": One of the transdisciplinary lessons from Agile is that it's harder for most people to specify "this is what I need" than to look at a suggested solution and talk through "here's why this doesn't work for me." Another way to see this: generating initial idea-seeds is a useful gift, even if we don't implement any of them, if discussing them leads to us figuring out what we really want. "Instead" is a goldmine.
- Margaret Killjoy's fiction: I was talking with friends about Margaret Killjoy's fiction the other night and realized I should gush about it someplace where more people will see.
In late 2016 and early 2017, the two books that remedied the political doom in my head were Cory Doctorow's Walkaway (you can read the accompanying novella Party Disclipine for free) and Rebecca Solnit's Hope in the Dark (I have not finished this yet but have found a lot of solace in it). Now I've found a third: Margaret Killjoy's novella The Lamb Will Slaughter the Lion. It's so perceptive "about the lure of authority" and about all the microreactions we have when we meet new acquaintances and decide how much to trust them, and thrilling (although if a bit of horror gore squicks you out, you might want to sit this one out). Like Killjoy's "Men of the Ashen Morrow" and "Everything that Isn't Winter" it's also a closely observed story about violence, loyalty, vulnerability, sacrifice, and the ways we try to influence each other when we don't have traditional capitalist/bureaucratic hierarchies to bring to bear.
In "Everything that Isn't Winter", our point-of-view character is a resident and guard of an egalitarian commune, itchy and melancholy about their own too-well-developed capacity for and comfort with violence. I found it refreshing to see the competence demonstrations, loyalty, sacrifice, tradecraft, and suspense I'd usually see in military SF deployed in a story about the defense of an egalitarian commune in the woods.
The Lamb Will Slaughter the Lion (available as an ebook for NYPL patrons to borrow via the SimplyE app for Android and iOS) particularly spoke to me in its attention to the subtleties of power and influence, especially in nonhierarchical organizations -- it brings the fantastic lens to "The Tyranny of Structurelessness". What does it feel like and what happens, within each of us and among us, when our inability to persuade others to take urgent collective action collides with the heartfelt desire to avoid dominating others?
Killjoy's fiction, like Walkaway and Party Discipline, shows us not just arguments people might say or think in the service of a freer life, but the forms those lives might take, the feelings and relationships that would emerge. Narrative gives us people to love and to imagine ourselves in community with. Recently I read lazenby's essay on the body as compared to art or love:
Art, as Ruskin wants it to be seen, is a co-equal portal of creation through which it is possible to glimpse a world that is something other than the vigorous hybrid of cleverness and sadism....
In rather the same way that art does not rely on the logic of power or the power of logic, its example allows us to see still other ways of thinking....
I attended a Regina Spektor concert a few weeks ago that felt numinous. Live music, like great narrative, is one of those magic things for me. If you have been feeling airless and sewn to the ground, I hope you find a chunk of magic somewhere that helps you.
- Wedding bells: My friends got married! Awwwww.
# 26 Aug 2017, 01:37PM: Choice, Habit, and Sunlight:
Years ago, when advising me on how to change a habit, Mel Chua told me about the stages of behavior-rewiring. And the first step is noticing. Mindfulness. Not just about the reflex, but about whatever stimulated that response. Making it a conscious choice instead of something that happens automatically.
I am getting slightly better at noticing the cues and guiding myself into better habits. I start noticing that I'm about to do a particular thing as a response to boredom/fear/other stimulus, and so I let myself do that, as a conscious choice, but I tell myself that not next time but the time after that, I'm going to make a different choice, and then the time after that I'll do the unconstructive thing. And then each day I decide that the next day I'll choose to do that thing slightly fewer times. And over time the habit fades.
And sometimes this is fairly fraught. No more denying whatever pain, fear I'm avoiding. I need to let myself feel the panic masked in boredom, the anger or loneliness that feels anxious.
And that is hard. It's hard to rip denial away and face these. Maybe to grieve whatever loss I haven't admitted yet.
But you are what you practice. And what do I want to get good at -- or even better at, if I've been practicing for a long time? Do I want to get better at lying to myself? Probably not. And hurting my future self, procrastinating, feels like a lie -- it's the self-deluded lie that problems will go away if I avoid thinking about them.
At least for me, the metaphor feels like: I got jabbed by something sharp and jagged, and the wound didn't heal right, and I need to uncover that wound and feel fresh air on the bare skin again and rinse it out and look after it as it heals again.
Best wishes to us all.
# 27 Jun 2017, 02:52PM: Learning To Get Around In Java:
One of Changeset Consulting's clients is working on modernizing a legacy web application; we're improving both its structural underpinnings and its user interface and outgoing APIs. It is like we are Chief O'Brien in the first season of Star Trek: Deep Space Nine, surveying and retrofitting Terok Nor. But that's not a fair comparison; O'Brien has to not only grapple with alien engineering approaches, but with the resentful and deliberate trashing the Cardassians inflicted on the station before handing it over. I haven't seen Stargate Atlantis but perhaps that's a better analogy; with every component of this long-asleep lost city that we resuscitate, a new console or room shimmers to life. Which is pretty rewarding!
The original authors wrote this application in Java. I've never worked on a Java application before, so the last few weeks have been quite an education in the Java ecosystem, in its tools and frameworks and libraries. We're improving the installation and deployment process, so now I'm more familiar with Ant, Gradle, Maven, OpenJDK, JDBC, Hibernate, and WildFly. I've gotten some API documentation in place, so now I know more about Spring and Javadoc.
As I was explaining to a friend this weekend, the overwhelming thing isn't Java as a language. It is a programming language and you can program in it, fine. The overwhelmption is the seemingly endless chain of plugins, platforms, and frameworks, and the mental work to understand what competes with, supersedes, integrates with, or depends on what.
Imagine you come to visit New York City for the first time, and wish to visit a specific address. First you need to work out where it is. But you do not have a map; there is no unified map of the whole place. Surely you can figure this out. Watch out: if someone doesn't tell you what borough an address is in, it's probably in Manhattan, but then again maybe not. There are multiple streets with the same name, and "31st Street and Broadway" in Queens is quite far from "31st Street and Broadway" in Manhattan. The avenue numbers go up westwards in Manhattan, eastwards in Brooklyn, and northwards in Queens. And so on.
You ask around, you see sketches of maps other people have made on their journeys, and eventually you feel pretty confident that you know the rough distance and direction to your destination. Now, how do you get there from your hotel room?
You probably don't want to walk all the way; for one thing, it's illegal and dangerous to walk on the freeways. This is why we have the subway (express and local), and buses (express and local, both privately and publicly run), and government-regulated taxis (street-hailable cabs and private car services), and bike rental, and commuter rail, a funicular/tram, car rental, ferries, and so on. Also there are illegal rideshare/taxi services that lots of people use. You try to learn some nouns and figure out what sort of thing each is, and what's a subset of what.
A MetroCard works on some of these modes and not others, and some transfers from one ride to another cost you nothing, and you can't use an unlimited-ride card twice at the same station or on the same bus within 18 minutes.* You can bring a bike on some MTA-run services but not all, not all the time. There are whole neighborhoods with no subway service, and whole neighborhoods with approximately no street parking. At rush hour the trains get super full. Service changes at night, on the weekend, and on holidays. Cars and buses get stuck behind accidents and parades. People and signs in Manhattan refer to "uptown" and "downtown" as though they are cardinal directions; they often correlate to "north" and "south" but not always. Metro North trains terminate at Grand Central, but Long Island Railroad trains terminate at New York Penn Station, which is named after Pennsylvania because it's where you can catch a train to Pennsylvania,** and there's a Newark Penn Station too but over a crackling loudspeaker those two station names sound very similar so watch out. And so on.
You're lucky; you find a set of cryptic directions, from your hotel to the destination address, based on a five-year-old transit schedule. It suggests you take a bus that does not exist anymore. Sometimes you see descriptions of travel that you think could be feasible as a leg of your journey, and you read what other people have done. They talk about "Penn Station" and "the train" without disambiguating, refer to the subway as "the MTA" even though the MTA also runs other transit, talk about "the 7" without distinguishing local from express, and use "blocks" as a measure of distance even though some blocks are ten times as long as others.
Aaaaagh. And yet: you will make it. You will figure it out. New Yorkers will help you along the way.
The decades-old Java ecosystem feels overwhelming but this application overhaul is like any other task. Things are made of stuff. Human programmers made this thing and human programmers can understand and manipulate it. I'm a human programmer. I made Javadoc do what I wanted it to do, and now the product is better and our users will have more information. And every triumph earns me a skill I can deploy for other customers and groups I care about.
* Just long enough for you to enjoy a little break from the podcast you're making with President Nixon!
** Also see St. Petersburg's Finland Station.
# (2) 13 Jun 2017, 10:41AM: Transparency And Accountability In Government Forensic Science:
In February, I learned that the New York State Assembly was planning a public hearing on government oversight of forensic science laboratories, and then was invited to offer ten minutes of testimony and then answer legislators' questions. This was a hearing held jointly by the Assembly Standing Committees on Codes, on Judiciary, and on Oversight, Analysis and Investigation and it was my first time speaking in this sort of capacity. I spoke on the importance of auditability and transparency in software used in devices the government uses in laboratories and field tests, and open source as an approach to improve these. And I testified to the efficiency, cost savings, security, and quality gains available by using open source software and by reusing and sharing open source software with other state governments. Here's a PDF of my testimony as written, and video and audio recordings are available as is a transcript that includes answers to the legislators' questions. It is a thrilling feeling to see my own words in a government hearing transcript, in that typeface and with those line numbers!
As I was researching my testimony, I got a lot of help from friends who introduced me to people who work in forensics or in this corner of the law. And I found an article by lawyer Rebecca Wexler on the danger of closed-source, unauditable code used in forensic science in the criminal justice system, and got the committee to also invite her to testify. Her testimony's also available in the recordings and transcript I link to above. And today she has a New York Times piece, "How Computers Are Harming Criminal Justice", which includes specific prescriptions:
Defense advocacy is a keystone of due process, not a business competition. And defense attorneys are officers of the court, not would-be thieves. In civil cases, trade secrets are often disclosed to opposing parties subject to a protective order. The same solution should work for those defending life or liberty.
The Supreme Court is currently considering hearing a case, Wisconsin v. Loomis, that raises similar issues. If it hears the case, the court will have the opportunity to rule on whether it violates due process to sentence someone based on a risk-assessment instrument whose workings are protected as a trade secret. If the court declines the case or rules that this is constitutional, legislatures should step in and pass laws limiting trade-secret safeguards in criminal proceedings to a protective order and nothing more.
I'll add here something I said during the questions-and-answers with the legislators:
And talking about the need for source code review here, I'm going to speak here as a programmer and a manager. Every piece of software that's ever been written that's longer than just a couple of lines long, that actually does anything substantive, has bugs. It has defects. And if you want to write code that doesn't have defects or if you want to at least have an understanding of what the defects are so that you can manage them, so that you can oversight them (the same way that we have a system of democracy, right, of course there's going to be problems, but we have mechanisms of oversight) -- If in a system that's going to have defects, if we don't have any oversight, if we have no transparency into what those instructions are doing and to what the recipe is, not only are we guaranteed to have bugs; we're guaranteed to have bugs that are harder to track down. And given what we've heard earlier about the fact that it's very likely that in some of these cases there will be discriminatory impacts, I think it's even more important; this isn't just going to be random.
I'll give you an example. HP, the computer manufacturer, they made a web camera, a camera built into a computer or a laptop that was supposed to automatically detect when there was a face. It didn't see black people's faces because they hadn't been tested on people with darker skin tones. Now at least that was somewhat easy to detect once it actually got out into the marketplace and HP had to absorb some laughter. But nobody's life was at stake, right?
When you're doing forensic work, of course in a state the size of New York State, edge cases, things that'll only happen under this combination of combination of conditions are going to happen every Tuesday, aren't they? And the way that the new generation of probabilistic DNA genotyping and other more complex bits of software work, it's not just: Okay, now much of fluid X is in sample Y? It's running a zillion different simulations based on different ideas of how the world could be. Maybe you've heard like the butterfly effect? If one little thing is off, you know, we might get a hurricane.
# (1) 08 Jun 2017, 09:30AM: Trashing, Pile-ons, Accountability ... and AEDs:
I've written a new MetaFilter post, "Distinguishing character assassination from accountability", pulling out quotes from eleven writers from the past 40 years on how we take and charge each other with responsibility and power within communities, and in particular how we do accountability in progressive groups -- from Jo Freeman and Joanna Russ discussing "trashing" in the US feminist movement to people in the last few years and weeks talking about times to get on the phone, making trusting relationships for accountability, and lessons from Occupy. Perhaps the most immediately useful link in there is this "pod" discussion and mapping worksheet.
Speaking of MetaFilter: after the US election in November, I decided to take some concrete steps to be a better neighbor, so I took a CPR and first aid class. In it I learned about how amazing and underappreciated automated external defibrillators are. I did a bunch of reading and wrote up this MetaFilter post:
If someone had a heart attack right next to you, could you get to your nearest automated external defibrillator, grab it, and use it within 3-5 minutes of their collapse? More and more, the answer is yes, because of Public Access Defibrillation (PAD) programs (that statement is from 1995; 2015 update to AHA guidelines).
In that post, I commented about how difficult it can be to get PAD data, in New York at least. I ended up sending in a document request to the New York State Department of Health, and need to review what they sent back to me. Also I happened to mention my amateur AED research while talking to my city councilmember at a local Democratic Club meeting, so he might be introducing a bill soon to make the PAD data for NYC more accessible? So that's cool.
On average, when a person in the US calls 911 because someone's suffered cardiac arrest, emergency medical responders get to the scene in 8-12 minutes (Red Cross) -- but for people suffering cardiac arrest, for every minute defibrillation is delayed, the chance of survival goes down about 7-10% (American Heart Association, PDF). Bystanders (even untrained ones) who use AEDs on victims can save lives; "Application of an AED in communities is associated with nearly a doubling of survival after out-of-hospital cardiac arrest."
But where's your nearest AED?...
# 31 May 2017, 12:18PM: Resilience:
Fifteen years ago, in my last semester of college, I was planning to set up my own desktop support business while supporting myself as a substitute teacher. I took and passed the California Basic Educational Skills Test, making me eligible to work as a substitute teacher. Then, in late May, just after I thought I had graduated, I found out that I'd made a mistake and I hadn't quite graduated, and to get my bachelor's I'd have to take another class. I took a six-week summer school class that met 4-6pm on weekdays. I started running out of money. I couldn't find temp work that would be fine with me leaving at 3:30pm to make it to class, and I didn't want to ask my parents or Leonard for more money. I started looking for jobs. I felt restless and embarrassed. In early July, I finished the summer school class, and on July 15th, I accepted a customer service job at a bookstore. I stayed there for about a year and then went to work for Salon.com, and I never got back to the teaching and desktop support plans.
Monday and yesterday, I was riding back home from WisCon with my friend Julia, and I was telling her this, and I was looking back and asking: why? Once I finished the summer school class, why didn't I go back to the plan that I had cared so much about and crafted with such ambition? Right now I'm fairly happy with where I am, but why did I give up on the thing I'd wanted to do?
I look back and I see that my mental health is better now than it was then, and I see that my parents -- though I think they wanted to be supportive -- didn't nudge and remind me, "hey, you can get back to your old plan now" -- Mom wanted me to find a way to regular employment, particularly with a government. And I so wanted to be independent of my parents and my boyfriend that a regular paycheck was so enticing -- and I didn't even consider using unemployment assistance or a credit card to give me more financial leeway. But more than all that, I just wasn't good at the skill of resilience when it came to big life plans and projects. I didn't feel like I was particularly in control of my own life, I think, and so when a big unexpected obstacle popped up, I just defaulted back to taking the opportunities that were in front of me instead of working to make my own.
This morning, catching up on friends' blogs, I see Mary Anne Mohanraj (whom I met eight years ago at WisCon):
...she thought the main difference between me and a lot of other people, is that when I want something, I tend to just try to do it, whereas she, and lots of other folks, would waste a lot of time dithering.
I think that's probably accurate. And I could try to unpack why that is, why I don't tend to hesitate, though I'm not sure I know. Some of it is base personality, some of it, I suspect, is cultural and class background -- being raised in a comfortable economic situation with parents who trained me to work hard, but also expected that I would succeed at whatever I put my hand to.
That gives me a baseline confidence that makes it relatively easy for me to try things, and even when I fail (I flunked calculus, I failed my driving test the first time, I have messed up far more sewing projects than I've succeeded at, I have plants die all the time because I forget to water them, etc. and so on), it mostly doesn't get to me. I can shake it off and either try again, or just move on to something else.
All this reflection is bouncing around in my head, jarring loose thoughts on adaptability, confidence, entrepreneurship, Ramsey Nasser on failure, saying no, danah boyd on the culture of fear in parenting, Jessica McKellar on why she teaches people to program, the big and increasing emphasis Recurse Center puts on self-direction in learning, etc. Love and strength and fear. You know, the little stuff. ;-) Onwards.
# 18 May 2017, 08:59AM: She's Out:
Tomorrow is a highway broad and fair,
And we are the many who'll travel there.
Tomorrow is a highway broad and fair,
And we are the workers who'll build it there;
And we will build it there.
Come, let us build a way for all mankind,
A way to leave this evil year behind,
To travel onward to a better year
Where love is, and there will be no fear,
Where love is and no fear.
Now is the shadowed year when evil men,
When men of evil thunder war again.
Shall tyrants once again be free to tread,
Above our most brave and honored dead?
Our brave and honored dead.
O, comrades, come and travel on with me,
We'll go to our new year of liberty.
Come, walk upright, along the people's way,
From darkness, unto the people's day.
From dark, to sunlit day.
Tomorrow is a highway broad and fair
And hate and greed shall never travel there
But only they who've learned the peaceful way
Of brotherhood, to greet the coming day.
We hail the coming day.
("Tomorrow Is A Highway" -- words by Lee Hays, music by Pete Seeger)
We didn't know how it was going to turn out. We thought she'd be in prison for decades more. And then, even after President Obama commuted her sentence, I remained privately worried that something would happen, some snag or tragedy. Yesterday she got to have a hot slice of pizza -- so a few people gathered at my apartment and shared pizza and toasted her release. It was so good to have something to celebrate with friends.
I've been listening over and over to "Tomorrow Is A Highway". It's got some lovely stark lines, like "leave this evil year behind." Time and space have unified ; it doesn't say that we'll walk into the future, but rather, that the future is this journey, and there are only two time durations in this song, days and years -- tomorrow is a highway upon which we'll travel to a better year. And it's sort of a mix of prescriptive and descriptive, prophetically defining us as the people who are making this tomorrow. This song does not explicitly say "this might happen" or "we should hope for this to happen"; instead it combines "this will happen" and "let's make it happen". It's less a song of hope, and more a song of faith and promise and invitation.
It can be hard to let go of hope, and it can be hard to let go of dread. I can stop holding my breath now. She's out. We've moved from promise to fact.
I can't seem to find my copy of Ursula K. Le Guin's The Dispossessed at the moment -- did I lend it to you? In it, Shevek thinks a few times about how our conception of time and promises and intentions work together -- a coherent future doesn't just happen, it's intentional human actions that make a "road" and breaking promises denies and breaks that "road" connecting past, present, and future.
I have been feeling as though nothing is solid under my feet. And part of that is that I couldn't trust that she'd really get to be free. But now she is. And for the sake of my own forward motion I shall work as though the next stretch of the road exists too -- perhaps every step is in some measure a leap of faith.
# 16 May 2017, 05:56PM: PyCon & WisCon:
I just updated my "Talks" page -- I'll be at PyCon May 19-25, to represent Zulip at a booth and then to help run the Zulip development sprint. I will likely also have a new zine to share!
And then I'll fly straight from there to Madison for WisCon. I am not on any panels at WisCon this year but I'm the auctioneer for the auction benefiting the Tiptree Award. This year's auction includes a signed first edition hardcover of Octavia Butler's novel Wild Seed, an "Elect Alison Hendrix" pin from Orphan Black, an art print of "Aswang, at Night" by M Sereno, and a bunch more.
(As much as I love Open Source Bridge, I won't be there this year, and I won't be at Worldcon 75 (Helsinki) either, in case you're wondering.)
# 10 May 2017, 09:59AM: OSCON, For a Single Day:
I'm going to be at OSCON in Austin, Texas to represent Zulip in the Open Source Alley tomorrow (Thursday) 10am-4:30pm. Please consider coming by and getting a demo, or just talking with us about Python 3, mypy, and how we help new contributors (especially those who have a hard time setting up development environments on their own machines).
# 07 May 2017, 08:18AM: Timesaving Negativism or Masculine Calumnies?:
"Do your lairstone relations HAVE to come over?" she snooted.
"Look, my uncles are almost done repairing their peatship, so happiest
case, this is the last time for a long while."
"After all day patching up that thing, I suppose they'll need a
"'Just a teardrop,'" he parroted.
"And then they'll intoxicate themselves into such a state of
"I promise you, I understand your exasperation, but if my zombie
uncles forget their precautions and catch another xenoparasite, this
time it's on them to dig it up."
"Fine -- but you serve this time, I'm not a starwise waitress."
(This tiny short story inspired by Mark Dominus's list of awesome English anagrams and his !!Con talk on this topic.)
# 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.
# (2) 01 Apr 2017, 09:02AM: Scifi Takes on Coen Brothers Movies:
Leonard writes scifi novels, and one of them (that a publisher is currently considering) has the working title Situation Normal, a followup to the previous working title, Explosion of Honor. It's witty military scifi -- like Star Trek as directed by the Coen brothers, as I told some folks at MergeSort. A few of them didn't care for the title Situation Normal and didn't get a "this has humor" vibe from it, so I told Leonard.
"OK, here's a title suggestion. 'Bargo," I said. "It's, like, short for 'embargo' but it'll remind people of Fargo."
"I got some bad news for you. It did not remind me of Fargo. Also there is no embargo in the book."
"Oh there isn't?"
However we did start thinking of more scifi takes on Coen brothers movie titles:
(If you liked this, consider skimming "Tonight's Episode".)
- Green Blood Simple
- Intolerable Cruelty To Robots
- The Man Who Wasn't There Because He Got Teleported
- True Grid
- A Serious Spaceman [or, A Sirius Man]
- O Brother Where Art Thou? Venus
- Hail, God-Emperor!
- The Hudsucker Epoxy
- The Amazing Colossal Lebowski
- No Planet For Old Men
- Inside Llewyn Davis [unchanged]
- Literally Raising Arizona
- Burn After Scanning
- The Ladyreanimators