Stack/Unstuck: Building A Common Language

While working in a software stack, IT professionals may have to bridge gaps in practical knowledge, institutional knowledge, and communication. Teams may be located in different countries or backgrounds, and may even work in different areas of the stack.

The practice of building software is deeply technical, but it’s also deeply human. In the final episode of Stack/Unstuck, we discuss how bridging gaps in communication and expertise helps teams come together from across a software stack to build something great.

The Compiler team would like to thank everyone they spoke with in the making of Stack/Unstuck. Earlier in this series, we mentioned how building software was like building a house. One of our guests, Ryan Singer, made a great video where he discusses the similarities. Check out his explanation here.

And to check out what David Van Duzer and his team are up to, you can visit the Open Up official webpage.

00:02 — Mike Anello
I've been an active member of the Drupal community for over 15 years, and once I got what I felt was my 10,000 hours in building Drupal sites, I turned my attention towards writing curriculum and teaching people to do what I do.

00:19 — Kim Huang
This is Mike Anello. He's a trainer and developer who specializes in Drupal. Drupal is a web content management system that we've talked about over the course of the last few episodes. Mike and his team are known for a training program with a very striking backstory.

00:37 — Mike Anello
It's a 12 week, three-ish time a week Drupal training course that got started about 11 years ago, oddly enough, because the space shuttle program retired.

00:52 — Kim Huang
It was around the early 2010s that the space shuttle program was winding down. Mike's wife caught wind of what was happening at Kennedy Space Center and the fallout from the program's retirement.

01:05 — Mike Anello
Thousands of folks who work at Kennedy Space Center were being laid off, and the majority of them were skilled workers.

01:13 — Kim Huang
Together, the couple began to work on a proposal.

01:16 — Mike Anello
Our idea was that we were going to create a long form Drupal training program, specifically geared towards skilled IT workers who were being laid off from Kennedy Space Center.

01:29 — Kim Huang
But it was easier said than done. While there were some people who had relevant skills good enough to rebound from the layoffs, there were others with more steep challenges.

01:41 — Mike Anello
Some of them had relatively modern experience, and we had other folks who had worked on software for the space shuttle launch control system, which if you think about it, all that stuff was written in the 1970s, maybe the 1980s. So these were folks who they knew programming, but they walked out of a time machine, almost.

02:07 — Kim Huang
Mike and his team would have to bring the experiences of those programmers into a new age. Hearing this story made me wonder, when IT professionals differ in experience, they have to bridge gaps in what they know and how they communicate. Teams maybe from different countries or backgrounds, they may even work in different areas of the stack, but everyone has to be able to understand each other so that programming and development, all those things we've been talking about, can come together. How do we build that common language?

02:44 — Brent Simoneaux
This is Compiler, an original podcast from Red Hat. I'm Brent Simoneaux.

02:50 — Angela Andrews
And I'm Angela Andrews.

02:52 — Brent Simoneaux
We're taking you on a journey through the software stack. We call the series Stack Unstuck.

02:59 — Angela Andrews
Today, we are wrapping up that journey. If you want to listen to it from the beginning, you can start from our episode, The Great Stack Debate.

03:10 — Brent Simoneaux
Both of our producers, Johan Philippine and Kim Huang are here with our story.

03:16 — Angela Andrews
Yay. So Kim, Johan, do you know what this story reminds me of?

03:21 — Brent Simoneaux
Do share.

03:22 — Angela Andrews
So I remember when my mom, she was a programmer, she went to school for programming back in, I want to say the 80s, punch cards and the whole shebang. And I remember her trying to make this leap, her being this really technical person, and it was like apples and carburetors. It was not the same thing. So I can only imagine Mike and his wife, how difficult it had to be to retool people who had learned this one way of technology. And moving into something like Drupal, which is a lot of Wizziwig, but a lot of understanding the underpinnings. I can only imagine how challenging that must have been for them.

04:06 — Kim Huang
Yeah. He talks a lot about educating a group of people that have a wide set of skills, and that's the setting that a lot of people are faced with when you're talking about coding boot camps or even formal education. You have so many people with different skill levels and different skills themselves.

