Episode 103: Adrienne Tacke on Beating Imposter Syndrome

Brian Dawson: Hello. Welcome to another episode of Dev Ops Radio. I'm Brian Dawson and I'll be your host for a conversation with another fantastic guest, Adrienne Tacke, a senior developer advocate at MongoDB and today we'll be talking with Adrienne about everything from serverless or from durable functions in serverless environments to coding for kids and Python to diversity and her Filipino heritage. So I'm really looking forward to a wide ranging and fruitful conversation. Adrienne, hello.

Adrienne Tacke: Hi, Brian. How are you?

Brian Dawson: I'm doing well. How are you doing today?

Adrienne Tacke: I'm great. Happy to be here.

Brian Dawson: Awesome. Awesome. All right. I am excited to dig in, but before we do, to start as usual on Dev Ops Radio, can you please give me and our listeners a brief overview of what you do today at MongoDB, what is a senior developer advocate really, and then what's your career background? How did you get to where you're at today? What was the journey?

Adrienne Tacke: Sure. So my day, a typical day as a senior dev advocate at MongoDB is a whole number of things, but it could be anything from creating content for YouTube or Twitch or a blog post to helping prepare for events to going back to our product teams and getting a lot of the user feedback to them so they can fix some things or improve some things or integrate new features. And that's kind of a mix of a whole bunch of things every single day. So it's always different every single day. It's always entertaining.

Right now currently we're preparing for our really, really big conference. It's our biggest conference, Dot Live. And so everything is just revolved around that conference right now. So that's kind of my life right now. But how I got there is – the quick whistle stop tour is I needed a job to pay for college and at that time my major was a pre-international business major because I thought having that major was gonna give me a job like Anthony Bourdain, but I figured out that that doesn't correlate. So I was like, "Oh, no. I need to find something else," but I didn't know what to do.

And at the time I needed to find a job for college. The highest paying one was for a student technician at the IT help desk at the university. So I'm like, I will go there. So I did that and that's how I got into problem solving, troubleshooting, helping people. Then it was through that that I learned about the other departments and other places in tech and which is where I also got a software development internship. So that's really what kickstarted how I got in there.

With that I also switched my major to not CS, but management information systems. So it's like a half business, half CS degree. That proved to be very fruitful. I graduated and worked at the university as a full time software dev for a while and then I did a bunch of different jobs around small and medium sized companies in Las Vegas as a .NET developer, C sharp developer. Then right before this job I actually quit my last job because I was doing a bunch of conference talks and I loved it so much that I was just focusing – I like to say I was doing dev rale for myself.

I wasn't doing it for anyone. I was just kind of – I wanted to apply to conferences and talk about stuff I was interested in and would have built and through that and sharing those experiences was what caught MongoDB's eye and that's how I ended up at MongoDB doing dev advocacy, which is thing I didn't even know existed.

Brian Dawson: Well, that's fantastic. So it's funny. I had three questions I was gonna ask you that you answered. Your response was so clear and comprehensive, but I managed to develop a couple of other questions. I wanna dig in on career. First of all, from your standpoint, especially not even knowing this role existed, but happily transitioning from being a developer into this role, and it's a role that I'd say if we flash forward in five years, ten years you're not going to see anybody that doesn't know of the role dev rail or dev advocacy. So in your opinion and based on what you've learned now that you're in the role, what is the importance of it? Why is it needed? Why do we have it?

Adrienne Tacke: I think the most important part and I think the part that resonates with me the most is like it's a direction connection in relationship to other developers. So I'm a developer by background. I didn't start with all of this content creation or talking at conferences. Those are all avenues of teaching and of sharing knowledge with other devs. But I think a really important part of it is first of all understanding the pains and the pressures and the difficulties of learning whatever it is that you're learning. There's so many new things. There's a lot of complicated things.

There's work flows of everything that you need to learn to be successful. It's super overwhelming. I, myself, am – I feel for everyone who is starting out and who chooses that because there's so much more than when I started. So knowing that and understanding that pain and understanding how difficult that is, I feel that a super important part is to empathize with that and know that now that you have that knowledge or have a better understanding of how to get the knowledge that you need, I feel that's our responsibility to help share that and make the developer – not only the developer experience better, but to do it in a way because you've literally had your shoes in those person's shoes. You wanna make it better for them. So having that background, having gone through all that stuff, I think that's gonna be one of the most important parts of this role.

Brian Dawson: Yeah. There's so much I wanna unwrap there in terms of my commentary. A couple of things I'll hit though is what you're talking about solving, education, learning, and when we look at it from a commercial perspective is look, and just to use it as an example, we are no longer in the days of big blue where you had a 50 person sales team that when in at the top level, sold something to a company and then they figured it out. At the end of the day for Mongo, for CloudBees, for any software organization to, at least in our space, in the dev tools, dev technology, it has to be implemented.

It has to be implemented and it has to show value. That means that we're heavily reliant not only the business where developers are, but commercial vendors are heavily reliant on developers understanding the technology, understanding how to bring it to fruition, and it helps for us to help developers be better people, point one. Point two, and jump in at any time if you have a thought, is we did some research. It was really interesting. I have to throw away the fact that I was a developer by trade and we did a marketing lens research on developers.

And one of the biggest fears emotional was impostor syndrome, was there was so much to learn I feel like I'll never be an expert. I feel like I can't ask my teammates because my teammates know so much. There's this underlying, I know we're talking about impostor syndrome, but there's this underlying challenge to know everything and angst that dev's feel. I see you nodding. We're on camera.

Adrienne Tacke: Yeah. I can resonate with that a lot. Look, in the beginning and even until now, something that I like to share, I like to think that I've gained a little bit of wisdom being in here for almost ten years. But everybody feels impostor syndrome at every stage whether that's in the beginning because it's overwhelming and there's so much to learn, whether that's in the middle because you're like, well, I'm not a beginner anymore. I know I'm capable of larger projects, of more complex systems, but I don't think I have the leadership skills or I don't know how to architect a full system or whatever it is you consider as a senior role.

