New job title: Developer Advocate

I've had a lot of job titles in my career:

  • Technical Writing Intern
  • Queen of Documentation (It was 2000, OK?)
  • Technical Writer I, II, III
  • Technical Communicator
  • Senior Technical Writer
  • Technical Writing Consultant
  • Documentation Architect
  • Documentation Mercenary

You might notice a theme there. I've been a technical writer for a lot of different companies, because that's been my career, my expertise, and my passion. I want to take everything that's great about technology and make it easier to use, more transparent, more thoughtful, more humane.

Lately, I've been having trouble describing what I am doing in terms of writing alone. Two job interviews in a row, my interviewer stopped asking me questions about my qualifications so they could take notes on my ideas for their product. My conference talks are sort of nominally about writing, but actually about patterns I'm noticing in the world and in technology. I love writing, and I'm never going to give it up, but it's also…not quite a good fit anymore.

Through the power of All-Women-In-Tech-Are-Connected, I got an interview for a Developer Advocate position. I would never have applied for this position on my own – it's so far beyond what I think of as my skill set. But in the discussions and interviews, I really came to believe it was not just a company I could work for happily, and a product that I think is useful and not toxic, but a position that lets me get out there and do the kind of thinking and helping and problem-solving that I love.

Photo credit: Women of Color in Tech Chat

Developer Advocate is a super broad range of positions, actually, but our interpretation of it is basically me continuing to do all the things I'm doing now: conference speaking, blogging, listening, and noticing. It's just that now I'll be doing all that and getting paid for it, instead of using it as a loss leader for my consulting. I get to go out in the world, find out where developers and users need help, and figure out how to make it happen for them. We're seriously at "pinch me, I must be dreaming" levels of exciting here. I even get to keep writing a little, although I may have reached my personal career goal: not writing the release notes.

Yes, I'm being deliberately coy about my new employer. That deserves its own post. I'll just say that I think we're going to get along well, they say I get to continue to be a pink-haired weirdo, and I will feel proud of the product.

I honestly feel like changing my job title is like the day you get new shoes and you realize you'd outgrown the old ones without noticing.

Oh! This is so comfy.

Consulting retropsective

I’ve been doing Agile for too many years to feel like I’ve learned something unless I identify it with a proper retrospective. I’m about to start an FTE job, and my consulting will obviously drop way off (but not entirely). So here we go:

What went well

  • I passionately loved the independence. I could fire a client when I thought they were doing something that was stupid/unethical. I didn’t have to account to anyone for my time at conferences. I made it to all the weird middle-of-the-day school stuff. My spouse was in the hospital for 11 days, and I could absorb that without talking about it.
  • It really forced me to get better at negotiation, scoping, planning, and self-management. No one was going to save me by telling me the priorities of projects — that was on me.
  • I learned a lot about building a personal and professional reputation. It matters that I blog. It’s important to follow up on business cards and connections. I never advertised my services except by telling people they were available, and I had stages where I turned away work.
  • I discovered moxie as a selling point. Not unreasonable bragging, but people are happier when they spend a lot of money on someone who seems confident about themselves and what needs to happen. I would have guessed that would be a turn-off, but no, that mostly applies to earlier stages in a career.
  • I got to work on some kick-ass projects and refine what parts of writing and projects I’m good at.
  • I got to go to so many conferences and learn so much stuff about things that I never would have thought I cared about, but it all feeds into the hopper and then a week or a month or six months later, it turns out that data was valuable.

A smattering of the stickers I carry around with me

What needed improvement

  • Cashflow. Sweet fancy moses, cashflow. This year to date, I have pulled in about $30k and gone $10k into debt. I had two contracts die on me after I had turned down other work to take them, and a client that paid Net-45….ish. If I reminded them. As a sole earner for a family of four, including two teenagers, this is not super. If I knew I was going to make that persistently, I would adjust our style of living, but I kept optimistically thinking that the universe would not screw me over again, right? And this was just a little bump. It wasn’t.
  • Relatedly: taxes. I did not get that set up as soon as I should have and I will spend some time untangling it.
  • I needed some things in my contracts that weren’t there: a kill fee/clause. A late fee. I racked up about $700 in late/overdraft fees because I thought people were going to pay me when they said they were. This is not a malicious problem, it’s a problem because I had already exhausted my buffer cash.
  • I need to keep working on how I track time. There is a lot of my job that is basically talking to people, wandering around thinking, and staring at the ceiling. It’s legit work, but I feel weird charging people for ‘I mowed my lawn and also thought about your data structure problem for two hours’.
  • I need to figure out how to pay myself for loss-leader/reputation building stuff, like blogging and mentoring. If I classify it as “not-work”, it eats the leisure time I need to recharge, interact with my family, and sew nifty dresses. If I classify it as work, then it’s unpaid work, which has a lot of emotional stuff going on.
