A grey cat on a red blanket stares into space

The naming of cats… or feature flag patterns

Eeee! I’m super excited to start this year because something I’ve been working on for a while is ready for all of you to look at!

Feature Flag Glossary

It’s hard to use a pattern, or even imagine it, if you don’t have a name for it, so we put together all the names for feature flag patterns we could come up with in one place. I’m sure we’ll keep adding to it, and you’re welcome to, as well.

Here’s a snippet:

A listing of terms and definitions.

Bonus poetry content:

The Naming Of Cats 
by T. S. Eliot
The Naming of Cats is a difficult matter,
It isn’t just one of your holiday games;
You may think at first I’m as mad as a hatter
When I tell you, a cat must have THREE DIFFERENT NAMES.
First of all, there’s the name that the family use daily,
Such as Peter, Augustus, Alonzo or James,
Such as Victor or Jonathan, George or Bill Bailey–
All of them sensible everyday names.
There are fancier names if you think they sound sweeter,
Some for the gentlemen, some for the dames:
Such as Plato, Admetus, Electra, Demeter–
But all of them sensible everyday names.
But I tell you, a cat needs a name that’s particular,
A name that’s peculiar, and more dignified,
Else how can he keep up his tail perpendicular,
Or spread out his whiskers, or cherish his pride?
Of names of this kind, I can give you a quorum,
Such as Munkustrap, Quaxo, or Coricopat,
Such as Bombalurina, or else Jellylorum-
Names that never belong to more than one cat.
But above and beyond there’s still one name left over,
And that is the name that you never will guess;
The name that no human research can discover–
But THE CAT HIMSELF KNOWS, and will never confess.
When you notice a cat in profound meditation,
The reason, I tell you, is always the same:
His mind is engaged in a rapt contemplation
Of the thought, of the thought, of the thought of his name:
His ineffable effable
Effanineffable
Deep and inscrutable singular Name.
A grey cat on a red blanket stares into space

My first year, a professional review

A bit over a year ago, I applied to a startup. I’d never been a developer advocate before, and I wasn’t sure what the job actually entailed, but the person who recommended me (thanks, Rach!) and the hiring manager said that probably my experience doing talks about technical writing was enough to make me a plausible candidate.

I wasn’t sure then exactly what developer relations actually was, and now I’ve been doing this for a year and in an active community of other people doing it, and I think it is like the parable about the elephant – it looks different to everyone because we’ve all got different parts of the same beast.

For me, it looks like going to conferences – a lot of conferences! And being on twitter and writing blog posts and talking to people and being available to answer or route questions. It looks like offering a feature flags open space at every possible place I can. It looks like reading a dozen articles a day, looking for insight and parallax and industry position and good ideas, and funneling it back to the team. It looks like meeting teams who are actually developing with our tool and taking notes on all the things that are annoying them. It means really, truly, non-sarcastically caring about stickers and swag and conference sponsorship and organization and postcards and follow-up.

It’s not an entirely new skillset, but a lot of it is new, and I’ve never been this close the the sales and marketing parts of a company before, and I’m more convinced than ever that it is a really technical skillset that is tragically under-rated for difficulty.

If you’re observant, you’ll see what’s missing from my list: coding. It’s on my list for next year, because I have some neat ideas that I’ll need to use our tool to implement, but it’s not actually very relevant to what I’m trying to do right now.

My goals for this year