Then even at senior levels or director levels or whatever, there's always new challenges and there's always different things to learn. Even if you just stayed the course and you're like, "Nope. I'm happing being an individual contributor. I'm gonna stay a dev the rest of my life. I love building." There's always new tech to learn. So there's always something that's gonna be new and unknown and not comfortable because you don't know it. You're not well-versed in it and that's something that I wrote about in one of my blog posts, but impostor syndrome is normal at every stage.

I say that now more confidently that knowing that fact actually makes me feel much better. Before I felt exactly the way that you described. I'm like, "Oh, no." Especially as a woman in tech I'm like, "Oh, no. I'm gonna be found out that I don't know what I'm talking about. I'm gonna get kicked out." I didn't wanna ask questions because I felt like there was this persona that I had to show of like, "No. I know my stuff." Even now I sometimes feel that way where I think as you continue on and become more and more senior in career it's almost like there's this expectation of, well, you've been in there for so long. You should know everything. You shouldn't be asking questions.

It's taking a shift of the mindset to say it doesn't matter. You're actually better off asking the questions. You're more approachable. You actually learn a lot more by just asking the question. So that's still something I'm trying to practice today because there is a lot that I don't know. There's a lot I know and there's a lot of different subjects that I'm very well-versed in and passionate about, but there's even more that I do not know about and that's where we need other people to help.

Brian Dawson: And I think my couple of comments on it – put my old guy hat on – one of the – in game development, console development, one of the things I learned early on in my career is there's immense power in our space with the people we work with in saying, "I don't know." I don't know with an answer into how you're gonna find out or if you're in the right situation asking a question. But like you say, nobody knows it all and I think when we talk about dev advocacy, this hyper focus on community as we move into dev ops, that's the idea that we can crowd source knowledge. No one person has to have all the answers, right?

Adrienne Tacke: Absolutely. It's different for everyone and it's – you learn so much more when you just ask about different experiences and different implementations. It's a very core part I think of dev rail, but of tech in general too.

Brian Dawson: Well, and pretending to be Yoda here. I'm probably leaning in on my age a little early, but I'm gonna lean in on it. Even when you think you know, sometimes it's good to assume you don't. Flip impostor syndrome around a little bit and just ask questions. So this actually is a transition and I know I'm going off script for our guest. We agree on a list of questions that we're gonna walk through and then I usually blow my contract with our guest, which I'm doing that to Adrienne now.

I wanna talk about a couple of things. I wanna talk about Mongo and I wanna talk about the modernized representation of data in our software development delivery modernization movement. I wanna talk a bit about your heritage and how that's interacted with your career and then we're gonna get a little – then we're gonna get real. When the conversation gets real with talking about durable functions, serverless, and where that stuff relates. So first of all, can you tell us for those that don't know what is MongoDB? Why is it important? How does it help your dev's that you're supporting, for one of a better word? Can you tell us a bit about?

Adrienne Tacke: Sure. So MongoDB is probably the most known to people if they've ever started learning web development. You may have heard of the MERN stack or the MEAN stack, which is just a set of technologies that are used to build an application. The M in both of those is MongoDB and that's your database layer. So I, myself, come from a sequel background, a traditional, relational database system where you use sequel. You have joins. You put data in tables and there's relationships between them. There's one to many, many to many of the little diagrams of describing that.

That's been great. That's been working for a while. They're still in use. Where MongoDB is different is it's a different way of storing data and it's a different way of thinking about data. So MongoDB is what we like to call a document database. So that just means a lot of the data that you may have, instead of storing it in super rigid and strict tables you may store a bunch of related data together in a single place, and that single place is something that we call a document.

One of the biggest differences and one of the biggest benefits that we like to say about MongoDB is that if you do come from a relational background, that rigid structure of having data in tables that makes you have to think about data in a certain way. You have to have something called a schema. It's a set of rules of what your data is supposed to look like, what type they are, how they interact with each other, and with no sequel or MongoDB and document databases as one example, we like to say it's schema-less.

So there is no kind of rule there. There is a flexibility in your data. That's really important for lots of things. It's important if you're just starting out and you needed to prototype something really quickly. That can go all the way through to production apps where maybe your data is ever changing. And that's kind of the case for a lot of people and a lot of different industries. So having that flexibility is actually a benefit. If you've ever worked with relational data before, if you needed to add another column on to this table it's a whole ordeal. It's a big –

Brian Dawson: Schema migration. I'm trying to think of a clever analogy. I can't. But for those who have been there, managing schema versions and schema migration is a big pain in the – anyway. Back over – yeah.

Adrienne Tacke: Absolutely. And so that's one of the things that is gone from that. Now this isn't a golden solution. It doesn't work for everything, but it does work in a lot of cases where if you do have data that changes a lot, if you have a large scale of data, and if you need to fluctuate between the kind of data that you store, then it would be an option, a good option.

Brian Dawson: So fantastic explanation and being that we are Dev Ops Radio, can you help us understand. So no SQL has – with MongoDB being, I'd almost say at the forefront, no SQL has really taken off, right? It's taken off a line along with more rapid iterative development, more modern development practices. Do you see that continuing? What is the relationship between CICD Dev Ops modern software development and the rise of no SQL DBs?

Adrienne Tacke: I think it's definitely a plus when you think about how fast you want to deliver to customers. So in my understanding of continuous integration and continuous delivery, that's one of the whole points of why you do it and why you automate it. You wanna deliver value to the customer faster. Instead of waiting for a big bag release every month or something like that, if you have it a proper pipeline and in place you can deploy up to multiple times a day and fix things right away. So I think this type of data layer, it's less MongoDB specific and more about what works for the type of application that you have.