Empty wallet in male hands. Isolated on white. Studio shot.

Empty wallet

Action items

If I do consulting full-time again, here are some things that make it more likely to work out for me.

  • Start with 6 months of cash buffer instead of 3. This is because I don’t have any other income stream
  • Write my own contract (well, hire a lawyer to do it), and make sure my clauses about kill fees, late fees, and payment schedule get into whatever contract I sign.
  • Hire a tax accountant sooner rather than later.
  • Work on adding passive income to smooth out bumps.
  • Factor in equipment costs and less-obvious travel costs in my calculations (if you take 50 flights a year, you wear out luggage, even the nice stuff) (I’m using a 3-year old laptop, and software costs money.)
Purple spinner suitcase

My next suitcase – a slightly smaller TravelPro in PURPLE

Software and pink collars

Yesterday, I said this:

And I want to come back and address it in a bit more depth, because someone called it “a bold statement”, and it is, but not unfounded.

Premises

Before I start, I’m just going to say up front that here are my premises, and if you disagree, feel free to go do your own research.

  1. When women become a majority in a job category, the pay and prestige of the category declines.
  2. Coders are paid more than non-coders of the same experience level at the same company.
  3. Money is a useful proxy for what a company values.

Economics

Code schools and bootcamps are frequently aimed at career-changers and non-traditional students. There is also a healthy representation of young people. Almost all of them are not putting themselves through this for some idealized love of coding, but because they want a well-compensated job.

If user experience, quality assurance, technical support, project management, or technical writing were compensated at the same rate as coding, market pressures would encourage people to offer programs that would provide the same level of education in these other fields.

All those positions are an important part of the product – they affect how people feel about using the product, how much they can accomplish, how frequent releases are. However, this is where we follow the money trail further.

The people who buy software are often not the people who use the software. The purchasers are trying to solve organizational problems while balancing budgets, ROI, security, data conversion, all that stuff. They are not the people at the pointy end of the software stick. They don’t spend hours every day entering tickets in it, or trying to port it to the cloud, or designing marketing materials, or designing microchips.

This disconnection between the user and the purchaser leads to a lot of problems where it is the best interest of the software to address the wants and needs of the purchaser, rather than the user. This complicated relationship is made even more complicated by second-order purchasers, also known as investors. Investors want to be impressed, and also want to make purchasers impressed. It’s a lot of levels of abstraction from the woman in your doctor’s office trying to enter billing data. (I fly out of Minneapolis, which is the hub link for Madison. SO MANY Epicor people.)

Investors are often like pre-Moneyball baseball. They are using pattern-matching to try to figure out which resources and people will be valuable. Enormous and important companies are driven by coders – think Facebook and Google – so it must be that coders are the most important part of a company to invest in. That seems like a successful pattern to match. I think, or at least hope, that as the market matures, we’ll start looking at how often companies make it on base with good products, not just how much they look like other companies.

Products are more than code

Good companies hire experienced people to take care of all the parts of the product that aren’t code. Great companies compensate equivalent experience equally. There are not a lot of great companies in the world.

One of my Twitter interlocutors said that it was just hard to make a value argument for documentation or usability, that people don’t understand why it matters. As a consulting technical writer, I have this argument approximately a millionty times a year. Why wouldn’t usability, consistency, and reliability matter? Do you really, actually have a functional product if only elite nerds can figure out how to install and run it? Or do you have a bunch of aspirational code that may or may not run on most browsers?

