The One Where We Geek Out on Platform Engineering with Hazel Weakly

Sep 19, 2023

Ask episode

Chapters

Transcript

Episode notes

About our guest:

Hazel Weakly (she/her/hers) spends her days working on building out teams of humans as well as the infrastructure, systems, automation, and tooling to make life better for others. She’s worked at a variety of companies, across a wide range of tech, and knows that the hardest problems to solve are the social ones. Hazel currently serves as a Director on the board of the Haskell Foundation and is fondly known as the Infrastructure Witch of Hachyderm (a popular Mastodon instance). She also created the official Haskell “setup” Github Action and helps maintain it. She enjoys traveling to speak at conferences and sharing what she’s learned with others.

One of her favorite things is watching someone light up when they understand something for the first time, and a life goal of hers is to help as many people as possible experience that joy. She also loves swing dancing, both as a leader and a follower.

Find our guest on:

Find us on:

All of our social channels are on bento.me/geekingout
Adriana’s Twitter
Adriana’s Mastodon
Adriana’s LinkedIn
Adriana’s Instagram
Adriana’s Bluesky

Show Links:

Additional Links:

Transcript:

ADRIANA: Hey, y'all. Welcome to Geeking Out, the podcast about all geeky aspects of software delivery, DevOps, Observability, Reliability, and everything in between.

I'm your host, Adriana Villela, coming to you from Toronto, Canada. With me today, I have Hazel Weekly. Welcome, Hazel.

HAZEL: Hey there. I'm glad to be here and I'm really looking forward to this episode. It's going to be a lot of fun.

ADRIANA: Yay. Super excited. So first things first. Where are you calling from?

HAZEL: So I am calling from the sunny surprisingly town of Redmond, Washington and if you were to ask me in a couple of weeks, I'm going to be closer to Seattle. Seattle. And we'll see how that goes. But yeah, I'm in Seattle.

ADRIANA: Yay. Very exciting. Very exciting. You're my second West Coaster that I've spoken to for the podcast today, so I'm being outnumbered.

HAZEL: I mean, West Coast is the best coast, and I'm sorry, I don't make the rules.

ADRIANA: Fair enough. Fair enough. Yeah. There is something like, I think, kind of magical about the West Coast, where it's like, chill vibes at one with nature.

It's a different vibe from East Coast, for sure.

All right, cool. So I'm going to start with some lightning round questions.

HAZEL: Awesome.

ADRIANA: Prepare. Tun tun tun...

Okay, first question, lefty or righty?

HAZEL: I am a rightie.

ADRIANA: All right.

iPhone or Android?

HAZEL: Android

ADRIANA: For personal use. Do you prefer Mac, Linux or Windows?

HAZEL: Simultaneously, macOS and 'Nix OS.

ADRIANA: All right, cool.

Favorite programming language.

HAZEL: Probably....I feel like I'm obligated to say Haskell because I'm on the board of directors of the Haskell Foundation and it's true that is one of my favorites.

My cheeky answer is also that my favorite programming language is the one that I write in and nothing bad happens.

ADRIANA: Awesome. I do like that.

All right. Dev or Ops?

HAZEL: Yes

ADRIANA: Yes. Okay. Wow. Both. Okay.

And final question. Do you prefer to consume content through video or blog post?

HAZEL: Blog post. I read way too fast to sit there and not read it.

ADRIANA: I am the same way. I was just telling my previous guest the same thing. She also prefers blog posts because I cannot sit there and just listen to someone go, "Blah, blah, blah," where I'm like, "Get to the point."

HAZEL: I mean, developers being ADHD in this economy, who would have thought

ADRIANA: I know, right? For realsies. So I guess let's get into the meaty bits.

Well, first things first. So before we get into what you do, tell us how you got to where you are. How did you get your start in tech?

HAZEL: How I got my start in tech? That is a really interesting question because I have mostly had moments of a ridiculous amount of luck and then the ability to at the moment capitalize on that luck.

So how I got my first job was I was at a programming lab at university and I ended up happening to overhear two people talking about Erlang. And I was like, "I know that language."

Well, I didn't know it, but I knew of it, and what kind of weird ass nerd knows about Erlang in undergrad?

So I ended up talking with them for 2 hours after the lab and one of them actually said, "Oh hey, I work at a company and soon we're going to have internships. Do you want to do an internship here?"

