#192 - Brain Refactoring: Overcoming Your Common Bugs & Obstacles in Tech Career - Dagna Bieda

[00:01:20] Introduction

Henry Suryawirawan: Hello, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today is one of those episodes that I like to cover because this is something about personal growth, you know. So normally, we cover things like technical stuff, architecture, you know, technical leadership. But today is something about more like a coaching yourself, how to grow yourself to become a much better software engineer, both in your personal life and also in your career. I’m really excited to have Dagna Bieda. So she’s an engineer turned into a coach, who is actually helping a lot of software engineers to actually actualize themselves to become a better person and engineer altogether. So welcome to the show, Dagna.

Dagna Bieda: Thanks so much for having me, Henry. I’m really excited to be here today.

[00:02:03] Career Journey

Henry Suryawirawan: Right, Dagna. Maybe before we go into the whole gist of our conversation, I’d like to invite you to probably introduce yourself a little bit. Maybe telling us any highlights or turning points that you think we all can learn from that.

Dagna Bieda: Yes, absolutely. So like you mentioned, I’m an engineer turned career coach for engineers. And I like to say that I moved from programming computers to reprogramming human minds, because that’s what I do with my clients right now. And as I worked in an engineering, in various different engineering positions, I realized that there are four common obstacles that are stopping engineers in progressing in their journey. Some of those things I learned because of my own experience, but some of them I noticed as I was working with my coaching clients who are across different domains, working from small companies to big companies with different levels of experience and different kinds of positions from individual contributor to even a CTO over like a smaller to mid sized startup.

And so the four obstacles that I hope we’re going to dive into today are the imposter syndrome, the burnout, trouble dealing with other people, and self marketing struggles. And I can tell you when it comes to trouble with dealing with other people, that was a huge one for me. And mostly because I grew up in a different country than I currently live in. So as an immigrant, I experienced how your cultural background can actually have an impact on your career, which is like, you know. Unless someone like points it out directly. Hey, Dagna, you grew up in Eastern Europe, and now you’re in the United States, and that’s why your communication comes across as aggressive, even though you’re thinking you’re being direct.

And that’s something that I currently help my clients with, especially those who either immigrated to the United States, which is a big chunk of people in tech, or grew up in immigrant families. Because it’s not really clear. If you have a manager or your boss does not have that kind of direct experience, it’s really hard for them to verbalize what is it that’s holding you back. So they’re not capable of providing you the kind of feedback you need to hear in order to grow.

[00:04:27] Dagna’s Career Transition

Henry Suryawirawan: Those four things, I have all of them, I’m sure. Everyone here also has most of them, if not all, right? So I think what is very exciting, you mentioned in the beginning that you used to program computer programs. Now you kind of like help to program human minds, right? And you just recently published a book titled Brain Refactor. So I think we can use some brain refactoring here. Well,

Dagna Bieda: That’s right!

Henry Suryawirawan: Degna is showing the..

Dagna Bieda: The book’s coming out!

Henry Suryawirawan: Yeah. So maybe let’s start from this one, right? So what makes you actually write this book? Is this something that, like what you mentioned earlier, right? So you found from your journey and from your coaching clients that there are some things that we all need to be aware of as a software engineer.

Dagna Bieda: So first thing that I want to kind of point out, it kind of goes back to your very first question is that I’ve dreamt about writing a book for a long time. The idea came to me seven years ago, but I actually started working on the, on it only two years ago. And then when I started, I thought it’d be six months for me to like condense all that knowledge and put it into a book and just publish it and have it out there. Turns out like from six months, the whole process exploded into two years. But I’m really happy it did because I wanted to make sure that it’s a quality product, you know.

And the reason I’m talking about it this being my dream and being connected to your initial question is because in my career, I didn’t realize it at the very beginning, but I was chasing impact. I was always curious about creating impact. So initially I studied control engineering and robotics, because I thought, hey, if I built robots, surely that means I’m going to build the future. And that means I’m going to have impact, right? Whatever that means in a mind of a 15 year old, right? That has to decide where to go to high school and college.

And so, I quickly realized as a robotics engineer after I graduated that building robots takes a long time and it’s like kind of too slow and I was impatient and I wanted to just go, go, go and grow in my career and it was just not cutting it for me. So then I moved from robots to essentially being a software engineer and working in a setting that deployed apps who would impact literally millions of lives. And I thought, wow, that’s the kind of impact that I want to have. But it turned out, after years of working in software engineering, whenever you’re one cog in a huge machine, that might have a great impact, if that impact is not aligned with what it is that you truly want out of your life, you’re just going to feel like that, like a cog in a machine.

So after years of working in that setup, thinking, okay, I just need to get to the next step, get that promotion, move on, get more money. You know, keep chasing those like shiny objects that we typically do when we think about career progress. I never really considered what I wanted other than chasing that impact that was very much undefined at that point in time. And I ended up burning myself out eventually in my career to the point that a job I used to love, I didn’t want to wake up and go to work anymore. I didn’t want to like get myself to the meeting. I would procrastinate on the smallest of things. Not wanting to send that Slack message or follow up in an email, I just didn’t care. Because I thought nobody valued what I had to say.