I don’t know how to solve this problem. I am doing my bit, going to coding conferences and talking to developers about what it means to write, and what mistakes they commonly make that have to be fixed by other people. The problem is much much bigger than that, though. One pink-haired speaker is not enough to change how an industry regards itself.

I blame the patriarchy

Well, really, I blame the kyriarchy, but that’s a different essay. When I say that technical writing, especially at the end-user level, is a pink-collar job, I mean that it is dominated by women. I don’t have good stats on other product jobs, such as QA, PM, and UX, but the gender ratio for them is certainly closer to even than it is in coding. I think it’s not an accident that the jobs which require more emotional labor are filled with people who have been trained to do it for more years (that’s women and under-indexed people). Pink-collar is a corallary to white- and blue-collar jobs, and conveys class as well as payment expectations.

Have you ever heard someone say, “Well, she’s a real jerk to work with, but she’s such a great writer that we just can’t get rid of her?” I haven’t. And yet I go to interviews frequently where someone asks me, “How do you work with developers who don’t like talking to writers?”.

Until we level out our status structures, we’ll keep having this problem. and well-meaning people perpetuate it. Girls Who Code. Girl Develop IT. Google Summer of Code. All the technology mentorships and programs funnel people into development, not the allied skills, because the allied skills are…lower status? Less aspirational? Most of our problem is that “the pipeline is leaky and full of acid”, but perhaps some small part of it is that we are trying to fit everyone into the square, high-status hole labeled “developer”, and some people are pegs better shaped for writer or QA.

What can you do?

  • Compensate everyone based on experience and value, not role
  • Advocate for more mentors and assistance for non-coding roles
  • Spend money on continuing education for everyone
  • Promote cross-training
  • Be aware when you are treating coders as more valuable than other team members
  • Respect everyone on their team for their contribution
BIG CONCEPTS small docs. User documentation is a failure of user interface. Faster and cheaper than making your developer write it. Elegant writing saves money. Paid by the anti-word.

Why are there no documentation bootcamps or schools?

Sarah Mei and Sarah Fox and some other people and I were talking on Twitter about code school graduates, and how they frequently do really well at mid-level positions because they have communication skills from their previous careers.

We all agree that teaching someone to write well enough to be a Professional Technical Writer is more than you could cover in a six-week intensive, probably. Depending on where they start. I could absolutely turn a motivated journalist into an entry-level tech writer in 6 weeks. They’re 3/4 of the way there already. But most people would need to learn the following from scratch (in no particular order):

  • Audience analysis
  • Task-based writing
  • Procedural writing
  • User story writing
  • Error writing
  • Bug writing
  • Conceptual writing
  • Diagrams, illustrations, and screen captures
  • Rudimentary tools use
  • Sentence construction
  • Bullet point use
  • Theory of simplified English
  • Accepting editorial feedback
  • Accepting technical feedback
  • Elements of information architecture and presentation
  • Elements of usability and accessibility
  • Style guide use

Even if you’re coming out of a liberal arts/literary background, half of that list is something you may never have heard of. You can construct a great sentence, and you know how to use a semicolon, but your experience to date has rewarded you for things that don’t matter at all in technical writing. You’ve gotten good grades for making persuasive arguments or writing pithy literature reviews, but no one in my English Lit classes ever told me that I was addressing the wrong audience or designing my headings badly.

So that’s a daunting list of things to try to cram to get people into what is, let’s face it, a less glamorous profession than Code Warrior. I happen to think it’s the best and most influential place to be in a development team, but that’s not what the pay scales say.

That said

That said, I think I could do a LOT with teaching code school students and other developers some really basic writing skills. I tried this out at a Workshop at Write the Docs this year, and it went pretty well. I’d love to present it elsewhere. I’m putting the outline below the cut, if you’re interested.

Give me your developers for a day, and I’ll teach them to write a well-constructed error code and a readable bug report and a coherent status email. Give me two days and I’ll teach them about audience and analytics and deletion.

I want to do this for code schools, so we can catch people when they are frantically learning, so they will remember to look it up later. I want to do this for open source projects, because it is so hard to find or hire a technical writer. I want to do this for conferences where junior developers are looking to elevate their game. I have been traveling around to developer conferences for several years now, trying to distill everything I know from 20 years of my career into something that has value for coders, and I am convinced it has value.

