Whether you have a disability or not, whether it's visible or invisible, accessibility affects you.  Parham talks about the benefits to everyone of clean code, explict error messages, and using multiple modes of communication. He talks about his experience getting into tech, the unique challenges, and joys, of doing so without the benefit of physical sight, and gives some tips for how every one of us can improve the quality of life of everyone else who uses the systems we build.

Resources
Microsoft Accessibility resources
Apple's developer resources
Book: Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin

Guest
Parham Doustdar
Twitter: @PD90
Web site: https://parhamdoustdar.com/

Transcript

Jonathan: Ladies and gentlemen, the Tiny DevOps Guy.

[music]

Jonathan: Hello, everybody. Welcome to another episode of the Tiny DevOps podcast. I'm your host, Jonathan Hall. On this show, we like to talk about dev and ops and, all related things for small companies. That's the opposite of fame. We're not deploying 10,000 node, Kubernetes clusters. We're focused on 5 or 10 or 20 engineers in our engineering team. That's the focus of our show. Today I'm excited to have an old-- Should I say old friend? We've been friends for several years.

Parham: Yes.

Jonathan: We worked together briefly. My friend, Parham Doustdar here. Did I say that right? I probably didn't.

Parham: You said that perfectly right.

Jonathan: Perfect. Wonderful. I'm excited to have Parham here. He is going to hopefully help enlighten me and the audience on how we can do, how do I say, how we could be a little bit more accessible in the work we do in DevOps. That probably doesn't make sense yet, but I'll let Parham give an introduction here about himself and his unique perspective on the types of work that we do, and how we might be able to improve our work through his perspective. Welcome, Parham. Tell us a little bit about yourself.

Parham: Hi, thanks a lot. My name is Parham. I met Jonathan in booking, where I think it was five years ago. Since then, I basically moved on to Core-Infra where I was creating deployment software to help people deploy their software to multiple Kubernetes clusters. We wrote an open source software called Chipper. That was how I was personally involved in DevOps.

I was born completely blind, so I have been programming with something called a screen reader that reads the screen to me. That was basically how I was involved in my DevOps days. Now I'm the engineering manager of accessibility at booking, which is a very new position. I've been here for like four or five months, so very new to the role, but still very in touch with the DevOps world and what's been happening there.

Jonathan: That's great. As Parham mentioned, he's totally blind, which puts him in a unique position, I think, to talk about coding or engineering in a way that many of us often don't think about. I heard you gave a presentation maybe three years ago at a Go meetup in Amsterdam. You talked about coding and Go, and the reasons you like Go because of its simplicity, its syntactic simplicity, and it makes it easier to understand certain things. You also talked a lot about coding style. I wonder if you might talk a little bit about the coding style. Actually, before we do that, let's discuss why accessibility is important for everybody, not just the minority of people who don't have vision, because you talked about that in your presentation. I'd love to hear your thoughts on that.

Parham: Yes. There is a well-known fact-- When I was doing my talk, I wasn't actually in accessibility, so I didn't really have access to data about this. As I've gone deeper and deeper into accessibility, there is clear data around the fact that when you are creating software, and whether this is digital assets or it's just writing code, and you have a wider audience in mind, what ends up happening is that you lift up the quality of that software or the source code, or whatever it is you were doing for everyone as well.

That was what I was talking about in that Go meetup, which is ideally the way I think about my code, is that the least experienced person in the team should be able to understand it with no problems.

If we get there then we are a very productive team. What I've seen people do sometimes, and I was guilty of doing this five, six years ago as well, is that you go read a book about whatever algorithm of traversing a tree on Bash. Then you're like, "That's cool I can totally apply that to this problem that I'm solving." There's a better way or an easier way or a more easy to read way that's not horribly, I guess non-performing or isn't horribly bad in performance, but you're like, "I learned this new thing. I really want to apply it at work."