I didn’t really write down my goals when I started, because, like I said, I didn’t know what I was doing. But here are the things that I was working toward:

  • Give talks about feature flags/feature management at technical levels from “what is a feature flag” to “how does that work with containers”
  • Standardize the industry term on “feature flags”, so everyone was talking about the same thing. (Kelsey Hightower said feature flag, and you bet I screencapped that. I was delighted.)
  • Visit real live people using our product and funnel their needs back to the right people on our side.
  • Explain what a feature flag was often enough, in enough places, that people started to recognize the concept.
  • In September and October, I would go to conferences and say to someone, “Do you know what a feature flag or toggle is?”, and I would get a lot of blank looks. This July I went to a conference and someone who wasn’t me proposed an open space of feature flags. That’s anectdata, but I think the needle is moving, and I’m giddy. It’s not just me – there are dozens of people talking about this. Martin Fowler hosted a post from Pete Hodgeson on his blog in October of 2017. Willy-Peter Schaub writes about them from the Microsoft MVP perspective, and Raven Covington from MailChimp gave a talk on feature flags at Bath Ruby.
  • It’s partly me, though. I’ll take some credit. If we assume an average audience of 50 people, by 30 conferences, that’s 1500 people who have gotten to hear me enthuse about Testing in Production and Democratizing Release and Progressive Deployment and Continuous Deployment Means Shipping Broken Code and Kill-Switch/Circuit Breaker Patterns. (It’s not quite perfect math, because not all my talks are about feature flags, but not all my audiences are as small as 50.)

Retrospective

I’m not going to spread my whole retrospective out here, because there’s a lot of it that’s purely personal or company internal, but here’s a sampling.

What went well

  • Conference acceptances are encouraging
  • New talks making good impact
  • Feel like I can explain the product with a reasonable degree of technical accuracy and depth
  • Honestly like my company and my co-workers
  • I love learning things. Going to conferences is like all the good parts of college, with much less homework
  • Feel like I did ok mentoring other speakers

Could improve

  • Nearly burned myself out on travel
  • Planning to get speech coaching to hone my skills
  • Want to learn to do code-ier demos
  • Continue improvement in travel booking and organizational skills around writing blog posts and talks
  • Got tired of my conference dresses. Need to sew more batches when I’m home

Looking ahead

  • I’d like to set up some client meetings while I’m visiting places for conferences.
  • Need to not totally drop fitness goals while I’m on the road.
  • Be slightly more selective about conference submission and acceptance. Fine-tune for conferences that have the audiences we need.

    It’s been a good year, and I’m looking forward to next year and don’t feel like there’s any reason for me to worry about finding interesting things to do in the coming year.

    In the meantime, if you want to ask me a question about feature flags, or conference speaking, or the care and maintenance of bright pink hair, you can reach me at heidi@launchdarkly.com.

Guest post: UX Booth

I wrote a 2018 User Experience Prediction at UX Booth. Amy Grace Wells asked me what I thought was going to be a leading theme in UX in the next year, and I said, “better accessibility”. I think that’s both a serious prediction and a hope, because there is never enough accessibility, but I also think we are getting better.

So many things that are designed for accessibility, but that we don’t always understand that way when they happen, and frequently we mock them as lazy or luxurious. Backup cameras on cars seem silly – why not just turn around? Until you physically can’t turn around, and then you realize how much they matter. Pre-chopped vegetables, electric can-openers, and velcro shoes seem laughable – unless you’ve ever been unable to hold something in both hands at once. In the same way, building web and mobile apps to respond to a variety of command styles may not occur to us if our fingers are nimble or our voices clear, but will matter immensely to people who are not in that category.

Since before I was employed at LaunchDarkly, I’ve been fascinated by the ability that feature flags offer designers to customize user experience. We haven’t had a good test case yet that I know of, but it will come, and I’m looking forward to it.

Peeled oranges in plastic containers

Pre-peeled oranges for accessibility

Well, that didn’t go like I imagined

The Toggle Talk

As a speaker, there are three things I count on to give a talk:

  • Slides
  • Narrative flow
  • Speaker notes

My dependence on these elements decreases as I give a talk multiple times, but I use the slides to help me remember where I am in the narrative even if I don’t refer to the speaker notes often.

This fall, I designed a new talk and built it in Twine, a game engine for choose-your-own-adventure games. Each slide was actually an HTML page rendered by the game engine, and the narrative was supplied by the audience choosing from several options. This was a radical departure from my usual method, but I’d practiced it, and tuned it, and wrestled with the CSS and I felt pretty confident I could make it work, even though I wouldn’t have speaker notes or a unified narrative through-line.