Continue reading

Open Source Citizenship Award

I was at Open Source Bridge this week, with my kiddo Baz. We were both giving talks, and I was giving a workshop on interviewing with Carol Smith. Also I got to MC the slideshow karaoke part of the after-party, which was huge fun.

But the big news is that I won an award for Open Source Citizenship. This was not captured in pictures, but I literally spun in a circle, trying to figure out who behind me was also named Heidi. They were pretty clear they meant me.

Open Source Citizenship Award

Shiny 3-D printed medal that says “Open Source Bridge Truly Outstanding Open Source Citizen 2017”

I have real trouble thinking of myself as an open source contributor – sure, I go to a bunch of open source conferences, and I write for opensource.com, and I give talks about how to be a better self-documenting writer, and I livetweet almost everything I go to, but I don’t code, you know.

It’s like that moment when you recognize your internalize misogyny. Oh, I am devaluing my contributions for NO GOOD REASON. I have imposter syndrome not about my talent (goodness knows, I’m pretty cocky about that), but my place in the community. Any minute now they’ll find out that I haven’t edited Wikipedia in 9 years, and they’ll reject me! That’s not how it goes. Contributions of all types are valuable, and I’m glad to be recognized for what I do.

In 2009 or so, there was a giant fannish explosion we now colloquially call Racefail. One of the most valuable people/roles in the whole thing was “Archivist of the Revolution” – a position held by @ryda_wong and others. They read, collated, and commented on an incredible amount of data, packaging but not altering it so that we could consume relevant posts without seeking them out ourselves.

I don’t see myself as that dedicated to the cause, but it’s something I can aspire to — to offer up information, to curate what I see, to help create indexes and pointers. I do live-tweeting because I think it’s valuable and because it’s a way for me to manage my ADD. 8 hours a day of extremely thought-provoking talks is HARD.

For a little while, I thought that perhaps I was outshining other contributors because my conference persona is loud and tweety and charismatic. And I truly feel that charisma is not always the best indicator of value to a community. There are a lot of charming assholes in the world. I hope I’m not one of them, but I assume that charming assholes never notice it until someone calls them out on it.

But then I remembered that this is voted on by attendees. Individual people found what I was doing useful. And I remembered the very smart thing that my mom told me about compliments.

“Just say thank you. Arguing is insulting their judgement.”

So thank you! I’m going to be happy that I won something! It’s true: I do spend time, money, and energy on the open source community.

  • I mentor other writers
  • I spend hours and days crafting talks
  • I quietly support other women and under-represented people, dozens of hours a year
  • I contribute thousands of words to the corpus of knowledge with tweeting and blogging
  • I ask stupid questions so other people don’t have to

That’s a pretty good list. I’m happy with it. So thank you, members of the Open Source Bridge community. I appreciate your recognition, and I’m honored.

Creative destruction

I was making a joke about the fact that I accidentally have two profiles for Open Source Bridge – one is with pink hair, and one with brown hair. Obviously, one of them is the mirror universe me. Probably the one with brown hair. No one with pink hair could be sinister, right?


I said that my mirror universe self would obviously specialize in creative destruction, instead of speed-building documentation sets from nothing. But in truth, I do both.

Any sufficiently complicated documentation set is indistinguishable from a pile of cruft.

Creative destruction is related to deleting, but is not the same. Creative destruction is less trashing things by category, and more like letting a herd of goats loose to clear a hillside covered in Himalayan blackberry. The goats are a lot more discriminating and not as destructive as a flamethrower, but they are omnivorous enough that your wild roses may also get eaten with your blackberry brambles. Creative destruction lets you take a cleared space and plant something new in it, without having to work around what has grown up over time.

This is the part of the konmari method that I identified with most. Put everything of a category together, look at it, and decide what it is that you want to keep. It's really difficult to make distributed decisions because it requires holding all the objects of that type in working memory, and our working memory, as literate humans, is just not that good. Play to your strengths, which in this case means "make it easier to be bold about deletion/destruction".