04:27 — Angela Andrews
I love this episode already.

04:32 — Kim Huang
I spoke with someone that I thought would have a lot of interesting things to say about that common language or dealing with people and how they communicate across the stack or across different levels of experience. His name is Ryan Singer, and he's the former Director of Engineering at Base Camp. Nowadays, he's an author and a product developer.

04:52 — Ryan Singer
If I was working in the auto industry or something like that, there would be so many old things that were figured out in the 70s and 80s and everything you know that would be set in stone. And in the software industry, it's this crazy free for all of everybody trying to understand, "Whoa, what do we do and how do we do it?"

05:11 — Kim Huang
Ryan often talks to people about what he says are core concepts of the development process. One of them he talks about at length is called the vertical slice.

05:24 — Ryan Singer
This is where we talk about horizontal layers versus doing one vertical slice. And this idea of one vertical slice where there's some backend working, there's something that you can click on, and it does something that we can actually try it out and understand does it do what we thought it was going to do? And getting to that point sooner than later, that's a really great moment for a team.

05:50 — Brent Simoneaux
I don't think I quite understand this concept of the vertical slice.

05:54 — Angela Andrews
Me either.

05:55 — Brent Simoneaux
Can you give me an example of this, Kim?

05:58 — Kim Huang
Sure. A vertical slice, if you're thinking about a cake, if you're thinking about different layers, different layers of the stack, if you're cutting something vertically, it's showing all of those layers working in sync. They're all working together. All the flavors of the cake, all the layers, the frosting, the cream in the center, the sprinkles, they're all working together to give you what you should expect from that cake. It's the same thing in development. A vertical slice is showing all those different components that we've talked about over the course of the last few episodes, all working together to bring whatever product that a customer is looking for to life. It's a different vibe from a demo where a lot of the parts of a demo can be simulated. You want to demonstrate to the person who's looking at the demo a slice of reality. That's what a vertical slice is. And that can be used to communicate to different people who work in different areas of the stack, a holistic picture of what the work is now. That can open up discussion for challenges, issues, and even improvements that can be made on future versions of whatever they're building.

07:13 — Brent Simoneaux
So we've been talking all series-long about the software stack, but where does that come in here, Kim?

07:22 — Kim Huang
Ryan says challenges can come up that are beyond the issue or the topic of what stack to use. In a way, the stack often takes a backseat to those much larger conversations.

07:37 — Ryan Singer
Honestly, the same problems happen everywhere, and people like to have really spirited debates about, "You shouldn't be using this, you should be using that," but real life is real life, and we don't get to go in with our perfect programming language and our perfect framework of choice. And the thing is that a lot of companies today don't have the clarity about the different kinds of work that have to be done in order to make a product, and so they dump it all in the programmers like they should figure it all out. But that doesn't mean that as a programmer now you are responsible for becoming a product strategist and the UI designer, and all of those things. The more that we become clear on, "Oh, these are different kinds of work," then as a programmer, if someone is saying, "We need to decide which questions to ask people in the onboarding screen," and we say, "Well, whose job is it here to talk to customers?"

08:31 — Angela Andrews
There are so many different parts of “how do we get this product to market?” It's not just about programming. He talked about strategy, and UI, and there's testing and there's... It's huge. Again, when I'm hearing it, I'm trying to follow, but it sounds like it's just a lot. It's a lot. And maybe the issue is big. Maybe that's why it sounds this way.

09:00 — Kim Huang
I think that you understand what he's saying perfectly, and that programming is complicated, and building software is complicated, and some people don't really have a grasp on how complicated it can be and how complex it can be. And I think that's what he is saying here.

09:17 — Angela Andrews
It's complicated.

09:21 — Kim Huang
It's complicated.

09:21 — Brent Simoneaux
But Kim, what you said earlier, I think is really important here, which is that we have been talking about the stack in this series and development processes and what it takes to build an application, for example. But what you said earlier is that, that often takes a backseat. That's not always at the foreground of what companies are talking about, or even decision makers are sometimes talking about.

