7 Practical Tips for Inclusion

This chick I know, I interviewed her last week for my upcoming podcast debut. She’s phenomenal in a way that makes me so proud, grateful and humbled all at the same time. Sufficed to say, I found a place to put one of the ideas I had been holding on to ever since I started going to the Women In Tech group at my work:

“Practical Tips to Help White Dudes Help Out”

Trust me, I’m a subject matter expert on this. I’m so white, I made the vanilla ice cream we had for dessert tonight say “daaaaammn!” (then I ate it up). And though I’m not into sports and don’t have lots of chest hair, I am definitely dude.

I’m the kind of dude that wants to help. I have a son and daughter and I want the world to be a less sexist, less broken place by the time they are out in it. It’s that attitude I look for in others, not the other things that differ between us.

Yet it still remains, there are huge imbalances in society no matter what angle you look at things from. Good intention matters a little, but action in the face of injustice matters a whole lot more. It’s what you do that defines you to others most because only a few people in life will ever spend the time to see past that.

What Can We Do to Help?

The difficulty with things like gender inequality, under-representation, privilege, and inclusion is that they’re too nebulous/vague/ethereal for the side of the crowd that can/should/doesn’t do something about it, namely white dudes, to take action on a daily basis. It’s not that we’re white or that we’re dudes, but for whatever reason, many dudes just need practical instructions, marching orders, or technical requirements to move from well-meaning to noticeably effective.

So I wrote some specific tips down. Their implementation might differ from person to person, so I wrote them in their most generic form:

WP_20160214_004

Since they aren’t exactly marching orders, more fortune cookie mnemonics, I’ll put down some examples. They apply to all people, not just dudes to women, white people to everyone else, they apply to people who want to help other people. For the sake of this article, I’ll write it as instructions to my fellow white dudes:

1. Step up by being willing to step aside

Instead of offering your own idea, ask a co-worker for her opinion first. This works best if you do it once or twice casually on a personal basis before doing it in a group or meeting.

Doing so privately before hand can establish trust and help you understand if it’s appropriate to do so in a group setting like a meeting, so that you don’t accidentally put them on the spot.

If you do successfully help to elevate someone else in a group, congratulations you’re using your white dude privilege properly, that’s why you feel good.

2. Invert the situation in your head

When people address a group as “guys, guys”, think about what it would be like if you were in a group and someone addressed you as “ladies, ladies”. It’s a trite example, I know, figure of speech, but ask yourself: why is there even a gender associated with that figure of speech? #culture

When was the last time you heard the words “aw, it’s so great to see a man programmer, really brings some diversity of thought into the group”? or “really? you like beer? are you sure you don’t want some wine or a fruity drink?”

Gender/racial/sexual bias is baked in to _every_ aspect of American life, so there should be plenty of opportunities to invert the situation and see how subjugating it would feel to be on the other side of things.

3. Learn where the gaps are around you

Be willing to ask your human resources department to provide you statistics of gender, race, and ethnicity in your organization. Look around at how many black dudes or women are in your group? How about people from outside your background? If they say no, ask why? You can’t be fired for asking about this stuff. If you are, then be glad! You’re no longer working at the wrong place to work.

4. Don’t chalk things up to a stereotype

Please, white dudes, please do not in your head justify the actions that a woman is taking with the fact that she is a woman. Do not think that he’s thinking that way because he was raised in the ghetto (a.k.a. where all ignorant white dudes think black people come from). And for the love of whatever, please do not justify your homophobia by saying “so long as he doesn’t try to hit on me, I’m cool with it”.

Stereotypes limit people to presumptions you have about them regardless of their actions, which are the one thing we all control about ourselves. Reduce how someone chooses to put themselves out into the world, and you reduce your capacity to see clearly, to respect, to love, and to be loved.

5. Listen; be more interested than interesting

I will never reach a point where I can’t get better at listening. I’m terrible at it today, I hope to suck at it less tomorrow.

The more you listen (awareness), the more you maximize your opportunities. It’s that simple. Action without listening is ignorance.

The practical way to do this is to write “STFU” on your hand, on your notepad or tablet before a meeting, or picture everyone in the room having it tattooed to their foreheads.

When you actively listen to someone, you express interest in them. People like to feel interesting, just like you, and giving that feeling to them as a gift is not a complicated or expensive affair. Both parties win in the end.

6. Find a liaison, socialize, and invite

It’s intimidating to visit someone else’s group or circle. The easiest way to smooth that social gravel is to have someone native invite you and liaise between you and the group.

This puts a responsibility on you to be inviting and socialize people not in your group. It also puts a responsibility on all of these groups to be inviting and look for opportunities to become a liaison too. Yes, I’m calling everyone out here.

Women in tech, take the time to bring a white dude to group. Black people, there is so much I don’t deserve, but the privilege I have you’re welcome to it so long as you’re my friend. We share friendship, we share privilege. That’s one way to get things flowing in both directions.