And so when I burned myself out, I hit this point where in a one on one meeting with my manager, I burst into tears. And in my mind, it was like ridiculous because I thought, no way in hell this is happening right now. I am a professional. I keep my cool at work. Like what is going on right now? Like I could not contain that feeling of being burned out and unsatisfied deeply about what was going on in my life at the time, that I burst into tears.

But that was a turning point, Henry. And let me tell you, this was really good. Even though it was incredibly embarrassing, because I decided to reach out to talk therapy afterwards. Get a third party professional who would understand what it is that I was going through and could help me get myself out of that situation. And after just a couple of months of simply talking, not even taking any sort of medication, just talking with this person who got me, my quality of life changed. I started seeing things from a completely different perspective.

And that’s when it hit me. Wow, because it was like a massive impact that she had on my life. And I was like, this is what I want to do. I want to have this massive impact on people’s lives, working with them directly one on one as a coach. And that’s when I made the transition from being an engineer to a coach. You know, plus being there’s so many opportunities in tech, and I was really good at what it is that I was doing as a software engineer. I had no doubt that if my entrepreneurship would fail, I could always come back. Fortunately, didn’t have to. So I hope that answers your question. Both of the questions, really.

Henry Suryawirawan: Yeah, thanks for sharing your story. So I think it is also mentioned in your book, right? So I think that’s very good story for people who may be relating to the experience that you just mentioned, right? Feeling burnout or maybe frustrated at work. Or maybe they just can’t progress in wherever they are in their role or their job, right?

[00:10:08] Our Legacy Codebase

Henry Suryawirawan: So I think, let’s start to talking about this thing about brain refactoring, right? I think in your book, you mentioned every one of us has legacy code, either it’s inherited maybe from, you know, childhood or maybe from school, culture, whatever that is. But sometimes we tend to just let the legacy code run by itself like unconsciously. So tell us why it’s very important for us to understand this legacy code and what should we do about it?

Dagna Bieda: Absolutely. I love that you point out that legacy mental code, because I love the analogy too. So I believe that the people here listening had a similar experience when they join a new company that already has an existing product with that legacy codebase, right? And then you kind of have to jump in and you have to first understand what other people put in there before you have the chance to look into that code and do something about it, right? And it’s kind of the same concept with the legacy mental code that’s hidden in your brain. Your parents put stuff in there. The past experiences, your teachers, your friends, people that you just happened to watch or like lived next to and observed and modelled after. They have put programming into your brain before you could look into what’s there and do something about it, right?

And I think that the critical aspect here too is understanding that because the legacy code is already there, it is up to you to discover what’s hidden in that code base. Because a lot of the time, we don’t even think about it. Most of the actions that we do are happening on autopilot. So we just kind of have those background processes that’s been running in our brain that someone else has put there. And we just kind of live it, according to it. Not really putting a debugging point to stop and look into all that spaghetti code that’s there. All the things that are coupled that shouldn’t be coupled. It’s not possible to like do a git blame and see who or what particular experience put that programming into your mind.

But you can still reprogram what’s not working. You can find those hidden bugs, find those inefficiencies, and optimize your mental code. Do a software update, right? And therapy setting as well as coaching setting really help with that. Because your code is essentially the stored beliefs, the stored memories, your thoughts that all kind of creates that legacy mental codebase that you get to refactor whenever you choose.

[00:13:04] Feedbacks as Debugging Points

Henry Suryawirawan: Yeah, so I think it’s really important, right? So for us to actually understand this, there’s a legacy programming that is embedded, you know, as part of our life’s journey, maybe, right? So from childhood, maybe past experience, past trauma. Whatever life experience, right? Sometimes, unconsciously, it gets programmed into our mind and it becomes our default mode, right? Some people even unconsciously know that this is such programming that is already embedded. So I think it’s very important, like one thing that can be done, of course, if you are self aware, so you know all these biases that you have or maybe, you know, you read a lot of resources and all that. But sometimes it’s very tricky. You don’t actually realize what make you stuck in life, what make you stuck in your career. And you mentioned about debugging point, right? And in your book, you mentioned one of the best source of debugging points is actually feedback. Maybe tell us a little bit more about this concept.

Dagna Bieda: Yes, so feedback from a programmer’s perspective is super valuable, right? If you deploy an app and it gets into your user since and they click on a button and an action happens that was not supposed to happen, you want to get that feedback, because that’s how you can fix things. And it’s not really personal. They’re not attacking you. They’re just letting you know, hey, your software isn’t working as expected. So let’s apply it to this same context of your own mental programming. What if the feedback that you get just carries information that tells you, hey, your software isn’t working the way that it’s supposed to, right?

So, one way to kind of see it, I’m going to draw on my own personal example, is because of that cultural background that I mentioned that was clashing with my American workplace after I moved to the States from Poland. What happened one time was I was working in a company that had made a difficult decision. They had to let a lot of people go, including many engineers that I had worked with. Later that day, at an all company wide meeting, I raised my hand, I pointed some things out that, you know, I thought the leadership team hasn’t really thought about, they haven’t taken them into account, and I was worried because that would have impacted the way that we care for our mobile apps, and then like how we care for our customers. I was just, I was worried. I thought that my feedback was coming in from a place of care.