09:50 — Kim Huang
Yes, those fundamental questions are most important because the what and the why is going to determine the how. In this case, if the team is either choosing their stack or they're inheriting it, they need to have a shared understanding of how those components are going to come together to build what they want to build.

10:10 — Brent Simoneaux
Not only the components with the people as well, right?.

10:13 — Kim Huang
Exactly.

10:15 — Ryan Singer
What I find is that it's the same techniques that we need to do, no matter what framework we're using. We need to not just dive in and start building without having a clear understanding of what connects to what. We do need to do a little bit of homework to understand how does the hip bone connect to the bone? Does that API actually give us what we think it's going to give us? Is the data coming in the form that we think? We think we can change this billing system, but does it actually work the way that we thought? Those things should actually be worked out before we commit.

10:49 — Angela Andrews
Before a line of code is written.

10:51 — Kim Huang
Mm-hmm. Exactly.

10:52 — Angela Andrews
That is a lot to understand. The hip bone connecting to the leg bone and the rest of it. It is so important to figure out before you start writing code, it's almost like, "Wow, let's paint the walls.""Wait a minute, you don't even have the framing up. What are you talking about walls for? We haven't even built this thing." So, that analogy is very good.

11:14 — Brent Simoneaux
How often does that happen in practice, Angela?

11:17 — Angela Andrews
Well, you think about it, programmers just want to start writing code. They just want to start doing that thing. They can maybe do a little bit pseudo coding, thinking a problem out loud, putting pieces together that they take from their experiences and what they think could be a solution for this problem. But again, because there are so many disparate parts, as we've learned in the stack, you really do have to understand the really full picture. And I think if you just start digging and start coding, you're really missing a really big part of the communication part of it. So it has to be much more holistic, and I think that's what Ryan is alluding to. There's a lot of work that has to be done before we dig into the what and the why, and then you get to the how.

12:14 — Brent Simoneaux
I'm going to ask a question that I think I know the answer to.

12:18 — Kim Huang
Okay.

12:19 — Brent Simoneaux
What happens if you don't figure all this stuff out ahead of time?

12:24 — Angela Andrews
You ship it.

12:28 — Kim Huang
That's what happens.

12:32 — Brent Simoneaux
Okay.

12:32 — Angela Andrews
Yeah. I mean, there's a lot of bugs that happen that you have to fix while things are in production. Sometimes things don't ever get off the ground and you have to throw it all away anyway, so there's a lot of different scenarios.

12:43 — Brent Simoneaux
Johan, I want to bring you in here. What are some of these different scenarios?

12:48 — Johan Philippine
Lewis gave us, in the database episode, an example of when you initially build an application, when you're learning things, for example, his Rolodex application, you might have some demands on the application that over time change, and so you might set it up in a way that works initially, but then as the application scales, as you demand more things of it, those changes in demand means that you also have a change in how you need to write and maintain that application.

13:20 — Kim Huang
Good point.

13:21 — Angela Andrews
So why is this so difficult? We're still trying to figure this out. It seems pretty clear cut if you have all the pieces, if you're communicating, why is this so hard?

13:35 — Kim Huang
That's right. And we've heard a lot from Ryan about the commonality of all these problems that people can face in development, and we've heard some ways to address them, but to Angela's point, why are they still so hard to address? We're going to talk about that next.

13:53 — Johan Philippine
So the next person we spoke to is David Van Duzer, and he's a consulting architect here at Red Hat. Now, he's been tinkering with computers and working on them for quite a while, and that history, having lived through a few different eras of computing, gives him a lot of context for the work that he's doing today, and that's context that newer developers and newer people in IT in general, they often don't have. And when they're on the team together, that can be an issue.