Because I hadn’t solved the hosting problem yet, I needed to “play” it from my laptop, but that was no problem – I had a USB-C to HDMI adapter. The talk before mine ran long, but I only have technical problems a tiny handful of times in my talks, so I didn’t think I’d need much time to get set up.

I had reckoned without the USB-C/USB-3/HDMI problem, because it had never happened before. I always present from my ipad, and it’s usually a rock-solid toolchain. So I get up there, I’m rushed for time because of the talk before, I’m nervous because it’s the first time I’m giving this talk, and because it’s so “weird”, and…. it failed. The combination of cable/laptop/projector failed so hard that my computer rebooted and came back looking weird, and I had to accept that I might have just bricked my brand-new work laptop, in front of an audience, in a talk that had already technically started.

I had no slides.

I had no notes.

I had no narrative.

I had practiced, but I had not practiced the complete failure scenario, because it had never occurred to me that it could fail this hard.

I still managed to pull a coherent technical talk out and I only ran 10 minutes short, and honestly, it’s one of the accomplishments I’m proudest of in the last year. Literally everything went wrong and I still delivered value.

Afterwards, when I was trying to quietly dump adrenaline, I could only think about how I had failed to achieve any part of my goals. My hands were shaking, my throat was tight, and I felt a little like crying.

That wasn’t how it was supposed to go!

Later, I got to talk to people who had been in the audience, and they asked questions that they could have had if they’d gotten the real talk. That was cheering. I joked that this was the worst this talk could possibly go, because there wasn’t anything left to fail!

Then I got the speaker evaluation cards, and people were universally complimentary about my poise under tough circumstances. It hadn’t felt like poise, it felt like literal flop-sweat, like a drip from my shoulderblades to my waist. But they couldn’t feel my sweat, they could only experience my description of a brand-new talk focused on something that they had to imagine.

The webinar

One of LaunchDarkly’s goals for the year is to nurture and encourage customers to feel comfortable telling their stories, whether on stage or in a blog post. To that end, we are offering some people speaker training. Remembering my fall experiences, I solicited nice people on Twitter to come to a beta of my talk. That would give me a chance to try out the tool, the content, the process, before we offered it as a finished product.

I learned so much! Almost all of it was a little painful.

  • I need to log in early because I’m a panelist, not a host, so we need to coordinate that so I can show my slides to the webinar.
  • I did test my A/V setup!
  • I didn’t realize how unnerving it would be for me to talk to dead air. For all of my teaching/preaching/tech talks, I’ve had an audience. I can make eye contact with them, hear them start to fidget if they are checking out, notice their grins and twinkles and coughs to stay connected to them. But obviously, none of that happens when I’m talking into a headset with the audience on mute.
  • I need to do some work on the content. Not too bad, but I always have to give a talk at least once to live humans to get the suck out.
  • The lack of response makes me so nervous I talk even faster than usual. SLOW DOWN, ME.
  • I have to figure out a better way to wrap up/end the webinar. I didn’t think about how to tie it up neatly, because talks work differently.

So this is all great. When I do the webinar “for reals”, those are all mistakes that I’m not going to need to make because I know where they are.

The meta-lessons

  • It is hard to predict how you’re going to fail, but it is possible to build in a reasonable degree of redundancy.
  • Tests in isolation are not going to catch systemic problems.
  • It is better to degrade what you provide rather than failing entirely.
  • Test with a subset of users so you can predict how your solution will scale.
  • Don’t get so distracted by your failures that you fail to notice surprising data or silver linings.*

* One of the most beautiful night skies I’ve ever seen was on a winter night in the middle of a widespread blackout. I was stomping across the yard to get firewood, and I happened to look up and see the stars without light pollution. A lot of things had gone wrong, but if they hadn’t, I would not have had that moment of starlight bright enough to reflect off the snow, and the milky way like a second snowy stripe in the sky.

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!