So having a MongoDB database as your backend, yeah, the flexibility might go hand in hand with that. When we did our gaming content, my co-worker, Nick and I, we were showing how to build a game in C sharp and MongoDB and one of the things that we really loved is that as we went through, like most people who start building things, we thought we knew what we wanted in the beginning. So we had a plan.

We laid it all out and then as we started to build, as we started to iterate and started to go build these different versions, we realized, "Oh, we actually don't need that data," or "Oh, we forgot this." So having that flexibility allowed us to continue that rapid development, which I think falls in line with that whole goal of CINCD of bringing value to the customer. So in that sense I don't want to say that you have to use MongoDB or any no sequel database to achieve this kind of flexibility, but it is an option and that's one of the biggest reasons why a lot of people do choose it is for that flexibility.

Brian Dawson: I think to that again, another I think great and unbiased explanation, one is – I'll go back. I'll site ratchet and clank developers, Naughty Dog, that had developed early on this practice if they write the game engine once – Andy Gavin. This was his mantra. And then they throw it all away because there are – there's a discovery process. I don't know what my data model should look like. I don't know what my object model should look like. Yes, there's places absolutely for relationship DB's, for as your form of persistent storage and there's a lot of variance.

As you called out, I may be half way through my development cycle before I realize that I need to extend a given class and I need a rapid high performant way to load it. Now I'm out mucking around with tables trying to figure out what else does it – so it gives a level of velocity. I also would beg to say, and you can tell me I'm wrong if I am or just nod your head if I'm right, is that as we have shifted to a, what I would say pizza size team, agile mindset, full stack developer mindset shift left, no SQL approaches offer the ability for a developer not only to get the feedback, but then to more easily incorporate those learnings as opposed to – and I will share a story of a large medical provider that shared with me. I believe just their ETL team, just their extract transform and load team is 600 developers.

Adrienne Tacke: Wow.

Brian Dawson: That's not even including the entire data team. So when we talk about velocity, iteration, learning, and feedback that could present friction in a developer led process.

Adrienne Tacke: Absolutely. Again, it depends. That's the golden answer there. It depends. So yeah. If you have a smaller team, if you're all super light and you work with each other and trust each other and everyone is on the same page, sure. You get that. You get the benefit of that velocity and flexibility. But that's not to say that it has some disadvantages too. The one that I like to point out where yes, we tell it it's good for prototyping. It's good for getting to scale quickly because you can iterate faster. It's also difficult if you are completely new.

So let's say you don't have the relational background. Let's say you go into data the first time learning no sequel. If you are given that much flexibility without learning some of the constraints that you need to keep in mind with that flexibility, you could set yourself up for failure technically because then you just say, "Oh, we'll just put everything in there," and we have these super huge documents and that's kind of an antipattern. So there's pros and cons to both sides, but I think that's one of the largest ones is that if you're fairly new to modeling data or working with data in general, that might be something that is missed because you just take advantage of the flexibility and just assume it's all gonna work.

Brian Dawson: Yeah. I'll use _____. I think I was in Aaron Alrich on an earlier episode and we just mentioned the pragmatic, not dogmatic kind of line and it's very similar here. So staying on that thread. I'm gonna get really personal with you later and we'll talk about heritage and experience in the space and diversity later. I wanna stay on this thought and you spoke at Global Azure a few weeks ago. You gave a presentation on durable functions, which is interesting to talk about here less so than just the specific concept of durable functions, but because it starts to touch serverless, which is emerging and new to a lot of people. Stateful and stateless. So maybe you can help us touch on some of that. What did you talk about and why are durable functions an important concept for people to understand?

Adrienne Tacke: Sure. So this was a very fun talk that I like to do because I give it in the context of Filipino food, which we can talk about that later.

Brian Dawson: Oh, I wanna – oh. It's lunch time for me. It's a late lunch, but go ahead. Yeah.

Adrienne Tacke: Sure. Sure. So I always start with, most people have heard of functions or Azure functions or lambda function, a function in general, serverless function. The way that I like to start is if even if you haven't done that, it's – what's the foundation of that? Well, sometimes you just wanna do something super small. One small task and you don't wanna think about servers. You don't wanna think about scale. You don't wanna think about resources. You have a thing to do and you just want it to be done.

So if you have something small like that, some task based event that needs to occur, I like to say Azure functions are good for that or any functions really because that's what it is. You don't care about the underlying resources or things that you need to provision. You write some code that says, "When this happens, I want something else to happen?" An example I like to give is let's say Instagram, when you upload a picture or something, I'm sure they probably downsize it to a particular threshold to meet because they have millions of pictures being uploaded every day. So that could be an example.

When you upload a photo they could have a function that says, "User Adrienne has uploaded this. Downsize it to a specific size," and then that could be the function. Since the function is triggered by the upload and then the task itself is the downsizing.

Brian Dawson: And it's stateless, so to say. It's isolated. It doesn't need context to be invoked. It can be invoked. It can perform at special purpose.

Adrienne Tacke: Exactly. That kind of task can be done in parallel. When you think about the volume of Instagram or any of these other platforms that has that scale you want something like a function because of that exact purpose. It's something that's generic enough that says it doesn't need to keep track of any kind of data to do its job. It needs to do something and then when it's done, hand me the next one. That's what Azure functions are good for.

Brian Dawson: And it's also at risk just going and noting again, looking at it through the lens of a procedural C and assembly programmer, not to say that that's the last time I was coding. But when we talk about performing these things, these operations at high volume and at scale, especially if there's a high need for context set up an environment. All of the set up just to call the function starts to get really expensive. We have to management swaps of memory. We have to link to given storage. We have to load registers. So speaking as a layman or uninitiated, part of serverless, stateless calls are removing some of that overhead. Is that correct?