Imagine my surprise, Henry, when literally after the meeting, one of the directors of engineering comes to me and he says, Dagna, why did you call our executive leadership team a bunch of idiots? And my jaw dropped, right? I was like, what? That’s not what I said. Like, is this really how it came across? And that’s the kind of feedback I’m talking about. With what he said, I was finally able to understand. I finally got that information like, hey, your software isn’t working. How you communicate with other people is not working. You’re not getting the things that you want in your life, which was at the time getting a promotion. Yeah, that probably cost me a promotion. So it was really important for me to get that information.

But the thing about feedback, too, is it carries information, but you have to allocate a thread in your mind to actually process it. Because people can be giving you feedback, and you might be completely deaf to it. And you might not even listen to it. And on top of that, feedback is not just the words that other people tell us. It’s what happens around you. It’s whatever brings information to whether your software is or is not working. It could be getting that promotion or not getting that promotion. It could be landing that next interview or not landing that interview. It could be a conflict that you have on your team. All that carries feedback which has information contained within it about whether or not your current software is working or not.

Henry Suryawirawan: Yeah, I think that’s really important, right? So feedback definitely is a key thing for us to improve. We cannot just rely on ourselves to improve ourselves, right? I think it’s sometimes, it’s kind of like, we have our blind spots, everyone has blind spots, right? Everyone has their own biases. And sometimes this kind of feedback definitely helps us to give us signal.

But also you pointed out a very, very important thing for me when I read the book as well. It’s not just the words that you hear from other people, you know, like, 360 feedback or manager’s feedback, or performance review feedback. But sometimes the situation around you, maybe the situation that happened towards you, like the missed promotion or whatever the results that you didn’t get, these are also good feedback for you to reflect.

[00:17:52] Psychological Safety in Receiving Feedback

Henry Suryawirawan: But one of the most important thing that I find about feedback is that as a person, you need to be receptive to it, right? So I think in your book, you mentioned you have to have a psychological safety for yourself and be open to actually listen to the feedback. So tell us this importance of, you know, being receptive to the feedback.

Dagna Bieda: Yes. So when it comes to bringing feedback in, the psychological safety is key. Here’s why. If you look back at how we evolved as a human species, you’ll see that whatever triggered our fear mechanism, like the fight or flight or freeze response, was good for us evolutionarily, right? Because it helped our species survive. But our brains are not really adapted to the modern environment that we live in that’s relatively safe. And by relatively safe, I mean there’s no tooth sabre tiger running behind you on your way to work, right? You don’t have to hunt or gather the food, because you might starve to death. Most of us don’t, right? We just go to a grocery store.

And our minds, you know, never were really prepared for this idea of being interconnected and constantly connected to internet or social media. And we’re still kind of running on that default configuration, which is kind of like a caveman configuration, because that’s what the evolution made us to be. And it worked, right? We are the most thriving species on the earth to the point that we’re destroying it. If we look back at how that default configuration was set in place, we’ll see that being wary of feedback is a good thing. And not trying to grow too fast is a good thing, because that keeps you safe. Now, in the modern times, you have to understand how that default caveman config was put into place and how it works and how it operates, so that you can reprogram it and choose to grow rapidly, because you are safe. I hope that makes sense.

Henry Suryawirawan: Yeah, so I think, definitely it has been covered in many books as well, right? About this evolution of our brain, right? From our primate’s life, so to speak, like the caveman or maybe, you know, a few hundred years ago, we are hunter gatherer, right? So we don’t like to be, I don’t know, like put aside in the social thing, right? And that’s why we always want to crave that kind of safety, you know, being accepted. And definitely critical feedback is maybe one thing that we are scared of. So many people are stuck in this mode. Because I think it’s kind of like threatening them, right, as the brain translates that. And that’s why they become a bit self defensive probably, um, trying to find excuses and things like that. And definitely it’s one of the refactoring that we have to do.

[00:20:49] 3 Common Mental Code Refactoring

Henry Suryawirawan: So maybe before we go to your algorithm, I know you have a very insightful algorithm. In your book you also covered the three common refactoring things, which I find it is very applicable in everyone’s life, I believe. So maybe if you can elaborate a little bit more, what are these three common refactoring? So that this is like the basic, you know, renaming stuff, moving class, and things like that, I assume. So maybe tell us about these three common refactoring mode.

Dagna Bieda: Yes, let me just pull it up real quick inside the book so I don’t, I rename my own refactoring algorithms. So basically, there are three refactors that I recommend in the very beginning, when I talk about the source code of the mind, right? The number one is attention allocation adjustment. It’s really critical where you put your attention. It matters, right? As engineers, we tend to put our attention into things that are curious, that are fun, that are intellectually stimulating, that are hard, right? Because that brings us pleasure. Staying after midnight to finish that bug fix or finish that feature. Ah, it’s just so satisfying. When in reality, your attention, if you want to grow in your career, has to be focused on things that produce business impact. Without that impact, without prioritizing business, you’re just not going to get too far, because you’re not helping the bottom line, right? So, in other words, or as I put it in the book, business comes first, always. And then quality engineering comes after.