14:25 — David Van Duzer
I struggle with this because I think that people who don't have my particular background in time and encountering certain of these devices early on in the hobby years when you could still take apart a Macintosh and see all the different chips, where now they're pretty much sealed shut, I don't share all these experiences with younger practitioners or even older practitioners who are newer to the field. For me, it's about learning new vocabulary, because quite often I'll find, even though we don't share this vocabulary that I take a second nature, the concepts are there. They've just been introduced in a different way. So part of that for me is we all have to learn different ways to develop a baseline vocabulary so we can communicate with each other. One thing that I think is a big problem in the industry is that this sometimes becomes a contest like, "If you can't speak my language, then I don't have time for you."

15:24 — Angela Andrews
So David is speaking directly to me in this tape. He is speaking to me. So I'm currently in this DevOps bootcamp, and I will say I'm the more senior person in this bootcamp. And because I've been doing this for so long and listening to how these younger folks are talking about technology and their take on it and how they came into it, I find myself having to stop. I have to stop first, because I don't want to come off as the smarty pants in the room because what they're saying is really valid, but because they don't have the historical context, you see where some things are missing. So as the more senior person, I have to be very mindful. How do I communicate this in a way so they can understand the historic technology about what we're talking about so it makes sense in this newer realm where everything is code, and this is how this works? It is a really thin line to walk in this scenario because you really do have much more experience, and you could probably run circles, but there's no need for that.I think it's our part, is to help these younger practitioners understand that it came from somewhere and let's build these bridges to, "This is how it used to be. This is how we're doing it now." Let's make these connections because one, it's a learning experience for them, and two, it's helping you understand better where they're coming from, because you're meeting in the middle somewhere. I find myself having this conversation with myself every night. I'm sitting in class going, "Oh my God, I just want to..." And you can't. You can't do this, so it's hard. It's a tight rope.

17:29 — Brent Simoneaux
It sounds like another part of what he is saying is that if you're carrying this attitude of, "If you can't speak my language, or if you don't know my vocabulary, then we can't even talk." That is the wrong way to approach this.

17:46 — Angela Andrews
Oh, yeah. That's not helpful. No.

17:47 — Brent Simoneaux
Yeah.

17:48 — Johan Philippine
That's how you build up walls between different elements of your team and then just problems don't get solved or not as [inaudible 00:17:54] as they could.

17:54 — Angela Andrews
Isn't this what DevOps was supposed to solve?

17:57 — Johan Philippine
Exactly.

17:57 — Brent Simoneaux
Yeah.

17:58 — Johan Philippine
David goes on to talk more about how making sure that we're all speaking the same language, that we're all understanding each other is a huge part in identifying and solving problems together.

18:10 — David Van Duzer
We also need to be able to understand how these layers of the big distributed stacks are built on analogous, smaller components that we can understand on our own. But in order to get that common enough layer of terminology, this is the tribalism of different languages, different operating systems, but the concepts live there in the same... They live there. No matter what you're doing with whatever size of computing system, at the bottom, you've got ones and zeros, binary code that's interpreted in a certain way based on a compiler. Shout out to the name of the podcast.

18:53 — Johan Philippine
Always going to include that at every opportunity, and I not going to apologize for it.

18:59 — Angela Andrews
I love it. I actually talked to Evan last week. Evan Stoner was a guest on one of the previous episodes on Stack Unstuck, and we were in a meeting together and he was like, "You sounded a little angry," and I was like, "That wasn't my point." But again, developers... I'm an infrastructure person, he has a developer background, and he was just like, "We have such differing opinions about things," and that's where the tribalism comes in. We bring our preconceived notions about how things should work, how things should be. And it was just so funny because it was a bunch of developers. I'm one of the few infrastructure people in this conversation, but we're really talking about the same thing. It's just that we're coming at it from different angles, and we're trying to find how we meet in the middle, because we're all working on the same project. We're all working on the same thing. So like you said, it's really all ones and zeros, but how do we, coming from our different tribes, how do we translate what we're trying to say so it's very basic amongst everybody across the stack? That's a skill. That is really a skill.

20:18 — Brent Simoneaux
And also how do we learn about and listen to people who are coming from a different perspective or coming from a different set of knowledge or skills?