And I was like, "Oh hell yeah, I do." Because I didn't have any other options.

And so eight months later I actually ended up getting internship there after applying to bajillion other companies and none of them gave a shit about me because I hadn't even graduated yet.

So it turns out that he was a racist, misogynistic, terrible person who liked to rant about like weird religious topics in the middle of a Costco food cart.

But other than that, it was an interesting first experience.

ADRIANA: Damn.

HAZEL: But if it hadn't been for that one moment of me knowing about Erlang, I wouldn't have had that job and then I wouldn't have been able to seal up in all the random weird crap that I had to, that got me my second job.

ADRIANA: And so what was so what was like? What was your second job?

HAZEL: Oh, you want the full history?

ADRIANA: I'm curious about the second job.

HAZEL: So the first job I have finally had enough of the person being really toxic because he had actually gotten the other intern to quit.

And I realized that his M.O. was going through and finding gullible college undergrad people. Getting them to be interns and then just having them be super cheap rate forever until they finally rage quit and left. And he never understood why everyone left and never talked to him again. Then I left and never talked to him again. Shocking.

So the second job, I looked around and found a company that was hiring and they were hiring for a front end job in React and TypeScript and all that stuff. And I didn't know TypeScript at the time, so I took a brief six hours and learned TypeScript and then took the interview and aced the interview because I had actually ended up, out of purely coincidence, helping my father-in-law at the time get his website built for a construction contracting company.

And because I had that whole thing built up from scratch, I had a huge amount of experience in that particular field that they needed.

And they pulled up that website during the interview and said, "We want this."

And I said, "Well, I know how to do it."

So that's how that worked.

And then during the first week there, I built out the entire backend in MongoDB, Node JS, TypeScript and did a whole bunch of ingestion from a very weird Microsoft Server database.

That was problematic. The whole thing was problematic.

It turns out that that company was a consulting company that was trying to use another company in order to bootstrap themselves without getting funding so that they could actually go and do the thing that they wanted to in the first place.

So you had a whole company whose entire existence revolved around their one single clients, never figuring out why they were paying this much money for a single website.

ADRIANA: Damm.

HAZEL: I know.

ADRIANA: Wow.

HAZEL: Shockingly, that didn't turn out. I don't why.

ADRIANA: What a shocker.

HAZEL: So after about after about ten months of that shit, it all fell apart. But in that time, I became the senior-most engineer on the team, IC-wise, built out an entire component library, re-did all the local developer environments, rebuilt everything in Docker, did like, a 10x performance improvement on the entire website and a 10x performance improvement on load balancing.

Got the entire back-end working more efficiently, leveled up the entire team in terms of being able to use the component library to redesign the entire website to meet the neurotic and weird ass requirements of a client that literally did not understand how things worked.

ADRIANA: Damn. So was all this happening, like, while you were still a student?

HAZEL: I, so I graduated halfway through my first job.

ADRIANA: Okay.

HAZEL: So I went from that first job to having designed the entire design system and done all those other things. That was about one to one and a half years after graduation.

ADRIANA: Okay. Now, was area of study related to what your work was?

HAZEL: My area of study was computer science and the university was Portland State University. It's a great university, but did it give me the tools that I needed to actually do the literal work? No, it gave me really good tools for understanding theory.

ADRIANA: Okay.

HAZEL: That didn't have a lot to do with programming. So, like my very first day on my job at my first company, I still remember it took me 4 hours to do some weird jQuery nonsense with a list in HTML.

And finally the head developer person was like, "What's taking you so long?"

And sat there and did the whole thing in front of me, essentially like ten minutes.

And then he was like, dude, "I thought you were good." Basically.

And then it was the weirdest thing was like his look on his face was, "I know you're smart, but what the fuck?"

ADRIANA: Yeah, it's funny because I do find, like, school never quite prepares us for the workforce because yeah, I mean, it's too much theory, not enough practical stuff.

The practical, quote unquote stuff that they make us do is so irrelevant that when you hit the workforce and you're solving the real problems of the real world, you're like, oh, shit, I have to learn this stuff from scratch.

HAZEL: Speaking of things in the university world that are not relevant at all, but I had a lot of fun doing. One of my favorite things that I ever did was during the operating systems course, we had to take a toy kernel and implement a multilevel feedback process, scheduler and priority queues.

So I implemented that with the vast majority of the state machine logic being implemented in about 80 to 100 lines of C preprocessor macros that were recursively, expanding using macros and a whole bunch of various extraordinary crimes.