Adrienne Tacke: Yep. That's exactly it and that's part of why it's so appealing too is that when you do deal in that kind of volume and scale and to do that much work it becomes way more appealing to use something like Azure functions or any public Cloud providers services. You take advantage of them doing all of that overhead for you and you just take care of the logic or whatever the task is that needs to be done.

Brian Dawson: Awesome. Okay. So I interrupted you. So now we get to durable functions, which explain and tell me a bit about what you talked about there and why those are important in this space.

Adrienne Tacke: Absolutely. So durable functions, it's – this all works out because the example I give is I like to think of durable functions as mods for video games. So you have video games. Like right now I'm playing Stardew Valley a lot, too much.

Brian Dawson: That's funny.

Adrienne Tacke: And a lot of these games like Minecraft or _____, they have a lot of mods that extend the game. They do things that original game does not do. They make your experience a little bit better. They are focused on adding additional things to the game to make it more enjoyable or whatever. So in the same vein, durable functions I think are like mods to Azure functions. So they are an extension to the Azure functions libraries. So they are based on that Azure functions library and what they do is they bring in a whole bunch of helpers for you to keep state.

So where Azure functions we said before it doesn't matter. You don't keep track of anything there. You just do the work and you're done. That kind of environment lends itself to not being able to keep track of data or does not lend itself to doing longer running, complex work flow. Something that takes longer than 10 or 20 seconds is something that technically you could do it, but you don't wanna do it in Azure functions. That's where durable functions come in. So if you have long running work flows or if you have state full work flows, that's where durable functions fill in the gap. So just to pair on to the Instagram example whereas Azure functions would be great for, let's say the downsizing of the photo.

Durable functions could be if you wanna keep track of a use that let's say violates the terms of service a number of times. So this person may upload something and it violate the terms of service. You wanna keep track of this particular user. They get one strike because they uploaded something that was against the terms of service and who knows? Maybe they don't do it in succession. Maybe they go a month later. However long they have that account they try to do it again or they take advantage of some sort of – unfortunately, with a lot of these things where you wanna help out people in crises and you have all of these donation type places asking for donations to help, there's a lot of accounts that pop up in this scenario and they ask to take advantage of people.

So you may wanna keep track of that kind of stuff. All of this is to say this can spend a longer amount of time, something that is way longer than the time spent of the initial request and it's something where a durable function would make more sense because you need to keep track of data, AKA the user that is uploading to the site, and it's potentially long running. It could go over the span of 30 seconds.

Brian Dawson: And in this case, and just curious, this is me being curious and we can call this, Brittany, at any point. We can edit this out. Of course we'll have to edit this or we can keep it depending on where it goes and potential edit point. Is – are these effectively overrides or they are extensions? So does the – from an inheritance sort of hierarchy standpoint if we look at an object model and how objects call or override or extend, how is a durable function called? Does the calling function call it and then let go?

Adrienne Tacke: They are an extension to the function. So Azure functions have something called triggers and that's what sets off the function. There's a blog trigger. So if any time you upload something to storage that's the trigger. That says, "Hey, something's been uploaded. Do something else." There's a timer trigger. So based on time, like a _____ job and that kind of model is now extended with durable function. So durable functions now have a very unique set and they work with something called a durable client. So that is what – it's based off of that same model.

You trigger a durable function with a trigger except it's specific to durable functions, and then with that now because it is triggered by that trigger, it will instantiate the durable function type of functions of which there are three. There's a client function. There's an orchestration function and there are activity functions. So whereas Azure functions, regular ones, they pretty much are like there's a trigger and then they do something which is that other function. In a durable function there's two other pieces. The client is where the trigger starts and that's the one that instantiates the orchestration function.

The orchestration function is what it sounds like, it's the orchestrator. That's where you list the steps of your work flow. That's the one that's in control and says this is what we have to do. That's also where you are able to keep track of your state because that's where you're able to access the queue and the task list of what is being done in your work flow. It's basically the list of steps it has and it's keeping track of for you. So all of those things are – you could do, but they're built in in durable functions.

Brian Dawson: Yeah. Your orchestrator function is, as we've been playing around on the game analogy or metaphor, in a basic game it's your main loop. It's the level of logic and iteration that knows what's going on that can kind of impose state above stateless calls. Cool. Well, okay. So now we're gonna shift – now that we've dug in, talked. You've given me a little more technical creditability so I'll feel like a little less impostor as I talk stateful and stateless with people. To shift up a bit, there's another piece that you did out in public that people can look for if you search for Adrienne Tacke. A few months ago you wrote a blog post and you talked about three things you wish you knew before becoming a software developer.

Adrienne Tacke: Yes. I did. That is something that I wrote to myself. It's like all the learnings I've had and what I wish someone told me. Even I reference this myself when I'm feeling down sometimes or feeling overwhelmed. But three things that I wish someone told me when I was starting out. The first thing that I have learned and want to share is that you need to fail fast and you need to fail often. That is something that sounds counterintuitive. That's something I have trouble with myself still to this day.

Brian Dawson: People love engineering mindset. That's – it is – it almost goes against the grain of your brain model to a certain extent, but yes. Go ahead. Sorry.

Adrienne Tacke: No problem. It's scary. Nobody wants to fail. No one wants to feel stupid. No one wants to feel like they don't know how to do something. Again, it just gets a little bit harder as you are here in this industry longer. You – it pounces back even stronger because you think all those years that you've been in the industry you should know it by now, but what I've come to find when I do listen to my own advice is that the faster I fail, the faster I try something and not understand it, and the faster I go through something and get all of the bugs, the faster I actually start learning because it's in those moments where I am Googling and saying, "What does this mean? What does this error actually tell me? Where am I having gaps in my knowledge?"

