Today’s episode is a field recording all the way from Florence, Italy where our very own Dave Anderson interviewed Mikey Ariel about her presentation at PyCon Italia. Mikey presented a keynote titled “Can We Make The Lightbulb Want to Change?” and Dave gets the low down from her about what this means in the context of documentation and the transfer of knowledge. During the episode they chat about Mikey’s background before diving into the work the Mikey and her organization, Write the Docs is concerned with. Mikey emphasizes the need for empathy and communication in this realm and believes strongly in the sometimes uncomfortable exercises of bridging the gap between kinds of expertise. They also chat about the philosophy that underlies this work, around human resources over tools and what really brings about the facilitation of changes most effectively. For all this and more be sure to tune in!
Key Points From This Episode:
Transcript for Episode 77. Make The Lightbulb Want To Change with Mikey Ariel - Pycon Italia Part 1
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsea, Manhattan. I’m your host, Michael Nunez. Our co-host today.
[0:00:09.8] DA: Dave Anderson.
[0:00:10.6] MN: Today, we got something a little special, we got an interview for you. A couple of months ago or weeks, I would say months. A couple of months ago, Dave, our very own Dave Anderson went out to Florence, Italy for PyCon Italia.
[0:00:27.5] DA: Yeah, a little than episode number 52 or something like that.
[0:00:31.9] MN: Yeah, you little rough run here at the podcast and sharpened it up and it’s amazing.
[0:00:35.8] DA: Ton about GraphQL.
[0:00:37.5] MN: Yeah, GraphQL, just a wave.
[0:00:39.3] DA: Yeah, finally looks into it in all the videos are out and I remembered they had these interviews that we never released.
[0:00:46.9] MN: Yeah.
[0:00:46.6] DA: Dang.
[0:00:47.9] MN: Yeah, no, I mean, this is a pretty good content that we got in store for you ladies and gentlemen.
Dave, before we start, I want to ask you, what was entertaining about PyCon Italia?
[0:00:58.4] DA: PyCon Italia is great. I love how there’s just all these different Python community throughout the entire world. I went to the PyCon in Cleveland, Ohio in the US in May and it was interesting, the contrast between them is like, PyCon US is huge and extravagant like all the speakers are great and wonderful, you know, core contributors and founders of this library and whatever.
There’s diversities, there’s a lot of other people too at PyCon US. But, PyCon Italia was a lot of fun because it was just like such a good local community. It was very - it’s very easy to talk to people, was more relaxed, you know, you could go up to anybody and just hang out.
[0:01:49.7] MN: Nice, that’s awesome. We have an interview with a person by the name of Mikey Ariel, she had a talk called, “Can We Make The Lightbulb Want to Change?”
[0:02:02.1] DA: Yeah, I thought it was a really great talk, it was one of the first talks that was given at PyCon Italia, it was the second keynote on the first day. It kind of had this really nice Esther Derby kind of flare, like six rules for change where you know, you're in a situation and you want to like, understand how you can make things better through understanding the people around you and not being a jerk about things.
[0:02:31.0] MN: Awesome. I think before we play the clip, I just want everyone to like close their eyes and meditate because this sounds like Dave is at like a coffee shop and it sounds amazing. We hope that you enjoy the transformation from being in New York to being in Florence, Italy.
[0:02:47.8] DA: Here we go, nonstop,
[0:02:49.0] MN: Let’s dive right into it.
[0:02:51.2] DA: Hello and welcome to the Rabbit Hole, the Definitive developer’s podcast, we’re coming at you live from the field in Florence Italy at PyCon Italia. It’s beautiful out here, I left William and Mike behind in dreary and drab New York. I have here with me, Mikey Ariel, who just delivered a keynote speech here.
[0:03:14.5] MA: Ever.
[0:03:14.6] DA: Yeah, congratulations.
[0:03:15.3] MA: Thank you.
[0:03:18.0] DA: Why don’t you tell people a little bit about yourself?
[0:03:20.5] MA: Great. Like you said, my name, Mikey and I am a technical writer for Open Stack platform at Red Hat. I was born in Israel, I grew up in California and now I live in Czech Republic working remotely. I’m also on the core team for Write the Docs, a global core team, we organized two main conferences, we have a bunch of meetups, we’re a documentation focused community that was built on the shoulders of Python and Django communities. We have a lot of open source philosophy that we implement and we’re very collaborative and it’s a really happy place to be in.
[0:03:51.8] DA: Cool, yeah. Open source means more documentation.
[0:03:54.2] MA: Yes. We’re here to help.
[0:03:56.9] DA: Please do.
[0:03:57.8] MA: Yes.
[0:03:59.2] DA: Yeah, your talk that you gave yesterday morning was on kind of like a framework for change, right? What was it called again?
[0:04:08.6] MA: It was, “Can We Make The Lightbulb Want to Change?” Was the question that I presented.
[0:04:14.9] DA: I love that. That’s like my life, basically. How do I get this to happen with the least amount of effort. I don’t want to like get up there and like get on a stool and grab the lightbulb and like twist it out of the socket, you just want it to like decide to do it’s own thing, right?
[0:04:30.7] MA: Right. I mean, assuming that the lightbulb is a conscious being that has some kind of choice.
[0:04:36.6] DA: It’s a smart lightbulb.
[0:04:37.8] MA: Yes, it’s a very smart light bulb. But the point is that you actually don’t want to treat the lightbulb as a lightbulb, if you want it to change. You know, you have to – you have to take it out of context, you know? The question was kind of a kickstarter for the philosophical question of can we – how can we influence change?
How can we induce change and manage it in a healthy way with ourselves and groups and other people?
[0:05:05.6] DA: Yeah. Being like software developers, like change is something that we’re always dealing with like –
[0:05:11.5] MA: You don’t always want to.
[0:05:12.1] DA: There’s always a new platform, there’s always a new technology, especially if you’re doing like java script exchanging a mile a minute, dev ops, I’m consistently blown away by all the things that are happening and new shiny things. You have to decide what change is important and what change is maybe not important. And how do you navigate that, those worlds.
[0:05:32.7] MA: Absolutely and as a writer and I’ve also done ScrumMaster work in the past so I’ve worked in agile teams and I’ve spent many years working with software developers, with QA engineers with support engineers with customer relationship managers within the last almost five years I’ve worked in open source which meant that I was working with community contributors. I am a community contributor myself.
You know, you work with the people with a lot of different levels of engagement and different levels of expertise in their field which somehow sometimes correlates to how resistant they are to change as well. You know, especially people who have deep knowledge of a certain field or you want to encourage new perspectives, new contributors.
There’s a lot of shifting perspectives and a lot of shifting engagement that you have to deal with if you want to manage relationships and manage the evolution of whatever it is you’re working on.
[0:06:36.6] DA: Yeah, I guess the challenge of like managing that kind of expectations and people in that context of like an open source project were like people are heavily invested in the outcome but like it’s a very loosely couple team compared to like people who are sitting in the same room and like convincing all of those people in the same room to get on the same page or something is its own challenge but they’re in the same room.
You have kind of some other bonds that you may have and like you know, someone who is like halfway across the world, convincing them to adopt a new way to do something like have its own pair of challenges.
[0:07:16.0] MA: Of course. Having remote or distributed projects is a challenge because you want to communicate something, anything really, all the communication needs to be more broadly understood by different cultures, people in different countries, you know, sometimes people in different languages, are there – is there a native language but also, there is another consideration about the open source projects, especially people who are working on a volunteer basis, they don’t work on it because it’s necessarily their job, they work on it because they really love it, because they want to. There’s a much bigger emotional attachments sometimes than when you have a more traditional project or a team.
You know, I’ve worked in proprietary software houses, I’ve worked in open source as a job and I’ve also done volunteer contributions so you kind of see a different ways to engage people on change because you can’t assume certain things and give that people will automatically continue to work on something.
You can’t assume engagement.
[0:08:22.5] DA: Right, yeah, I guess like with a job where you’re paid and like you're there like, there’s that itself but you don’t have with an open source project. It’s so much lower cost to just walk away.
[0:08:34.0] MA: Exactly. On the other hand, if you're in it and if you're contributing to the project, especially if let’s say, for example, you’re one of the founders or you’re one of the leaders of the project then you’re much more likely - you know, the term benevolent dictator for life, the BBDFL concept was invented at open source.
[0:08:55.4] DA: Our fearless leader.
[0:08:56.1] MA: Yes.
[0:08:56.6] DA: We know.
[0:08:57.5] MA: Exactly. I mean, this is not just for the Python community, I mean, I’ve worked on open source project before who shall remain nameless to protect the innocent, where I’ve tried to collaborate on a certain change for example, related to their documentation to try and let’s say, migrate them from one markup language to another and we were basically shot down buy the founder of the project to refuse to accept any sort of different idea to his project.
You know, there’s only so much you can do, right?
[0:09:29.2] DA: It is a challenge. For me, when I see a project that’s like that, that has like a single person who is like on all the issues, responding to all the things. It feels like almost invasive to try to contribute or change something or adjust to something because it’s like, a product of their vision and it’s like, it hasn’t been built from the ground up with collaboration maybe, in mind.
[0:09:55.4] MA: Yes, this is something that for example, at Write the Docs, we try to do and I’ll right the ducks was built, was created by Eric Holscher and Eric Redmond and Joy Howard who were involved with Read the Docs which is a hosting service for Python documentation.
[0:10:09.6] DA: Awesome. Yeah.
[0:10:12.7] MA: Thanks Eric. He’s a good friend of mine but one of the things that when he started write the ducks and it kind of evolved as a community beyond one or two people would do and then I joined on and then Samuel Write joined and now we have Kelly O’Brien as well so there’s four people on the global core team and what Eric keeps saying is that, I don’t want to have to be here for this thing to continue to live.
I want to be replaceable.
[0:10:36.4] DA: Yes.
[0:10:37.0] MA: That’s like being irreplaceable parent or replicable teacher. You know, if they can’t replace you, they can’t promote you and you can’t really do anything else and then you end up getting caught up in the responsibility loop thing, this infinite thing and you don’t want to get caught up in it.
Some people prioritize a replicable or a portable community model or project that with the intention of letting the project live on its own without specific people being tied into it. In the documentation field, this is something that I’ve seen more prevalent than in the software development because documentation is a way to educate people on a certain software tool, right? Or about a certain product or a certain -
It’s about communication, it’s about delivering knowledge, it’s about sharing knowledge, you know? It’s something like, I work with a lot of software developers. My job is to extract information from software developers, who have a deep knowledge about a certain tool or a product and to take that and put a lot of context throughout it so that we can explain how this works to someone who didn’t make it.
[0:11:49.1] DA: Right, so it’s digestible and all that good stuff.
[0:11:51.9] MA: Right. I deal with a lot of people who make assumptions that people should know this already. No, no it is in your heads. You know I have to remind a lot of the engineers that all the background knowledge that you have people won’t have. So you’ve got to give me brain dump.
[0:12:10.2] DA: Yeah, I guess that is like a big focus on your talk was on empathy and that reminded me also like Esther Derby and her rules for change and how empathy is really super important in software development now more than ever maybe since it is so open and there’s so many people they come in together to do these awesome projects.
[0:12:32.7] MA: Exactly, I mean if you assume that people learn things in the same way that you do, if you assume people have the same background that you do, you are going to run into a lot of walls. Because we are not – we don’t always deal with homogenous groups and especially in open source where anybody can come in and contribute. You have to be able to step out of your own sort of pre-filters and being able to see things from a different perspective while you communicate.
Right when you interact really with anybody on an open source project. You know working in an open organization is built on top of – it grew out of open source communities. So a lot of the things that we do are still based on those principles which makes it a really pretty cool place to work. So we are encouraged to experiment, we are encouraged to run pilots and then socialize them to people. If you can sell your idea to your peers and your business units or whatever, we will adopt it and we will be happy to do it.
[0:13:36.1] DA: Yeah.
[0:13:36.6] MA: So they encourage that and people are paid to –
[0:13:39.3] DA: Yeah that kind of bottom up stuff is pretty great.
[0:13:40.8] MA: Yeah and I mean it is not just that. People are paid to work on open source projects and then we consume them back and package them to our invest stories. That is the business model but everything is open source. So the thing about empathy is that –
[0:13:54.3] DA: Also being experts in the thing I guess like yes.
[0:13:57.6] MA: It is being experts but opening the knowledge, right? So you are letting anybody access your code base. We also have a lot of GitHub projects like the Open Decision Framework where you can take a slide deck and resources and it’s all public on GitHub so people can use them for their companies you know?
[0:14:16.1] DA: So you are saying about empathy in that definitely.
[0:14:18.5] MA: Yeah and then when its point is to treat your – you can’t assume that people will see things in the same way that you do. It is not just about you, we don’t work in a vacuum right? So if Esther Derby talks about like she did this, she had this phrase that really resonated with me where people don’t – are not resistant to change. They are resistant to coercion, you know? So you can’t just slam change into people and expect them to buy it. You know you have to actually sell it to someone, you know?
[0:14:47.9] DA: Right which means like doing a lot more work than you would expect to do what you have to do.
[0:14:51.7] MA: It is a lot more emotional work, than you will assume, you know?
[0:14:56.1] DA: Yeah, I like that about your talk too. You have framed that as like you know being respectful of the other person to sign and doing research.
[0:15:04.2] MA: Do your homework.
[0:15:05.5] DA: To make sure that you actually have the right solution to the problem that you haven’t made some assumption that is like you’re own bias like understanding yourself and the problem as well as the people that you are trying to communicate to.
[0:15:21.3] MA: Yes and of course I learned this the hard way working on projects where personally as a technical writer, I come with a certain set of expert experience, right? I have a certain expertise, documentation, documentation systems, documentation tooling and then for example I start working on a project with engineers who have an expertise in the code that they write, in the build systems you know and all sorts of system administration.
And then if I want to propose let’s say in migration project or initiative between two formats of documentation and how to construct or architect a documentation set, I need to make a proper proposal and give the engineers the right context because they don’t have the same expertise that I do. You know I have spent years –
[0:16:10.3] DA: And they are going to be collaborating with you on this and on this in a technical way. It’s not only like the product that comes out of it, the documentation that is nice for our users but to get a documentation that is easily maintainable by anybody you have to architect the system.
[0:16:26.6] MA: Exactly and so if I propose a certain working model or workflow that requires also the engineers to say - like if I propose that we make documentation or requirement for any kind of patches, right?
So when you submit a patch to the codebase that requires any kind of user change, user behavior change, you need to include some documentation draft. I need to sell this idea to the engineers and basically take them out of their comfort zone because a lot of engineers are maybe not experienced with, not as capable or engaged or disinterested in writing documentation and it is related, right?
Because if you really enjoy something you will probably invest more time in learning how to do it better and if you are focused on the different expertise, it’s not that I am saying all engineers are bad at writing documentation. They are not experienced because it hasn’t been their focus. I have no knowledge about how to write code for example, you know?
[0:17:31.8] DA: Right, I mean I think for me it is just like naming a single variable is a whole test like finding the right names.
[0:17:38.6] MA: Naming things is hard. It is so hard.
[0:17:42.0] DA: And that’s the documentation that I am most focused on as an engineer. Like I want to make that software speak for itself and be a document for any future people so I can be lazy, which is the virtue of programming.
[0:17:57.3] MA: Laziness is the mother of automation, okay? A functional lazy person -
[0:18:03.1] DA: The best way to write documentation is to not need it but if you need it –
[0:18:08.6] MA: To a certain point, yes? I mean documentation could also be a code vomit. It could be a doc strain right? We have a saying in the documentation world whereas self-documented code is code that you wrote recently, because in six months you are going to look at it and you’re not going to necessarily remember.
[0:18:28.1] DA: Yeah, I mean you are basically a different person at that point so -
[0:18:31.4] MA: Exactly. So this is one of the things that I try to encourage people with the empathy is to think it’s not - to diffuse a lot of anxiety that people have around the word documentation and what it might mean, you know? So there is a talk that I give called [inaudible] where I focus on open source projects and I show, I try to show that you can make small, incremental changes in how you view documentation. It doesn’t have to be a monolithic, thousand page book.
And you don’t have to completely change careers to do it just take five minutes and think about the name of the function that you want to do or maybe put in a small comment, things like that and this is also related to the change, right?
[0:19:17.5] DA: It’s getting like breadcrumbs for the person that is going after you.
[0:19:21.4] MA: Yes, that is just barely good enough minimum viable content that you can get -
[0:19:26.1] DA: Yeah, like don’t leave it as an Indiana Jones expedition that you have to do in order to get the knowledge again through archeological means.
[0:19:34.4] MA: Exactly because –
[0:19:35.7] DA: Which can be fun but -
[0:19:37.5] MA: It could be fun unless you are on a deadline or something is broken and you have to debug it and you’re going, “What have they done here?”
[0:19:45.4] DA: Oh yeah that’s not fun.
[0:19:46.2] MA: “Oh that was me, what have I done here you know? I hate this so much.”
[0:19:49.4] DA: Right, oh get blamed myself or I do like the tool get blame someone else also, I mean you know rewrite the Git history.
[0:19:58.4] MA: Exactly, so empathy is something that permeates everything and you can do – it is such a useful practice that so many people, myself included still struggle with, you know? And I was telling you before, it is never about the tools because ultimately we are humans working with other humans. So, I mean, I gave, in the talk I gave a bunch of life lessons or change management lessons whatever you want to call it and about half of them are based on the human aspect.
And half of them are based on the more logistical knowledge, do the work factual, do your homework, laid by example run a DOC on things, actual respect for the actual content. But most of the benefit of empathetic change management is that you are going to get a more genuine engagement from people. If you are going to be able to present your idea in an empathetic way without assuming certain background or context and showing respect for the people that you are trying to sell your idea to you are going to get a more genuine buy in and people are going to do a better job, you know they are going to join your efforts, yes.
[0:21:20.4] DA: And it is less work for you in the end.
[0:21:22.1] MA: Yep, exactly.
[0:21:23.3] DA: Which I like, yeah. I like that a lot. Cool, yeah I hope that people are able to check out the talks online at some point.
[0:21:30.1] MA: So I have the slides are on Speaker Deck and I guess you can link it somewhere and the video should be posted I guess at some point. I mean the conference is still going on and they did some live stream but I guess they have to cut the videos or something.
[0:21:41.2] DA: Right, sure. Yeah they are going to do a good job on that.
[0:21:43.6] MA: Yes, I will also write a blog post about this conference and I usually sporadically blog on my traveling documentarian blog is called is called docsideofthemoon.com and –
[0:21:55.8] DA: Excellent pun.
[0:21:57.9] MA: Yes, thank you. So I usually do a recap blog of every conference I attend and I give them a little summary of the talk that I gave so I will put some links in there. I can share it with you.
[0:22:07.0] DA: So we’ll have to link that in the notes. Awesome, yeah so do you have any wrap up thoughts? What’s the big take away? Empathy? Software is people too?
[0:22:16.7] MA: Yes, yes. It is not just about the tools. I mean change starts from within, be the change and hope for the best and prepare for the worst.
[0:22:25.2] DA: All right, awesome. Cool.
[0:22:26.6] MA: So thank you so much for having me.
[0:22:28.4] DA: Yeah, it was great. Thank you for participating in our field recording here in lovely Florence, Italy.
[0:22:34.6] MA: Yes, it was a lovely recording in the wild and I hope it works out.
[0:22:38.2] DA: All right, let’s get back to it.
[0:22:39.7] MA: Thank you.
[0:22:40.0] DA: Okay, all right.
[0:22:40.7] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going.
Like what you hear? Give us a five star review and help developers like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast.
On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
Links and Resources:
