Dignity, Always Dignity

A fat tabby lies sprawled on its backOne of the interesting parts of being a semi-public figure by doing DevRel is that it makes you think a lot about how you look to other people, in a way I suspect is not a concern for the ordinary developer. It parallels the doubled perception that a lot of women already experience.

In 1972, art critic and philosopher John Berger wrote,

A woman must continually watch herself. She is almost continually accompanied by her own image of herself. Whilst she is walking across a room or whilst she is weeping at the death of her father, she can scarcely avoid envisaging herself walking or weeping. From earliest childhood she has been taught and persuaded to survey herself continually. And so she comes to consider the surveyor and the surveyed within her as the two constituent yet always distinct elements of her identity as a woman. She has to survey everything she is and everything she does because how she appears to men, is of crucial importance for what is normally thought of as the success of her life. Her own sense of being in herself is supplanted by a sense of being appreciated as herself by another….

It’s reductive and essentialist and troubling, but I’m not sure it’s untrue – there is a level of mindfulness to being visibly female, and a similar level of mindfulness to being visible/active online, and to representing a company.Like all forms of identity, there are a lot of intersections and nuances and complications and historical considerations. I personally know at least two female-presenting people who left technology because the cost to continue was too high, and I can think of many more who have taken deliberately lower-profile, less-dangerous positions. But I also know people who choose to be aggressively public about their gender, their level of ability, their struggles. It’s not a contest, but it is a grind.

There’s a joke-not-joke about how so many women in technology and especially information security have chosen to have obviously artificial hair color. We tell people it’s so we can identify each other in a crowd, or it’s because poisonous animals have bright markings, or because we’ve gotten to the place where we can’t get fired anymore. Because it makes us look queer (a lot of us are, but not all). Because it makes us feel fierce.

Those are all true, and many more reasons besides, but at least for me, having bright pink hair is also a level of defiance. I am not here to look pretty for you. I am not junior enough to worry about my career (a lie, of course). I am aggressively, boldly, assertively female, and I am not ashamed of that. It’s really political, at least for me. If you won’t hire me because of my hair, I don’t want to work for you. And I can make that stick.I know sometimes that people see it as juvenile, or childish, or girly, and discount me because of it.

But here’s the thing – if I am on stage, recognized by a conference as an authority, and I’m girly, it breaks people’s mental model about either what it means to be on stage or to be girly. Every time I make someone reconcile those two things, I hope to make it slightly easier for a junior person who likes winged eyeliner to get credit for a technical idea.

Because here’s the key point –

Dignity has nothing to do with competence.

My friends, if I rock up on the stage and give a mind-blowing talk on the origins of full-disk encryption and AES while wearing a clown suit, I expect you to listen to me and also not dismiss the next person you see trying to explain something while wearing a red nose.

I think, historically, dignity has been coupled with respect and professionalism, but I don’t think that’s an unbreakable triad. I think it’s a habit of mind.

I started thinking about this when I saw something on Twitter about how respect actually has two meanings – the first, for people who are already in power, is actually more like deference from people with less power. Respect the office, the badge, the cloth. The second, the respect desired and demanded by the powerless, is to be treated like a full human. As people in tech, we probably seamlessly use both definitions without realizing we’re moving between them, and which one we mean depends on where we are in the power structure.

Professionalism is, at core, very utilitarian. It means operating with the group standards in a way that keeps the organization from experiencing friction and loss of efficiency. If something is professional, it keeps the gears of collegial relations turning. It is not professional to sexually harass people because it degrades their work efficiency drastically. (It’s also terrible on a number of other levels, but corporations can only be persuaded by the bottom line.) If I’m being treated professionally, it means I have the same opportunities and liabilities as other employees, and that I can count on the explicit and implicit contracts to be followed and enforced. I’ll get paid on time, I’ll be physically safe, my work won’t be arbitrarily discarded, things like that.

I can be professional with pink hair. I can be respectful with pink hair. Those are behaviors that I control. But whether you see me as dignified or not? That’s a tougher call. If I dyed my hair brown, would it be enough? What if I grew out the mohawk? Wore a skirt suit? Wore a pantsuit? Stopped using swearwords in my talks?

No, I think the commentariat has proven that no matter how much competence a woman has, no matter how much time and energy she wastes trying to conform to the standards, there are always some people who won’t see her as dignified. And that’s ok, for me. I can afford that, to a degree. But culturally, every time I see someone dismissive about something that is coded as youthful, joyful, or feminine, I worry that they care more about dignity than they do about competence. I’m not ok with that, and you shouldn’t be, either.

Note: Of course I screw this up. My own internalized misogyny and other shit automatically makes me roll my eyes at signals I consider frivolous or less-than, and I will spend the rest of my life trying to eradicate those habits. Someone once told me that the first reaction you have to something is what you were taught growing up, and the second reaction is the more mindful reaction. Fast and slow thought, if you will.

Check your fast thought against your slow thought and try to make decisions based on what you believe, instead of what you ‘know’.

A small succulent plant with the San Francisco skyline in the background

Crosspost: The Recompiler Magazine, Issue 8: Build Your Interviewing Strategy

I’m a huge fan of The Recompiler, and not just because they sometimes publish my work. I support anyone who spends the time and effort to publish articles that are useful, thoughtful, and frequently action-oriented.

Carol Smith (of OSI board fame) and I put together a workshop for people who are doing technical interviews for the first time. We called it “The Hardest Part of Tech(nical Interviewing) Is People”. We’ve given it a couple times, and we’re hoping to do a recorded version. This article is part of what we talk about in the workshop – how to look over your past experiences, even if they weren’t in technology, and make them relevant and applicable. We hope this helps you!

