There are 4 common obstacles that are stopping engineers in
progressing in their journey. The imposter syndrome, the
burnout, trouble dealing with other people and self marketing
struggles. And it's kind of the same
concept with the legacy mental goal that's hidden in your
brain. Your parents put stuff in there.
The past experiences, your teachers, your friends, they
have put programming into your brain before you could look into
what's there and do something about it.
We tend to ask 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. 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 ACTO.
Because at the end of the day, as engineers, we work with other
people, creating products for other people.
Hello everyone, welcome back to the new episode of The
Technician 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
staff 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 turning to coach who is actually helping a
lot of software engineers to actually actualize themselves to
become a better person and engineer all together.
So welcome to the show, Dagna. Thanks so much for having me,
Henry. I'm really excited to be here
today, right? Dagna, maybe before we go into
the whole tiers 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. 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 4 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 ACTO of like a smaller to
mid size 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 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 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.
Those four things, I have all of them.
I'm sure everyone here also have 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.
Wow, nice. That's right.
That nice. Showing the book.
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.
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 only on it only two years ago.
And then when I started, I started to be 6 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 I got too slow and
I was impatient and I went 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 1 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, OK, 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've 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 e-mail. I just didn't care because I
thought nobody valued what I had to say.
And so when I wore 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, what 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.
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?
Couldn't burn out or might be frustrated at work, Maybe they
just can't progress in wherever they are in their role or their
job, right. 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?
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 code base, right?
And then you kind of have to jump in and you have to 1st
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 happen to watch or, or like live next to and and
observe and model 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 have 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 a
good 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 code
base that you get to refactor whenever you choose.
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 program
learning 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 stop in life, what make
you stop 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. Yes.
So feedback from a programmer's perspective is super valuable,
right? If you deploy an app and it gets
into your user sense 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 the same
context of your own mental programming.
What if the feedback that you get, just curious 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 a old 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 see, 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 from 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.
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.
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 these kind of feedback definitely helps us to
give us signal. But also you pointed out 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 managers feedback or performance
review feedback, but sometimes the situation around you may be
the situation that happened towards you, like the
mispromotion or whatever the results that you didn't get.
These are also good feedback for you to reflect.
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.
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 mechanisms, 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 in our minds, you know, never.
We're 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 driving 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 worked and how it operates so that you can
reprogram it. And choose to grow rapidly
because you are safe. I hope that makes sense.
Yeah, so I think definitely it has been covered in many books
as well, right, about this evolution of our brain right
from our primates life, so to speak, right, the caveman or
maybe you know, few hundreds 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.
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 trying
to find excuses and things like that.
And definitely is one of the refactoring that we have to do.
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 the
these three common refactoring so that this is like the basic,
you know, renaming stuff, moving class and things like that.
I I assume so maybe tell us about these three common
refactoring mode? 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. And 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 off. 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 that there's a ridiculous conversation 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 1st 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.
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 a 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 sites that we choose and we fight
against each other because of that.
And I think one important thing is about the maintaining the 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. 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, it's 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 dots.
So maybe if you can outline us what are these five steps and
maybe how can we use it, maybe using an example?
Yes. So let's name the steps 1st and
then we can dive in one by one. The first one is to identify
root causes. The second one plan out the re
factor. Third one script new responses,
4th is build libraries of evidence.
And then the first 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, it's like,
OK, 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've 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 encoding, 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 want to plan out the refactor, right?
We want to know what is it that we're replacing with what, what
are the potential side effects that we should be experienced
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 skill set. So I had to implement that skill
set 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.
In 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 are on
the 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 first 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 1:00 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 matter.
So when you're bringing building libraries of evidence, it has to
match to what is already there. You want to write libraries that
are kind of based on what it is that you already believed to be
true. The four that I mentioned are
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 4th 1 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 are 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 #5 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. 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 123 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 the production code, the good
production code. And then the 4th step is
actually build libraries of evidence.
So this is kind of like enriching your past experience
maybe from other people or maybe 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. So I think from all these steps,
what I find really, really important is actually step #3
which is to script new responses, right?
So sometimes, you know, all these 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 in 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 scripts to actually change your
communication style? Yes, so I give really great
examples within the book, specifically in the case of
burnout, imposter syndrome, trouble dealing with other
people in self marketing struggles, the four common
themes that I mentioned. And in the book I actually
outlined 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 phenomenal tool in
order to do that and say the things in a way you want to save
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 the
option to disagree with you and being OK 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 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 go 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.
Yeah, So think of it like the interrupt, right?
In your book, you mentioned it's like an interrupt.
So it's a program that keeps running.
You know, sometimes you just want to keep a pause, or maybe
you just want to change, take 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. And as we go to 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 conflict. So when you change so many
things, like you don't know what's going to happen, right?
Maybe there are more bucks. So in your book you also cover
about this challenge about the merge conflict, which is about
the cognitive dissonance someone might 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. 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 emerge conflict is coming up.
If you notice that cognitive dissonance, cognitive dissonance
comes from holding 2 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 submerged
conflict, the two conflicting beliefs that you hold.
I'm a person of integrity and marketing is lying to other
people or 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 OK with that because that's that's not what
we're about here. But you can update the model of
what marketing is. What if marketing mean 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 conflict 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.
Yeah, definitely. It's quite fascinating to
discuss about this, right? And with other much conflicts
that we experience in life, right?
So sometimes it's very risky to just, you know, apply the
mergers 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 us, 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 much conflicts, right?
So I think that's a key for everyone, one who feel that the
change that you want to aim doesn't feel right somehow in
your belief. So maybe that's why solving much
conflicts by asking from others, maybe coach, maybe your friends,
it would be a great help. So you mentioned about the four
common, you know, box, right, that typically we have.
So during our last section of our conversation, I'd like to
probably take one or two and maybe it's some of your
favourites, right? So maybe if you can take either
the burnout, IT process 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 box
from each of the category and how we can resolve that.
Awesome. OK, yes, these are the four that
are super common I see over and over again.
And when you think about these 4 obstacles, they are 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 first hand. 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 burn out 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 OK 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 phenomenal 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 see 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 based, that are
just like, yeah, I don't want to do that, right?
We tend to ask 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 based, a simple
change of the buttons 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 love 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 5 minutes
and something to like 20 seconds.
Like, wow, you know, I finished it and I was just so proud of
myself, Henry. I mean, you, you, you could
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 had 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 I was boring everybody from like the sales Rep, the
marketing Rep, the customer representative, my boss, their
boss, everybody was like dogma. 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 flourish.
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 is 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, which is tend to
value what's difficult. The third one that I want to
talk about, the legacy mental programming that led to mind
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
feel 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's 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 need it. So then you go, wow, the
interviewers. So whenever you're getting your
job interviews as a first 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. Well, 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 even intellectually more engaging.
But actually you mentioned in the beginning, business comes
first, right, always. And the 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 rights, 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 of 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. So maybe we have one more common
box that you can cover quickly. Is there any other favorite that
you would like to cover? 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 grab, he was a
self-taught dev, got promoted over my head to a team league
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, and as we already talked about it, I didn't have those
people skills and the communication skills, right?
So in the book, I explore 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. They don'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
presentation or meet up 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
ACTO. 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 * 2472 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 the 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 office politics, right?
I don't want to deal with office politics.
It's like, OK, but what if it's not just office politics?
What if you 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.
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 would 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 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 better star
that nobody likes. So thanks for raising that.
Exactly. Yeah, thanks for raising that.
So unfortunately, we can't cover the other two blocks, the
imposter syndrome and the self marketing or self promotion.
So I'm sure people can check out from the book by deck net.
So it's available on Amazon and wherever you find the books
from. Which brings us to the last
question that I have for you, Dagna.
I call this the tree 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 vision of wisdom so that we can
learn from you. 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 their 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 in poster 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, themindfuldeath.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. Fantastic.
So for those listeners who are interested in this concept of
brain refractor and you kind of like can relate to what Deckner
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 Deckner, 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, Deckner. I feel like I am 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. Absolutely.
My pleasure. Thanks for having me.