When I walk into an organization with existing documentation, I like to do a gap analysis: What traditional docs sections might they be missing? What things do I wish I knew as someone new to the product? Does the documentation cover every step of the product, from pre-installation to removal? Can people make good business decisions based on these documents?

A documentation destructionist looks to see what we can carefully, mindfully burn to the ground. Is it old? Is it about something we don't support? Is it a path we didn't follow? Archive it, delete it, and move on. You don't want to leave old versions of anything around if it will confuse the issue when someone is trying to use your tool.

Clearing a swath of ground makes it possible to see the daylight between the trees, give your good docs a bit of breathing space, plant new things that you want for the future or the present. New ideas grow best with some sunshine and elbow room, and even if you have infinite storage space for documentation, no one has infinite attention to read or maintain it.

Happy Tuesday! What can you destroy today? What would your documentation set be better without? What is out there bothering you ever time you go past it? Go get rid of it!

The art of deleting

I have a talk where I encourage everyone to be clear on the data they collect and keep. I encourage people to automate deletion so they don’t have to do anything extra. In the original incarnation of the talk, I said that everyone should apply konmari principles to the data they keep, only instead of “sparking joy”, data we keep has to have a clear and immediate purpose. It has to spark respect and utility.

I like konmari for the idea of grouping all of a similar type of thing together and then sorting them together. I, er, don’t usually attribute emotions to my socks. I think it’s a little difficult to sort data based on the emotions it gives you. Data at the scale most organizations are working at is less in the range of “books you own” and more in the range of “bacteria in your body”.

When I was looking for another analogy, I thought back to my time on the Microsoft BitLocker team. I was with them as a writer for that first year, when we were still explaining the value proposition over and over again. The laptop, we would explain, was an easy loss to write off, as long as the data on it was secured. A couple thousand dollars worth of laptop left in the back of a taxi was so trivial compared to the cost of a data exposure or breach. It was difficult to change our paradigm at the time to “trust the cloud”, but that’s where we were headed. The data was on a corporate network, or a backup, or in the rudimentary beginnings of the cloud. It was ok if we never got that laptop back. We all had to change how we thought about losing things versus losing access versus losing data.

Here are some instructions for deleting your personal data, as inspired by one of my favorite poems.

One Art

BY ELIZABETH BISHOP
The art of losing isn’t hard to master;
so many things seem filled with the intent
to be lost that their loss is no disaster.

Delete reminder emails, meeting notices, any ephemeral message about an event that has passed.
Delete pictures if they’re not labeled, anything of people you don’t know or care about.
Delete the easy levels, the games you don’t play, the spreadsheets for projects that are long past.

Lose something every day. Accept the fluster
of lost door keys, the hour badly spent.
The art of losing isn’t hard to master.

The hour badly spent is hard to delete, you’ve already done it. Nevertheless,
delete games you don’t enjoy playing.
Clear your media feeds and timelines of people who don’t feed your soul.
Dig down and delete those emailed fights with your ex, or your current. That was then; this is now.

Then practice losing farther, losing faster:
places, and names, and where it was you meant
to travel. None of these will bring disaster.

The opposition to this line is “Hold fast to dreams/for if dreams die/life is a broken-winged bird/that cannot fly
Delete who it was you meant to be, all the things that make you feel guilty.
Purge the Pinterest for a wedding you did another way
Dump fitness apps that you just wince at, delete false starts and walk away.

I lost my mother’s watch. And look! my last, or
next-to-last, of three loved houses went.
The art of losing isn’t hard to master.

What are you leaving for your heirs?
When we come to clean out your house, will there be boxes of clippings?
Clean and organize your bookmarks, toss all the pointers to dead sites
Ruthlessly rid yourself of mediocre selfies and unlabeled group photos and clutter.

I lost two cities, lovely ones. And, vaster,
some realms I owned, two rivers, a continent.
I miss them, but it wasn’t a disaster.

You will lose some things you meant to keep. That is the nature of things.
You will regret some deletions, and you will worry a bit.
I’m sorry, but life is full of loss, and paper fails and disks fail and the memory of humankind is frail.
It won’t be a disaster.

—Even losing you (the joking voice, a gesture
I love) I shan’t have lied. It’s evident
the art of losing’s not too hard to master
though it may look like (Write it!) like disaster.