20:30 — Angela Andrews
Listening first. That's always the best way to have a conversation and to communicate effectively. You can't lead with what you think is right. It's better to listen, in my opinion, to see what other people have to say about a situation.

20:44 — Brent Simoneaux
And this is why I love what we've been doing in this series, is that it gives us a little bit of understanding of what everyone is doing around us, and it gives us some of that shared vocabulary so that we can start to have a little bit of empathy and understanding for the complexity that our coworker is facing in the database, or any example from any episode that we have done in this series, and I feel like that's a skill that all of us should be building.

21:25 — Angela Andrews
It is. And as with all skills, they take practice.

21:30 — Johan Philippine
Yeah. I think one of the really important parts of that, and going back to the meeting we had with Evan Stoner and the rest of the developers, is that understanding each other is wonderful. You also have to be able to express and defend your own choices as well, because the choices that you're putting forward are maybe the best solution that you see, but that's going to affect the way that they implement their solution. And learning how to argue and defend your position while also taking and listening, and hearing how that's going to affect how they do their work, I think is the crux of what we're trying to get at here.

22:11 — Angela Andrews
All a skill.

22:12 — Johan Philippine
Underneath the terms that we come up with underneath the different tools that we use, there's that common set of ideas and processes that are, in the end, functionally the same.

22:23 — Angela Andrews
Thank you. Thank you.

22:27 — David Van Duzer
One thing that I try to push folks to do when I see these different tribal communities interacting is push them to use the simpler language. If there's some term that you have... You might be aware that the Java programmers, you refer to dictionaries as maps. We have ways of going outside our core vocabulary and simplifying. And if we can get better at that, at acknowledging when we are talking within our tribes and learning how to welcome people without that vocabulary and not just welcome novices, but speak to other experts in different tribes with a more common language. There'll be more communities. We can still be celebrities in our micro community, but there'll just be more people out there, more opportunities for everyone.

23:19 — Brent Simoneaux
I think what I'm hearing here is that the practice of building software is deeply human. As technical as we think it is, and it is very technical, it's also deeply human. A big part of building software well is communication and cooperation.

23:43 — Angela Andrews
It's all about communication, and it's finding a way to communicate commonly. That's where everyone has something to contribute. If we're talking about, like in the example he used about programmers using some say dictionaries, some say maps, well, if it's the same data structure, you can agree to disagree that you may say dictionaries, but you do mean maps. You can agree to disagree on that, making that a commonality. We're not choosing one over the other, but this is exactly what we're talking about. So I think it's when we decide that this is the language that we're going to speak, and he used the term where we're not just talking about folks who don't speak any of the language because they're malleable. They're going to come in and pick up things along and hear those conversations. But when the experts come in with their very deep understanding and they bring those gems to us and enlighten us, that's helping to broaden our language as well. So there's a lot of give and take. It's just the communication is so key in deciding what that language is going to be. And then listening. It's a lot of listening to what others have to say.

25:06 — Brent Simoneaux
Let me ask you, Johan. So David, he's really emphasizing the need to simplify.

25:13 — Johan Philippine
Yes.

25:13 — Brent Simoneaux
Why is it the answer to this to learn everything about every layer of the stack? If you just knew everything, wouldn't that also make communication a lot easier?

25:27 — Johan Philippine
I saw Angela just roll her eyes at that one. We're trying to tackle this with this series over the past few episodes. We've barely been able to dive into each layer of the stack. It's a lot to ask. That's a lot to learn. Even in an industry where constant education is pretty much required, putting that much effort into learning every single element of the stack, it's going to help you out in the long run, but that's a lot to ask for.

26:00 — Angela Andrews
It is. You can't keep up. If you had to know everything, there's no way.

26:08 — Johan Philippine
Now, David explained to us that things would probably go a lot more smoothly if people adopted more of a permanent beginner's mindset so that they could relate to each other, especially across disciplines and across layers of the stack.