My code was beautiful. It magically scoped in variables that were hidden. It did a whole bunch of things. It relied on some undefined behavior. I had to turn on GCC pragmas so that things actually compiled because Dead Code branch elimination wasn't working with ternaries and it was glorious.

Absolutely none of the TAs after the third assignment would touch my...like, none of the graders would touch my code. The only person who would grade my code was the TA who was a grad student and she's still a friend to this day. But that code was cursed.

ADRIANA: That's awesome. That's awesome.

HAZEL: It prepared me for TypeScript, is what I'm saying.

ADRIANA: So it's funny how the little things prepare us for the things that we don't even know are in store.

HAZEL: Right?

ADRIANA: Yeah. I feel like my whole life has been that. So one of the things that we have chatted about previously is, well, you've got many hot takes, and I feel like...we've talked about your thoughts and feelings around platform engineering.

So I was wondering if you could share that with folks because platform engineering is the hot topic of the day and everyone's got an opinion. There are tons of discussions going around. So throw your thoughts into the ring here.

HAZEL: Wow. Did you allocate the full four days required for this podcast to have all of my thoughts on platform engineering?

ADRIANA: No, shortly, no. I mean, sadly, no

HAZEL: Sure. So I'm going to have to summarize a bit. I wrote a blog post recently called "So You Want to Hire for Developer Tooling?" And in there I talk a lot about the first platform engineer or the first people that will become platform engineers in your company and how to not fuck it up.

And I'm sure a lot of people are going to read it and then fuck it up anyway, and that's fine. It's really hard to hire for it.

But hot take-wise, platform engineering is something that I find really interesting in that in the industry I see this habit of over and over and over.

Someone says, "Oh hey, in a sociotechnical system we need to solve the technical problems for the spice of the social problems and solve the social problems for the spice of technical problems and have them work together in a collaborative fashion, understanding the constraints and challenges of both."

And then someone goes in and says, "But tooling and vendors" and the whole thing goes to shit.

And this repeats over and over and over as organizations don't want to skill up in the cultural maturity and outsource understanding of something that they see as not a core driver to the business, which in modern economic theory, it makes sense.

If it's not a core competency of the company, why should you not externalize it and view it as a cost center?

And since the world is being eaten by tech, people haven't seemed to catch on to the fact that developer tooling, how developers work, the entire process of how they collaborate with each other and with the company is now inherently a core competency of existing in a tech-driven world.

So if you want to be relevant as a company, it's not platform engineering, it's not DevOps, it's not tooling...you need to understand how people work together and how people and solutions and technology work together and how to scale that understanding.

And the problem you will always run into when doing that is if your work is meaningless or if you are ruled by toxic work behaviors or you have a bunch of institutional biases and corruption in your company that prevent people from genuinely being able to improve the system as they see it, you will always end up with a broken system.

And so if you talk to executive leadership and say, "Oh," and they ask you, "What can we do to improve developer productivity?"

It's not productivity you want to focus on; it's the developer experience. And the developer experience there. The biggest leverage you're always going to have has nothing to do with the tooling, has nothing to do with Kubernetes, has nothing to do with fucking YAML.

Although swearing has a lot to do with the YAML because it's a natural and necessary defense mechanism when you have to write it every day.

With that aside, if you're going to improve the experience of developers at a company, the work has to be meaningful, the work has to be high impact. The work has to be high leverage and the relationship that the company has with the developers needs to be healthy and fulfilling and equitable.

And you will find very little leadership that is willing to take the full implications of that and execute on it.

ADRIANA: Yeah, I completely agree and I think that's, I mean, that's why we see so many of these so- called "transformations" fail miserably. Because leadership doesn't have their heart into it.

HAZEL: Mmhmm.

ADRIANA: They've been told by someone else who's like, "Hey, do this, it's in vogue."

HAZEL: Yeah.

ADRIANA: Go on, go forth, do it. And it's just like business as usual.

HAZEL: Did you know that related to that, it turns out one of the best indicators of quality in the system is whether or not people genuinely enjoy working on it.

And if you ask the question, "How does this system, how does your experience with interacting with this make you feel?"

Does it make you feel more alive and more whole?

If the answer is "Yes," it's probably a good quality system.

And if you need to choose between what to do, you can always ask yourself, "Which of these options will make me feel more alive and whole when interacting with the system?"