Practice losing, practice letting go, practice only saving things for a year, or two, or ten.

The art of losing, of forgetting, is built into us, the entropy that causes things to fall apart. Fighting our nature is sometimes noble, but less than we hope. it’s sometimes useless, but less than we think.

Nothing I write will be relevant in 5 years, 10 at best. That’s always been true. Technical writing is like that, and I have to accept that I’m etching server instructions in the sand at low tide, or lose my heart when the waves come in. Almost nothing you write, or save, or store, or archive will relevant for longer than that, either. Learn to let it go, and prepare your writing stick to scratch meaning in the beach at the next low tide.

Loss is not a disaster.

Lady Speaker Small Talk

Sometimes, I think the hardest part of going to conferences is the unstructured time – lunches and happy hours and sponsored parties. That’s the time I remember I’m surrounded by 2,445 total strangers. And I’m supposed to be networking with them. If I think too much about this, I end up at “what do I even do with my face?”

The goal is not really “networking” in whatever negative way you’re thinking of. The goal is finding interesting people and showing them that they have neat things going on.

It turns out that conferences are full of people who are alone or nearly alone. If you came as part of a team, or you are working the conference, the social stuff is different, but if you are alone, here are some things I do.

Look odd

I have fuschia hair that I wear in a variety of short, eye-catching ways. Since I’m almost six feet tall, I’m really easy to find in a crowd. You don’t have to make quite so striking a personal style statement, but it’s useful to have people able to find you because you’re wearing a tophat, or orange sneakers, or all safety orange, or whatever it is you decide on. Your conference friends, the people you have met at other conferences, will recognize it. Strangers will see you on stage and note the thing about you so they can find you to ask questions later. And if you make it something less permanent than hair color, you can not wear it and totally blend into the crowd.

Make a friend in the registration line

Odds are, you’ll be standing here a few minutes. This is a great time to turn to the person next to you and ask them their name, and what they’re here to see, and what they’re looking forward to going to. Not, like, all at once. Then you sound like a teacher asking about a book report, but as conversational starters. Is this your first year here? If you’ve been before, is there some local food I can’t miss? For the rest of the conference, you’ll probably be able to spot that one person you met early on and give them a friendly nod. And if you’re very lucky, the name on their badge will be readable.

Sidenote: The minute I get any standard-length lanyard, I tie a knot in the back of it so that it hangs higher on my body. Now people looking for my name don’t have to track their eyes past my cleavage. This is a habit I picked up several years ago, and I think that having your name as close as is comfortable and feasible to your face is a win.

Go to other people’s talks

It’s super tempting to hide in your hotel room frantically preparing for your talk. I’ve been there. But I also know that a large part of the value exchange in this conference is that it consts money to attend and I’m not paying anything. So I try to go to a talk in as many slots as possible. I might take the slot before my talk off, and sometimes, depending on how drained I am, the slot after. But mostly I really want to go to people’s talks. It may seem odd, since I don’t have power over any servers, I code in no languages, and I only nominally work in teams, but I still get a lot of value out of conference talks. The technical ones help me keep a finger on the technology zeitgeist. The people-oriented ones always teach me something, because being a consultant is both managing up and sideways.

I always livetweet the talks I go to, but that’s for a different post. Mostly what I want out of going to other people’s talks is an understanding of a technology or application of technology, and to have attended the same conference as other people. At a multi-track conference, it’s easy to go to different conferences in the same venue, depending on your interests, but if you go to talks, you’ll always be able to ask what other people went to, what they thought, and then respond with what you learned or wanted to argue about from the talk you watched. “What talk did you get the most out of today” is a lovely, neutral question and sparks a lot of conversation.

Remember the theory of paradoxical popularity, or charismatic loneliness

I’m sure there is an actual psychological term for this, but lazy googling did not find it. Did you know that the prettiest girl in a high school gets asked on fewer dates than an average-looking girl? Did you know a lot of people that you think of as important, or influential, or famous, eat conference dinners alone? 