All of that does not come out of just avoiding it and not failing. If you're waiting so perfectly for everything to work right the first time or you just follow through or you just copy a repo and then just assume everything is gonna work, you don't give yourself the chance to fail. By not failing you don't encounter some of the real opportunities to learn.

Brian Dawson: To learn, to instill. Right. To actually innately understand the space as opposed to going through motions. Interrupt for a sec. So that is lesson one. We're gonna go back to lesson two and three for a moment – I mean, in a moment. The world has changed a bit for a lot of developers and it'll continue to be more so. Look, when we were compiling and linking locally as our standard practice, and obviously local testing is an inherent best practice, but technologies are shifting.

We just talked about serverless. I had a little – my own environment where I can use compiler driven development. I could spend way too much time in documentation figuring it out. I could try it and the compiler would spit back at me, "You're wrong. You screwed up. Get it together." But now as we've moved to a mainline trunk development, multiple commits per day, I think part of the psychological challenge is well, now I'm learning in the open. And so I just thought I'd call that out.

But this again is where it's important – well, one important to do local testing and learn locally and iterate and a lot of other things like environments in your shared built environment and local and yada, yada, yada. But I think what you call out as important as step one is to say, "Look, as we move to more social, democratized open development, you got to have a level of comfort that we all are learning together to do it and fail." So I think that's fair. Thank you for sharing that.

Adrienne Tacke: Absolutely. And just to wrap that lesson, that insight up, it's not all on you as well. There's that – it's your part to say, "I'm gonna overcome my own fears," and just do it and get into it. But there's also something to say where the environment you're in has to give you that psychological safety to fail. If there's – if somebody breaks the production build, a lot of people are like, "Who's fault is that?" Well, number one, it shouldn't be anybody's fault. Number two, there should be processes in place to prevent that.

Number three, there should be multiple steps to prevent that even reaching prod. You can reach further and further and further, but the whole point there is assuming everything is there in place. You have your gates and approvals. You have your prebuilds and you give developers their own environment to play with and to fail there so they feel comfortable failing so they figure it out before it reaches prod and goes further into the deployment. All of that is part of this insight. So assuming all of that foundation is laid and you have that environment to learn and really sandbox everything, then it just comes down to you and just saying, "All right. I have all of this in place. Now it's just me. Now it's just the mental part of I can fail, but I can do it in a safe way and a constructive way."

Brian Dawson: And interjecting in real quick before I hand it back. I'll just say dev ops trinity, right? It is so important. People and culture, process practices, tools and technology. They all have a high level of interplay. That gives you that culture, the environment, the process, and the systems that then say, like you said, now let's get over any emotional and cognitive hurdles and don't be afraid to fail. All right. So what was lesson number two? What are you telling – what is it – 16-year-old – 16 years ago Adrienne? What's the second thing you're telling yourself?

Adrienne Tacke: So number two is something I think I already touched on, but that's impostor syndrome is normal at every stage. In that blog post I actually share that I completely admire Boston dynamics. There's scary parts of what they're doing, but for the most part I would – if I could start over I would intern there for free. I would do that right now. If MongoDB hears this, please don't fire me. But I would intern there for free just because I'm so interested in learning more about the robotic side and all of that makes me – even now I'm look at the GIF right now. I feel a little bit of impostor syndrome like, "What am I doing?"

These people are building autonomous robots that can do _____ better than me. So but that's just to say there's so many different pieces and I touched it already is that there's so much to know. You can't know everything. So no matter where you are in your stage of career, it's normal to feel it. You could be having a bad day. You could have maybe not understood the blog post that you were reading. So maybe you need to find a different resource. Maybe this is – you need to find a variety of resources to understand a concept. You didn't understand the question as well as you thought you did. You didn't study something as well as you thought you did. Maybe you need another cup of coffee.

There's so many reasons why that this feeling can overcome you, but in the end it's normal and it's gonna happen throughout your career. So just let it go. Let it go through you. Acknowledge it and then just get back to it in a day or two. That's something that is still something I need to remind myself every now and then.

Brian Dawson: It's hard, but it's – I'll be really corny, old GI Joe. So GI Joe cartoons where, "Remember, knowing is half the battle." Being aware of it so that you can work on it. I wanna thank you for sharing that in a blog post and also verbally here cause there's a level of vulnerability there that what I get excited about, at least we're on the cycle. Not that it hasn't been in this space before, but we're on this cycle of acknowledging the humanity in terms that humanity of the individual developer, the neuro diversity, the psychological dynamics, and to a certain extent you just being comfortable sharing your journey saying, "I know this. I learned this.

I'm still figuring out," is – I'm sure somebody has coined a term for it. It's taking an open source and crowd source approaching, but actually bringing it to the human ailment. Look, I'm gonna be open and I'm gonna open source the psychology of what we do. Thank you for being vulnerable enough to share it. I guess I should give you the floor back to cover number three.

Adrienne Tacke: Yeah. No. I hope it helps too. Again, it's – if anything, it'll at least serve as another reminder for myself as well. The last insight is something I hold very dear. I actually have a full talk on it. It's something I call there is no developer uniform. So this one speaks to me. It's near and dear to my heart because –

Brian Dawson: You mean you don't wear a hoody to work every day? Okay. Go – I'll –

Adrienne Tacke: No. No. If you've seen the GIF that I have there is the hacker man guy from King Fury. So unfortunately, that's kind of the stereotype that's perpetuated of what does a developer look like and even in movies and TV and anywhere you hear about devs or hackers or whatever, it's always a guy in a black hoody and jeans and they're in a basement and it's dark and they have no social skills and all of these silly stereotypes that are surrounding what a dev is supposed to be. Unfortunately, that's kind of pervasive in society and I certainly felt the effects of that as I was starting my career.