7. Don’t let failure stop you from trying again

All of these things will feel awkward, not just for white dudes, but for everyone involved. Creating something new doesn’t come easy. Easy is comfortable. If you’re going to be uncomfortable, let it be because of something worthwhile.

Other people are worth it. Try again. Don’t push it…if you’re doing #5 well, you’ll know when to back off. But don’t let failure stop you from doing the right thing. If there are others doing the same, the effect of trying will multiply itself in time.

Developer Experience is the UX of Your API

For software developers, APIs are a really logical choice for delivering how something should work on multiple platforms, acting as a sort of a common “language” between projects, systems, and teams.

Who really ‘uses’ an API?

Developers are the real ‘users’ of APIs. Sure everyone is the downstream recipient of the value of an API, but most of that doesn’t happen unless an API satisfies its first audience: developers. They need to understand how it works, how to incorporate it into what they’re designing, often designing APIs themselves. When something’s hard to understand on an API, they’re the ones that feel the pain, not the end user of the app.

You might stretch the definition of an API ‘user’ to encompass ‘anyone who benefits from the API’, but it’s really the developers who are adopting the API, proliferating it to others, and ultimately orchestrating the user’s interaction with your API, like digital gatekeepers. Benefactors and users are important to differentiate between as a business; one represents the volume of your business, the other represents your adoption curve.

Developers love something that just makes sense to them, and a well-designed API along with great documentation the best ‘UI’ an API can have.

dx-over-ux-equals-api

But APIs don’t have a UI!

APIs lacks a User Interface (UI) in the traditional sense, that is until you go back to your definition of who you mean by ‘user’ when you say ‘User Interface’. If the ‘user’ is a developer that interacts with code and APIs as their primary language, then you leave the UI up to them, but there is still an ‘interface’ to your API as a product.

Traditional ‘UI’ focuses on treating the ‘user’ component in terms of human sensory input and direct manipulation. APIs being purely digital products, they are primarily something you interact with conceptually and socially.

The social element of APIs is huge. By definition, by building an API, you are describing functionality in terms of what ‘your’ system can do for something else. APIs infer interaction, collaboration, and inclusion.

The role of UI and APIs in the User Experience

User interface (UI) is heavy work in terms of software; people slave over the perfect font, color scheme, and behavioral appropriateness of UI, only to find that the project is hard to maintain, change, or integrate with afterwards. Instead of thinking about how things look, good designers also consider how things behave.

User Experience (UX) design is a field that accommodates these considerations while also maintaining a keen eye on the consumer’s actual use, psychological reasoning, and emotional reactions to how a technology works. Yes, we need awesome UI, but only as a result of thinking about the human experience driving the functionality of the software, and only after we get the technical premises correct for the business requirements.

What Makes for a Great Developer Experience?

Developer Experience (DX) is the UX of APIs, but what lessons in great UI design can we apply to DX? What elements of great DX are unique to this non-traditional view of UX/DX?

If I had to boil it down, a minimum-viable API developer experience in order of importance consists of:

  • Documentation, both human-readable and machine-readable
    Hand-crafted API documentation is adorable, but most developers expect an M2M format like Swagger these days. A wise man once said: “he who hand-codes what he could have generated automatically using M2M descriptor is not spending that time making his API better”.
  • Minimize number of exceptions, not the exceptions themselves
    I get it. You’re special. We’re all special like snowflakes. Yay for us. Sad for users of your API. You may have some CRUD operational endpoints on your API, but more than likely you have domain-specific activities that require some explanation. Explain when you deviate from the most obvious, and try to keep things as simple as possible. Be sure to call out any exceptions to your own (internal consistency) rules like naming and type/structure differences between operations. And for the love of whatever, document why you decided to do so.
  • Test the new developer on-boarding process, constantly
    Proving that your DX is what you need it to be must be done regularly. Use hackathons, free account sign-up, metrics, and feedback to make sure that there are no broken elements of the on-boarding chain. If pricing is untenable, you might want to have the business owners focus on that for a bit instead of quarreling over design or feature specifics. Like a reliable disaster-recovery plan, a great DX only comes from putting your expectations through their paces.
  • Be personable, real, and transparent as possible
    Developers are people. Against the perception from non-technical people, they aren’t antisocial, they just hate bullshit and like to be passionate about really technical stuff. If your documentation, website copy, and support process reflect genuine concern for helping them solve their problem (and of course you do that too), you’ll be our their friend for life, or at least until you have a major outage.

Who Else Says Developer Experience is Essential to A Great API?

If you ask Jesse Noller, you’ll get an earful about documentation and transparency, and I agree. Documentation is the first thing a developer will reach for when working with your API. That doesn’t mean your efforts in DX should end there. You should also consider how other aspects like performance, authorization, and pricing play in to a developer’s decision to implement and evangelize use of your API over another throughout their team and career.

More reading: