This is the full text of an Ignite talk as prepared for DevOpsDays Chicago 2016.
Good afternoon! I hope you all had a splendid lunch. Thank you so much for having me today. I’m Alison Stanton, Chief Problem Solver at Stanton Ventures. My pronouns are she/her/hers and I’m here to talk about ways DevOps could be more accessible. Notice I have a hashtag, #devopsaccess which I encourage you to use for tweets. I also encourage email-based talk feedback.
The perspective I come from is unique. Both of my parents were programmers. I’m a white, cis, pansexual woman. I’ve had access to computers since I was 3. I’ve been online since 1995. HTML was my gateway drug into programming. I make a living as a data consultant. Currently, my main languages are SQL, Python, and LookML.
I found the word “goat” in the DevOps Dictionary and fell in love because it is an affirmation that talking to people to make things work for everyone is indeed a great thing not something to be chastised for. It also nods to interdisciplinarity which was, believe it or not, my undergraduate major. It speaks about curiosity and initiative and reaching your goal. All of which are things I believe I am and desire to be and do.
To me DevOps was just the new word for system administrators. Given my experiences that means it’s closer to the hardware-level. It’s the land of duct tape and band-aids. It’s the land of older men off in a server room being the person no one wants to talk to because he’s gruff and always saying ‘no’, ‘that’s too hard’ or ‘that will take too long’. The thing is when all the system administrators you’ve ever dealt with in your formative years said no we can’t give you access, (slide break) the system is too fragile you start believing that all system architecture is about 30 seconds from falling over at any given time. Turns out, that’s not what DevOps is about. But it took outreach and knowledge of and interaction of a safe person on the other side of that word – DevOps – to get me to realize that. To get me to realize I might already qualify to be a part of that world.
What do I mean by accessibility? I really mean the ability to enter and stay in DevOps by people currently under-represented in DevOps. I personally, today, in this talk, do not mean accommodations for missing senses. When I say under-represented I mean those who are not white, cis, heterosexual, able-bodied men, and in some cases those that pass as such.
To me, the root issue is tribal knowledge. To learn devops you must already be a part of the tribe. The tribe entry procedure is a secret and you’re either standing still or you’re on the highway. The on ramps are almost non-existent. But once you’re in, you have the keys to the castle. When you realize the castle is the server architecture, quite literally you have the keys. Let’s face it, you’re less replaceable than a programmer.
Now, as I said, I make my living as a data consultant, so as a data person and without a survey or other source of data, I went to Amazon.com to get a quantitative measure. These are the numbers of books in Amazon’s search results for these technical keywords, the year Wikipedia says that keyword came into usage, and the rate at which books for that keyword are published. As you can see, by orders of magnitude devops has fewer books. AKA fewer doors and fewer on ramps.
Therefore my main point to you today is that the root solution for accessibility in DevOps is to start being teachers. Share the wealth of knowledge. Give lessons. Answer questions. Mentor. Draw diagrams. There are multiple ways to contribute.
The principles of teaching that I would personally encourage starting with begin at: universality. Expand your audience. How could someone learn devops from a local library computer? You laugh, but there are legitimately people in the United States teaching JavaScript on paper right now because their students don’t have access to computers at home. Be multi-modal. People learn in different ways. People are in different circles of friends and meetups. Writing can include blog entries, books, and tweets. Speaking can include conferences, meetups, and small talk. Code can include github and open source software.
Approachability of people who do devops work is also key. Honestly, I think Devops has a perception problem as being folks with unattainable expertise. Perception issues are hard to combat but you have to play the short term and the long term game at the same time. So be welcoming. Be nice. And not just in words. Deeds count more.
I’m going to coin two phrases here today. The first is “use case learning“. To me, Use case learning embodies the concept of teaching with a focus on reaching a deliverable. It doesn’t see setup as the thing to learn. It realizes that setup is the first step in getting to some place productive. Instead of how do I fix this nginx port forwarding, it’s ‘how do I go from one server to a load-balanced architecture’.
Second, I want to introduce you to the concept of ‘full examples‘. When you give full examples you make up for unintended gaps in your explanations. You spell things out, step-by-step. By giving more context to the learner they are more likely to be able to recover from your bad assumptions about what they do and do not know. In that way a full example is more accessible to more individuals.
You know how on StackOverflow the top answer will be “go to the log file.” Do you know how many various log files are there on a linux box? Everytime I see that line I’m like: “which one? What directory is that in?” I don’t know! That wasn’t something they taught me in high school. It’s not implicit knowledge conveyed in the word “log” and I’m not stupid for not knowing it, I’m just a student in a different place of my learning journey then the speaker or writer is.
So my recommendation on how to make DevOps more accessible is for all of you to turn into teachers. Be the best teachers, because there is a lot of ground to make up for. I would challenge you to try to explain 1 thing a week. Here are some examples. They span mediums and audiences. And as you do these things think like a marketer. If you have the best content in the world but there’s only 1 copy and it’s not online and findable then you might as well not have made it cause no one is gonna be able to use it.
Ideas like giving credentials are, I would hazard to bet, scary concepts at first glance. It’s okay to start with read replicas. It’s okay to start by putting training wheels on it. It’s okay if you can only explain one thing a month not one thing a week. My point is that this is not a one and done item, it needs to be an ongoing effort to be the best teacher you can be.
You’ll notice I continue to be multi-modal in my suggestions. Because just as all learners learn best in different ways, so too do all teachers have their best mediums. The important part is that you aren’t insular. Don’t reinforce the DevOps echo chamber – let the sound carry to other portions of the tech world. Because the sound that can do this work is individual voices, most especially yours.
And honestly, stop with the excuses about why under-represented people can’t have access to systems. Especially the excuse that is silence. Do you have any idea how hard it is to learn a technology without access to said technology? It’s almost impossible. So don’t make excuses. Not because I’m telling you to stop but because teaching and mentoring can improve your reputation, give you a wider pool of talent to hire from, and a broader pool of people means you can move onto the harder, more challenging and therefore more fun problems to solve.
Here’s what I wrote in a LinkedIn post early this year: If they were really worried we would break something, they would teach us how not to break it. If they don’t have time to teach us they would tell us what certification to earn, what to read, or what examples to go build to make us qualified. If the system is so shaky and sensitive that giving someone else access is too risky they they are just admitting how horrible of an engineer they are. If the data is so highly sensitive then why are they storing it in the first place, why do they have access to it, and what is the qualifying, objective criteria to be given access to it?
Hopefully in this 5 minutes I have taught well. Thank you again for having me at DevOps Days Chicago 2016. Remember feedback is love. Go forth and teach! I look forward to hearing about your successes and your failures throughout the year.