And a lot of people will go, "But what about the quantification?"

Like, what about the numbers? This seems like hippie mumbo jumbo.

And no, you should be in touch with your fucking feelings. You should be in touch with the human side of yourself, and you should not just bury it deep in your ass crack in the name of capitalism.

It's literally more efficient to actually think about your feelings and think about what it means to be a human and the human experience and try and make the world a more wholesome and inclusive place for everyone around you.

It's literally more efficient. It's literally objectively superior in many ways. And you can show that.

ADRIANA: Yeah, that makes a lot of sense, actually, because I've definitely felt in the past, like, when I'm working on something where I feel like it's a pleasure to come into work every day because this work is fucking cool. I think you're going to see it in my code.

You're definitely going to see that extra. I'll go that extra little bit. Right? Just to get it done. Because I'm excited about what I'm doing. Because I think this is cool shit that we're trying to do here.

HAZEL: And you're invested in improving a system that you care about and that, you know, cares about you.

ADRIANA: Exactly.

HAZEL: No one wants to work on a broken tool and no one really wants to fit a broken tool if they don't think that it will actually be received. Like, you can't fit something that won't be integrated into the system and it cannot see improved something that doesn't want to be improved.

ADRIANA: Yes. And it's both by design, doesn't want to be improved by design and doesn't want to be improved by the human overlords of that tool. Right? Because I've been in so many situations where you come in and they're like, "Oh, yeah, this thing's a piece of crap and it could really do with refactor or rewrite." But then no one wants to invest the time. Right?

I've felt so many times where it's like this thing just straight up needs to be gutted. Like, keep somebody keep a team working on this thing to keep the lights on while the other team does the rewrite, right? So we can all be happy in the end, but a lot of organizations aren't willing to invest that extra time and money, right? Because that means you've got an overlap of like, two teams working basically on the same thing.

But I feel it ends up being a very short-sighted decision to not support those types of things because you're shooting yourself in the foot in the end.

HAZEL: Yeah. And so with migrations in general, one thing that's really interesting about that is it turns out there's like a pretty formulaic strategy you can use in order to execute a migration of arbitrary size and complexity. So there's three main steps that go into a migration.

The first step is de-risking a migration. So that involves talking to people and understanding what they actually need and working with the people that are being hit the most by the inefficiencies and the insufficiencies of the current situation. And then you get them the new situation and you make sure that it works. You work with them, you work on that. You make sure that this thing will actually do what you want it to. That's the first step.

The second step is the enablement, where you say, "Okay, what is all of the low-hanging fruit?"

"What is all of the automation we can do?"

"How can we take this migration?"

And as much as possible, take the toil out of it and take it out of the hands of people who don't have the context required to execute the migration. How can we facilitate that?

And the third step?

The third step is literally someone needs to sit there and A commit to finishing it and B commit to communicating about it.

So the thing that I find fascinating about migrations is that most migrations fail in the first stage of knowing, actually sat down and talked to the team before they ripped out a solution. Like people will rip out a solution that isn't broken or people will try and say, "Here's a new solution" that actually makes the problem worse.

If you just talked to people and actually worked with them to verify that something will be in fact the solution, you would save millions of dollars a year or hundreds of millions or even billions in your company over time. And you would save years of developer effort by just fucking sitting down and talking. And it's ridiculous that this is not a thing.

The second stage migration.

ADRIANA: Yeah, I actually agree with you.

HAZEL: And the second place the migrations fail the most is people celebrate the automation step and the majority and they don't celebrate the done done of, "We actually finished everything and turned off the old system."

Don't celebrate if you haven't turned off the old system and sit there and commit to fucking doing the last mile. If you initiate the migration, it's on you to finish it. You cannot just hand that off to someone. It's on you to finish it, but it's also on you to communicate about it.

And so many migrations are not able to be finished because the communication of your progress, the communication of the value, and the communication of what needs to happen in order to actually do this, never happened. So again, talking to people, or rather the lack of talking to people, kills most migrations. And it's astounding to me because sure, it's difficult to understand what leadership or what your management or other stakeholders or other teams are looking for in understanding the progress of your migration.

But it turns out there is a simple and effective strategy to figuring out what they need in order to feel like you're communicating with them.

You ask, "Hey, is this working for you?"

And they say, "Yes," or "No."

And if they say, "No," you change it and then repeat, right?

