The tech industry loves to talk about gatekeeping. We have a pretty extreme problem with it, as evidenced by the demographics of most engineering orgs and the fact that it’s a near-constant topic of conversation on Tech Twitter. When we talk about gatekeeping in the industry though, we’re usually talking about active gatekeeping — consciously taking actions that exclude a group of people simply for who they are, or raising the bar for entry so high for them that it’s effectively impossible for them to get in. For example, putting considerably more pressure on a woman you’re interviewing than you do for a man with equivalent skills and experience. This is pretty common, but I think there’s another type of gatekeeping, just as insidious and less often discussed.
Passive gatekeeping accomplishes the same thing: we keep someone out of a community, or make it much harder to get in, by requiring them to meet some bizarre standard. But instead of making an active choice, it happens unintentionally, whether it’s out of laziness, bad culture, habit, or ignorance. In my opinion, there are several ways we’re passively preventing junior engineers from finding their place, but I’m going to focus on two in this blog: jargon, and education.
The amount of jargon in the tech industry is absolutely bonkers, and we use it with wild abandon, rarely defining what we mean, frequently without considering that it might have another meaning (see: the many definitions and usages of “docker”). DevOps and cloud native are especially bad about this. Jargon has its place; for people who are on the same page, it makes communication more concise. For junior developers or newbies, it’s confusing and it makes understanding just what the hell we’re doing here far more difficult than it has to be.
“But Kat, they can just google it! We shouldn’t just hand everything to them!”
Why not? Because it wasn’t handed to you? We build tools and practices that make it so that we don’t have to deal with the pain points we feel when building software, so why is it acceptable (encouraged, even!) to keep it difficult to learn and communicate about these things? This is a barrier to entry that doesn’t need to exist. If you’re giving a tutorial or talking to a new teammate, the first time you use an acronym or a piece of jargon, just… define it. Take a few extra seconds and make sure that you’re on the same page, instead of making people go google it.
Until DevOps trade schools and bootcamps become a thing, or universities start teaching these technologies too, we have to take teaching this stuff into our own hands. Some people already have — there are a few great books out there, workshops, and a ton of content creators writing on sites like dev.to for products they don’t even own. I do this a lot, just because I remember how frustrating it was to learn all of this myself. We can’t solve the problem without help, though. A lot of it.
That help has to come from each of your companies, orgs, and teams. If you have the energy for it, mentor someone in your spare time. Make yourself available to answer questions, and make it clear that none of them are stupid. Pair program through a real-life demo application. Walk them through a tutorial. It’s ubiquitous to us, but not everyone knows what Ansible is. Proactively teach them the way they want to be taught, not the way you learned. Make it a junior on another team at your company, a new grad from the local college or bootcamp, some random person from Twitter, whatever.
I’m especially talking to you, seniors and team leads. If you let your junior teammates struggle longer than necessary, not only are you being a crappy teammate, you’re actively detrimental to your organization. You are wasting time, and DevOps is about reducing time wasted. As a senior, one of your responsibilities is to mentor junior teammates. That’s part of your job. You can’t allow things to continue as they are. We struggled to learn, but that’s not a reason to keep things this way. Suffering is not a rite of passage to DevOps excellence.
Both of these problems — rampant use of jargon and a lack of mentorship — are contributing to a culture in which newbies and juniors are made to fight harder than necessary to be involved. We aren’t doing this intentionally or maliciously; it’s just the way things are. Now that you know, though, go out and try to change it. Adjust the language you use. Explain things more thoroughly. Stop making assumptions about what your audience understands. We should want things to be better for the people who come after us, and that doesn’t exclusively mean better software. It means better processes, better documentation, and a better culture.
We use cookies to provide you with a better website experience and to analyze the site traffic. Please read our "privacy policy" for more information.