The second factor that you mentioned, Henry, was mental resource management. And it’s very important to think about your brain as your tool, as the most important tool that you have in your toolbox. So if you’re running on empty, if you’re coming to work tired, your ability to solve problems, which is the core of the engineering job, is going to be impacted. You’re going to be impaired. You’re not going to be able to solve problems as efficiently if you were well rested, well fed, and in a good mood, right? So it’s really critical to make sure that your tool, the brain that you’re using to solve problems, is being taken care of. That you take the downtime that you need, that you take vacation, that you go on breaks. That you care about the team dynamics and the atmosphere that surrounds you, both at work and at home, so that you can be efficient in doing your job.

The third refactor is called conversational outcome calibration. And part of it is coming from my experience of working as an engineer, where I’ve been a part of, or I’ve observed these ridiculous conversations on what’s better? Is it Linux? Is it Mac? Is it Windows? Is it C++? Is it C? is it Java? Is it Android? Is it iOS? And people just keep fighting, where in reality, it doesn’t matter. What matters is what kind of problem you’re solving, what kind of tools you have available, and then what are the constraints. So again, this kind of ties us back to this idea of serving business first and trying to solve a business problem using applicable tools, right? Because at the end of the day, programming languages, environments, and frameworks are just tools. So you have to figure out what’s available in the market, in the capacity of your team, and then use the tools that you have on hand in order to solve a problem, right? But it goes back to this kind of thinking that business comes first.

Henry Suryawirawan: Yeah, so I find this is really important for many engineers, because we all techies like to solve hard problems, you know, like technical hard problems, learn new technologies. There’s plenty of technologies these days. And also we like to have strong opinion on some technical stuff, right? Just like what you mentioned. Is it programming language, technology, cloud, whatever that is, right? It seems to have like some sides that we choose and we fight against each other because of that. And I think one important thing is about the maintaining the health of the brain, right, so to speak. Be able to maintain your freshness, be able to avoid burnout, you know, some people maybe work long hours over the weekends as well, never stop. So I think that those definitely need some refactoring.

[00:25:23] The Brain Refactor Algorithm

Henry Suryawirawan: So let’s go into this refactoring algorithm that you have, right? So for people who may have, I don’t know, like some particular situations in which the bug is so tricky, or maybe it’s just so difficult to solve, you have these five steps, right, in order to kind of like help solve the bugs. So maybe if you can outline us, what are these five steps and maybe how can we use it, maybe using an example?

Dagna Bieda: Yes, so let’s name the steps first and then we can dive in one by one. The first one is to identify root causes. The second one, plan out the refactor. Third one, script new responses. Fourth is build libraries of evidence. And then the fifth one is to continuously execute, right?

So with the identification of root causes, it’s very similar with what we do in software, right? Like in order to understand why there’s a bug that a user or beta tester reported, we need to kind of understand like, okay, when I click this, which function, class, object does it call? Which file is it? How is that related to all the other things that are being triggered? Is there any background process that might be hijacking this whole thing? So we would be like setting debugging points in order to kind of like, well, depending on the language, right? We just talked about the tools, but we will be trying to kind of like follow the line and see what’s the root cause of that particular behavior of our application.

So when we look at our legacy mental code, it’s similar. Except in programming, in coding, we look into lines of code. We look into files. And in terms of the mental programming code, we’re going to be looking at our beliefs about our thoughts. What are the memories that we have that are connected to that particular behavior to understand what is it in the past that programmed me to be the way I currently am, right? We’re digging into that legacy mental code who someone else really created and we’re trying to refactor what’s not working.

Once we’re able to identify the root causes, we take on to the next step. We wanna plan out the refactor, right? We wanna know what is it that we’re replacing with. What, what are the potential side effects that we should be experience, expecting? And essentially what kind of behavior we want to be happening instead of the buggy behavior that’s happening right now?

So, for example, when it comes to that example that I mentioned earlier about my poor communication style and how it was stopping me from getting that promotion. One of the things that I wanted to fix for myself was change how I communicated, how I came across. And what I needed to implement was using a different communication style. So I was coming across as an aggressive communicator. What I needed was assertive communication skillset. So I had to implement that skillset first. And then make sure to monitor if I was following it, right? If I was actually using the assertive communication style instead of the aggressive one.

And the third one, we’re scripting new responses. So those responses are essentially, you could think about it as something that you want to consciously implement instead of what is currently happening, right? So my default would be giving it to you straight, being very direct and just naming the problem. So my new response that I scripted for myself was to take a breath, pause, and use the new skills that I’ve learned around assertive communication. So the communication that would come out of my mouth was not as direct, but was rather assertive. And I have some specific guidelines for what assertive actually means.

The fourth step is building libraries of evidence. And there are different types of libraries of evidence. So what you want to do is essentially understand that your brain is smart, and it’s not just going to believe whatever. And in a way, you could think of it as having your application written in a specific language, you have to be able to match that language or pull in any plugs that will kind of translate from one to the other. But if you’re just going to plug in two different languages together, they’re probably not going to compile, right? And your brain works in a similar manner. So when you’re bringing, building libraries of evidence, it has match to what is already there. You want to write libraries that are kind of based on what it is that you already believe to be true.