What ends up happening is we end up increasing the complexity of the code, and which is very important in a DevOps situation because what ends up happening, someone is leaving the team, the new person comes in and tries to maintain the code, and they just don't understand it because they don't know the book you just read or they don't know the algorithm you just discovered. If you leave your code in that state, what ends up happening, people, I guess, see this problem in different ways and handle in different ways. Whatever that reaction ends up being, I guess we can all agree that that's not ideal.

Ideally if you're leaving a team, you should have made yourself absolute way before leaving in the sense that they shouldn't really feel you missing by much. That's basically the case I was making. I think I still do make that case to engineers when it comes to code quality and code readability, that the focus on clarity of the code is basically the point I'm making here. I'm not saying that means to the exclusion of everything else. This doesn't mean if you can use hashes for everything because it's more, readable make a 10-gigabyte cache of stuff, and don't do a proper way. What I mean is if there is a way that's clearer, easier to read, and easier to maintain that isn't very low in terms of performance, I would personally suggest you to lean more towards the one that's more readable.

Jonathan: Broadly speaking, the more readable the code, is the easier it is for you to understand, exactly the same way that it's easier for everybody else to understand.

Parham: Yes, that's basically it.

Jonathan: That's not like rocket science there. Basically, communicate clearly with your code and probably everything else you do. Is that fair?

Parham: Yes. That's the thing, I guess this is also in literary. If you look at Shakespeare, right, we have Shakespearean work where he is like, let me show you how awesome I am with the language, which doesn't necessarily make sense to the everyday reader like me. I'm like, "What the hell is this guy saying?" I think the work that he's done, that has survived is the more work aimed toward the common people, which is easier to understand and reason about. That's basically what I'm inviting people to do, which is code is a form of communication with the computer, but it's also a way of communicating with the poor soul who's going to maintain this after you're gone, so do that task in a very careful and responsible way.

Jonathan: Would you mind sharing your story a little bit about how you got into computers and computer programming?

Parham: Yes, sure. I basically started when I was 14. I discovered a form of a genre of games called an audio game, which is basically a game where you put on headphones and everything is done in a way that you're only interacting with the game world through audio. There is no videos at all. I played a couple of these and I was like, "Fine, I want to do these more. I want to create them." I started learning Visual Basic 6, which was a little bit outdated. This was 2004/5. That was basically the book I could find that was an audio tape that I could actually learn from.

Then I started creating audio games. Then I went into multi-user Dungeons, which is a text-based role playing game that you play online. There's a whole ton of them. I started programming those. That was my introduction to object oriented-programming because everything was an object, and you had to basically program verbs for them like "throw" and "pick up", and "attack", and stuff. Then I went on to learn PHP.

I went on to university where I didn't really have any books or any kind of material to study from. I basically just had to learn in the classroom or fail. That was my only two options. As soon as I found a job, I basically just quit because I was like, "This is too much work for little return." That's when I basically got my associate's degree and got out of university, and started working on web applications with PHP, and specifically the backend, because if I design the frontend, it's going to be horrible.

Jonathan: [laughs] Fair enough. What have been the challenges? Of course, our worlds are very different in certain ways, obviously. I'm sure you have the same difficulty imagining my world as I do imagining yours. What is it like going to university and finding a job without being able to see? I have two parts of that question. First, from your perspective, what's the day-to-day like? How do you read and write code, and stuff like that? Then second, interacting with other people who aren't used to dealing with blind people. How does that work?

Parham: On the first question, it's been a discovery journey for me because things have been getting better and worse in terms of accessibility of coding software. Right now, I'm using Emacspeak, which is a plugin that pulls out information from Emacs APIs like the color of text, any highlights and stuff like that, and turns that into speech, which is really cool because you can actually program it to do stuff that isn't accessible. Usually, a screen reader, what it does is it just pulls out information from software through the API that the developer puts in.