Build Your Interviewing Strategy

And in conclusion, support your local publications!

The Recompiler Magazine

Is this the gate you want to keep?

Today on Twitter, I said:

Guarded by succulents

That’s a lot of response for me. Like “Livetweeting @kelseyhightower” levels of reaction. So let’s stop and talk about that for a bit.

Honestly, I wrote the tweet because a group I respect put out a call for coders to help under-indexed coders do something that is entirely unrelated to coding, and I was frustrated.

Developers are not automatically the smartest people in any room, and I wish we would stop treating them like they were. It leads to all sorts of workplace toxicity. Yes, this is about the Google thing. And the Uber thing, and the thousand and one other sexist and racist things we could rattle off.

Certainly, deifying coding is a contributing part of coders acting like they’re little tin gods. Why wouldn’t they be cocky, if everyone they work with acts like their skill is all that keeps the company afloat? Heck, sometimes entire companies are “acqui-hired” just to get a functional team of coders – the supporting cast and the product are jettisoned, as if they had no value.

I’ve worked with several startups, and at a certain stage, investors stop asking about your coders and developers, and start making noises like maybe there should be a manager, or a financial officer, or a CTO who thinks strategically and not tactically. That’s because at some point, coders are people who exist to execute a vision, but somebody had better have a vision.

A vision isn’t just a rosy sales plan – it comes with understanding the industry, the problem space, the user experience, the way other people will see and use and touch the product. It comes with sales and marketing and QA and tech docs and support. If you are not actively courting the best support staff money can buy and paying them enough to show you respect them, you are, flatly, a fool. A good support person can make or break customer retention.

I know a lot of developers, and I mostly like them. They’re smart, and they sometimes have an amazing array of interests and passions, within and outside work. But they’re not magical. You can’t actually multiply productivity with them, and they won’t save your company. They can execute. The really good ones can execute¬†and anticipate your strategy and build toward it. But developers don’t end up leading companies because they’re¬†really good at Javascript. They end up in leadership because they didn’t let their coding skills be their entire definition. They worked on getting better at people, and meetings, and product, and even more people.

So every time you talk about teaching girls to code, or asking coders to help other coders with non-code stuff, or putting on a code school with no exploration of other aspects of software development, you’re saying that there is only one right way to be in technology. That is a narrow gate you’re setting up. I don’t like it. It makes me angry, and not just because I don’t code, but because it devalues the contributions of all the other people who make the magic happen.

It takes so much more than code to make a product happen.

Here’s to the PM who works hard to balance conflicting priorities and goes to dozens of meetings, to make sure things turn out as well as possible.

To the QA tester, who designs and runs endless tests in permutations you would swear no human would try, because there is no one more cynical about human intelligence than a tester, and they’re always right.

To the UX designer, who is so often dismissed as “making things pretty”, when they’re actually “making your product usable”. They run hours of human tests, watching and iterating until your product is almost invisible to the user.

To the writers, both technical and marketing, who spend all their time trying to figure out how to make the product real and relevant and useful to the people at the sharp end of the stick.

To the sales and marketing teams, who really do sweat the small stuff, who are actually kind of sick of fancy dinners and travel and airport seats, but who keep at it because they believe in this product and its ability to solve problems. Also sometimes they make us stickers.

To security, who may actually be the smartest people in the room, but have harnessed it all to righteous paranoia so that we don’t have to sit up every night worrying the way they do.

To support, who spend all damn day talking to people who are angry that something is broken, and still pick up the phone and say “How can I help you?” at the next call. They get everything from eyerollingly stupid user errors to actual arcane and intermittent bugs, and we expect them to know their way around our entire stack to troubleshoot. They know so much about the product and the customers, if only we ever asked.

To sysadmins, operations, cable pullers, and the invisible backbone of our infrastructure. We only notice you when things go wrong, but they go right so much more often, and we never notice the rough spots you sanded over already.

To finance and accounting and accounts payable and HR and company operations, who keep the lights on, and the fridge stocked, and who do get paged at 2 in the morning if the cleaning crew sets off the burglar alarm. I’m looking forward to the day I see an office manager tweet an #oncallselfie. They are amazing, attentive, organized, detail-oriented people, and I’m in awe.

To everyone who brings us food, cleans our toilets, vacuums at 2 in the morning, and otherwise lets us live like petty royalty – we owe you so much, and we are too self-conscious to even say thank you sometimes.

To management. Yes, management. Who go to so many meetings, you don’t even know. They’re out there making tradeoffs and calculations and doing the best they can with what they have and when you think about it, they have zero ability to make any difference in the product. All the responsibility, none of the power, at least in that direction.


The next time you hear someone talk about tech jobs as if they were all coding, stop and think a moment. I don’t want to devalue coding – it’s pretty cool. But I do want to pull all these other positions into the limelight of tech, and say,

“All of us make the product, and that’s awesome.”

Post on Opensource.com: How to nail a tech writer job inteview

I was excited to write another post for opensource.com:

How to nail a tech writer job interview

It’s an extension of a twitter rant I went on a bit ago, about how important it is to know certain things about interviewing as a technical writer, but no one is teaching them, from what I can tell.

  • What kind of samples should you offer?
  • What is ethical to use as a sample?
  • What is a reasonable (and unreasonable) writing test?
  • How do you talk about team projects or work for hire?

I’m already in discussions with the team about a follow-up, based on my New Sheriff In Town talk. That one will cover how to walk into a new position and figure out what to write first.

If you’re interested in more content on interviewing, Carol Smith and I are putting the finishing touches on a workshop about all the not-code parts of a technical interview. You’ll be able to read more about that in The Recompiler soon, and of course, I’ll post about it here.