26:24 — David Van Duzer
On the database person's side, they can see things like individual transactions that wrote to these fields, and then they'll need to be able to speak competently, maybe find a timestamp, and the application developer will see, "Oh, you got a transaction error that said a field was missing." And if I look over here, "Oh, we didn't upgrade our ORM schema and so our front end doesn't..." But you wouldn't find that unless you were able to correlate and discuss it in the first place.

26:57 — Johan Philippine
So here he is really advocating for what we were just talking about, making sure that you're speaking in such a way that you can understand each other, even though you're talking about really technical aspects of where the problem is coming from, it looked like it was a problem that was across multiple different layers of the stack. And so any one individual person probably wouldn't be able to fix that. And so the teamwork and that communication is what really led them to identify the problem and then be able to fix it.

27:33 — Angela Andrews
So more on that vertical stack phrase that we talked about earlier.

27:39 — Johan Philippine
Vertical slice.

27:40 — Angela Andrews
Oh, vertical slice. This lends a little bit to that, where in this scenario, he was talking about the database person having to discover this error and how do I translate what I'm seeing to a developer so it makes sense to what they are seeing? And when you start looking at that slice and where those pieces start to intersect, you're going to come up with that language that makes sense right there, that makes sense right there, that makes sense right there, because there's no other way to do it. You can't communicate effectively unless you figure out, "Well, where are we intersecting and how can we make this part where we're intersecting? How can we make it make sense?" That's almost like the money shot and being open to understanding, "Well, I don't know exactly how they do what they do, but I do understand what I know. Let me ask those questions. Let me be inquisitive. Let me have that beginner's mindset," like, "I don't know what this means to you, but this is what I'm seeing” type thing. So it's all about communicating.

28:54 — Brent Simoneaux
Yeah.

29:02 — Johan Philippine
Kim's got a few more stories about what your team can achieve when they're all communicating really well.

29:09 — Kim Huang
Back to the top of our episode, the story about Mike Anello and the Kennedy Space Center. How did it all turn out? Well, you'll be happy to know that overall, the program was a success. A lot of people who worked in the special program moved on and transitioned into new jobs and new industries. And since then, Mike has trained hundreds of people. I asked him what he thinks is the most important takeaway from the experience.

29:38 — Mike Anello
My expectation is not everyone's going to be a developer workflow expert, but you need to know the generalities of it so that you can be introduced to a new way of doing things, but not have it be learning a completely foreign language, maybe just a dialect.

29:58 — Kim Huang
And for those who are newer to tech, well, here's some wisdom from Ryan Singer.

30:03 — Ryan Singer
There isn't this perfect A-to-Z university education for software development. It's a hands-on craft that you learn here and there, and then you get into a job and all of a sudden, you're supposed to make something work and you're like, "Oh, my God. How do I do this?" I think the best thing really that can happen is to form a relationship between junior and senior. And of course, when we come into a team, and we are the ones who are new, we don't want to admit all the things that we don't know because we are supposed to be there as somebody who's getting paid to do this job, and we're supposed to be qualified and blah, blah, blah. But the thing is there's a lot that we don't know, and if we can go to the senior people with this attitude of, "How would you approach this?" Or even better, "Where do you think I should start on this problem? What is the hardest part of this thing that I need to solve first?"

31:08 — Angela Andrews
That is interesting. I've been in spaces where I've been the junior person, and you want to make sure that you're not wasting time on a question. You want to make sure that you form your question as fully as you possibly can because you don't want to come in half-assed. You want to come in whole-assed. And when you come into that senior, you're like, "This is what I've done, and I need your help." You want to be able to lay your story out. And because again, this is your job. You're supposed to be aware even though you're new. But have having the ability to frame your problem in a way that one shows you're interested, two shows you've done some work and you've, you're not coming to them without having done your own homework. And three, that you're open to the knowledge that someone else has to give you. It's a very vulnerable position to be in, but I think the senior person would really respect the fact that you've done a little bit of a work, and knows how to frame that question, frame that problem effectively.

32:15 — Brent Simoneaux
So Kim, Johan, Angela, we have spent the past six episodes making our way through the software stack, and so I'm curious, what are big takeaways from this journey that we've been on?