If they don't implement an interface, you just don't have access to the data anymore. Then, that's where a screen reader might just say "button" or "checkbox", and you're like, "What am I ticking if I tick this box? What's going to happen?" With Emacs and Emacspeak, because everything's basically done in Lisp, so you can go view the source code and modify it, and make basically stuff accessible that isn't accessible. That's why Emacs has been my environment of choice for five years now. That's been basically how I do my coding.

For a long time, I was also doing my personal task management and stuff inside Emacs with something called Org mode, which is a way to write structured text, like markdown. You can fold text and you can expand it, and stuff like that. That was pretty useful. That was basically my environment for a long time. Now that I'm an engineering manager, my days are in Gmail and Google Docs, and stuff, and Google Calendar. That's the Tetris game that we play with the appointments.

Jonathan: I know that Tetris game all too well.

[laughter]

Parham: That's the first part of it. If you have any questions, I'll let you ask those before I move on to the second one.

Jonathan: Are you still coding now that you're managing, or is that in the past now?

Parham: I don't really code anymore, no. I think I also, I guess, got burned out with coding. Is that the right preposition?

Jonathan: Yes.

Parham: I think the reason for that was I was basically just coding for my hobbies and as a hobby and as my daily job for 10 years for my professional life, and six years as a hobby, purely. I think I got word of development, and I got really drawn to people. I was very drawn to people, but I always saw that in a role as a developer. Then, I got to the point where that role of interacting with people, having a one-on-one relationship, getting to know people at a deeper level, and stuff like that at work became more important.

I used to do that in my personal life, but I ended up getting to a point where I was really looking forward to doing that at work as well. That was basically how I got into being a team leader three years ago, and then stopping to code a year ago where my reports exceeded six and seven people. I couldn't manage people properly, let alone manage people properly and code. I like that. I was like, "I'm going to just stick with this," because I feel like I can also deliver more value in a more sustainable way working with people right now.

Jonathan: When I was managing, I didn't have time or much interest in coding either. I was focused on people, and I really enjoyed that. I enjoy both, but I guess there's a time for each.

Parham: Yes. How did you split that between the two? Did you do that at home? Did you do coding at home? Did you--

Jonathan: I did some coding at home on an open-source project that I had written. I still maintained it. It's a shared library that I maintain.

Parham: Coding became more of a hobby for you.

Jonathan: It did. Now I'm coding. To some extent again, I'm no longer in a management position.

Parham: At some point, you had a hobby, a child, you were in a marital relationship, and you were working at the same time?

Jonathan: Yes, definitely. To be clear, I'm still on a marital relationship. We didn't get divorced or anything like that.

[laughter]

Parham: Wow. Sometimes I'm like, "How do people actually schedule so many stuff into their day?" I just feel lazy right now. I'm going to just get out and leave.

Jonathan: [laughs] Onto the second question then. How do you find a job, and how do you go to university, and how do you do these things with people who aren't accustomed to working with blind people? What's that like?

Parham: I guess there is a more sweet part of it where you encounter people who are actually excited to know you, to get to know your world, and to let you into their world, so it's more of a mutual relationship. They're really good at replacing body language with verbal cues. Then, once in a while, I just meet people who are not good at one or many of these. I was in meetings in my team at some point where I would say, "Is everyone okay with this?" Then I would just get silence, and I'm like, "Guys, I can't read your body language. You need to help me out here."

I think that was basically one of the moments where people could take information away or add that at will more readily than you can maybe hide facial expressions and so on. It all depends on how self-aware people are, and how interested they are in making that relationship work. I guess, just like you, I encounter people who are interested to do that, and people who are not. When it comes to an interview, I guess that's the most high stakes in a short amount of time conversation where I basically try to present myself. Usually, in the past, if I got rejected, I would take that on as, "I'm horrible. Why am I not a good software developer, and stuff?"

