The virtuous thank-you cycle

We talk a lot about vicious cycles, and how it’s easy to end up in bad places because the incentives are all bad, but let me tell you a story.

It’s a pleasant Saturday, my family is watching Star Trek: TNG together, and I’m in my home office, working on a side project and slightly resenting it. It’s the collateral for a workshop Carol Smith and I are giving at LISA about the non-technical part of interviewing, and we think it’s really an important part of helping people get jobs. So the workshop will be great and important, but I’m currently wishing I was doing something else. And then this comes across my twitter:

Marie says she uses the principles I espoused in that talk even when she starts side projects, like Call My Congress. Because she set it up to be easily localized, anyone could come through and easily add instructions in Spanish or Somali, without having to fight the project to do it.

I gave that talk 17 times. I took it to a different continent. I got most of my expenses paid, and I got an honorarium exactly once. I figure I spent 60 hours researching and writing it, and and 3-5 hours in prep and rewriting each time I gave it. I was working for myself, so no one paid me for that time.

A thank you note like this makes that all worthwhile. I give technical talks for the same reasons that novelists say they have to write – because it’s something burning in me, and I need and want to share everything I have learned the hard way so that other people don’t have to. In my grandiose moments, I think of it as reducing the entropy of the technical world, giving people a boost up the ladder. Most of the time I think it’s funny that all of my teacher-mother’s children have found our own ways to teach, far from school classrooms.

Now I have a job that pays me for development time for talks, and means that travel and conferences are not lost productivity for me, and that means the world to me, but most of the technical speakers you see at conferences are like I was — working evenings and weekends and taking vacation time to battle entropy with education.

I’m going to try to remember to do better about saying thank you, and thus spread the cycle of appreciation further and wider. A virtuous cycle perpetuates because the rewards are so good. Thank your mentors, and the friends who want you to expand your horizons, and the organizers who make safer spaces to speak in, and the bosses who don’t make you take vacation days. Thank them publicly and specifically.

Writing exercise

As a developer advocate for LaunchDarkly, I need to understand the product in a bunch of different ways – at a technical level to give summaries of how to make integrations work, at a business level to explain how feature flags can save time and money, and at a rhetorical level, so I can quickly gauge my audience and explain it to them in the most efficient way possible. Usually when I start a new project, I’m elbow-deep in documenting how it works and I have to work backward to why people want it to work one way or another. But this time I have the luxury of learning why a product adds value first.

I wanted to make sure I was grasping it, and as my friend Laura’s dad use to say to doctoral chemistry candidates, “If you can’t explain it to this ten-year old, you need to go back and work on it until you understand it yourself.” There is an apocryphal Einstein quote to the same effect. I think the modern version of making sure you really understand something by explaining it derives from Randall Munroe’s brilliant XKCD comic, Up Goer Five. Theo Sanderson built a little text editor with a linter that rejects all the words you can’t use, which is, um, almost all the words. But if you can conceptualize something really clearly, you may be able to describe it with the extremely constrained set of words. Here is my attempt to do so for feature flags:

Computers think in lines. Sometimes we want computers to think in a new line, but it’s hard to change lines all at once. We have to build the new line before we can change to it.

When we build the new line, we give it a cool name and hide it from the computer thinking. When we are ready, we change to the new line and lose the old one. The computer thinks the new line with the cool name is the only line. We can make the computer think with the cool name line or the old line any time. Cool/old, back and forward, when we want.

Sometimes, we want only some people to see the cool-name line. We put them in a cool-name group. Every time the computer gives them a thing, they get the cool-name thing from the cool-name line. Other people still get the thing from the old line. Who is happier? Cool-name group or old-line group?

We try to keep our computers happy and not too busy. Sometimes a new line of thinking takes more work for computers. Instead of making all the computers think the new line at once, which makes them slow and sad, we only tell some of the computers to think the new line. Then we add more and more computers thinking the new line, a few at a time. Soon, all the computers are thinking the new line, but none of them got too busy.

When we are finished with the old line, we make it go away. Now cool-name line doesn’t need a cool name anymore, it is just Line. We change its name to Line. When we want to write a new cool-line, we start over!

I’d love to see the results of some of you explaining your product using a thousand words. It’s not really useful as a way to explain things to people, since we want to teach customers our words and tune our language to their needs, but it’s very useful to show us if we understand something.

New employment: LaunchDarkly

Last week I told you about my exciting new job title, Developer Advocate.

This week, let me tell you about my exciting new employer! On Monday I started a job with LaunchDarkly, a startup that does feature flags as a service.

Feature flags are a way to distribute software with reduced risk. For example, if you had a holiday-themed CSS page that you wanted to activate after Thanksgiving, but you didn’t want the risk of deploying something that might break your holiday shopping experience, you could wrap the CSS in a feature flag. Using the feature flag, you can decide when to turn on the stylesheet. You can set the percentage of people who see the stylesheet. You can even hit the emergency kill switch for the stylesheet if it does cause problems.

Feature flags can also be used to test new features for part of your audience, or to replace conditional text, or to control which customers can access premium or paid features.

There are a bunch of implications that spin off from the ability to turn features on and off quickly and reliably – it changes some core thinking about what deployment is, how we think about a product, and what we do when something goes wrong. I’m really especially looking forward to working with customers to make sure that we are using and respecting their use cases. For example, while I was at DevOpsDays, I ran into someone who asked me how LaunchDarkly worked with HIPPA standards. I get to either find or write a white paper that gives them coverage for their needs.

It’s exciting to be an an inflection point in how we think about things. It’s happened to me a couple times — full disk encryption, multi-cloud management. I think this one may be another one. Ask me about it!