ADRIANA: That's it novel concept, right?

HAZEL: It's not like we've had language as a society for like 18,000 years or something, right?

ADRIANA: I know, right? Yeah. But it's so true and I think that's like the most fundamental problem that we see across the board with these types of initiatives.

My favorite example is always, like, infosec. I worked at a bank a gajillion years ago and we were like so we had admin mode. Like, developers had admin mode on their laptops and we were able to install certain software so that we could get the job done.

And this was, I believe, it was like, pre- approved software to begin with, but then all of a sudden, InfoSec, one day they're like, "By the way, we're going to block the installation of all software unless it's on a whitelist."

And then unfortunately, we had to discover as we went. Like, "Oh, shit, this is blocked."

OK, well, now we need to contact InfoSec to whitelist this. And we couldn't complete the simplest tasks. I mean, it was ridiculous. All of a sudden, developer productivity went to a standstill because InfoSec didn't bother to speak with development teams to talk about, like, "Hey, what would your workflow look like if we did this? Right?

So it was just like the directive came from whomever. And thou shalt live with this heinous crime against development. So yeah.

HAZEL: I mean, the real solution there, the real solution there obviously was to have all the developers move to Visual Basic and Microsoft Excel as their main development platform. Because it turns out Microsoft Excel is one of the most efficient, beautiful, and glorious development platforms out there. And it's one of the best programming languages, too.

ADRIANA: Oh interesting, Excel. Yeah, I guess so. Yeah.

HAZEL: Honestly, it is actually a good programming language because it turns out so one of the people that says that is Simon P. Jones, who is one of the people that helped create Haskell.

So actually the Visual Basic inside Excel is a functional programming language that has first-class functions. It has a whole bunch of other like, not-so-nice things in it. It even has lambda functions. It has all the fun, hot, trendy things. And the reactive programming model inside Excel was later stolen and turned into ReactJS.

I'm modifying the history. I'm going to pretend it was stolen from Excel. But Excel is actually pretty awesome. Like, in terms of a programming language, it would be hard to find something that is more accessible to people outside of tech.

ADRIANA: Yeah, that's true. You're talking about, like, straight up Excel formulas at this point. Are you talking about, like, okay, not the fancy stuff that you can do with, VBA?

HAZEL: They're the same thing. You can stick VBA inside basically any Excel cell.

ADRIANA: Very true. You know, like speaking of VBA and Visual Basic. I liked Visual Basic. That was like, I guess, officially my second programming language. I started on QBasic back in the day. Yeah, back in the day when it with the gorillas throwing banana bombs to try to destroy the city. And there's also the Nibbles game. Big fan.

HAZEL: Nice. So you've always been a BASIC bitch is what you're saying?

ADRIANA: I mean, BASIC was basic, but I liked Visual Basic. I thought it was intuitive. It was a nice way to develop GUIs I mean, especially when you go from Visual Basic and then try to develop any GUI stuff in Java. That was a fucking nightmare. And I did not last more than 2 seconds trying to sort that out before going, "Buh bye!"

Yeah, Visual Basic was great. It was fun. I used it in high school. Like, my high school programming class was Visual Basic and built some cool stuff. I did some shitty animations with Visual Basic. It was great.

HAZEL: Visual Basic is so underrated and so related to Visual Basic. A lot of the programming languages and environments of the previous decades got an incredible amount of things very right. And so one of the things that I've actually said decently often about DevOps and infrastructure-as-code and all these things, is it's really just people trying to recapture the fever dream hyper productivity of SmallTalk and the SmallTalk VM, but with an audit trail for compliance.

That's it. Trying to manage a wibbly wobbly ball of state in real time, at scale, without fucking it up. But the best feedback loop and the best productivity you have basically ever really been able to get in terms of being able to dig into a system.

If you've ever seen SmallTalk, honestly, it's incredible.

ADRIANA: I've never seen it. I've only heard of it my dad used to code in SmallTalk back in the day. Would not shut up about it. Yeah, that was because I think it was like one of the original object oriented languages out there. Right?

HAZEL: It was THE object-oriented programming language

ADRIANA: There you go. Yeah.

HAZEL: And every other language after SmallTalk took object-oriented programming and said, "What if we ruined it?" And then proceeded to do exactly that?

ADRIANA: So basically no one has succeeded in capturing the glory of SmallTalk, is what you're saying.