This was five years ago when I was applying for companies to get out of Iran and come to Europe in general. What I ended up learning is that some of these companies, it's not just a matter of passing the interview at any cost. It's a matter of, do I really want to be working with these people? If this person's not letting me into their world and making a mutual relationship happen over a conversation that's an hour, should I even want to work with them over a period of time? I think one thing that I've discovered is I'm now a lot more picky on who I spend time with, especially now that it's COVID.

I can freely choose and be like, "Hey, Jonathan, are you free to have a virtual wine or, well I'm not into wine, tea, coffee, whatever?" It's a lot easier now to surround myself with people who I actually connect really well with. It's a lot harder when you have to go out there and going to do job interviews, or be a manager the way I was before where I didn't pick my team members. They were basically assigned to my team. Now, at work, there's a whole hiring interview and stuff like that, so I can test out is this support and I-- Am I and this-- Wait. Are I and this support going to have a working relationship that's going to be productive or not?

I guess a lot of this has been me growing and becoming more aware of what I find useful and not in a relationship. That's been basically the journey that I've been on to get to know what really is productive for me, and also to articulate it, because I think most of the time I was like, "That's tough. You shouldn't really say that. It's not really--" A lot of my journey has been to say that in a non-judgmental way but actually say it rather than hide it and forcing the relationship to work. This goes way beyond DevOps, but I hope--

Jonathan: It does and it doesn't. I always say that DevOps is really about people more than it is about computers. It's about culture and it's about cooperation.

Parham: Yes, especially DevOps, because you're basically at the intersection of other people and computers, right?

Jonathan: Exactly. A moment ago you said that over time, I might misquote you, but I think you said over time, accessibility has gotten both better and worse. Do you want to elaborate on that a little bit? What do you mean?

Parham: The problem in most situations is that people are not aware of people with disabilities or any sort of neurodiversity, who's in the workforce and is using their application, or is using their code. What's happening is that there are people who are very aware and they write proper code, and they write proper software, and there are people that are not. Because of the fact that we don't really have proper policies in place and there is no easy way to test software to see how accessible it is, the state of accessibility tools and accessibility software, and operating systems and stuff like that fluctuates a lot.

When you are writing a code to either now deploy your container on Kubernetes and you're looking at the logs, you're able to skim with your eyes and just quickly take in a whole lot by looking for, I don't know, red lines versus green lines. When maybe you're heuristically saying, "If the number of red lines exceeds some subjective feeling, then I see that things are wrong, and I need to get more into detail and read the actual line." Because of the fact that I cannot do that, then I rely on, for example, software that looks at the logs and uses AI to pull out information that's useful for me.

If that software is accessible, great, my life is great. The fact that it's great today, it doesn't mean that in one month it's still going to be great. That's what I experience overall in my career, is that something that's working today in terms of accessibility could be not working tomorrow. This goes from very crucial stuff like Gmail and basically whatever we're using to manage logs, for example, when I'm deploying, because take that away and I cannot deploy anymore.

I think one thing that's really cool too, and I think, Jonathan, you were a part of booking when this was going on, is that when we're told to create software in a limited amount of time, the quality of the code ends up decreasing, but the usefulness of it as well ends up decreasing. Then I remember that I and Jonathan, we used to have conversations about, "Hey, this is not working for me," and Jonathan would say, "Yes. it's not working for me either, and I can see." What was very evident for me when I joined Booking was, if something isn't working for me, there is a very high chance that it's not working for a lot of other people as well.

It's just that it's not just as annoying as me, so people can muddle through and make it work somehow. For me, that little difference is a lot of difference. Then basically, there was this whole conversation of how to make this better over time, which I hope all organizations partake, especially in smaller organizations, and people in these organizations that are listening to this podcast, because you have a lot more control over your environment. There is not 300 people contributing to an internal tool. It's four or five, or six people. That makes it a lot easier to make these choices early in your organization's lifecycle.