The four that I mentioned are a repository of past experiences. You want to dig into the past and see yourself in situations that you’ve already been in, but from a different perspective, in a different light. And that can help you change how you think about yourself. You want to use visualization, because that’s really powerful, and we know anyone who’s seen Olympics probably heard about the topic as well, that it’s commonly used by athletes to win gold medals. Then we also have third party perspective, which is allowing that feedback in from someone who can guide you, who can give you valuable feedback, because who you get feedback from matters too. Sometimes it can be helpful, sometimes it’s just garbage. And then the fourth one is outside models, which is looking for people who are having the kind of outcomes that you want to model after. And then trying to mimic what it is that they do. Or basically asking them, hey, how is it that you’re doing this thing? I want to be like you. How do I get to be more like you? What is it that you’re thinking? What is it that you’re doing? And then making adjustment in your legacy code based on what you’ve learned. These libraries of evidence, you could think of them as libraries that you plug in to kind of speed up your refactoring. So you don’t always have to create a new image library. You can just plug in one to draw the image that you’re trying to draw within your application. That just makes things much faster, right?

And then finally, the step number five is to continuously execute. And you want to execute, because otherwise, that programming is not going to take. And I know it might be frustrating, because I keep comparing the brain to legacy code. And you might be thinking, Henry, something along the lines like, Dagna, but if I created the feature and deployed it, then that’s it. That’s it. I don’t have to do anything more, right? But with the human brain, basically, we need to continuously execute, keep on implementing the new pathways. Because as we think new things, as we do new things, our brain changes its hardware, right? So the programming lines are not programming lines, they’re actual neuron and synapses that are getting built in our brain, and that takes time. Because we need to grow those pathways, we need to reinforce and strengthen them. And by continuously executing different patterns of thoughts, different patterns of behaviors, different kinds of beliefs, that’s going to take time before it actually sinks in. So these are the five steps.

Henry Suryawirawan: Thanks for outlining these five steps, right? Again, just to repeat, identify the root cause, plan the refactoring, script new responses. I feel that this step one, two, three is like the TDD loop, right? Where you probably want to write the test cases, right? You plan the refactoring, write the test cases so that you can actually implement the production code, the good production code. And then the fourth step is actually build libraries of evidence. So this is kind of like enriching your past experience, maybe from other people. Or maybe a model that you want to follow and ask from. And the last one is to continuously execute. Think of it like maybe a continuous integration pipeline, that helps you to actually continue to adopt new behaviors.

[00:33:45] Script New Responses

Henry Suryawirawan: So I think from all these steps, what I find really, really important is actually step number three, which is to script new responses, right? So sometimes, you know, all this legacy mental code is like habit, right? It’s a bias. And in order to change that, it’s not so easy. It’s like changing your habit, right? I think it takes a lot of small steps and an incremental conscious step that you can do. So tell us maybe, maybe from your experience, you know, changing your communication style. How can you use a new script to actually change your communication style?

Dagna Bieda: Yes. So I give really great examples within the book, specifically in the case of burnout, imposter syndrome, trouble dealing with other people, and self marketing struggles, the four common themes that I mentioned. And in the book, I actually outline some of my clients’ case studies. So these are based on my work with real engineers in engineering positions who are struggling with those particular things. And when it comes to scripts it’s really few steps that you want to outline for yourself that when you notice that a trigger is coming or you want to take a specific action, you remind yourself of those few steps to take, right?

So the scripts are very simple, very easy, nothing complicated, right? It could be as simple as when you notice, for example, that it’s your turn to speak and you don’t want to sound like an arrogant asshole, how I used to sound. So you essentially take a pause, take a moment, take a deep breath to relax yourself and create that environment of psychological safety. Breathing is a phenomenal tool in order to do that. And say the things in a way you want to say them.

So when it comes to being assertive, the first thing that you want to do is make sure that you are acknowledging what other people are bringing to the table. Then you’re stating your concerns or talk about your needs, depending on what it is that you’re talking about. And you have to make all that, making sure you’re not trying to manipulate anyone else into agreeing with you, right? So still giving people the option to disagree with you and being okay with that, right? You’re just there giving your own opinion, sharing information, but without putting the pressure on others to agree with you. So that’s basically, um, the assertive communication bit that I wanted to share.

And that’s how my script would look like, right? The important part about the script is you have to be aware and notice when you want to invoke them. And it’s kind of like going to the terminal and essentially manually invoking the script. There’s no way to automate it other than repeating it. And then by repetition, it will finally sink in, those neural pathways in your brain are going to be created, and your new automatic responses are going to be overwritten. And they’re not going to be the old ones like in my case, being arrogant, being direct, being harsh and rude, but being assertive, instead.

Henry Suryawirawan: Yeah, so think of it like the interrupt, right? In your book, you mentioned it’s like an interrupt. So a program that keeps running, you know. Sometimes you just want to keep a pause or maybe you just want to change, tweak the behavior a bit, right? So it’s like an interrupt that you put in the program to give a signal that, hey, maybe you should try something else, right? So I think this script is really powerful, because, you know, you can’t just change the habit overnight, right? You need to take a small incremental step. And also the most important thing like you should feel psychologically safe to change the behavior, right? Sometimes it takes a while before you can actually do so.

[00:37:33] Merge Conflicts & Cognitive Dissonance

Henry Suryawirawan: And as we go through a lot of refactoring, especially when you change a lot of legacy code, obviously, one of the biggest challenge in coding is actually about merge conflicts. So when you change so many things like you don’t know what’s going to happen, right? Maybe there are more bugs. So in your book, you also cover about this challenge about merge conflict, which is about the cognitive dissonance. Someone may experience something that gets them into some kind of a weird situation where they don’t believe in what they’re doing. So maybe tell us about how we can resolve this conflict.