I like to dress up. I like to wear heels. Sometimes I like to wear make-up. I like to wear dresses, the full feminine gamut. When I started – actually my first job outside of UNLV after graduating, I was a junior .NET developer and I would wear typical office attire. And I was always being told, "Well, you're never gonna be taken seriously as an engineer if you wear that stuff." I'm like, "What do you mean? Why – this is like – this is proper dress code. Why does this matter?" They're like, "Well, you're on the engineering team."

To me it didn't compute. It doesn't matter. I'm doing my job. I'm learning, but also at the same time because I was a junior and new and a woman I was like, "Well, maybe this is how it is." So actually for a point in time I switched it up. I would wear the hoodies and would wear the jeans and I would try to fit in to try to be taken more seriously, but what I found that even switching to that dress code that at meetings I would still be glossed over or any kind of opinions I would give to technical solutions, they're like, "Well, she doesn't know what she's talking about."

Number one, I found that well, this is just stupid. I'm not gonna change what I look like because it obviously didn't matter. So I changed back into what I like to wear. Then number two, I also found that I needed to get out of that company. I found that there are better environments out there that don't care what you look like, what you wear, what you prefer. So this kind of thing has stuck with me and I try to share this as much as I can. It doesn't matter what tools you're using. It doesn't matter what language you're learning.

There's all these silly programmer wars of what is cool and what is not. It's like all of that doesn't play a part into your skill set. If I wear heels that doesn't make me less of a software developer than someone who doesn't. So just be comfortable in whatever you're wearing, whatever you want to do, whatever you want to look like. Come as you are and then just do what you like to do. It should be that easy. So hopefully sharing that inspires more people to just stick to who they are rather than trying to fit in.

Brian Dawson: Yeah. And I wanna dig in so much on that. So thank you. We're not gonna have time for me to dig in the way I want to, but let me just say for those that are listening, everybody, both females in tech, males in tech, the majority community in tech, the minority community, the post is really powerful. Just to explain a bit for you guys, Adrienne posts on Instagram and Adrienne, as she says, dresses the way she dresses and her post on Instagram turned into a meme. And there's so many differences. There's the nothing is more beautiful than a girl who writes code, which both could have a positive connotation, but there's also a very negative connotation. We talk games.

We can talk about, we'll just say some of the drama that has happened there, HN _____. What is – I'll just read a couple of them so they'll inspire people to go look. The comments that came on that are telling in so many ways. "Whoever codes obviously isn't standing because they know they'll be there for hours." "Girls that are developers would never dress like that. The girl in the picture looks like a PMM." "I'm absolutely positive she's standing there doing nothing."

Then there's an interesting one that doesn't have the – and this is actually a female. It doesn't necessarily have the gender connotation or the bias connotation to it, but it's an example of an unhealthy view on what we do. "Are you sure she's a programmer because typically a programmer doesn't have time to even brush his or her teeth, let alone dress up?" And we all can be guilty of looking at things this way. I just think I'll stop or try to stop there. It's just an important slice that can become a good, novel view on some of the biases and challenges even in a space whereas I told you in the pre-call is meritocracy based largely.

It's not devoid from other influences. But if I wanna wear a three piece suit and a tuxedo to work every day, if I understand my domain, I'm working with the team to get stuff done, and I'm delivering, nothing else really matters.

Adrienne Tacke: Right. Exactly. That's the whole point of that is trying to just dispel all of those views and anything else that's been perpetuated that's just wrong. I think the most disheartening point were all the comments from other women. I was like we're supposed to be in this together. We have it hard enough to kind of prove that we're supposed to be here, but to – yeah. So you can check out all the other ridiculous comments that were on there. I didn't ask for this. I'm like, I did not wanna be a meme, but that's the trouble with having a public account where you try to share your journey with other people for the good part of it, but that can also happen as well.

Brian Dawson: So this is gonna be a good transition, but I do wanna call out so we give kudos to where we all can learn on the journey and we can support and represent. Kudos to a Michael Robinson that said, "These posts about female programmers are so consistently demeaning, misogynist, and out of touch." And look people, there's some malicious actors that post as there are in any comments in any section, but a lot of what is said are just traps that we all fall into if we don't stop and think about it. _____ _____, "I know who she is and she's no impostor." So thank you to y'all for chiming in on that moment.

This is a good transition to get a couple more points before I have to begrudgingly let you go get on to advocating for developers. Is you have written – so first a bit, as I usually do, even a little bit about me personally. I am the father of a 23-year-old CS and mathematic student who happens to be female, African American, and Filipino and happens to as we talked about here, have a focus on gaming. Of course I raised her on games and computers. So she's very oriented there. Then interestingly enough for this segue, is while I'd also say very socially active both in the fighting for gender equality as well as for Filipino rights, frankly. This leads into clumsily a couple of things.

First, actually, I'm gonna blow my segue. First, Adrienne, when I look at your Twitter post, the Filipino flag is there. You seem to be very forthcoming about your background as a – not your background – your identity as a female in tech and as a Filipino in tech. How important is it to you? Why does it matter? Why is that something that you're so forthcoming about?

Adrienne Tacke: It's a really, really big part about it and you've hit the nail on the head there. Any little bit of representation and sharing of my identity is important to me in the tech space because there's not a lot. Just like a lot of the other underrepresented minorities that we don't see, it's always nice to see yourself somewhere in the place that you hope to be or aspire to get to. For me, a really big part of that is you may have heard that there's a stereotype that a lot of Filipinos go into the medical field. It's partially true.

My mom herself is a nurse and a lot of my family is in the medical field. But I knew growing up that I did not wanna be in the medical field. I would hear stories from my mom. She would talk about the surgeries that would happen and the things that she would do and I was like, "I'm not ready for that. I don't wanna do that. I don't wanna deal with cutting people open and seeing the insides of people. That's not my jam." However, as I was starting to get to that age of what are you gonna do, what are you gonna study in college and all of family is pressuring you to say what is your life goal and what are you gonna become, I didn't know. I knew that I did not wanna go in the medical field, but I also didn't know what the alternative was.