That may be by choice — there’s a lot of people energy involved in giving a talk and then doing the networking afterwards, so if a person wants to eat alone, let them. But I’ve noticed that people I think of as amazing sparkling wonderful stars in this context are eating alone. I think we are all valuing their time as too precious for us, and not even asking, a kind of low-level excessive politeness. I’m not saying you should ask more than once, but it’s probably ok to say, “Hey, I really admire what you’re doing, I’d like to talk about it more, do you have someone sitting with you at lunch?”

Talk to the sponsors

These people are sitting at the vendor booths, handing out swag and trying to get a badge scan off you beacuse someone is juding them on this back home. If you do want something on their table, walk up, make eye contact, and ask for it, don’t just grab. If they’re busy talking to someone, spend a minute or two listening to the pitch. You may not be a person in the market to buy things now, but it never hurts to treat the people who make conferences happen well.

The same goes for organizers. They seldom get to see the conference, because they’re making it happen. The have worked months on this, and whether they’re paid or unpaid, they are on constant alert for Something Going Wrong. It’s really stressful! So if your organizer stops and asks you how it’s going, or if you have what you need, remember to say thank you before you start in with a complaint.

Pacman

I got this one from Eric Holscher at Write the Docs. We tend to naturally form a circle when we’re standing around talking about a topic.  It takes a special kind of courage to approach a ring of backs. Instead, as you’re standing in the ring, open up space between you and a neighbor to leave room for a new person to slip in and add to the conversation. You’ll be surprised by how much difference this little bit of body language makes in making your informal conversations more interesting and varied.

Volunteer

The best way to love a conference is to be part of it. Not every conference offers this opportunity, but if you can volunteer, you should consider it. Having a set role makes it easy to interact with people. “Here’s your badge and your t-shirt. Have a great conference!”. You’ll also get to know other volunteers and organizers, as there’s almost always a backstage that attendees don’t see. This is where I have had some pretty amazing conversations over the years.

Stickers

I have a gallon bag of stickers that I carry from conference to conference. People take some, I collect some from tables and people and vendors. The stickers come with stories and then I can re-tell the stories at the next conference. Much like doing a jigsaw puzzle, sorting through a pile of stickers encourages people to stand around and have an idle conversation without feeling tense or anxious. I’m sure if everyone did it, it wouldn’t be novel, but even if you have one type of sticker, from your employer or personal brand, it’s still something to talk about and enjoy together.

On the topic of business cards

Spend money on business cards. I know it seems like an antiquity in the age of tap-contact-swaps, but there’s something about the tactile delight of a good business card that makes people comment on them and remember you. Mine are especially bright, with a plasticky finish. The back of the cards more-or-less matches the color of my hair, which serves as a good mnemonic. I get mine from Moo, which means I can have the fronts different designs — I’ve used this to put 5 or 6 witty tech writer slogans on the front, and I happen to know that people will pin them to cube walls because they’re funny, bright decoration. There is no higher state of winning than having your business hard pinned to a cube wall. In contrast, printing yourself or using a cheap printing service means you’re handing out something that feels disposable, so people do dispose of it.

If you have to hand out your company cards, that’s what you’ve got, but consider if there’s some other personal branding that would feel natural and satisfying to you. At my last conference, I gave away tiny (1/4 inch) hedgehog stickers for people to put on their badges as an indicator that they’d met me. Spontaneous fan club! Or something.

Done talking now

One of the hardest things I had to learn was how to end a conversation gracefully. I almost always start by thanking someone for their time/insight/advice. Then I say something like:

  • I’m off to the next talk! Catch you later.
  • I need to make a call.
  • I’m meeting someone in a few.
  • I’ve gotta go do a thing.