Jonathan: If you know, what percentage of people in IT have some sort of disability, whether it's vision or hearing, or you mentioned neurodiverse? Do you have any sense of that?

Parham: No, not really. I think what makes that tricky is that, first of all, with what they call invisible disabilities, the ones that are more around neurodiversity, people may choose not to disclose them. Also, they might not just be aware of them, especially with cases like autism where people are highly functioning, or like dyslexia or ADHD where people are on spectrums of these. I've actually had colleagues in the past year get some feeling that "Maybe I have ADHD. Maybe I have dyslexia. Maybe I have--" I'm talking about a copywriter, for example, that is like, "I think I have dyslexia or autism."

They go and do a test and it turns out, yes, they do. These people are above 30. What makes this number very hard to find and define is that first of all, people are not aware of it always. If they are, it's not easy for them to disclose, or maybe they don't want to do that because they have the liberty of doing that, whereas, for example, someone on a wheelchair or someone who's blind doesn't really have that liberty. There is that fear of how are people going to react or how are they going to act differently after they figure out that I have this disability?

I think the very important cases that I, for example, fall on the more severe list of disabilities because my lack of sight is complete, but there are a lot of people on the spectrum of sight. I'm just talking about sight specifically, but that diversity exists everywhere. If you're, for example, just relying on colors to convey information, and I see that a lot in DevOps software, then people who have color blindness will be missing out a whole lot. There's a lot of people with color blindness. I just don't understand why we're doing that on DevOps because someone must have that problem and must raise it already. Why are we not speaking out about this stuff?

Jonathan: That's a really good point. My father is colorblind. The red-green, go together. Those are the two colors we use the most, right?

Parham: Yes, exactly.

Jonathan: We're just red and green. My father wouldn't be able to tell the difference.

Parham: DevOps is just red and green.

[laughter]

I don't know if that's accurate because I haven't seen it, but I imagine.

Jonathan: You were talking about logs earlier. I was just rebooting my Linux system earlier today, and it shows all these or green statuses. If there's a failure, it's red, and that's it. That's all you see is green for success and red for failure. There's no purple or pink or yellow or whatever.

Parham: Yes. I remember that when I joined your team, Jonathan, in the beginning, we had a tool for compiling all the assets into one bundle. I remember that I ran the code and then my shell prompt just came back. Then I was like, "Great, that's bundled and ready to go." Then the person working with me who was another backend developer was like, "No. If you go up like eight lines, there's a red line in there. I'm like, "Oh; how the heck am--" This returned an exit code of zero. How can you have a red line and returned an exit code of zero? I actually went eight lines up. I read the line but I couldn't necessarily tell that it was an error.

It didn't have the word "error", it didn't have any word that would say to someone who doesn't know the system that this is a problem. Basically, that was the last time I rolled out any code at Booking in the main booking.com website. I did that in our own core infrastructure software because we got to write the pipelines, and there were proper GitLab stuff. That was just the last time that I used any software like that. Imagine if I didn't like to work at Core-Infra, if I didn't want to go that route, or if I actually wanted to basically contribute to the areas like that where we were using software like this, I was basically unable to do my job.

I guess that's the point that I'm hoping people take away from this episode is, this is not just a nice to have your basic in making people unable to do their job if you're not doing this right. Maybe you're here about it because they raise it. Maybe you don't because they don't raise it. Either way, I'm hoping that the awareness that such a thing could actually happen encourages you and urges you to keep that in mind as you're writing code that spews out any output, or as you're writing code itself.

If you're looking at writing some source code and you're, for example, using colors, notations that are only visible to a certain set of people and stuff that to convey meaning, don't put asky art in your comment like. "Why?" I've read code where someone's looking-- Instead of telling me what each key of a hash does, they just manage to turn it into an illustration of, this is what this hash contains is. Just tell me in proper code. Why are you doing it? Sorry, just went off on a rant.

