Building on existing technology is at the heart of much technical innovation and is the essence of open source culture, and embracing our history provides an invaluable perspective.
Kat Cosgrove, a lead developer advocate at Dell* and Kubernetes* release team member, joins us to talk DevOps culture, the constant push to reinvent ourselves along with tech, and how to get involved in projects like Kubernetes*.
Katherine Druckman: I’ve followed you on social media, seen presentations you've given, and I'm excited to talk to you because there aren't enough cool women in tech, though we're working on that every day.
Kat Cosgrove: We're working on it. It's a struggle. But we're working on it. It's better than it used to be.
Katherine Druckman: That’s fair...When I was first working in the open source world, we liked to throw around the number two, that it was about 2% women. I think it’s improved...
Can you introduce yourself to those who don’t already know you?
Kat Cosgrove: I’m a lead developer advocate at Dell Technologies. I live in Edinburgh, Scotland. You might be asking yourself, “What on earth is Dell doing with developer advocates?” It's a little bit weird as a developer advocacy position in that none of us actually talk about or sell Dell products much. My job is strictly educational and largely around the topic of DevOps.
So, I spend a lot of time doing both internal and external education about DevOps tools, tech and culture. I’m a big believer that the culture is necessary there, but I’ve also been a member of the Kubernetes release team for the last seven releases...I'm part of the team of people that helps cut Kubernetes releases for you, so you've always got a fresh, clean one, four times a year.
Katherine Druckman: Thanks for that.
Kat Cosgrove: You're so welcome. It takes a lot of people. It's a lot of moving parts.
There are lot of sub teams to make that process run smoothly, but it runs more and more smoothly every time.
I've been involved in open source for several years now. I'm a big fan and aggressive proponent, both externally as a thing that I enjoy and internal to Dell as a function of my job, so I am currently getting paid to do things that I actively enjoy, which is really nice.
Katherine Druckman: We have that in common! You say people wonder about Dell and the developer advocate role at Dell, probably people wonder the same about us at Intel.
Kat Cosgrove: What does the developer advocate at Intel do?
Katherine Druckman: Well, I get to talk to you!
I get to do a lot of really cool things, and Intel is heavily involved in open source software. We contribute to so many projects and people don't realize that because Intel isn't the first name you think of when you think of something like the Linux* kernel, for example...
Kat Cosgrove: Dell is also a very large upstream contributor to the Linux kernel, and similar thing, people don't think about it.
Katherine Druckman: We think hardware. We think gaming laptops or something, and we don't necessarily think about open source.
I wanted to talk about how you got here because I think your story is like mine. I don't have a computer science background. In fact, most people I know in tech don't have that traditional background, so I don't know why we keep perpetuating the myth that it is the norm.
I have an art degree. I never talk about this, and I've been in tech so long that it doesn't really matter, but it's something I've always been hesitant to talk about. I went to grad school for History of Decorative Arts as well.
I think it's an advantage wanted to know if you think it’s an advantage, too.
Kat Cosgrove: I went to college but dropped out...I studied biochemical engineering, not computer science.
I worked as a bartender for a while. I spent several years working at an independent video rental store in Memphis, Tennessee called Black Lodge. From that and from bartending, I learned to gracefully handle people that I didn't like yet I had to appear to like, or handle difficult people sometimes, actively antagonistic people, without getting myself or anybody else into trouble. Handling people who are antagonistic has been incredibly valuable. It's a very valuable skill as an engineer. It’s a very valuable skill as a developer advocate whose job it is to talk to the public. Being able to handle people who actively do not want the best for you in a graceful way and still get what you want or need out of the interaction is super useful. Getting a computer science degree doesn't necessarily teach you that. That’s one of those soft skills that people give talks about at conferences that you just have to learn through experience. Not everybody needs to work as a bartender or in retail or food service to learn that skill, but it’s a valuable one.
I wouldn’t have the career that I have today without those people skills.
Katherine Druckman: I’d like to pivot and talk about reinvention: people in tech and the open source community are constantly reinventing themselves to keep up to date on new technology. You have to constantly learn new things. How short is the half-life of technical skill? We're always on to the next thing, but I think we have a slight tendency to overestimate the uniqueness of our ideas. We like to reinvent and pretend everything is new and shiny when maybe we're just recycling just a tiny bit, which isn't necessarily a bad thing. We’re building on previous knowledge, and that’s the spirit of open source, but I’d like to talk about history and being aware of it and building on it.
Kat Cosgrove: I’m strongly of the opinion that absolutely every advancement we’ve ever made in tech and computing is a result of a need to do something faster and or at greater scale every single time. Once we nail down the fundamentals, once we figured out virtualization, for example, we couldn't fully virtualize anything until we figured out memory virtualization, which we did with the Atlas Computer that was the first cracking of the virtual memory problem. Then the first commercially available machine that supported full virtualization was the IBM System 360-67, I think, and after we cracked that problem, everything we’ve done has just been how to do this existing thing and how do we do it even faster.
Sometimes the answer is you abstract away a pain point that slows you down. With CI/CD for instance, the first fully fleshed out CI/CD tool was released in the mid-90s, and it's not in use anymore, but that was born from the need of a doctoral student at the University of Oslo to handle configuration on a whole fleet of lab computers with different environments. He handled that by abstracting everything away behind a domain-specific language (DSL). Before that, it would have been like running different makefiles on each machine, which is kind of like configuration management, but that was our first infrastructure-as-code (IaC) tool in the 90s. Then our first real CI/CD tool also came out in the 90s, CruiseControl. It was similarly revolutionary...
Cruise Control at its core is not functionally doing anything different than what Jenkins* or Circle CI* or whatever other CI/CD tool does. The core of that is the same. But when somebody asks you about where you think CI/CD has its origins, they're not thinking of CruiseControl. When somebody asks you where infrastructure-as-code comes from, they're not going to talk about a doctoral student in 1994. They're going to talk about Terraform*, or they're going to talk about Circle CI or whatever CI/CD tool is hot right now, like Argo CD*.
Each of these things feels super new. Terraform feels like a really new tool, but it’s not. It’s solving the same problem that we've been solving for decades. It's just abstracting away more of it. It feels a lot like every time a Silicon Valley exec on a TV show makes a joke about “Uber for dog walking.”
About the Author
Katherine Druckman, an Intel Open Source Evangelist, is a host of podcasts Open at Intel, Reality 2.0 and FLOSS Weekly. A security and privacy advocate, software engineer, and former digital director of Linux Journal, she's a long-time champion of open source and open standards.