I know – a thing? But it works. 

    In summary

    If you think of conference conversations as purely utilitarian, they will be difficult and dry. Instead, think of them as a way to learn a new and interesting thing from everyone. Good luck out there!

    Wordstar 2000, the Sapir-Whorf Hypothesis, and the moulding of a young mind

    I came across this interesting article about how some people still use Wordstar as a word processor. The two main points are that Wordstar is designed to be used entirely without moving your hands off the keyboard, and that Wordstar behaves more like the act of writing a document longhand than typing or retyping something in a page-based model. It delves into some really esoteric features, but the majority of the features the author mentioned were things that I remembered fondly.

    Wordstar 2000 was my first word processor, and it was the foundation that made it easier for me to grasp semantic markup like HTML when I met it later. If you wanted to bold something, you did it without switching mental contexts, you just typed a command that would make things bold until you turned it off again. There wasn’t a mouse (the “2000” was aspirational, not descriptive). There wasn’t much of a visible menu, there was just you and the black screen and the blinking green cursor. That idea of inline formatting stayed with me.

    There’s a linguistic theory called the Sapir-Whorf hypothesis that says the way we think is influenced by our language. Our linguistic pathways make it harder or easier for us to think in a certain way. I think that’s certainly true of software that we encounter at formative stages. For me, Wordstar taught me to separate the content of my writing from the formatting of the output. Now we call that writing with semantic markup or sometimes just semantic writing (which is a deplorably broad, fuzzy phrase). My formative computing and writing happened at the same time, at the end of the typewriter era (I learned to type on a typewriter) and the dawn of the visual web. I think it gives me a distinctive quirk to the way I think of text, and writing, and all the intersections thereof.

    Sarah Mei recently posted that even if Ruby did not survive as an intact language, it would influence a generation of people who think about code, the way Smalltalk influenced the generation who started originating the ideas for Agile. I loved that idea, and it made me think of the ways that academia has to trace lines of influence and inheritance of ideas. I started out as an English lit major, and we are super into “the marxist reading of Frankenstein” and who Mary Shelley had read and would be influenced by, and so on. It’s a habit we don’t have as much in technology, I think. We tend to treat ideas we adopt and raise as if they were entirely our own, and we either deliberately or accidentally strip them of context and heritage. 
    I think about that tendency when I rewrite something, and when I leave a project. Because I do work-for-hire writing, there is almost no expectation of attribution. I come in, take whatever text there is, rework it to serve the needs that I can see or have been told of, and then move on. But in some hypothetical state where software could track all my works, I wonder if you could see the places where I learned task-based writing, where I played with and mostly-discarded DITA, where I was working from story cards or working from interfaces. Academics keep track of all the things they write for publication. I have LinkedIn because I literally have no idea who I’ve worked for without a reminder.

    The thing about the Sapir-Whorf hypothesis that I find extra fascinating is that if you really and truly learn an additional language, you can remap or add onto your thought paths, identify colors that don’t exist in the original language*, construct ideas that just don’t work in your original language, all sorts of magical thinking. Learning an entire human language is daunting, but any language we learn, any concept we internalize can rewire us to an extent. I have probably…. 8 distinct registers for writing, and each of them is deliberately learned and curated. Every time I add a new one, I can see places that it would have been handy to think this way on past assignments.

    What does all that have to do with my first word-processor? It makes me honor how different pieces of software “think”, what their paradigm is, and how I can write in a way that keeps that intact. For example, this week I learned something vital about YAML files ( I think). I was having a terrible time getting an indented TOC to work, and the error message was just this side of useless. I took a break to do some sewing, and reminded myself that the curves have to match on the sewing line, not the edge of the fabric, the edge of the fabric is not important. When I came back to the accursed YAML file, I figured out that the indentation is not based on how many spaces you are in from the line start, but that your indentation marker is directly below the first letter of its container. That changes the whole paradigm. The program is not counting spaces, it’s counting the first meaningful character on a line. If I get this into my head well enough, the next time I meet something like that, I will know to check my assumptions on which part needs to match.

    What about you? What languages have shaped how you think and work? What paradigms do you use every day?
    —————-

    * I used to think that the men I knew didn’t care enough about colors to identify them correctly, and were therefore being lazy to say “blue” for both “teal” and “cobalt”. Then I realized that a) some of them are colorblind and may not even know it b) they are discouraged from or never taught the extensive color names that are practical and useful for someone who dresses as a woman. If you tell me a sweater is plum and it shows up eggplant, I’m annoyed, because those are different colors to me, and I was planning on one of them. 

    It makes me wonder how many things I’m lazy about identifying because I don’t care or I’m socialized not to make the effort. Like, um, baseball positions or birds or knots. I can learn them if I care, but I don’t right now, so it’s all “small brown bird” and “knot around things”.

    Linguistic relativity in colors