Jonathan: No, that's great. I think that's where I want to take this episode, by the way, is what could we do as coders and as engineers? What steps can we take? What change of mind do we need to improve in these areas? You've mentioned a few things of course at the beginning, more readable code, don't rely on a single indicator, combine a color with wording or something else. What else can we do? How can I as an engineer accommodate more people in the work that I do?

Parham: I think you basically wrapped up and summarized what my two main points are. I think just the fact that, and maybe validate me on this, Jonathan, because you've fallen in this category of people. I feel like just the fact that you're aware that such a group of people, exist or like a diverse set of people are going to read your code or use your software, just having that awareness already brings up things in your head in critical moments that you maybe didn't even think about before. I don't know if that's actually been true for you.

Jonathan: I would say so, although I know I have a lot of room for improvement. Just historically, I tend to make a mistake until I realize it's a mistake, and then I go back. For example, just what you described to me now about coloring your log lines. I had never really thought about that in that context, I will color my log lines but I also put the word "error" or "warning" there. I do that more for the fact that I want to be able to grab that line with the tool when the colors aren't there.

Parham: Exactly.

Jonathan: Which I guess is related. The tool is also color blind. I hadn't thought of it in the sense of my dad might read these logs, or Parhan might come along and need to be able to deploy this without visual cues. Now that you've made me aware, definitely I will be thinking about this next time I'm writing a log line or anything includes colors.

Parham: I think the colors are certainly important there to be there. Maybe one can make the colors customizable for people who are color blind or something like that, but certainly for people who can use it. Totally, let's put it there. Let everyone use that as well. Just don't take that grabable string away so that you can use that in your tool, I can use that in my grab tool, everyone can use that in grab to pull out all the ears.

I think that's actually a great point that using Linux tools that are colorblind is basically a really great way to say, is the information that I'm conveying here all readable for someone who might not be able to see the colors in for any reason or not? If you can read it with ork or printf or whatever, then you're all fine. If you can only pull that information out with coloring, then it's going to be harder for everyone me, included.

Jonathan: Yes. My first computer when I was eight years old was a Commodore 64. We had it hooked up to a black and white television set. I was effectively color blind for the first three or four years of my computing, just for the fact that I had a black and white monitor. I remember being frustrated, like, "Why don't people make games that work with higher contrast?" I'm digressing a little bit.

Parham: Yes. Maybe we should give everyone a black and white game.

[laughter]

Would that be Matrix or would that be blue? I've heard that blue.

Jonathan: Matrix is the movie, you mean, right?

Parham: Yes.

Jonathan: I think they were green for a lot of their stuff.

Parham: Green, okay. We should just give them green and red screens.

[laughter]

Jonathan: Great.

Parham: I'm not sure if it helps my case if you give people just green and red because I think that covers like 99% of use cases. I think as long as it's not-- I think the best case is to just give everyone the same color, like white. Just white. Not black and white, just white.

Jonathan: Just white.

Parham: Yes. Because then that's forces everyone to take color out of the equation. I'm hoping that part of your listener base is also working on software that is making other people's jobs easier by helping them roll out codes, see how their code is performing, how things are going production and blah, blah. Usually, that set of software is very, very inaccessible to me because-- I've been in contact with companies about that, and they're like-- I created an issue, and I swear, the comment that I got is, "This is a visualization tool. We're not going to change it. Go find something else."

I think that was Grafana. If you're working in one of these companies, take that into account because finding a job as someone with any disability, and you're basically someone with a bias that you can actually do the job, it's already hard enough. Don't make it harder by making your tool inaccessible so that these people have to jump through hoops to do things that people who are not having any disabilities can do all of that stuff for free with very little effort.

Jonathan: Do you know any resources that we can share with the audience if they're interested in learning more about accessibility considerations in the software they're designing or the engineering they're doing, blogs, podcasts, books, anything like that?