HAZEL: And we probably never will, because now people are really used to being able to undo something or statically analyze something. And honestly, both of those are extraordinary inventions like the ability to say, oh shit, never mind, is actually really good. However, that has a lot of false confidences, in that, in the real world, your system is actually pretty mutable and pretty ugly anyway. So for people to say, "Oh, we can just undo this," or "Our state doesn't actually REALLY exist," that is kind of untrue. And so pretending that that's the case leads to developers having this very mismatched and distant view of the system that they work with.

Whereas in SmallTalk, if you fucked up production, you knew the second you hit enter, because you just crashed the entire VM and the entire company is now screaming down to its knees, sobbing, the whole thing fucked up. But you KNEW...INSTANTLY.

ADRIANA: Right. Yeah. So you get that immediate feedback versus the pussyfooting around maybe there's a thing that's wrong.

HAZEL: Yeah. And the immediate feedback, it makes you fear yourself the appropriate amount. Like, if you release code that's about to nuke production, "What could nuke production?" You're gonna double- check it, whereas now, we're just like, "It's stateless. It's in Kubernetes. It's totally fine. We can undo this."

And then you actually delete half your database and then OpenSSL Bleeding Heart happens and then all these other things happen, and it turns out that you're just like, you're crying in a corner, you eat 20 years in five days, you're like, stress bleeding out your toes. It's a whole thing.

ADRIANA: That's that's actually a really interesting way of viewing it because yeah, I agree. It's similar...This reminds me of the argument where making developers responsible for their code once it goes into production, rather than throwing it over the wall, right? Because if you're the developer responsible for your code, there's no fucking way you're going to let shitty code go into production, because you're the one who's going to be on the hook if something happens.

HAZEL: Right. A lot of people will think about that and they'll go, "So if I just make everything the developer's responsibility, it's all better." And that's not true. Because, with equal power comes equal responsibility.

But with equal responsibility needs to come...With greater responsibility needs to come greater agency. Agency and responsibility cannot be separated because they are the same thing. And if you pretend that they're not the same thing, you're going to end up with a bunch of pissed off, burnt-out developers who hate you, your whole company, everything about you, and they're going to burn the entire economy down to the ground.

ADRIANA: Yeah, absolutely. I yeah, and I think, unfortunately, that's kind of how I felt early in my career. I was just so fucking burnt out. Like my first job out of school, I was pulling these ridiculously long hours where I was working six days a week, 14-hour days.

And I remember I complained...this other guy, and I complained...like, I was fresh out of school. This other dude, Dale, he was engaged, so he's like, planning a wedding, and we're both like, "What the fuck, man? This is like, way too much work. We're dying."

Like, we have no life. And so we're like, okay, we're going to complain together, right? And then Dale bailed on me and I complained to my boss and then he's like, "Oh, you can have the weekend off."

And I felt so guilty. I felt so guilty for taking the weekend off because the rest of my team was like working and Dale bailed on me. So I was like the little prissy-ass bitch who was complaining about, "Oh, she can't handle the work."

But as a result of that, I had zero vested interest in seeing that thing succeed because I was like, I hated that system. I'm like, if it goes down in flames, I do not care because they treat me so badly. I don't care. I don't care about my work.

HAZEL: And if you were to take any of the executives and just talk to them and say, hey, you just ruined any capability that this company had of building a team that is engaged and able to actually put everything where it needs to go, they would just look confused and go, well, this is a cost center, so why do I care? But the knowledge required to operate and build and improve this is really about something that fundamentally can't be a cost center.

ADRIANA: Yeah, and that's interesting because I feel like this whole, like, "You're a cost center" argument ends up really interfering with innovation and productivity because, well, it costs too much. We can't invest in that. You're not making us money. And it's to the detriment of the entire organization as a result.

HAZEL: Yeah. One of the things that I always try to do when I am leading infrastructure teams is I see infrastructure as the way, or not "The Way," but as "A Way" to enable people to have low risk, high quality, rapid experimentation.

You want that experimentation to be risk-free, and you want to basically sow the seeds of innovation. And the way to do that is you get a bunch of people that are smart, you put them in a room, you more or less let them do whatever the fuck they want to, as long as they have like, a vague sort of agenda that they're kind of going towards. And then you let them try out as many ideas as possible, and you let them understand the system.