So clumsily falling into tech, I got there because I needed to find a job to help pay for college and the highest paying one was the student technician job. But even then I didn't know about software development. I just knew – I learned in that student technician job a lot of troubleshooting, of how to talk to people, of empathizing with someone who doesn't know too much about tech. So that's where I found the problem-solving skills that I liked and then it was through there that I found the opportunity to intern at my university software development department to do software development.

So all of this is to say that I obviously ended up loving it and changed my major to MIS, management information systems, but I wanna keep sharing that, the fact that I'm Filipino because I know that there are a lot of other Filipinos out there who feel the same way as I do, who are like, "Well, I don't really know what to do in life, but I also don't wanna go in the medical field." So I'm hoping my journey and sharing that fact is showing them that there is an alternative and a very good one and exciting one at that.

Brian Dawson: Well, that's awesome. Again, I think some of what myself and those that help me at Dev Ops Radio have tried to do is I'll go to the crowd sourcing thing again, crowd sourcing experience. So I think another thing that's powerful, like the specific thing – I would beg to say looking at what you've done, what you're doing, and having a conversation with you, Adrienne, it's a little bit bigger than you found something you like. You found your calling, in my opinion, my simple armchair assessment.

The real catch is going back to that thread. There's no developer uniform. The _____ is we can harm ourselves as an industry if we don't proactively make visible the diverse tapestry of what development is and what tech is because there's a whole contingent of people that either based on cultural leanings, family leanings, or just not being able to project themselves and being in that role don't even give consideration to going into a field. And we start to see when we talk with people like you, Adrienne, the variety of guests that we have on, like how much we lose if we don't have everybody that is meant to do this, that is inspired by this participating in it.

So I fully agree. Thank you for putting yourself forward. That's no obligation of anybody, of any underrepresented group to have to put themselves forward, but there's absolutely value to it. So this gets to the next topic that I fumbled the segue on when I tried to introduce my daughter and python and kids, and is what is so awesome is coding for kids, python. You have actually created a children's book. Now I'm gonna do the personal correlation. This is a family where – have you heard of Bits Box?

Adrienne Tacke: I have. Yes.

Brian Dawson: Okay. Yeah. Where we have my nieces and my brother's daughter and my other brother's daughter, we're all in similar domain cause our father was an engineer. So we sort of inherited some of this. But just phenomenal working with scratch, working with Bits Box. I think it's so powerful to expose kids and as we said, kids of all backgrounds to this early. And maybe stem isn't your thing. Maybe computer science isn't your thing, but you're not gonna know till you touch it. Hopefully I didn't lead the witness. So what led you to creating the book?

Adrienne Tacke: So this was a super unexpected, but cherished opportunity. It was because I was sharing on the Instagram, like you mentioned. I was trying to change what Instagram was. It's a photo-based app where you post pretty things on there. I'm like, "How am I supposed to talk about tech here?" So I started a series called Don't Be Afraid of the Terminal. If you search that hashtag you should still find some stuff there.

Brian Dawson: I've got to check it out. I haven't seen it. Sounds awesome, but yeah.

Adrienne Tacke: But it's exactly what I did. I was scared of the command line of the terminal. I didn't know what this black box of nothingness would do, but I did know that if I entered something wrong it could do some really powerful things. So I kind of started that series. I'm like, let me break down what these commands do and how people should not be afraid of them. So that series was what led to a publisher actually contacting me. They're like, "Hey, we really like the way that you break down these concepts. It's very easy for anybody to understand. We are not technical at all and we could understand what you were talking about." They were looking for an author to write a book, Coding for Kids, a Python book.

So I'm like, "Well, it's one thing to write Instagram posts. It's another to publish a book." So I had a lot of impostor syndrome there. I'm like, "I don't think I can do this," but we tried it out. We spoke about it. They – we talked about what the goals were for the book. I'm like, "Well, this actually sounds like a really interesting challenge," and I actually love that it was for kids because a lot of how I explain things is with lots of silly examples. I like to use desserts. I like to use food. My talk from Global Azure talked about durable functions in the context of lumpia, which is a Filipino food. So it's – it was just a natural match to write a book in this way. So yeah. I – we had the outline and it was the hardest thing that I've ever had to do –

Brian Dawson: I can imagine. Yeah.

Adrienne Tacke: To work as software engineer, have your own deadlines, have your tasks, and all this stuff you already had to do and then come home and then do your second job, which was that for me for the time. So I wrote that book within a span of three months. Whew. I'm very proud of it though.

Brian Dawson: Yeah. You should be – I have a lot of effusive things to say about it and I probably won't get in. I am gonna give a tribute to one of my co-workers, Tristen, and say, "Dude, sick." That is – it's really – it's sick, that is – to play on the word sick, it's awesome. Honestly, it's really powerful. I thank you for doing that. A bit of getting ahead of myself, I again say probably would have been a phenomenal nurse or a physician or whatever you chose to be. I think you found your calling and we need you doing things like this and representing the way you're representing. So I'm gonna ask you to be vulnerable again now. What is a dev oops? Not dev ops. Dev oops: O-O-O-P-S, "Oh, smack. I screwed up moment," in your career that you learned from?

Adrienne Tacke: So a very classic example, it was actually the catalyst for why we started to create our pipelines in Ashier using Ashier pipelines. So the last company I worked for, we deal a lot with files and generating files and deal with money. Let's just say there was a feature that needed to generate an invoice and there was a decimal point that was missing in a very specific place. So I made a mistake on one of the calculations for basically a fee that we added on to our services and in the generation of the invoice.