Parham: Unfortunately, we have very few people who have gone to be like very successful engineers and write books and stuff to others about how to write accessible code. When it comes to producing accessible software, I would say look at the accessibility guidelines for your platform. That's Windows and Mac. Microsoft has this really great developer website for accessibility. Mac, if you go to developer.apple.com and search for accessibility, you'll find a whole lot of information about native apps in general. If you're looking at code, what I found is that as long as you're writing high-quality code in terms of taking the readability into account, and I think for me the uncle Bob's book of-- what was that called?

Jonathan: Clean Code. He has several Clean Code, Clean Architecture.

Parham: I think the Clean Code specifically was about readability. Maybe you don't agree with the solid principles or object-oriented programming, and you want everything to be functions and all of that, but the the core message of the book, and I think you'll find that out if you check out the book, is that the core message is still applicable to basically any language that you're using. It's just that it's up to you to figure out how that actually shows up in your language. I feel there's a lot to learn from a book like that and apply that in your everyday life and job.

Jonathan: I agree. I like the book too. I'm not an object-oriented advocate per se, but the book is still, like you said the core concept of the book is still valid in just about any language.

Parham: I remember it was actually beginning with a code. He just copy-pasted some random code from some random open source software. Then he ended up refactoring it through the book. Just by comparing the two versions in the beginning and the end, you'll get the point. There is so much difference in clear function names, especially in functional languages where, for example, if you start getting setting a function anger, most of the time, at least for me I realize, wow this function is doing three things because the name of my function is get table and render to table, or something.

Then I'm like, "It's getting it. It's laying it out in a format and it's rendering it. Wow, that's three different things." Just by clear function names, that has a domino effect into, "Now I need to split this into three different functions. Now my functions are shorter. Now that means it's easier to reason about." I'm sure all the functional programming people would agree, smaller functions, easier to test, easier to make sure that there are no side effects and all of that stuff.

Jonathan: Parham, thank you so much for coming on. People want to get in touch with you. Are you on social media or do you want to share your email address, or anything like that?

Parham: I am on Twitter. I'm not active. I just use it for responding to people's direct messages. My Twitter is PD90. That's pretty easy. My website is my full name dot com, so that's parhamdoustdar.com. You can get in touch with me through there. That's basically my home on the internet. I'm also working on getting together a podcast which will not be about DevOps sadly, but I'll just let Jonathan know you guys about that more.

Jonathan: All right. Go to your website to learn more about the a podcast when it comes out, I suppose.

Parham: Yes.

Jonathan: What will it be about, by the way?

Parham: I'm very much focused on learning at least one or two new things a week. These are things that you apply in your everyday life. This goes beyond any role or any job. What I found is that I'm very lazy to share that in a blog format because I have to write it, publish it, find some thumbnail for it, and so I thought that it's going to be much more fun and engaging for others and for me if I put that in audio form, where I can actually edit it in a way that what I'm seeing is what everyone else is seeing. Also I can bring in interesting people and have interesting conversations about what I'm learning, which is always something that I want to do, because I guess you know, Jonathan, that I just love conversations. I talk a lot though, but I'll have to cut.

Jonathan: That's all right. I look forward to hearing the podcast. I hope that the other listeners will visit your site and check it out too whenever it's live. Is there anything else you'd like to add before we sign off today?

Parham: I guess the only thing I wanted to say is I really thank all of your listeners for seeing the title of this episode, which I imagine is unusual to a whole lot of people, and still listening and getting all the way here. It really means a lot that you're considering people who might not be in your usual circle of what you consider as colleagues. Thanks a lot for being curious, for being open-minded, and for finding out ways to actually help those people. Thanks for being curious, and thanks for taking action.

Jonathan: Wonderful. Thanks again, Parham. Thanks for listening. I hope you join me again next time on the Tiny DevOps podcast

[music]

Jonathan: Find me online at jhall.io.

[music]

Jonathan: Theme music is performed by Riley Gaye.

[music]