Dagna Bieda: I love that you brought it up, right? Merge conflict in programming is so common. And it’s so annoying, because you just upload the code and you know, you want to be done with merging in your feature request and then there’s a merge conflict and you have to fix everything, and it’s so annoying, right? And with mental code, it’s the same kind of concept, because you’ve worked so hard to implement this new code, but it’s not sticking for some reason, right? And that’s when it’s important to understand this concept in the setting of mental programming. Basically, you’ll notice a merge conflict is coming up if you notice that cognitive dissonance. Cognitive dissonance comes from holding two beliefs who are at odds with each other, right?

So for example, you could believe things like, I am an honest person with integrity. And, at the same time, believe that marketing is lying to people. It’s basically deceiving other people. And then, say you work with a coach, or you’re trying to get that promotion, and you’re trying to market yourself more. What’s going to happen? You’re going to feel a lot of discomfort. It might show up as a tension in your body. You might notice that even though you consciously are trying to market yourself more, the words are not coming out of your mouth, like your behavior is not in integrity, what it is that you’re trying to do, because there’s a merge conflict. The two conflicting beliefs that you hold. I’m a person of integrity and marketing is lying to other people, are at odds with each other, right?

So you have to update the model. And obviously, we don’t want you to update the model of yourself being, yes, I’m a cheater, I’m a liar, and I’m okay with that, because that’s not what we’re about here. But you can update the model of what marketing is. What if marketing meant actually educating other people with integrity about what it is that you have to offer and the value that you get to bring? If you update that model of marketing, there’s no more conflict. Because all of a sudden you can market yourself as a person of integrity that you believe you are, right? So being on the lookout on those merge conflicts is kind of an art in a way because you have to be really observant and aware of what is it that is coming up for you internally or externally, right?

And a lot of the time, that’s when having that third party perspective is so valuable. Because you could be following the advice from my book, for example, and not notice that you’re having a merge conflict. But then you talk with your friend who you worked with, two companies ago, two jobs ago, and they’re like, hey, by the way, you said you were going to do this, but your behavior is completely out of line. Like, there might be a merge conflict there. So, like, you need that third party perspective that will help you notice those merge conflicts.

But I love that you brought it up, Henry, and that we got to share this idea, because I think it’s a very fun parallel between the programming code, the technical that we know that we do in our daily jobs as software engineers, and the one that’s happening in your own brain.

Henry Suryawirawan: Yeah, definitely. It’s quite fascinating to discuss about this, right? And with other merge conflicts that we experience in life, right? So sometimes it’s very risky to just, you know, apply the merges ourselves, right? Especially if we don’t fully understand the kind of changes that we are getting from the other branch, for example. And it’s always important maybe to bring the third party, ask, you know, what these changes are, before you actually embed that into your programming. So I think that’s kind of like a good analogy of, you know, how to resolve merge conflicts, right? So I think that’s a key for everyone who feel that the change that you want to aim doesn’t feel right somehow in your belief. So maybe that’s why solving merge conflicts by asking from others, maybe coach, maybe your friends, will be a great help.

[00:42:07] Common Bug #1: Burnout

Henry Suryawirawan: So you mentioned about the four common, you know, bugs, right, that typically we have. So during our last section of our conversation, I’d like to probably take one or two, maybe some of your favorites, right? So maybe if you can pick either the burnout, imposter syndrome, dealing with other people, or self marketing. Maybe we can take some of them to actually go through, walk through what are the common bugs from each of the category and how we can resolve that.

Dagna Bieda: Awesome. Okay. Yes. These are the four that are super common, I see over and over again. And when you think about these four obstacles, they’re usually the ones that are holding you back from thriving in tech or in engineering or in your career. And that are stopping you from getting that, whether it’s success, fulfillment, money or impact that you’re looking for in your career. So when you can refactor these out, then you can open yourself up to incredible opportunities that are available there in tech, right? I feel like tech is such an incredible industry where so many things can happen.

So in terms of like the one that I would like to dive into would probably be burnout. Why? One, because it’s very personal to me. I’ve experienced it firsthand. But two, there are some, I would call them legacy mental programming that led to my burnout that I see that are very common among the engineers that I used to work with and I work with right now as a coach. So number one is perfectionism. And perfectionism can lead you to burnout whenever it’s an overdrive, right? So there are two different configurations that I want to distinguish here. Being a perfectionist versus being a high achiever, right?

When you’re a perfectionist, you’re going to have impossible standards, and that is a highway to burnout, basically. Because you’re always striving to do more, to do better, and there’s never enough. You’re never good enough, because the perfection is just impossible. But if you’re a high achiever, you set the bar high, but your mindset is set on the journey, not the destination. So you’re okay with failing as long as you learn and grow as a result. So you don’t want to be a perfectionist, because you’re going to burn yourself out just like I did. You want to be a high achiever, which is phenonemal for, you know, the kind of growth that’s possible and achieving a lot in your career. But without the detrimental to mental health effects that perfectionism has.