32:33 — Kim Huang
Well, Stack/Unstuck has been an amazing experience for me. I've learned a lot of things that I did not know before about how apps are built and how software is built, and how the stack comes together. And for me, it's the fact that people rely on understanding the same things so much in software development. If you're on the same team, if you're on different teams, or teams working in sync or parallel with each other. But not everyone comes into that knowledge the same way. Some people come through different experiences or from different backgrounds. We've had people from working in the public sector, from people working in civic coding and just doing things on the side. We've had people going through boot camps or getting certifications on their own. There's so many different entry points, and we have to find a way to build a common language to share information, those experiences, and also lessons learned along the way.

33:37 — Brent Simoneaux
What about you, Johan?

33:39 — Johan Philippine
The thing that stuck out to me the most was this really interesting mix in, you have these really specialized positions and career paths where you can really dive deep into any one aspect of the stack. But on the other hand, you also have a lot of people who move between the layers, and they'll do the front end for a while, and they'll move onto the database, or they worked on frameworks for a long time, and then they move onto the operating system. So even though these paths and these different layers are so specialized, there is enough room for people to switch around a lot more than what I was expecting to hear.

34:20 — Brent Simoneaux
As we've gone through each of these episodes, I've had Jameel in my mind. So if you remember from the first episode, Jameel was a FedEx driver who was trying to break into the tech industry. And I'm curious, Angela, I think a lot of our audience is in that same place. They're newer to tech. What should they be taking from this series?

34:52 — Angela Andrews
It is my hope that what their takeaway is that we don't have this all figured out. That's the first thing. You would think that everyone is so experienced and they have all this knowledge, but as you can see, especially in this episode, we're still trying to figure out how to communicate effectively. We're still trying to figure out a lot of the basic things because having a common language that can speak to our newer folks and that our more seasoned folks can contribute to, those are the things that they should know that that never is going to go away. Some of the main things, and these are the themes that I've seen across, and starting with Jameel and his hunger to be in tech and his curiosity, and how he was communicating and networking with people that he was delivering packages to. Those are the things that we're constantly going to be doing throughout our entire career, staying curious, always communicating effectively, and also being empathetic to people who are more junior or more senior because the isms exist and we have to be very mindful of how we're communicating with people. So, that's what you see across all the layers. You're seeing that people are inquisitive. People are always willing to learn new things. They're not afraid to learn new things. How are we communicating with people that we're working with? These are constants that'll always remain in tech. And tech is open. There's always room for more people to make their way into it, because we love you here. We want more people like Jameel to join us, because they're hungry and they make it worth doing. So I loved this episode. I loved all of these episodes and I'm glad y'all did this. Stack/Unstuck was a great idea. It was a great idea. And that does it for this episode of Compiler.

37:07 — Brent Simoneaux
Today's episode was produced by Kim Huang, Johan Philippine, and Caroline Craighead. Victoria Lawton provides us with everything we need from A to Z.

37:20 — Angela Andrews
Our audio engineer is Christian Prohom. Special thanks to Shawn Cole. Our theme song was composed by Mary Ancheta.

37:29 — Brent Simoneaux
The big thank you to our guests, Mike Anello, Ryan Singer, and David Van Duzer. David, along with a few other Red Hatters, are actually building a game to teach the basics of the software stack. You can play through it, or better yet, you can help build it. Check out our show notes to see what they've done so far.

37:52 — Angela Andrews
Our audio team includes Leigh Day, Laura Barnes, Stephanie Wonderlick, Mike Esser, Nick Burns, Aaron Williamson, Karen King, Boo Boo House, Rachel Ertel, Mike Compton, Ocean Matthews, Alex Traboulsi, and Laura Walters.

38:10 — Brent Simoneaux
If you like this series, share it with your friends. Go ahead and rate the show, leave a review, follow the show. It really does help us out.

38:20 — Angela Andrews
We love that you listen. Keep on listening. Until next time.

38:24 — Brent Simoneaux
All right, we'll see you then.