Mandy MooreRelicans host, Rachael Wright-Munn talks to Senior Software Engineer, Aaron Marks about analyzing data and making data make sense, teaching data analytics, and accidentally automating himself out of a job!
Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you're going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you'd like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.
Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.
Rachael Wright-Munn: Hello and welcome to the Polyglot. Today I'm talking with Aaron Marks who's a senior software engineer at National General Insurance. He moonlights as an instructor at Louisville Central Community Center, teaching data analytics as part of their Rapid Upskilling Program. So, Aaron, I'm going to be honest here. I'm a software engineer. I've been one for a long time. And I've heard the term data analytics. I'm going to assume it has to do with analyzing data, but I'm also going to assume there's more to it than that.
Aaron Marks: Definitely because it's not just analyzing data; it’s making data make sense. And in most cases, it's making it makes sense so that we can do something about it, whether that's within your organization you're crunching budget numbers or what have you. And that gets you some sort of sales targets you need to meet or maybe even layoffs you have to make. Or if we're dealing with even social justice concepts, we can analyze the data that we find publicly available, and then that helps us not only identify our problem but we have evidence of that problem. And now we can act on it. And of course, data analytics even go so far as to prescribe certain things that you can do by just by crunching the numbers right.
Rachael: When you say prescribe certain things that you can do, do you mean make recommendations about decisions inside of an organization or even decisions for a city or country?
Aaron: All of it. When I say prescribe, what we do with that is in prescriptive analytics; we answer questions about what should be done by crunching the numbers and seeing what happens when we do it. Even local, down to our own homes, when we're building our budgets, we can do analytics on our own budgets to say, "Hey, what happens if I pay off this credit card, that credit card, these student loans, whatever, whatever and I throw 10% of my money into savings? What happens then?" Well, that means at the end of 2023, we have $45,000 in savings and no credit card debt, and potentially a very good credit score. Maybe it's time to go buy a house. So that's what you do with prescriptive analytics is you literally ask the question, what happens if?
Rachael: You're saving money. You're hoping to get that $45,000. You're hoping to pay off your credit card, but there's always going to be some sort of standard deviation. There's always going to be some variance in the amount or the results that you're expecting. How does data analytics account for that?
Aaron: Well, I honestly don't have a good answer to that. We can assume that life will happen. And so maybe that's part of our what if? We say, "What if I do all this but then lose my job in three months? Or what if I do all this and then the housing market goes berserk?" And the next thing you know, that $200,000 home you were saving for is now $450,000 with no inspections, that kind of thing. So we can definitely get into that granular level. We start with our baseline assumption of this is the problem I want to fix, and this is how I want to fix it. Let's see what happens. And then we add on --
Rachael: Uncertainty.
Aaron: The uncertainties, exactly. What if?
Rachael: That's really interesting. And certainly, in this market, it's easy to lose a job.
Aaron: It sure is. It's also easy to watch that house that you really want go up in price by $200,000. Ask me how I know.
[laughter]
Rachael: Oh no. I want to ask a little bit about how you teach data analytics to students and how you coach them, and the problems and projects that you help them solve.
Aaron: Well, honestly, I follow it the same way a science teacher would. I run them through the scientific method. I say, okay, so you observed this thing. You see this thing going on, and you haven't collected any data. You just see this thing, and you have questions about it. Well, let's ask the question and then come up with a hypothesis. What do you think is happening? Once you've got that, okay, so I found this problem, and I think this is why. Then you grab the data because anything in science has to be proven. You can't just go out there and say, "Oh, the sky is purple." Well, yeah, it might be but prove it. Tell me why it is and show me some evidence. And that's going to be the case with anything we do in data analytics.
So we come up with our hypothesis, and then we say, okay, what does the data tell us is happening? Why is the data telling us this? Because sometimes, the data tells us bad stories, and that's because it's bad data. Oftentimes, there will be cases where data sets are incomplete. They tell you the wrong answer because you don't have all the data, or they can be intentionally incomplete, which was an accusation that came up in the class I teach.
Rachael: Really?
Aaron: Where perhaps some of the data had been omitted because it put the source of that data in a bad light. And so there were questions about that too. But we do the best we can with what we've got. Data is valuable, and some people don't make all of it available. Sometimes data is a trade secret. It's intellectual property. They're going to hide it.
Rachael: That's really interesting. I remember a story that was similar to that with Florida's COVID numbers. What happened in the classroom?
Aaron: Well, so this was (and we don't have any proof) just an accusation that occurred. One of the teams of students was working on a project where they were trying to get to the bottom of the practice of redlining as it occurred in Louisville, Kentucky. And so to do that, they focused first on the current, the present-day impact of that practice by grabbing all the data they could about foreclosed homes, homes that were sold in an auction because of taxes in arrears, things like that.
And what they found didn't match what they felt like was their lived reality. They couldn't quite, with that data, substantiate every claim they were trying to make, and they felt like something was off. And so they even reached out to the various data sources and just asked, "Hey, is this data complete? Has there been some data entry issues, things like that?" No accusations, it's just, "Hey, it seems like this might be off. Could you help?" They did the best they could to maintain that line of communication and sort that out. But in the end, it wasn't strong enough.
Rachael: I see. That's very, very interesting. What other sorts of projects have your students worked on?
Aaron: That was the best one that I had right there, the one on redlining. I loved that project and the other projects I don't remember. That one was so good. It literally blew our minds.
Rachael: [laughs]
Aaron: As an instructional team, we had a meeting after the fact, and me and our lead instructor, the fabulous Dr. Haleh Karimi, who also used to be my department chair when I taught at the university; she and I talked. And I was like, I don't even know what the other presentations were about. I'm still in this redlining data. I'm looking at their maps. I'm reading through their dashboards. I'm going to the sources that they cited. I forgot. [chuckles] And that's awful because everybody did an amazing job, I do remember that. I walked away from that class feeling like an amazing instructor, especially since I was a last-minute addition to the team. But I got nothing. [laughs]
Rachael: So you've mentioned a little bit about the visualizations. You've mentioned the data sources. What is it that makes up the data analytics?
Aaron: That's really it. You've got your data, and you've got the questions you ask of your data, and you've got the way that you present the data or the answers to your target audience.
For my team, it's an entry-level data analytics course. We're not getting into statistics and the really icky math that happens. We're getting into CSV files full of sales information or what have you. And then we're getting into okay; what is this describing to us? So we get into the descriptive analytics. We say, hey, can you create a dashboard for me that describes the current situation? And then we take it again. And we're like, all right, can you create another dashboard for me that shows me in ways that I don't have to know the data to know the issue? Can you show me diagnostic analytics on this? So why these things happen.
Then, later on, get into predictive analysis, and we say, hey, can you tell me based on the data that you have and the questions you've asked what might happen in the future because of this data? What are the trends? What do they look like?
And then finally, especially with that one case, we get into prescriptive analytics where we say, okay, what should be done? What happens if? How do we fix it? And that's the basis. I know there's a lot of science behind it, and some data scientists will probably be very upset to hear me describe their whole career as what if? Here's some data. And that's not what data scientists do. They dig so much deeper than we could possibly get into in one of these courses.
Rachael: But you're right. That is an easy way of breaking it down into four different components. You've got what it is today with descriptive analytics. You've got predictive analytics; what will it be tomorrow?
Aaron: Well, there's diagnostics. So, why was it like that today? And then there's prescriptive. How can we make it happen tomorrow? So it really boils down to what has happened and what are our goals? And I think that those are good questions for any of us that are doing any kind of introspection or analysis on any part of our lives, whether it's our organization's data or what we want to be when we grow up.
Rachael: You're right. It can inform us a lot about our personal lives. Do you have any data analytics projects that you'd like to share with us?
Aaron: So in 2019, at the ripe old age of 36, I completed my master's degree. And I'd like to tell people that my master's degree was in being broke.
Rachael: [laughs]
Aaron: It was in poverty science.
Rachael: Oh, what? [laughs]
Aaron: Well, so I go out, and I get this master's degree. Now at this point, I'm already a developer already working in tech. So why am I getting this master's degree? Why am I spending $40,000 to not get a single increase in pay? But it's also a double-edged sword because the capstone project for my master's degree was a budgeting app, a budgeting app that really calls back to my roots.
When I was younger, we grew up poor, like real poor. And into my young adulthood, before I got into tech, so really up to about ten years ago, I was still broke. And when I say broke, I mean seriously like, debit card pre-authorizing your last dollar in your checking account two days before payday, so you get a tank of gas to get to work hoping and praying that your check clears before that transaction hits.
And it hit me, I'm like, wait a second, I've got this magical career already under me, and I'm building credentials to make it even stronger. And my career is to take zeros and ones and, as if by magic, turn them into useful things. Well, why am I not making this useful? So I'm like, okay, so I have a history of working with marginalized groups in classrooms and whatnot. I have a history of being economically marginalized, and I automate things for a living. So let's think about that.
So I created a budgeting app, and the budgeting app is one that realizes that sometimes we have to rob Peter to pay Paul. So it starts off with a survival budget. It asks you not what you need to pay as far as credit cards and all that other stuff that's not going to leave you homeless and hungry. We're talking about the essentials: your rent, your light bill, your water bill, your grocery budget, maybe your transportation to work. That's iffy. It's up to you. And then once we've got that, that's your survival button. That's your panic button right there. That's where you can say; you know what? Things are getting really, really hard, and I'm having trouble doing all the other things I want to do, but I need to know this is secure. Let me smash the panic button, take my budget back to those roots.
After that, we would set up a current budget, which is your survival plus all the other things you need to pay like the credit card bills or student loans things like that, things that are not integral to survival, but they are integral to eventually getting out of debt and building wealth, so we do that.
And then, over the course of time, people who use this app, they'll focus on paying for their survival stuff first. It uses an algorithm to look at exactly what they've got due, and when it becomes due, it says, "Hey, if you're struggling to make this bill, this bill here can probably be pushed off by three days to give you a little space to pay that bill."
As they grow, we start integrating things like debt repayment like tackling debt Dave Ramsey style, Snowball Method. So we start with the biggest, most expensive, most nasty interest rate having debt. We pay that off first, and then we snowball those payments into other things, and we get you out of debt. All the while, you're building a better credit score. We integrate some savings in there once things seem comfortable.
We've done all these things. Well, guess what? Now we've set you up for wealth instead of just getting your paycheck on Friday and seeing it disappear by Sunday because you've paid all your bills and you have nothing to show for it. Now you've got all your debts paid, or at least most of them. You've got sizable savings. You've got a decent credit score. Now you can go get those things that we call wealth in the society, so buy a home, make investments. Maybe you've already got home. Maybe you were fortunate enough to have one given to you or left to you in a will or something like that. Maybe you're okay housing-wise. Okay, fine. Then you can do some investing. You can start throwing that extra money into IRA, things like that.
And so this app attempts to start bridging that gap so that you can start off with full acknowledgment that right this second, things are bad, and we're going to dig you out of that. So it's not Mint. It's not You Need a Budget. It's not just here's what you're doing in two weeks. It's not here's what you're doing this month. It's here is how we're going to get you out.
Rachael: That is incredibly impressive. I've used Mint for a long time. And I have to admit I've not been in that situation before, but I can see how you're talking about economically dealing with things from that perspective. And that comes from your own unique perspective and lived experience as somebody who's had to climb out of that debt.
Aaron: Absolutely. And the thing about it is that this app that I'm building it's not about making money. I never intended to make money off of it. It's a passion project that I hold in my back pocket for those moments when I just need something to do that makes me feel right. So it'll go out there. I might deploy it on Heroku one of these days; just hand it out, do your thing. And when it's all said and done, if you decide to leave that app, well, you haven't paid anything for it, and that's fantastic. You're also giving me feedback on how I can make it better to match more lived experiences, and then you move on. That's fine.
If you go to Mint or you go to Quicken or whatever you do, that's fine. But here, let me even make it easy for you to take your data with you because that's your data. I don't want it. I'm going to delete it when you go. You should have it before you do because it's none of my business if you're not asking me for help. So I just want there to be a bridge so that people can participate in our economy in a way that makes them feel confident and lets them have the things that they've worked so hard to get.
Rachael: Yeah, because financial insecurity can happen at any time, whether it's losing a job, catastrophic medical expenses, or losing a home.
Aaron: Definitely. And I mean, these things happen even to those of us in positions of privilege. We get hit with a collapsed lung on a random Monday morning and spend a week in the ICU. Those things happen. They come with bills, and it sucks. But when you have financial privilege, when you've built some wealth because you've been given a platform to at least stand on and feel stable long enough to start doing your own thing, then okay, let me pay these off. It's not anxiety at that point. It's like, oh gosh, this sucks. It's eating into my savings. I may not be able to go buy that Tesla or whatever, but we can handle it.
But before we could do anything else, we've got to level the playing field and start helping people up to that spot where we can acknowledge that, yeah, the American healthcare system is a complete dumpster fire and then help them prepare for that. Acknowledge it for what it is.
Rachael: That makes sense, to tell the automated my job away story.
Aaron: It's funny you mentioned that because when you automate your job away, there's another place where financial insecurity comes into play.
Rachael: When you automate your job away?
Aaron: Mm-hmm. Absolutely. So you're minding your own business. You've just escaped the call center industry, and you finally got your first job that's kind of in tech. You're working as a sysadmin for an outsourcing company. And their client has asked that they assign someone to the task of pulling down all of their users out of Active Directory. And this is a big client. This is not a joke. It's a huge company, 2,500 users in these domains.
And you pull them all down into an Excel spreadsheet, and then you go over to their identity management suite, and you do the same thing. And then you match them one for one to make sure that every user has only that which they're entitled to. It's a nice little identity management audit, and that was my job. And it paid really good compared to the call center. I think it was a 50% bump for me. And it still wasn't tech money, but I was good.
Rachael: Yeah, that's office money.
Aaron: But then I realized this was 30 hours a week of me staring at Excel, writing VLOOKUPS. It's all it was, VLOOKUP, copy-paste into a command prompt. We're done. Meanwhile, I've got other things that I could be doing too. I can be more helpful to the organization. So let me take this tedious thing that's eating up 30 to 35 hours a week to do it once. I've written some code before. Let's just automate it.
Rachael: Whoa. Okay.
Aaron: So it starts off with me going back to my old school roots. I grew up learning BASIC; that was my thing. In the late '80s, early '90s, I was on a Commodore 64, had BASIC all day. Well, I let that go. I let it sit and get stale for the longest time. And it wasn't until that job that I actually started writing code again for a reason. Otherwise, it was just "Hello, World." And I was stuck in that tutorial limbo.
So I pulled back my BASIC roots. And I said, you know what? Visual Basic for applications exists. Let's Macro this out. And so I took this thing that took me 30 hours to do and automated it to the point where I could hit play at 8:00 a.m., and it was done by 4:00 p.m. All I had to do was copy and paste some changes.
Rachael: Wow.
Aaron: That wasn't enough. That only freed up eight hours.
Rachael: [laughs]
Aaron: I needed more. I needed much more. I really wanted to get this down to where I could overkill it. So I completely scrapped the Visual Basic. I also scrapped the whole Excel concept. I wrote it as a C# desktop application.
Rachael: Okay. So you built the C# desktop application, and it goes to Active Directory. It pulls in all of these. It does a VLOOKUP, you said, into the identity management solution and makes sure that everything is synced up.
Aaron: Yup. And so, the C# app would do all of this. And it would handle all these users. It would automatically make the changes that I had previously been copying and pasting into terminals, and it would generate a report, and it did it in an hour. And I ran it daily instead of weekly.
And so I ran this for a while, and I built this. Nobody told me to build it. I was just like, if I'm going to spend 35 hours doing tedious stuff, let me automate tedious stuff. I'm still doing it in 35 hours. It's still getting done, and this is just tedious. So I did it.
A couple of months later, after this has been running and running and I'm sending out daily emails, all of a sudden, I'm laid off.
Rachael: Noooo.
Aaron: Now, in their defense, this could be correlation and not causation, but I have a distinct feeling that this was a correlating situation where I had automated myself out.
Rachael: But did they have access?
Aaron: They did not. That was the thing that they messed up.
Rachael: [laughs]
Aaron: So this goes on. And so they lay me off. They give me a week's notice to say, "Hey, you got this week to work. And after that, we'll try to find something else for you, but good luck. God bless."
And so I spent three months unemployed. My budget took a heck of a hit. Thank goodness for a little bit of unemployment insurance, but that was back to call center money. Things were very, very scary. And it was a few months after that I got my first job as an actual developer. In the background, while all this was happening, automation and whatnot, I was working on my bachelor's degree. I was also completing a code bootcamp that was done through a labor program in Louisville. It's called Code Louisville. I was doing all these things, and one plus one, plus one, plus me being unemployed, all of a sudden led to me accidentally getting a junior developer position, and the rest is history.
Rachael: That's a great story in an interview. I automated myself out of a job.
Aaron: Heck yeah.
Rachael: I built this full C# application. [laughs]
Aaron: That was almost ten years ago. I still tell that story because to me, that's like the high point of my career when I said, you know what? Nobody told me to, but I'm going to do this thing. And oopsie, I put myself out of a job for a good reason.
Rachael: So you can move on and do better things.
Aaron: Absolutely. And so again, we come back to what kind of hit that did to my budgeting, and it was not pretty. But it did give me the space to start working on future plans. So now I get to be a developer. Oh, I'm going to finish my bachelor's. Oh, I'm going to get my master's. I'm going to teach. So wait, I go from a poor call center employee with a GED to all of a sudden, I'm teaching people at a university? How's that happened? Not bad for a poor, working-class guy like me.
Rachael: It happened through a lot of hard work. You worked hard. And now you are at the Community Center explaining things to all of these new data analysts in plain English.
Aaron: Absolutely. And I think that's the most important part is that in technology, like any skilled trade, we have developed a specialized vocabulary that describes the complex things that we do in simple terms for those of us who are familiar with the trade. So if I look at you and I say, "Recursive algorithm," you know what I'm talking about. But what about the junior dev behind me or those people who say things like hierarchical decomposition when what they really mean to say is break stuff down? And that's a whole lecture I get into with any class I teach is that people will use technology and terminology within our trade to gatekeep either intentionally or unintentionally. Sometimes it's accidental.
And I start off by getting into this lecture, and I'm like, all right, so today we're going to talk about hierarchical decomposition. And my students immediately panic because never in my text or in my syllabus do I mention it. I do that for a reason. I want them to be a little anxious. How could they have possibly been prepared for that?
So then I explain what that term means, hierarchical of, or pertaining to a hierarchy. So you're dealing with a set of interrelated components, so things that work together to build a whole, cool. And then you've got decomposition, the process of breaking things down into their constituent parts, so breaking the whole back into its parts. The whole purpose behind that phrase is to break stuff down. So, why don't we say it that way? Why do we have to flex a $10 term to make a $2 point?
And so we don't get into it to actually dig into hierarchical decomposition because once you remove the mystery behind that and get it from behind that $10 phrase, anybody can do it. We can break things into small bite-sized pieces, but sometimes those terms are helpful. So again, we come back to recursive algorithm, and if I say that to you, you know what I'm talking about.
But now we have a reason to think about what is the impact of us using that specialized vocabulary in our everyday conversations? If we say recursive algorithm, you and I get it, but what about the junior devs behind me, in front of me? We want them to learn too because our job as a developer is not just to write code and do stuff, but it's to serve as mentors and educators to those who are starting to do what we're doing now. So we had these conversations.
Just like even on this podcast where you talk about technical concepts. And I understand that we're talking about mid and late-career folks here. But we all need to know these things. And sometimes, even those of us who are 9, 10 years in, we don't know some of these terms because we've gotten away with not knowing.
Rachael: I'm nine years in, and nobody has said hierarchical decomposition to me. And I'm just like when you said that, I was like, yes, hierarchical decomposition. That's what we're going to talk about. Most of the time, I have to pick stuff up from context.
Aaron: Yeah, but that creates unnecessary anxiety for you because you heard that phrase, and it's intentionally a $10 term for an intentionally $2 concept. It's done not to actually have something, although it's great at parties if you want to flex.
Rachael: [laughs]
Aaron: It's really all about shining a light on how absurd it is that we use these big terms to describe these simple concepts if you think about it and how that denies our audience, whether we know they're listening or not, access to that information. It creates that anxiety. We have enough problems with imposter syndrome in tech. Let's not create more reasons.
Rachael: That's true. I think that tech necessarily breeds imposter syndrome because there are constantly new techniques, new practices, and nobody can learn all of them. So, in essence, what we're doing is saying you must be knowledgeable about all of these things in order to be successful in your job, but you don't know what your code will be used for in the future. You don't know what the current technical practices are. You can't know about all of the current technical practices that are happening. Nobody knows the full language specification, or if they do, that's all they know. There are constantly new libraries.
I think it's very difficult to exist in tech without at least some sense of imposter syndrome because people expect you to know all of that. They expect you to give an opinion with all of that. They expect you to build something, and you know that you only know 10% of the thing that you're building.
Aaron: Absolutely. And I think we all go into tech this way. I made the mistake of answering a couple of questions at work about Angular, and now I'm the Angular guru. Y'all, I'm a fraud. I don't know what's going on.
Rachael: [laughs]
Aaron: I've said as much to the team who called me their Angular guru. I'm like if I'm your guru, y'all got lied to. You got sold a bill of bad goods. I am competent in it. I'm nobody's Angular specialist. I'm definitely not anybody's Angular developer advocate. I'm just not. That's not me yet. I'm getting there. And we all feel this no matter where we are in the stages of our career. Some of my mentors in the field have been out here for 25, 30 years. Sometimes I say things, and they're like, what? I didn't know that. We all don't know. As software engineers, our level of seniority is not determined by what we know. It's how efficiently we can use Google to find the answer.
Rachael: [laughs] There's definitely something there. I want to go back to recursive algorithms because hierarchical decomposition, yeah, that's got the same number of syllables. But I was thinking about how I would describe a recursive algorithm in other terms. We need to build an algorithm where the main function that uses it calls itself. And we have an end case that allows us to escape it.
Aaron: You just did it. That's the answer. A recursive algorithm...so an algorithm is a recipe, how to do a thing, a set of instructions. Recursion is just calling yourself, doing the same thing, calling yourself to an extent. And then you're going to have that sentinel value, or that base case, that stop value. That's a recursive algorithm.
Rachael: I agree. And if we're explaining what recursion is, we can do that. But I'm just imagining sitting there in a meeting and being like, "Hey, why don't we use a function that calls itself with a base case that allows us to escape in order to solve this problem?" versus saying, "Why don't we use recursion?"
Aaron: Well, and we can do that if we know our audience. But if I've got two junior devs sitting next to me, both of whom have completed bootcamps, they don't have the benefit of a CS degree, which, full disclosure, neither do I. Then I am going to tone down the experience level required for me explaining things. So instead of saying recursive algorithm, why don't we use recursion? Why don't we just use code that calls itself? Why don't we let this situation just handle itself in that way? And that works. Or if I really want to use recursion, if I really want to use that $10 term, fine. Follow it with a $2 description.
So hey, how about we use some code that calls itself? Maybe we can go use a recursive algorithm. Now I've defined it, and I've used the term. We all have a common understanding of recursive algorithms. So I don't have to say code that calls itself repeatedly. I can definitely dig in in a sidebar and say, "Hey, this is code that calls itself. It usually has some sort of condition under which it will stop. Otherwise, it will overflow the stack, and things will crash, and everything will be on fire, and it will be bad." And I can explain that later because that gives my junior dev enough context to know, hey, I kind of understand this, but I need more context, and that's the guy I need to ask about it.
Rachael: That's interesting. I can see that you could offer an explanation, especially if you know that there are junior devs in the room that might not know the answer. I personally favor "Are you familiar with?" and then the $10 term.
Aaron: I love that. You know something else, though, is there are a lot of senior devs who may not quite know this terminology either and especially in technical interviews. Let's be kind to our senior devs. Many of us are...we're fairly talented at various levels with what we do, but we have anxiety, and we feel like frauds. So let's be kind to each other.
How about instead of saying recursive algorithm and just leaving it there, throwing it on the floor, how about just going ahead and saying, "How about we approach this in a way that the code can call itself? We can use a recursive algorithm to sort this out." Again, that same definition but with a different audience, and it's not meant to demean them or make them feel like, oh, you don't know things, so I'm going to explain it to you. It's meant to make it open, friendly, and accessible to them so that if they are one of those senior devs who come from a non-traditional background, they know what you're talking about without looking like a fraud. You've removed that possibility because whether they understood you at recursion or they understood you at code that calls itself and made that connection in their head from some long-lost system architecture class they took five years ago, they have answers for you. And no one looks like a fool.
Rachael: Maybe we just need better terms.
Aaron: Absolutely.
Rachael: Just thinking about this, databases have amazing terms associated with them. If you're talking about a relationship where you have one object and many objects on the other one, it's a one-to-many relationship. If you got two Joins attached to one table, that's a Cross Join.
Aaron: Yeah, absolutely.
Rachael: Maybe the problem is the source of our terms is wrong. [laughs]
Aaron: In databases, we deal with many relationships where you've got many things that will have many other things. Well, guess what? Now you build a relationship table. You talk about those relationships, and there you go. It's done. Now, I know there's a more technical term for a relationship table. I can't remember what it is, and I don't care. It's not accessible to a general audience. It's accessible to those folks who are really good at databases. I am not one of them.
Rachael: It's about experience, right?
Aaron: Absolutely. And we have to go through these moments of oh my God, I'm a fraud, or I don't know or just, I don't know. And it happens in all of our careers. Heck, my first development job, they hired me because I had some baseline competency in writing C# desktop apps, as evidenced by being unemployed.
Rachael: [laughs]
Aaron: And so my first day they gave me my own office. I was already in awe. They showed me my offer letter. I was definitely feeling some sort of way. And then my boss comes in, and he's like, "All right, I need you to take this classic ASP web application and turn it into an MVC app." And I looked at him, and I'm like, "What the heck is an MVC?" And I felt like a fool. But I learned from that day because I googled it. And then, I googled it in the context of ASP.NET, and I googled it in the proper context. So I started putting the pieces together. I broke it down into little bite-sized things that I could manage, and he got what he asked for.
Rachael: We should normalize asking those sorts of questions. I feel like that's the real issue because I can't guess what your prior experiences have been. And I don't mean you in the you personal sense, but you in the grander sense like the plural you. We can't guess what experiences another person has had, and this is something that I strongly believe. I believe that whether something is easy or difficult depends extraordinarily on your previous experiences with that topic.
Like, when I think about databases, I think about my intro to databases teacher, who did an extraordinarily good job explaining them. When I think about my searching algorithms, I still remember Dijkstra's because of the teacher I had. When I think back to information security, I remember the professor who told me, "No, you can't use a dictionary to figure out what the result of this–– is going to be. And I don't remember anything about information security.
Our experiences define what is easy and difficult for us. There's simple and complex, right? The problem can have a simple solution or a complex solution. But it's really about prior experiences. And we need to normalize that all of us are learning on the fly and what jobs we've picked up, what experiences we've had, strongly influence what we know and don't know.
Aaron: And this is why during all the interviews that I do for development teams and eventually when I join the team I implement, is I have a principle of not creating a learning environment. That's insufficient. We're going to create a teaching environment. We're going to create a space where A, I can say, "I don't know. Can you help me?" B, "Here's this thing that I learned," and C, "I am excited to tell you about it." So now we make space for I don't know. We make space for gaps in our experiences as technical professionals. And we also start building a proven track record of mentorship and being an educator, which in turn looks great on a resume and creates other career paths. So now you take someone who's spent 9, 10 years with teaching classes and being a senior dev and teaching less experienced devs what's going on. You take that proven track record, you put it on a resume, and you say, "Hey, I can be a developer advocate. I can do DevRel."
And I've talked this over with one of your colleagues. Y'all have too much fun for what you get paid, and it's not fair. I want to join you. [laughter] But seriously, because we've taken the time to build this environment where it's safe to say, "I don't know." It's safe to say, "Why?" It's safe to say, "How?" And we also built the environment where we're open to just let's talk about it. Let's explain it. And we meet people where they are. Some folks I can talk to, and they understand. Other folks, I got to show them, and that's fine too. We build that.
And then we open up all these career possibilities for us when we're no longer as enthusiastic about a particular tech stack or a particular type of development that we do. Maybe we want to escape .NET and go to Rust. Maybe we want to escape being an IC dev, and we want to get more into helping other devs be good at their job. Now we've done it. We have a proven track record. So everything all ties back to where because you foster positive, happy teaching environments. Now you can do bigger things with your life too.
Rachael: That's so true. And you're right; my favorite workplaces that I've worked at are ones where I was able to learn, able to grow, and able to ask people questions.
Aaron: Absolutely. Those are the places that encourage us. Those are the places that when we leave, it hurts. Those are the places that, honestly, sometimes when we find ourselves in a bad place, in a new job, like years down the road, we miss them. And we think about maybe I should go back. That's how you retain employees. So when you allow that environment to exist within your organizations, not only do you help them be better versions of themselves and more productive to your org, but they love y'all so much because of how welcome and safe they felt in that space. They'll come back, but you might not be able to get rid of them.
Rachael: [laughs]
Aaron: And in tech, it's pretty tough because, in tech, we tend to hop jobs. What if we build environments that people actually say, "You know what? I'm going to leave to branch out. I'm coming back." Wouldn't that be wild?
Rachael: Yeah, it would be. I want to thank you so much for talking with me today. This has been an absolute delight, everything from your stories about automating your job away to your insights into technical jargon teaching and imposter syndrome, and of course, everything that I've learned today about the different types of data analytics and the foundations. Because to be honest, I started this podcast where I think we've kind of come full circle. To be honest, I started this podcast not knowing what data analytics meant, and now here we are.
Aaron: Absolutely. Well, I'm glad I could help.
Rachael: Thank you so much.
Aaron: Thank you.
Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. We'll see you next week. Take care.