The second legacy mental programming that led to my burnout was hard work bias. And I say it over and over and over again. Because, again, as engineers, as we go through our education, we are essentially trained to overvalue the technical skills that are difficult and hard and undervalue the people skills, but also things that are boring, that are copy-paste, that are just like, yeah, I don’t want to do that, right? We tend to, as engineers, overvalue things that are hard and assign more value to things that are difficult and hard and undervalue things that can have a massive business impact that are easy, right? A simple copy-paste, a simple change of the button’s color can have a business impact, right? And engineers tend to dismiss that, because, again, we tend to overvalue what’s hard, what’s difficult.

In terms of my particular experience, I remember clearly working on these two tasks back to back. One of them was essentially super interesting, super fun. I loved doing it. It was intellectually stimulating, challenging, and I was so proud of myself when I did it. It was essentially rewriting the mobile app that we had and the build time. I was able to reduce the build time of the app from five minutes and something to like 20-ish seconds. Like, whoa! You know. I finished it and I was just so proud of myself, Henry. I mean, you, you can probably tell, I can see you’re smiling and you’re like, yes, I did that too in the past. And then literally, the next week, I had this boring copy-paste task where it was kind of like setting up a build for one of the bigger clients for the business, but it was boring. It was super boring. So I did it really quick, because I wanted it off my plate. I wanted to do more fun stuff.

And guess what? After I did my first task that I thought was hard and difficult and was “wow, that I did it”, nobody cared. It changed just my life and one other engineer and nobody cared. It didn’t have impact. I was happy, but that’s it. The second boring task that I did faster than the time was allocated for, because I wanted to not do it for too long because it was boring, everybody from like the sales rep, the marketing rep, the customer representative, my boss, their boss, everybody was like, Dagna, that’s amazing, wow! Turns out that that client brought a lot of revenue to the business. And keeping that client happy made the business bottom line flourished. And that’s when it clicked. You know, it clicked to me that I have to focus on business impact rather than valuing what’s hard or stimulating and fun and challenging. That’s sometimes easy, if it has the impact, it’s the way to go. That was a huge eye opener. And I see it over and over and over again in my coaching practice, too. We just tend to value what’s difficult.

The third one that I want to talk about, the legacy mental programming that led to my burnout, was basically lack of boundaries. This concept, I have not heard about boundaries before I ended up in therapy trying to fix my burnout back in 2019 after that one on one when I was crying in front of my manager. Totally embarrassing. So, the idea of boundaries to me feels similar to the idea of testing practices. When you’re in college, when you’re in boot camp, you don’t really care about that, right? It’s only whenever you get your first professional job, you start, I mean ideally, hopefully, you start learning about tests and testing practices so that whenever you’re creating code, you can anticipate some problems that might happen.

So in a way, tests are there to protect your system, the integrity of your system, and so are boundaries. Boundaries are meant to protect your well being so that you’re in a good place. You don’t burn yourself out. You don’t do things that are potentially bad to your well being. But I haven’t learned that concept until, you know, it was kind of late. But if you can learn about creating healthy boundaries for yourself, it’s kind of like learning about testing in college, right, before you actually needed. So then you can wow the interviewers whenever you’re getting your job interviews as a fresh grad. And the same idea applies here. If you know how to put protective boundaries, you’re going to be in a good place. You’re going to be able to avoid a lot of trouble down the road that are bound to happen, if there are no boundaries or bound to happen if there are no tests.

Henry Suryawirawan: Wow, thank you again for such a great story, right? Personal story. So this is kind of like from your experience and your career, right? So I think just to mention again, the typical, you know, burnout anti-patterns, you call it, you call them, right? So the first one is the perfectionism bias, right? So you always strive to be perfect. You know, you want to the level of details that is sometimes impossible, right, for some people to follow. This is sometimes gets you frustrated and also spend a lot of time to actually do it. The second one is about hard work bias. So always choosing the work that is more difficult, more engaging, maybe mentally, intellectually more engaging. But actually you mentioned in the beginning, business comes first, right, always. And maybe quality engineering comes next.

And the third one is about clear boundaries. So I think this is also something that a lot of people experienced maybe during pandemic, maybe in the past few years where there are a lot of changes in the industry, right? Be it AI, be it the layoff and all that. Protecting your mental health and well-being is definitely an investment. You mentioned that in the book as well, so don’t forget about coming up with boundaries, right, be it, you know, like not taking too much on your plate, right, or maybe also ask help. I think that’s very important as well, not everything must be done by yourself. Maybe you should check, you know, in your life at the moment, is there any boundaries that are kind of like crossed too much. So probably you should also try to protect that.

[00:51:21] Common Bug #2: Dealing with Other People

Henry Suryawirawan: So maybe we have one more common bugs that you can cover quickly. Is there any other favorite that you would like to cover?

Dagna Bieda: Yes, the idea of dealing with other people, right, that being a struggle. And, you know, again, I will be drawing from my own personal experience, which is when this weird thing happened in my career. When someone who wasn’t even a boot camp grad, he was a self taught dev, got promoted over my head to a team lead position that I wanted. And at first, I was outraged, because I was a senior engineer. I had more years of experience. I had better education. I knew more. But as we already talked about it, I didn’t have those people skills and the communication skills, right?