So at the time we were just – our deployment model was we copy and paste files from staging to develop or to prod. And there was really no gates there. There was very minimal testing. Yeah. So when that was deployed and some of our clients were calling very angrily asking about why a certain fee cost this much, I had the CEO on my back. They're like, "What happened here?" Rightfully so was upset. And so I double checked and oh, it was me. I was missing a decimal point. So we fixed that, but that became a good thing because that acted as the catalyst for us to say, "Look, this is something we've been talking about as part of our tech debt. We need to implement this now."

And we were able to use that as the reason to say, "Look, we need to dedicate a few sprints to implement this pipeline, this automated pipeline so that this never happens again, that we catch it before it ever goes out to the client." So it was very, very bad at the time, but it became a really, really good thing.

Brian Dawson: That's awesome and that's scary. Yeah. We see in your background you work for a financial services organization. A direct path to production for – and maybe this is shifting, but for a lot of developers sounds awesome. Get all the checks out of the way. Get the friction. Let me get – but you can't do that without putting up guardrails, lines in the lane, lane separations, stop lights, et cetera. You should actually welcome some of the controls, guidance, and governance that having in agreed upon standard CD pipeline provides for you.

That is – and it's funny to say as we get in this modern CICD bubble and let's have quality checks. How many organizations and people still are not working that way? I just add – my quick anecdote is to say I'm sorry you had to be the one to be the cause of that pain, but sometimes it takes that pain and that pain raising to a CEO to make change. I was in a conversation recently with a family member of mine. Let's anonymize him a little bit. They were driving a quality first approach. He oversees QA at an org and they were – been beating the drum, we need a quality first approach.

Well, when the CEO found defects in the product and had a bad experience, thankfully quality first became the mantra of the organization and now they can get it done. So what is a podcast book resource person you follow? If our guests get nothing else out of listening to this episode except your answer on this, what would it be that you'd give them?

Adrienne Tacke: I actually have two.

Brian Dawson: You're only allowed one, Adrienne. No. No.

Adrienne Tacke: I'm gonna combine it really quickly and just yell the names out or you can follow me on Twitter and I'll tell you all the resources, but that's the dev rale in me speaking.

Brian Dawson: The brand building. There you go.

Adrienne Tacke: Like and subscribe. No. The first one is if you're interested at all in getting into dev rail in a little bit more of a structured way, there's an advocate. His name is Sam Julian and he's incredibly gifted at compiling a lot of very useful, actionable information into manageable pieces. He has written a book called Getting Started in Developer Relations and it's a very, very good segue for people to learn what it is if you're interested, how do you get into it and how to be a good one.

Brian Dawson: Awesome. Thank you for that.

Adrienne Tacke: And then the other resource I have is – I don't know. You may – I don't know if you had her as a guest. Did you know April Sprite?

Brian Dawson: No. I don't.

Adrienne Tacke: No? Okay. She's known as vogue and code on Twitter and also on YouTube. But she also wrote a Python book for kids and I like to share her book as well because hers came out after mine. So hers is a little bit more updated than my book and she also does a lot of mixed reality tutorials. So she's a mixed reality advocate for Microsoft.

Brian Dawson: So awesome. Yeah. I think I've come across April. I have not had contact with her, but you've just spawned – we are identifying speaker sets for a number of activities we're doing including our Dev Ops world conference. In addition to Shirley looking to reach out to you and I ask you to submit a call for paper, Adrienne.

Adrienne Tacke: Okay.

Brian Dawson: Just go to CloudBees.com or DevOpsWorld.com and submit a CFP. If you don't, I will try to remember to chase you down and I will also chase down April. Thank you for those references. Those are awesome. I now ask, what are your final thoughts? Actually before – I'll do it afterwards. What are your final thoughts for our audience?

Adrienne Tacke: I think that if there's anything that is taken away from here, especially for anyone that is new and listening, is that you definitely belong here and I think the most important thing too is that if you're interested in tech it is not just development. It's not just coding. So there are a lot of people that get discouraged because they do the code. There's a lot of push on learning how to code and they're starting them younger and younger.

Some people just don't like to code and that's fine. There's so many other ways and avenues to get into tech. So I urge you, if any of this resonates, maybe dev rail is your thing. Maybe being a designer is your thing. Maybe – there's so many avenues. So please, please we need you and there is a spot for you. It may just not be in coding, but you are absolutely necessary and needed in tech.

Brian Dawson: Thank you. I'm gonna risk watering down your final comments just to say, it takes a village to use – maybe a corny or cliché adage – developers, the people that sit down with hands-on keyboard generating application code are only one piece of the puzzle, very important piece, but they are one piece. Everybody in the process of bringing technology to bare is important and there's a role for everybody. Thank you for that thought.

And I'm gonna borrow your phrase. So in your blog post you called out Michael and Esa and you said they're awesome and I just wanna say, Adrienne, impostor syndrome be damned. You are awesome. Thank you for the conversation. Thank you for the work that you're doing. Thank you for the vulnerability. We appreciate it and we need more people like you helping us move forward.

Adrienne Tacke: Thank you so much. I appreciate it.

Brian Dawson: All right. Well, thank you, everybody for taking time to join in on Adrienne and I's conversation. Hopefully you subscribe, you stay tuned, and you check out our next episode of Dev Ops Radio and in the meantime be sure to follow Adrienne and I will give her Twitter handle. Follow Adrienne on Twitter at AdrienneTacke: A-D-R-I-E-N-N-E T-A-C-K-E. Look her up. It's a fantastic feed, a person with a fantastic perspective. Again, Adrienne, we thank you. Look forward to when we get to speak. I look forward to watching her talk at Dev Ops World.

Adrienne Tacke: I'm on it. I already have the tab open. So we're good. We're good. Thank you so much.

Brian Dawson: Awesome. Thank you. Bye-bye.

Adrienne Tacke: Bye.

Brian Dawson: All right.

[End of Audio]