PREROLL: Let's face it, your code is going to have errors, even code written by kick-ass developers such as yourself. When bad things happen, it's nice to know that Honeybadger has your back. Honeybadger makes you a DevOps hero by combining error monitoring, uptime monitoring, and chron monitoring into a single-use platform, all for way less than you're probably paying now. Honeybadger monitors and sends error alerts in real-time with all the context needed to see what's causing the error and where it's hiding in your code, so you can quickly fix it and get on with your day. Included uptime and chron monitoring also let you know when your external services are having issues or your background jobs go AWOL or silently fail. Go to Honeybadger.io and discover how Starr, Josh, and Ben created a 100% bootstrapped monitoring solution. Why is this important? Self-funding means they only answer to you, the developer, rather than a venture capital overlord. Greater Than Code listeners get 30% off for 6 months. Simply mention Greater Than Code when signing up and they'll apply the discount to your account; no credit card required. Rein Henrichs: Welcome to episode 196 of Greater Than Code. My name is Ryan Hendricks and I am here with my friend Coraline Ehmke. Coraline Ehmke: Hey everybody. I am very excited about today's guest. Aisha is a champion of feedback, a fierce accessibility advocate, and a steward of strong teams currently building , a musical tech conference. She also supports community by co-organizing self-conference and Detroit Speakers in Tech. Aisha is a theatre kid turned tech community leader, she approaches speaking and teaching as a way to give others the tools to shine as brightly as they can. In her spare time, she sings karaoke and pets dogs. And I'm very excited that this is going to be an entirely musical episode featuring Aisha singing. And I will be accompanying her on guitar and Rein. I think you're going to be the bass player. How does that sound? Rein Henrichs: Sounds good to me. Coraline Ehmke: [laughs] Aisha welcome. How are you today? Aisha Blake: I'm doing all right. I'm hanging in there. Coraline Ehmke: That's all we can do these days, right? Aisha Blake: Absolutely. Rein Henrichs: Aisha, we're going to ask you the question we always ask, which is, "What is your superpower and how did you acquire it?" Aisha Blake: Well, so my super power I would have to say is proofreading. I came by in my proofreading power after years of being nurtured by my grandmother, who was a grammar teacher in New York city for a long time. She's very, very strict and very passionate about grammar and the sort of importance of words. And that was instilled in me as I got older to the point where [laughs] by the time I got to college and I was really, I was in New York city starting to date kind of as an adult. One of the things I remember including in my OkCupid profile was actually one of the things I'm good at is proofreading. And so if you come at me with a message that I'd rip apart with my red pen, you might want to think. Coraline Ehmke: [laughs] Well, OkCupid is known for, it's a thoughtful dialogue, it's carefully consider positions and it's clear communication, so that was just a great vehicle for that, right? I'm sure everyone responded in kind. Aisha Blake: [laughs] Oh yeah, I did actually have a number of people comment on it like, Hey, how did I do? [laughs]. Coraline Ehmke: Oh wow. So proofreading is an important skill and it's very much returned to documentation in our day jobs. And I know you have some pretty strong feelings about documentation. So what would you say to someone who says the code documents itself? I'd want to say a lot of things, but what I would actually say [chuckles] is that, you might feel like the code documents itself and to an extent your code should absolutely be readable. That should be, in my opinion, one of the first considerations, you should be able to write code clearly. But I think it's also important that we really put an emphasis on solid approachable documentation separate from the code itself, because there are certain things that really can't be communicated well in the course of actually building whatever you're building, unique context, you need more of an entry point, especially if we're talking about someone who is new to software development, someone who is new to your project and that goes for internal documentation as well as end user documentation. Coraline Ehmke: For sure. I like what you said about context, because one of the things you cannot communicate in code very clearly is intent and context. Why is the code doing what it's doing? What alternatives did we think about, what forces shaped us, what circumstances shape this code? And I think to a degree, documentation is not just for other developers, documentation can also be for stakeholders or for communicating the work that you've done and can be used kind of as a narrative, right? Aisha Blake: That idea of a narrative is really important to me. And I think that it makes a lot of things so much clearer. It's easier to relate to and understand where the tool or the product fits into your own story. Coraline Ehmke: It's to valuable skill for developers to learn how to write. What would you say to a developer who buys into the notion of the strength of documentation on the value of documentation, but they're not used to writing documents for anyone except for other developers? Aisha Blake: I think it takes practice like anything. And, it takes a willingness to be wrong sometimes and to ask for help. I think that no matter how good you are as a writer, you're always going to need an editor. At least one. I know that my own writing is made so many times better by a particular friend who is an excellent editor. Anything that I feel really strongly about that I want to make sure comes across in the way that I intend, I take it to her, and she just, she tears it apart and helps me build it back up again. And it's so important. Rein Henrichs: I don't think that a lot of code comments get edited. I was thinking as we were talking that when people think about code documentation, I think people mostly think of code comments that get rendered as some form of documentation. But I don't think that that's efficient either. I don't think that code comments are a good place to discuss sort of the trade offs that were considered when a decision was made. And I don't think the code comments do a good job of telling a story about how code got to be the way that it is. So I was wondering if you could talk a bit about what forms of documentation you think are important and worth investing in. Aisha Blake: The form of the documentation takes really kind of needs to match the goal of the documentation. So depending on the type of software that you're building, you're going to need different types of documentation. So in my experience, working with more internal documentation, most of the time that is used in onboarding and it's used as a reference, right, for people who are actually working on the tool. And so in that case, the onboarding documentation is a combination of, these are the tools that you need in order to get up and running and to be successful on this project. And this is how the project is architected. These are the different systems that are important for you to understand, this is how everything links together. This is a synopsis of how we've gotten to this point. And here are the places you can go to learn more about each of these things. Where as in your day to day as a reference, that then it becomes more important to understand really how more individual decisions were made. And so in that case, I actually feel really strongly about writing really good commit messages and being really explicit in your pull requests. So if you're using a different kind of platform for version control and get hub, then you know, you have to kind of adjust to whatever it is that you're using, but one of the most successful teams that I've ever been on really, really great about kind of building up a whole story for each kind of task that we went through, really kind of taking [laughs] kind of taking the idea of a story that you pull across a board almost literally, and making sure that all of the changes that we made, it was really clear why we're making them, who is making them, what kind of input we had from stakeholders, how it related to other things. And so whenever I went back to look at a particular change, it was easy for me to travel back to its origin and understand, okay, this is why that decision was made. This is where I need to go from here. Coraline Ehmke: I think that two things survive civilizations as civilizations come and go: One is the architecture, which is hopefully built to last in roll-out, last set civilization. And the other is the stories that that civilization told to itself. And I see that really reflected in software development as well because the architecture lasts longer than the author of the code, most likely, and the story behind the code also needs to be preserved. And it sounds like one of the ways that you're suggesting we can do that is storytelling through commit messages. Aisha Blake: Yeah, absolutely. Coraline Ehmke: I think an important part of storytelling is knowing who you're telling the story to that requires empathy, right? That requires putting yourself in someone else's place. Aisha Blake: Yes. Oh my goodness. It is so important to understand, in my opinion, before you even begin who you're speaking to, and that goes for commit messages, that goes for your pull requests, that goes for tutorials that you write, that goes for reference guides. No matter what you're writing, you should know why you're writing and who you're writing it to. And that really helps you to hone in on what really needs to be included in that story. What kind of context do you need to give? What's going to be the most effective Avenue for that story? Rein Henrichs: I was thinking about the importance of understanding the goals when you write documentation. But I was also thinking that the people reading documentation often have conflicting goals. So for example, a narrative or a story may not work as well as a piece of reference where you generally want sort of like random access to parts, you know, to specific information. So I guess my question is first, do you agree with that characterization? And then if so, how do you balance sort of the desire for documentation to tell a story and the desire for it to be useful for things like reference and other purposes? Aisha Blake: Yeah, I think that there is definitely a balance to be struck and in a lot of cases, I'm kind of like, why not both? I think that there is space for straight reference almost, just a list of methods and properties and what they do and what they are. And I think that that's fine as long as somewhere you have context around it. I think that references have their place. Absolutely. Rein Henrichs: Do you think that the same artifact should contain both? Like, do you supplement function or method level, reference material with like class or module level stuff that tells a story? Is there like some external to the code place where that documentation should live? Does it depend? Aisha Blake: [laughs] It always depends. In this case, depending on the size of your team. So again, getting back to that, who, who are you writing for? As well as the complexity of your project, as well as a number of other things. There is room, I think, to provide additional context when you, even when you have a reference. So for example, imagine something like a straight reference where you have a list of end points. Let's say, I'm working in something like swagger and I've got my API and I'm listing out my end points. And that's kind of been generated for me, from my code and from comments. And that's great. Even in a situation like that, I think there is room for perhaps a separate resource where you get more context on, how do I even get started this API? What is this API for? And at the same time, if I'm a new member of a team that is building this API, there is probably a separate resources, hopefully a separate resource for me to understand, okay, well, how do I get this? How do I get this up and running? How do I test this? How do I contribute to this? What is the process for bumping the version of this API? That's kind of what I mean by needing context around a straight reference. Coraline Ehmke: I know I've I've been in situations before where I'm trying to consume a public API. And if all I have is a list of end points that really doesn't help me connect the dots, because there's probably a workflow that I'm trying to achieve. There's probably a combination of end points that I have to hit to complete a workflow. And I've very rarely seen API documentation that corresponds to a user story as opposed to a function. And I think that user stories are valuable tool, but we don't carry through user stories into our documentation typically. Aisha Blake: Yes. Oh my goodness. I can't tell you the number of times I've had students come to me saying, "So I found this API and I think that it has information that I could use in my app that I'm building for the first time, but I don't know where to start. I don't know how to connect to this API. I don't know what I would really use this for. I don't know how to incorporate it into this front end application that I'm trying to build." And I think that that's a problem, honestly, with a lot of documentation [chuckles] when it does exist. A lot of the time, I think we make too many assumptions about what the reader knows. And so you end up with particularly new users or users that are trying to decide between products or services or whatever, being really turned off by either a lack of documentation or poor documentation that makes too many assumptions. Coraline Ehmke: I keep thinking Aisha about your theater background and how that has informed your desire to tell stories through documentation. Do you think there's a link there? Aisha Blake: Oh yes. Yes. What comes to mind is, thinking about playing a character and how, for me, that means that I'm kind of sinking into this whole world that exists in the context of the play, but also in my own mind, I've made choices as this character and those come through in my performance. In the same way, I want to try and sort of sink into the existence of whoever it is that I'm writing documentation for. I want to understand what they need. And that can mean that I'm just sort of trying to imagine it, but ideally that also means actually talking to people. Rein Henrichs: It seems like if you have, let's say five personas for your product, you actually need at least five different documentations, or you need to resolve their conflicting goals and, and you know, in one thing. Aisha Blake: Yeah, yeah. Depending on what you're building. Yeah. The types of documentation that you produce, they probably should be varied. Let's say, for example, that you are building a front end web framework. You might have a number of different people who are kind of approaching it from different angles. You might need to write for somebody who wants to integrate with your framework. You might be writing for someone who is trying to learn how to code through your documentation. You might be writing for someone who is trying to develop their own system of say something like a, a UI library or something, and they want to depend on you. How do you kind of bring all of those needs together and write a single piece of documentation for you? You can. I think that's okay. I think that you have to approach documentation from that perspective of like one size is not going to fit all. Coraline Ehmke: I'm still thinking of it as theater background [laughs] Aisha. Aisha Blake: [laughs]. Coraline Ehmke: I'm sorry. I'm kind of fixated on that. It occurs to me that some documentation is not read. Some documentation is performed, and this will segue nicely [laughs] into your conference organizing, because there are different kinds of conference talks. And the technical conference talks that like, tell the story of how a particular technology evolved. And when you're on stage as a speaker talking about technology, I think the most effective talks tell a story, there's a narrative. Do you think developers should be thinking about their documentation as if they're writing for a performance? Would that improve the quality and improve or create a vehicle for practicing empathy and documentation? Or what do you think of documentation as performance? Aisha Blake: I like that. And that, that really resonates with me. Thinking about really how title of conf came about. So this musical tech conference, but I'm still holding in my heart and will absolutely happen really. Where that came from was it's sort of a combination of things. I met Anjana Vakil at a conference called JS heroes. And we sort of joked. it Would be so funny if there was a whole conference of musical tech talks, because she was preparing to deliver one leader that year. And when I saw she and Natalia Margolis perform, Oh, it was incredible. So they did this, they did this performance, truly performance of three sort of parodies of Disney songs and wrapped it all up [laughs] and called it Tail Call Optimization: The Musical!! And you could go from not having any idea what Tail Call Optimization was to actually understanding some kind of pieces of the puzzle and why it's important. And that is so beautiful. That's a very literal kind of interpretation of what we're talking about. Actually performing, actually telling a story on stage about this piece of technology, but it's so powerful, the idea that you can take a relatable medium that is so important and so emotional and so personal to a lot of people and use it to convey technical knowledge. I just think that that's amazing. And so I wanted to give people the space to do that even more. I wanted to support it. I wanted to find people who were doing it already and connect to them. And so that's why I'm still so excited about title of conf instantly named after one of my favorite musicals, title of show. I'm really excited for people to explore a different way to learn and a different way to understand the types of technical topics that, I think, we have a really rigid view of how to teach. Rein Henrichs: It actually seems really difficult to even define what documentation is. If you ask developers to point to something that has documentation, they might show you through react API docs or the standard library documentation of their favorite programming language or something like that. And those are sort of prototypal examples of documentation. But then there's a lot of other stuff that is sort of less obviously documentation architecture, decision records, probably documentation, random confluence pages that talk about the thing, maybe documentation, old Slack conversations that have to do with a thing. Are they documentation? It's really, you know, is a talk at a conference given in the format of like spoken word poetry documentation, maybe. But I think if our understanding of documentation is sort of narrow and fixed and binary, then we're really missing out. Aisha Blake: I agree. I think that there's so much opportunity to expand how we think about teaching someone to use a tool or to contribute to a project. I think all of those things can be documentation. And it's a matter of being intentional about how you pull those different sources together. Rein Henrichs: We'd like to take a break in the show to let you know that Today's show is sponsored by strongDM. Managing your remote team as they work from home? Managing a gazillion SSH keys, database passwords, and Kubernetes certs? Meet strongDM. Manage and audit access to servers, databases, and Kubernetes clusters, no matter where your employees are. With strongDM, easily extend your identity provider to manage infrastructure access. Automate onboarding, offboarding, and moving people within roles. Grant temporary access that automatically expires to on-call teams. Admins get full auditability into anything anyone does: when they connect, what queries they run, what commands are typed. It's full visibility into everything. For SSH, RDP, and Kubernetes, that means video replays. For databases, it's a single unified query log across all database management systems. strongDM is used by companies like Hearst, Peloton, Betterment, Greenhouse, and SoFi to manage access. It's more control and less hassle. strongDM. Manage and audit remote access to infrastructure. Start your free 14-day trial today at strongdm.com/SDT . Coraline Ehmke: One another interesting thing that you touched on a little bit is, how creating different vehicles for talking about our technology can help people with different learning styles. I know that I've encouraged early career developers to do this trick where every time they have to Google something technical, they have to write it down in a journal. And the Next time they need to figure out or remind themselves of how something works, they should look to their journal first, before they go to Google. And the reason I have people do that is because, the act of writing it down can improve retention and can improve understanding. And it seems like making documentation accessible in different media might be a better teaching tool because it's more adaptable to different people's learning styles. It's an option. It's another way to get at that understanding of really what's going on. Aisha Blake: Yeah. As long as the documentation is first accessible. So making sure that literally every one or as many people as possible can access the documentation, whatever documentation you have. So making- so things like making sure that there is some text component to everything that you write, including audio, video, all of it, all of it's captioned or transcribed or both, all of it is accessible. Then I think it's about making documentation approachable. So do people retain it easily? Does it fit with their own conception of kind of how they learn? And for me, it's not typical, certainly. And it would be very difficult to maintain, but song is absolutely that for me, I can conjugate a single verb in French. And it is because I was taught a song in the ninth grade. Coraline Ehmke: That's amazing. Aisha Blake: [laughs]. Coraline Ehmke: And people know about tail call optimization because of a song. And I think we should require all developers at all organizations to sing their documentation. I think that'd be a great idea. Aisha Blake: I would certainly enjoy it. [chuckles]. Coraline Ehmke: [laughs] But the importance is the storytelling. The importance is adapting to the learning style of your reader and all of that requires empathy. And I've done a lot of talking and writing and speaking about empathy and software development. And I think this is one of those situations, documentation's one of the situations where it's really an opportunity to practice empathy, because you have to put yourself in the consumer of that documentation's place to understand where they're coming from, to understand maybe what they already know and how to build on what they already know. That strikes me as a larger responsibility than one developer writing documentation. That's a group effort. Right. And in some cases, in the case of like an open source project, that might even be a community effort. Aisha Blake: Yes, absolutely. It is so important to have that kind of buy in from a community or a team, kind of whoever has the ability to contribute to that documentation. I know, certainly for me, I've been concentrating on documentation for the last several months. And the biggest help to me has been the ability to collaborate with engineers as they are building a feature and to be able to work with them to help. And so it's a back and forth. I'm helping them to understand how to think about communicating the thing that they're building, just as they're teaching me how this thing is used, how it was built and what it can be used for. And particularly for open source work, I think that's kind of where a style guide for your documentation becomes really, really important kind of holding yourself and your team and your community to a standard. Coraline Ehmke: And that ties in with so many other community building activities. It strikes me as that it can be a matter of a value that you hold being clear communication or being beginner friendly, whatever your goal is. And then expressing that value through artifacts. That's the same kind of thing that we do with codes of conduct. That's the same kind of thing we do with documentation of team culture or ways of working. Those are all community management tools and documentation is, is its own kind of community management tool, right? Aisha Blake: Yes. Yes. I absolutely agree with that. Rein Henrichs: One thing that community is required is, a shared common ground. There has to be some agreement about the language that you're using for example, and the values that the community shares have to be compatible and so on. And learning also requires common ground. There is no way to teach someone something if you don't share common ground. So in order to be effective at writing documentation, you also have to be effective at constructing a shared common ground. And so, I think, it's actually, like you're saying Coraline, directly related to community building. Coraline Ehmke: So, Aisha, how can you be deliberate about that? How can you be deliberate about the value that you place on documentation and making sure that everyone in that community, whether that community is a team or an open source community or, or what have you, I guess even the relationship between a company, their products and their users, how can you best be intentional about that? How can you make sure that everyone is living up to that standard that you aspire to? Aisha Blake: I think that it's important to have those conversations early and often. And by that, I mean, in your onboarding process, whatever it is, whether we're talking about a team or a community, or whether we're talking to users, making it clear from the very beginning of that relationship, that this is important to you, this is how you uphold that value. And also I think that that means being willing to enforce that standard, being willing to say, Hey, this didn't meet the standard that we have agreed to. Hey, you know, we have this value for a reason, and these are the ways that I think we could be upholding that value better. And that gets into the question of like, how do you give constructive feedback? How do you kind of build that trust and kind of get the work done? Rein Henrichs: How do you do that then? Aisha Blake: [laughs] Well, I have a lot of feelings about feedback. I have some strong opinions. I think it's undervalued much like documentation. [chuckles] I think that feedback is undervalued. And I think that it is often mischaracterized as being purely negative. When we talk about feedback, I think we jumped to, Oh, I'm being reprimanded for something. And if it's good feedback, if it is well-constructed feedback, that's generally not the case. If I'm giving you feedback, I personally [laughs], I'm giving you feedback, you can trust that it's because I care about you and I want our relationship to be better. I want our work together to be better. If I didn't, if I didn't care, I wouldn't bother. I think that feedback is a really important tool to help build those relationships, to help build that trust if it is done well. I think that often it's not done so well and it can really drive a wedge between people and it can make it harder to get the work done. It can be harder to hold people to a certain standard, whether we're talking about documentation or just sort of more general work practices. Coraline Ehmke: I stitch fix where I work, one of our cultural values is feedback. And one of the things that I realized about feedback is that just like any other social interaction, feedback requires consent, how would you bring consent into the picture when you are in a position where you want to give or need to give feedback to someone else, and you want to make sure that it's going to be received well, or that they're in a place to receive it. How do you navigate that? Aisha Blake: Yes, [chuckles] I'm going to say it depends again. And it depends on the urgency of the feedback. I'm coming at this as someone who has a lot of experience giving peer to peer feedback. And I think that it is important to kind of lay out expectations as much as possible. So in an ideal situation, you have established a relationship where you are regularly giving each other feedback in that scenario. If we're on the same team and you know, something comes up, I want to talk to you about it, that's kind of part of our regular communication already. That's ideal for me. But if something does come up and it's sort of out of the ordinary and I want to be intentional about that conversation, then I will say, Hey, I didn't feel great about XYZ. And I'd like to talk to you about it. Could we set up some time? So that does a couple things. One, it lets the person know what I want to talk about. I cannot tell you how upsetting it is for me to get a message that just says we need to talk in a professional context. Coraline Ehmke: I hate that my boss just did that to me last month. And I was like, am I getting fired? What's going on? I ran through all these like worst case scenarios and it ended up being trivial, but I really have problems when people do that to me. [chuckles]. So. Aisha because wherever we have a strong feedback culture, we then think about that as a skill to interview for. And we have mechanisms in place for measuring, at least attempting to measure someone's problem solving and belly, or their ability to translate a problem into code. How do you interview for the communication skills, the interpersonal skills that are required to give good feedback? Aisha Blake: Yeah. So I've seen it done a few different ways, and I personally think it's important to interview for the way that a person gives feedback and also how they receive it. So do they take responsibility for what they've done in a given situation? How do they move forward as well? That sort of after the feedback phase is really important to me, like what changes? Does anything change? As far as giving feedback, I'll generally start by asking, you know, tell me about a time you gave difficult feedback. What I'm looking for is not necessarily details. I don't need details, but I want- what I want from that conversation is to see, did they get consents? Or did they sort of rush in assuming that their feedback was valid? How did they, how did they deliver that feedback? So was the sort of problem, the behavior or the impact of something, or was that problem attributed to a person or their personality? When they had that conversation, what was the relationship like? What was the level of trust and how did they, how did they contribute to that trust on an organizational level? Those are the kinds of things I look for. And on top of kind of do I think this person can give genuine feedback, because you hear people talk about the compliment sandwich, there are a few other terms for that, but did they deliver the feedback in such a way that they were communicating the importance of the impact? As well as making it clear that their feedback was about that impact for the action, the behavior and not about the person. Rein Henrichs: I really love tell me a story as an elicitation method, in all sorts of contexts. There's only one other method that I know of that works, which is roleplaying. And if you're thinking well, that's weird. I will just say that when you hand someone a marker and tell them to go up to a whiteboard and write a quick sort algorithm, you are both role playing, being a person who gives a shit about solving a quick sort algorithm on a whiteboard. Aisha Blake: [laughs]. Coraline Ehmke: [laughs]. Aisha Blake: Yes. So I actually have a workshop that I took around to a bunch of different conferences, a couple of years ago. And it is essentially that I talk about feedback, I talk about why it's important, some ideas around how to deliver it well, and then we role play. I have a little set of cards, but I just started carrying with me all the time. The way that it works is, each person gets- split up into a group. So usually groups of four or five, and everybody gets a little sack of these cards. And the cards are broken into pairs. And the pairs have one sort of recipient of feedback and one deliver of feedback. And the idea is, for each person to take a turn, playing out one of these scenarios. So the person who is delivering feedback kind of gets a run down of their own backstory and what they think is the problem. But the person who is receiving feedback gets none of that context. They have their own story. Then given kind of what we've talked about and what we've worked through, in the first part of the workshop, their job is to have the conversation and work out where do we go from here? How do we change? Does anything need to change? Or is it just how we think about this problem? It's really one of the best experiences I've had as a conference speaker to just walk around and listen in on everybody doing this exercise. [laughs]. It's a lot of fun as well as enlightening. Rein Henrichs: That sounds great. So Virginia sat here, did a thing in her family therapy that she called sculpting, where she would actually get family members to re-enact certain family dynamics. So for example, if the husband blamed the wife, she would position him in a way where he was sort of pointing at her and maybe like towering over her. And then she would try to get them to talk about what it felt like to be in their body at that moment and things like that. And I always found that really fascinating. Aisha Blake: Yeah. That's so interesting. One of the reasons that I really value role playing as an exercise is that, you feel it in your body. Like, the situation might be contrived. Like the specifics of what you're talking about are actually things generally that have happened in my life, in the case of the workshop. But they're not your problems necessarily, but you feel something like what it feels like to tell someone that they're coming to work smelly. Rein Henrichs: Yeah. Aisha Blake: Or, [laughs] or you thought that the way they handled a client interaction was inappropriate. And you have to say those words, you have to look someone in the eye and tell them that. And then the other person has to take it and they have to respond. Rein Henrichs: Yeah. Aisha Blake: And whether or not that specific situation actually happened to them, it doesn't matter as much as you might think. Rein Henrichs: And it's different when you put someone's body, even in that context. And I mean, there's very scientific evidence that this is true. So for example, in cognitive interviewing, one of the main things that you do is you try to reconstruct the context. So they'll take a witness back to the scene of the crime, for example, and that's because cognition is extended and the context that you're in when you're thinking matter, it changes how you think. Aisha Blake: Absolutely. That kind of brings me back to the topic of learning through song actually. When I listen to a song or when I sing something, I am often taken back to a time either when I listen to that song really often, or when I first learn the song, I can absolutely see how that extends out into so many different areas. Coraline Ehmke: We've been talking about documentation, we've been talking about performance, we've been talking about feedback, all of this strikes me as skills that are undervalued in our field. That kind of brings me around to the idea behind self-conference. And in fact, this podcast Greater Than Code, where we focus more on those human aspects. And we've talked about interviewing for those human aspects, and these are the interpersonal skills varies so much person to person, culture, to culture. What kind of advice would you have to someone who maybe has been approaching their work from a very technical mindset? How do you communicate to them that these other skills, whether it's writing documentation, writing user stories, giving their colleagues feedback, how do you communicate the importance of those things? Aisha Blake: That is a big question. That's part of why things like self-confidence are so important. It very intentionally gives us space to talk about those things. So for anyone who isn't familiar, self-conference is a conference here in Detroit, which for years has been a very intentional split between what we would typically describe as technical talks, and what we would typically describe as soft talks. We call them people talks. And they're very focused on teams, on communication, on kind of building each other up. And we talk about things like mental health. We talk about things like accessibility. We talk about inclusion and how to actually include people rather than just talking about it. And we talk about things like feedback. Self-conference was actually my first conference I ever attended, spoke at. Certainly the first conference I ever helped organize. And just holds a very special place in my heart. But part of the reason that it does is that the community that then comes out of this conference where we are focused on building up whole people who work in technology. That's huge for me. I think, if we're going to communicate why those skills are important, I think it starts with pointing out the missing scare in our teams. And to a certain extent in our industry. But I think it starts with saying, Hey, this specific thing, I think, we can all agree, for example, let's say, we're talking about feedback. I think, we can all agree that it does not feel good when your boss says we need to talk at work, whether or not you are very, very focused on what we call people skills or technical skills, whether or not you see a distinction between them. Most people would probably say that is not a pleasant experience and that it can have an effect on your performance at work. I think, it's important to focus on the impact of the issues that these skills can help us address. That impact is often emotional and has an effect on our mental health. But I think that we can pretty clearly draw align between those impacts and the way that our health then affects our work. And I think that that's more, that's more compelling for some people. For some people, you really need to spell out, Okay. Yes. The fact that I don't get feedback that hurts and that has an effect on me personally. But then in turn, that has an effect on my work, that has an effect on the way that I communicate with the team, that has an effect on our bottom line. Coraline Ehmke: One of the lessons that I've learned in researching the history of ethics in computing is that, I remember one of the first laws of technology. There's the expression that technology is not neutral. It's neither good nor bad, but nor is it neutral. Because technology exists within a societal context. And it strikes me that the work that we do with technology also exists within a social context. And we ignore that social contexts act great para. Aisha Blake: Oh, yes, yes. The number of times that I have heard someone say effectively, Oh, you know, don't bring politics into tech. Tech is neutral, is painful to think about because it's just, it's so dangerously wrong that we could suppose that the systems that we build don't then have a huge effect on our society, even as they're influenced by that society. Coraline Ehmke: And that goes all the way down to the level of the people creating it and how they interact with each other. Right? Aisha Blake: Absolutely. Coraline Ehmke: So we can conclude then that not only is documentation, feedback, empathy, not only those important skills, but we have a moral responsibility to think about them. Aisha Blake: Yes, absolutely. I think, it's imperative that we really, really develop those skills and try to be as intentional as we can be about the way we apply them. The things that we build have an impact, a huge impact. And we have the opportunity. We have the potential to really counteract this incredible systemic injustice. Some of us. I think that it starts with the way that we treat each other. If we can't do that properly, then how are we going to use this incredible power that we have for anyone's good. Rein Henrichs: One way in which this is true is, when you write documentation and you have to think about making it accessible or what sort of people you want to be able to understand it, you are necessarily making choices about who to include and who to exclude from your community. So for example, documentation that uses he pronouns instead of they, that documentation, the purpose of that documentation is to exclude certain people, regardless of whether that was the intent or not. Aisha Blake: Yes, absolutely. Whether you're talking about pronouns, whether we're talking about the accessibility of the website or application or whatever it is that you were even hosting that documentation on, are you building this site so that it is accessible to someone who uses a keyboard to navigate? Are you building it in such a way that someone with a certain range of cognitive disabilities is able to understand what you are writing? Are they able to operate the site? How are you truly thinking about everyone that needs to use what you are building? Coraline Ehmke: And that starts with the people we interact with every day. I love that. Aisha, it's been really wonderful talking to you over the past hour. I have learned a lot and I am also remembering how much I miss self-conference, and how much I was looking for the title of conf. Just for the sake of our listeners, I applied to perform at title of conf and I have not performed on stage since I was 24 years old. So that was kind of a big deal to me. And Aisha, I am such a big fan of your work and I cannot wait to participate in the intentional communities that you've been creating over your entire career. I've really enjoyed the participation that I've had so far, and I can't wait for where you're going in the future. So thank you so much for talking to us today. Aisha Blake: Thank you so much. OUTRO: Collaboration between different disciplines in your organization can be difficult, and finding clarity and alignment on both the right problem to solve and the right solution design is even more so. We each approach improvement from our own (limited) perspective, without taking into account the whole story. How is that effective? Ha! Paul Rayner's EventStorming Facilitation Virtual Workshop is a multi-day online event, it promotes collaboration between different disciplines in order to solve business problems in the most effective way. This virtual workshop with Paul consists of 4 sessions on Sep 28 through Oct 1 from 9am to Noon in Central time (CDT) each day. To register and get 20% off your ticket, visit virtualgenious.com/events. Use the code VGGTC. In this highly hands-on and interactive virtual workshop, you'll learn advanced EventStorming facilitation skills spanning from large scale business discovery to collaborative solution design at the team level. Also, Paul is great. That's my personal opinion. Once again to get 20% off your ticket, visit virtualgenious.com/events and use the code VGGTC. The end.