So in the book, I explored this concept of lone wolf versus a master collaborator. And who I was at the point in time when I missed out on that promotion and being super angry about it initially, I was being a lone wolf. I cared about mostly myself, didn’t really care that much about team dynamics. I was interested in pursuing and growing my technical knowledge, but I didn’t necessarily share that knowledge with my teammates, like over lunch and learn or a presentation or a meetup or whatever. And so, you know, when you’re a lone wolf, you’re going to get to that senior engineer tops. But forget about being a staff engineer, forget about being an architect, forget about becoming a CTO. Because at the end of the day, as engineers, we work with other people, creating products for other people. And so like the people aspect is just unescapable.

But if you can figure out how to work effectively with other people, then basically, you’re able to create a lot of impact, as a master collaborator. And this is who that person who got promoted over my head was, there will be much more opportunities for you, right? Because you grew your impact. Instead of being that solo person who has 24 hours within a day. If you get to lead a team, you’re able to have, you know, if there’s three people on your team, 3 x 24, 72 hours in your day. And that’s kind of the output that you get to produce, that you get to claim, you know, rewards for in your career. So it’s really important to understand this idea of where do you as an individual contributor thinking about progressing in your career lie on this spectrum from on one hand being a lone wolf to being a master collaborator.

Because if you want to progress in tech, if you want to have impact, you need other people on board. You need to master dealing with other people. And a lot of folks I work with tend to just call it like, oh, office politics, right? I don’t want to deal with office politics. It’s like, okay. But what if it’s not just office politics? What if you’re just dismissing it, because you don’t have the relevant skill set that will help you navigate the people aspect of your job, right? We tend to, as engineers, go so deep into technical that sometimes hiding behind our computer is comforting, right? Because we know what’s happening, we know what’s going on, we can kind of grasp it intellectually. But when we don’t have the equivalent of those skills when it comes to relationships with other people, that can be daunting.

And those skills, by the way, if you don’t have them, it’s not your fault, because they’re not part of the engineering education. Engineers are not being handed a soft skills playbook. It’s something that if you’re lucky, you learn from having an incredible manager or incredible teammates. But like, relying on luck isn’t the best career strategy. So people skills when it comes to communication, collaboration, becoming that master collaborator. is what sets you apart And also helps you in a difficult economy, right? Because that’s how you become that highly skilled professional that people want to hire. You become the top of the top, creme de la creme, because you’re able to effectively work with other people. And many engineers are missing out on that.

Henry Suryawirawan: Yeah, definitely this is one of the common bugs in many engineers, right? Maybe sometimes, because of, maybe also our interest in the very beginning, we like to talk to computers, play with just computers all by ourselves, right? So we tend to neglect, you know, the people’s soft skills aspect. But I think as many people have learned as well, especially those who went into management and become leaders, right? Soft skills is definitely maybe the number one priority that you should continue honing and continue upskilling, right? Rather than technical, so that you can actually progress much, much more, become a master collaborator where people would like to work a lot more with you rather than the lone wolf, right? So someone who is like a diva or, you know, like this badass star that nobody likes.

So thanks for raising that. Yeah, thanks for raising that. So unfortunately we can’t cover the other two bugs, the impostor syndrome and the self marketing or self promotion. So I’m sure people can check out from the book by Dagna. So it’s available on Amazon and wherever you find the books from.

[00:57:02] 3 Tech Lead Wisdom

Henry Suryawirawan: Which brings us to the last question that I have for you, Dagna. I call this the three technical leadership wisdom. I always ask this from all my guests. If you can just think of them just like an advice that you want to give to us. Maybe if you can share your version of wisdom so that we can learn from you.

Dagna Bieda: Yes, so the very first one is that your brain works just like code. So you can reprogram whatever is not working.

The second one, the wisdom that I want to leave you with, is to allow the feedback in. Because you can’t grow without feedback. You need other people in order to understand what’s holding you back. Because, like we talked a moment ago, right, as engineers, we work with other people, create products for other people. So that aspect is just inescapable.

And then the third one is if you see people on your team struggling in their career right now, it’s most likely that they’re experiencing one of the four bugs we talked about today. It’s either imposter syndrome, burnout, they have trouble dealing with other people, or they have self marketing struggles. And by understanding what’s the exact programming in their case that might be holding them back, you’ll be able to help your teammates advance in their career as a leader. So these are the three wisdom that I would love to leave you with.

And I would love to connect with you guys on LinkedIn or through my website. And of course, we did do a deep dive today on my book, Brain Refactor, but if you want to know more, get more details, just like Henry said, feel free to grab it off of Amazon, or you can find it on my website, themindfuldev.com in the top book which has the link to Amazon. And if you do read it, I would love to hear your feedback. I would love to hear what resonated, what didn’t, and talk about the book.

Henry Suryawirawan: Fantastic. So for those listeners who are interested in this concept of brain refactor, and you kind of like can relate to what Dagna has mentioned earlier about her experience and some of the strategies that we can choose in order to refactor some parts of our legacy code, please do reach out to Dagna, right? So you can find out on LinkedIn. We’ll put that all in the show notes.

So thank you so much for your time today, Dagna. I feel like I’m refactoring my brain now with some of these common bugs that I have. So thank you again for pointing out good strategy, practical tips for us.

Dagna Bieda: Absolutely. My pleasure. Thanks for having me.

– End –