Because this whole idea of software development, or development, or building a platform is really about, "How do I understand this so deeply and intimately that I can express the entire understanding of this problem in a way that other people can interface with this as if it was knowledge made concrete and tangible, and interactable."

And that requires you to try out a whole bunch of things that are not that thing. It requires you to evolve the understanding of that thing over time and the understanding of the knowledge itself, the process of getting that knowledge, and the process of even thinking about what it means to communicate about it.

And that's what you're doing. It's not programming. It's knowledge work. It's creation of understanding itself.

ADRIANA: I think that's such a cool approach, because I think by having these loosely-defined borders...parameters...it opens up your mind to creativity.

Because now it's like, oh, I feel like if you let people do their thing, I think they will naturally gravitate towards finding the problems to solve and then they will be excited about solving those problems. And like you said, they'll learn things along the way. And for me, I think one of the coolest things after solving a ridiculous problem is taking a step back and thinking, holy shit, look at all the things that I learned along the way to be able to get here and having there's no better way to inject enthusiasm into a team than doing that.

Personally, I always tell my bosses, "I don't like being bossed around." I thrive...And that's the thing I appreciate about my current boss is...They know that I thrive from doing my thing and doing it well, and finding cool problems to solve and then writing about it or whatever. Like sharing the knowledge in whatever way.

And I think more managers need to recognize that because the field that we are in is ultimately a very creative field, contrary to popular belief.

HAZEL: It's one of the most creative fields out there. And one thing that I think of, that you reminded me of is we have the concrete work of doing something, and then we have glue work, which is tying together things in a way that is not necessarily recognized. But there's a third secret option. It's not glue work, and it's not the concrete things. I'm going to call it innovation work. It is work of finding inspiration and drying it out and bringing it to life and sowing those seeds.

And it's not glue work. It's not concrete work. It is the work of divining inspiration itself from sources around you and making that visible and making the process visible and figuring out what it means to be innovative and to execute on visions you don't even know you need to look at.

ADRIANA: It's yeah, and sometimes that means like, finding collaborations in the periphery of what you're doing, or finding connections to your work from somewhere that you wouldn't necessarily see that connection, because everything I think, brings us to where we need to be.

It's kind of like what you were saying. I think we were talking about this earlier. Career-wise. All the things that we do, all of our experience leads us to where we are now. And you draw on that experience. You draw also like what you said on the serendipity and the opportunity taking advantage of lucky situations. I mean, you're only truly lucky if you take advantage of that situation.

And I think a lot of us tend to not recognize when we are in a lucky situation and that like, hey, this is something that I need to grab a hold on before it goes away.

HAZEL: Yeah. And fine-tuning that notion of luck and that gut instinct of I should focus on this or I should prioritize. This is something that I've done a lot of and it's been one of my greatest career accelerators. Because that fuzzy feeling of this is important, or this person is cool, or this is where I need to be in right now, or I need to go into this room. I don't even know why sometimes, but I just trust it because it's going to lead me to pretty cool places like here.

ADRIANA: Yeah, actually that's a really, really excellent point is trust your gut. Trust the fuzzy feelings.

HAZEL: Unless it's talked about, then don't touch it.

ADRIANA: I was just going to say we are coming up on time. But before we go, I would love to get any hot takes or words of wisdom for our viewers and listeners.

HAZEL: So a hot take. Someone asked me once to explain what Kubernetes was because they felt like it might have been a practical joke or something, because they're trying to figure out what it is, and there's just so much nonsense going on.

And so my explanation of what Kubernetes was...is...Kubernetes is what happens when you take about five to ten years of institutionalized tech debt, reinvent it, and create an entirely new parallel universe of tech debt as a consequence. Which is to say that it is highly effective, and yet much of it, to some degree or another, is simultaneously needed, yet unnecessary.

ADRIANA: That is awesome. I think that is my favorite view of Kubernetes to date. So thank you. Awesome. Well, thank you so much, Hazel, for joining me today on Geeking Out. Y'all. Don't forget to subscribe and be sure to check out the show notes for additional resources and to connect with us and our guests on social media. Until next time.

HAZEL: Peace out and geek out

ADRIANA: Geeking Out is hosted and produced by me, Adriana Villela. I also compose and perform the theme music on my trusty clarinet.

Geeking Out is also produced by my daughter, Hannah Maxwell, who, incidentally, designed all of the cool graphics. Be sure to follow us on all the socials by going to bento.me/geekingout.