The number one result of a really good lead is reduce
technical debt, seeing technical debt just melt away and then
stop occurring in the future. If you're a good lead, your
systems will be stable all the time.
Hey everyone, my name is Henry Surya Virawan and you're
listening to the Technically Journal podcast.
The Show Where I'll Be. Bringing you the greatest
technical leaders, practitioners and thought leaders in the
industry to discuss about their journey, ideas and practices
that we all can learn and apply to build a highly performing
technical team and to make an impact in your personal work.
So let's dive into our journal. So Shelly, in the beginning I'd
like to ask you probably if you can share a little bit about
your career journey, especially the highlights or turning points
that you think we all can learn from.
Sure. Yeah.
So I have been in tech now for 25 years and my journey, you
know, started as like a junior dev to senior and then lead.
And I think that my career journey is interesting because
I've also had experience as an author now and a trainer
instructor. I have 20, so like Pluralsight
courses. I have courses on Udemy and in
about a couple weeks, probably by the time this is out, it'll
already be out. But now I'm a LinkedIn
instructor as well. So I've had a lot of interesting
experiences, but I think my hardest journey was in
leadership, trying to learn how to transfer technical skills and
then learn soft skills and then lead people.
That's very difficult for people that are technical, so that's
why I'm here today. Wow, you have so many courses
out there. So maybe a little bit of tips
and tricks for people who would like to also build their online
courses. I know it's like very trendy
these days after Pandemic especially, so maybe some tips
from you. Sure, yeah.
Oh, people ask me this all the time.
First of all, when you write courses, keep in mind your
audience. Generally when I write a course,
I have had that same problem previously, right?
I always teach stuff that I struggled with that makes the
best content overall. And with online courses
especially, the production quality really matters because
people expect high quality now, even on YouTube.
Any platform. And when you're writing code and
you're walking people through code and teaching it, increase
your font size, make it like 18 OK, because people are watching
this on their phones. So yeah, like I can't read 10
point font on my phone very well.
I don't know about you, but. Yeah.
So neither do I, but I think those are really good tips,
right. So teaching what you struggled
before, right. And also keep in mind about your
audience. And I think, yeah, production
quality these days do matter, especially with all this like
Mr. BS production and all these great, great content creators
out there. So I think we are competing
against them as well. Hey, thank you for being part of
the Techly Journal community. This show wouldn't be the same
without your ears, and you are the reason.
This show exists. If you're loving TLJ and want to
see it keep on growing, consider becoming a patron at
techligional dot dev patron or buying me a coffee at
techligional dot dev. Coffee.
Every little bit helps field the research.
Editing and sleepless nights that go into making this show
the best it can be. Thanks for being the best,
listeners, any. Podcast could ask for.
And now? Let's get back to our episode.
So let's move on to the main topic today, Which is your book,
right? Which is you're still currently
writing with Manning Early Access program, so lead
developer, career guide. So in the beginning you
mentioned that you also struggled a little bit about
leadership, you know, learning about soft skills.
But in the beginning, right? Tell us what made you wanted to
write this book? Yeah.
So I guess this whole thing started.
I pitched it in October 2022, so it's been a little over a year.
It takes a long time to write a book, by the way, but I was
really inspired by Alyssa Miller.
She has a guide on Infosec and I saw it and I was like infosec
career guide, like there should be one for lead developers
because we're not managers and we're not the person who is
hiring people, right? So it's this kind of step up
from technical to leadership, but not like all the way.
So you still have to do technical stuff, but then you
still you have to learn leadership as well.
And it's really, really hard. Most people like me who excel at
technical stuff are sort of just thrown into this role with no
mentor, no guide, no nothing to like learn leadership skills,
how to run meetings, how to interface with clients.
That was the hardest part for me was being the face of the
development team to the clients and being trusted to make
decisions, you know, And it was just very overwhelming at 1st.
And as I said, if I struggle with anything, I'll teach it
after I figure out, like, how to do it properly.
Yeah, because I don't want anybody to struggle as I have.
Right. I think most of the engineers
when they studied computer science or software engineering
right? I think most of them were not
taught about leadership or even soft skills.
Like great soft skills, right? We all have to self learn
through books and also painful experiences, you know, having to
deal with stakeholders and clients just like what you
mentioned, right? Like I mentioned, there are so
many different flavours of lead developer title, right?
So what are some of the other flavours in the industry that
you know of so that people maybe can set the same same level of
understanding? Yeah.
So the multiple flavours, I think it comes from company
cultures and kind of each company's approach to tech
overall. I've heard lead architect, so
there are some overlapping skills there.
But the main thing is that if your company has a lead
architect, that position is more technical.
It's more like you're in charge of the architecture, right,
architect architecture. So you're making diagrams and
flow charts and, you know, stuff like that.
Whereas a lead dev is more the person that has to be talking to
the project managers, the clients, the actual team to
relay all of this information, make decisions and be trusted
with that process. Yeah.
And then there's kind of like a tech lead.
Tech lead, I feel like is more in line with lead architect, but
like I've seen so many companies approach things completely
differently, right? So Tech lead, Architect, lead
dev, they're all similar, right? But they just have some key
differences. I hope that answered your
question. That's pretty abstract.
And I think it confuses a lot more by you know, going into
specific industry or big tech versus you know traditional
companies, right. But I think we mentioned a few
titles already, right. Hopefully people at least have
the same level of understanding, OK.
We are talking about this kind of role.
Then you mentioned that this role specifically right is
expected not just be good at tech, which is probably in the
beginning, they are really really good in tech, but also
they have to exercise their leadership skills.
So tell us why this leadership skills is also becoming equally
important in this role? Yeah, absolutely.
Leadership skills in general, they are kind of important for
everyone actually. But for this role particularly,
it's just so hard to learn while you're trying to also be
technical at the same time. But these skills like holding
meetings, outlining approaches, you know, just talking to
people, talking to stakeholders, interfacing with humans is what
I like to call it. A lot of us, me especially, are
people that like to not talk to humans all day, right?
Like we got stuff to do, we've got code to write.
And me personally, like, I just like quiet time, right?
I just like to be alone and all of that.
So with leadership, it's more like you have to understand how
to resolve conflict, how to assess conflict.
I'll talk a lot about conflict because that was definitely the
hardest thing for me to learn. But yeah, you have to be
organized. You have to be a mentor.
You have to lead an entire team of projects.
Your product, I don't know. There are a lot of different
aspects to it. Wow, you throw so many different
things right? Different responsibilities so to
speak. When you get into this title, I
hope people are not scared, right?
But maybe from your experience right?
And in your book you also outline this.
What are some of the main responsibilities that we should
expect when we deal with lead developer?
Yeah, absolutely lead devs. I think one of the most
important responsibilities is mentorship.
You have to be able to help people grow and improve, because
without that it's just like people need a guide right?
And like I personally have many mentors, but lead devs I think
need to be able to understand dev's problems as well and
communicate to project managers and ensure that people aren't
over tasked as well. That is a huge one.
Help the project manager, help your team.
And then on top of all of that, handling client requests, making
sure that when clients and this is something that happens a lot,
that's why I'm smiling. Clients will try to tell you
what to do and how, and they're usually wrong.
They're usually completely wrong.
So you have to find a way to like diplomatically be like.
That's a good start, but let me show you this this other way
that's actually new and actual best practices without saying
that with like an attitude like I just did.
Yeah. Yeah.
So for people who may not work with external clients, right,
you can also think client as internal clients, I guess,
right. So we have business
stakeholders, yeah, we have product managers or whoever in
the company. When you build product that you
are given a requirements, sometimes they give you the how
as well. But yeah, I think what you said
is right. So the task of the lead
developer is to actually help guide these kind of
conversations with them. So you mentioned about
mentoring, right. I think many of these engineers
also as they grew in their career, sometimes they have good
mentors, sometimes they didn't have good mentors, right.
How can they become confident as a mentor now, now that they
assume this position? Yeah, I love that you brought
that up. Not all mentors are good, and
honestly, having no mentor is better than having a bad one.
But to avoid being a terrible mentor, I think we need to keep
in mind that everyone's experiences are their own.
My experience and advice wouldn't apply to everyone all
the time, so that is why everyone needs to have a group
of mentors. But leads especially need people
to help them. Besides my book, you should also
just talk to people. Ask for help because that is
something I did not do and that is why it's in my book.
I'm sorry if I didn't answer your original question, I think
I went off on a tangent. No problem, right.
So yeah, I think like having bad Mantas sometimes, sometimes it
can give you the reverse effect as well, right.
So you know that that was bad. So that is probably will avoid
it. Yeah, you will avoid it in your
next maybe experience, right, when you mentor people.
But I think yeah, bad mentorship sometimes can leave a lasting
effect, sometimes that person also may not want to go to
management or leadership because of that.
So I think another thing that as with all these kind of role that
has multi dimensional kind of a task and responsibilities,
right, Sometimes it feels very difficult to gauge how
successful we are in that role, right.
Some people will think or I just go into different meetings,
communicate with a bunch of people.
You know, maybe write a bit docs here and there, write a little
bit code here and there, but I don't seem to kind of like
finish something end to end. So how do you actually measure
for, you know, someone who is successful in this role, the
developer role? Yeah.
First of all, I mean, hopefully your job has reviews and will
actually tell you if you're doing well.
However, that is not always the case.
I would say that honestly, the number one result of a really
good lead is reduce technical debt, seeing technical debt just
melt away and then stop occurring in the future because
the person is making the correct decisions so that the tasks are
performed just the one dime instead of, you know, oopsie,
this task isn't exactly correct. We're going to push this code
anyway and then fix this resulting bug later, right?
If you have a clean code base and you know what you're doing,
and you make the right decisions and you do the maintenance, do
the system maintenance, you know, Oh my God, I my #1 pet
peeve is when people don't do maintenance, things break and
they fix them and they think that that's an OK procedure,
Things should never break. If you're a good lead, your
systems will be stable all the time.
That's really a great point because as we build a lot more
features, right, technical depth definitely pile up.
As you add more people normally also we'll have more technical
depth and I think some people might also have this kind of
impression that if everything goes well right, sometimes you
are not appreciated. So what do you think about this
kind of mindset? Oh goodness, I love this topic.
When you're not appreciated, Oh, that is the worst.
That kills your motivation, right?
So I would hope that you would be appreciated by your team at
the very least. In my experience, generally it
is leadership that kind of fails you in that instance, but that
is really, really hard. Generally, if I'm not
appreciated by leadership, I leave and I just find another
job, which is why I have unfortunately had like 27 jobs
now I've I've had more than that.
But yeah, it's so hard to feel unappreciated.
It makes you want to just not show up and to be complacent and
all of that. But I am here to tell you you do
not have to stay at a job that doesn't appreciate you.
There are lots of jobs out there.
Yes, the market is very tough right now, but trust me, like
there are better jobs out there. You deserve the best.
Right. Thanks for bringing up that
point. Right.
Because I agree with that because if you're not fully
appreciated and it is prolongs for a long time, right, I guess
it's pretty miserable. You also want to feel fulfilled,
right? Doing your job that you love,
but at the same time also appreciate it, right, as a
result of that. So I think yeah, probably it's
time to take some other jobs if you feel you are stuck in this
kind of a role at the moment. So for people who are listening
to this, probably they are not there yet, right.
In your book you mentioned about the career trajectory someone
might take in order to get into this path.
So maybe if we can outline a little bit like how do you
actually start in your career until you get to this position,
what kind of a milestones or kind of like checklist probably
that we can aim to be a good bit developer?
Yeah, so kind of the standard path is the dev path, right?
So junior, mid and then senior lead, right?
My path was actually different. My path was really interesting.
I was a dev first, then a trainer, then a training
manager, then a lead developer. So there are different ways to
learn all of these skills, but I'll tell you, I do wish that I
had been a lead developer before I was a manager.
Because as a manager I was hiring and firing people.
And so it would have been a lot easier if I had kind of eased.
If I had done the lead developer thing first where I was a leader
and I was learning leadership skills, but I didn't have to
like interview or hire and fire people because that was just
awful. So apart from the normal career
path, right? If you're an engineer, you know
you start from junior media, maybe some people call it right,
meet developers, senior developers.
Sometimes you also went through like yourself, right?
You went through different route.
How about if maybe they have different speciality, right?
Is it purely because in some people's mind the perspective is
like mostly developer comes from the back end engineering point
of view, right? What about front end?
What about test engineer you know?
What about mobile developer? Can they also become the
developer? Absolutely, yeah.
I actually had a job recently where it was the first job that
I ever had where they had a lead front end developer and I was
like, thank you, thank you because I don't know anything
about front end development, front end and back end.
They are completely different. The processes, the procedures,
all of that. So I asked them for a really
long time. I was like, can I just get a
lead front end on this project? Because I don't know what I'm
doing and I need help. And they did it.
It was the best. I've never worked anywhere that
did that. And I don't know why.
Because like I said, front end is completely different and it's
really grown a whole lot because when I started in tech, there
was no front end. There was no, you know, it was
all just the dev. I was the designer.
I was the back end. Front end, yeah, just
everything. I'm so glad that they split it
up into different specialties, yeah.
Yeah. And these days there are so many
different technologies for each stream, right?
Like, you know, you have mobile front and back and all have
their own permutations of technologies, libraries and all
that. I'm sure it's pretty hard to
catch up, right. The industry has moved along so
much, I think compared to our time back then.
So last time I also had to do a lot of all these full stack
engineer, right. But I think it's pretty hard to
be full stack these days with a lot of these technologies.
Absolutely. Another thing is like when you
actually are given this opportunity, right, sometimes
you are hesitant, you're not confident.
How can you assess that you are ready for this, right?
Is there any kind of a science or is there any kind of
checklist again that we need to think and consider about before
we agree and assume this role? Yeah, I love that you ask this
question because I'm actually writing this chapter right now.
And overall, I mean, when do you ever know that you're ready for
anything? Parents will tell you this, like
no one's ready to get pregnant or have a baby, right?
Like, it just happens. You just kind of toss yourself
into the deep end and see what happens.
But with this particularly, I mean I think that people will
signal you for me specifically, like I was told kind of early on
that I had leadership qualities and so overtime I just learned
more. And for me, the moment that I
knew that I could manage A-Team was really when I was holding
meetings and just organizing agendas and speaking publicly
and just trying to keep everything organized.
Like you definitely have to be organized, but I think all of us
are, we're devs. I think devs in general have to
be organized to keep our code clean.
But yeah, I think that's pretty much it.
Yeah. It's a fairpoint, right.
I think like in any kind of roles, especially if I step up
right, you'll never feel ready, right.
So I think for those who are still thinking, OK, what kind of
things you need to consume or maybe prepare, right?
So sometimes it's just a leap of faith, right?
And you mentioned about signals from others, so it could be your
managers, it could be your Manders, right.
I think that provides some kind of cue that probably you should
be more confident in assuming you will succeed in this role as
well. So that's I think a very, very
valid point, right? Don't try to be ready.
So sometimes even like people say, when you feel you're ready,
you're too late, right? So I think we all.
Don't. That's exactly right.
Yes. Oh, I love that.
If you feel like you're ready, you're already too late.
I'm totally going to write that down.
That was a great quote. All right.
So you mentioned in the beginning about the leadership
skills, right. So maybe tell us what kind of
leadership skills that we need to think about because
leadership is a wide range kind of thing, right?
You mentioned about leadership styles in your book as well,
maybe a little bit of both, so that people can learn what kind
of leadership that is important for this role.
Sure. There are a lot of leadership
styles. I talk about 10 in my book.
So there's like autocratic, democratic, transformational,
transactional, servant, visionary, coaching, laissez
faire, affirmative and commanding.
So all of these approaches have been around for a really long
time. So the one that you want to stay
away from is commanding. Commanding is great in the
military. And that's all.
You can't be a commander of a dev team.
People need support and not pushing down to like push them
to work harder or faster or whatever.
So my style, like I have a combination of a lot of them.
But I guess for me, my overall approach is coaching, coaching
and servant. So I am not in charge, right?
Like I am helping teams to provide quality products.
I am not there to make anyone feel inadequate or slow or
anything like that. If anybody has performance
issues, that reflects on me as well.
It's not one person's fault. There's never like a problem
that one person caused. There was a whole path of stuff
that went wrong, right? So leadership styles, overall,
you need to curate your own style, a style that will match
your personality. And that's also why you need
multiple mentors to show you different styles to choose from.
So it's important to be comfortable as well, which
probably won't happen for a while.
But yeah, if you just know your own style and personality then
it'll really help you to be successful as a lead dev.
Yeah. So you brought a very good point
right at the end, right. So before we know what kind of
leadership style, we also need to know our sort of personal
tendencies or characteristics, right?
There are many personality tests that we can do as well.
Also, importantly, you mentioned about not commanding, right?
I think in some places I could still think that there are
people who are more commanding rather than, you know,
supporting sometimes even maybe they do the work themselves
rather than teaching others to do the same kind of work.
So I think a leadership style is something really, really
important for someone to maybe find your own path, find your
own style. And I think the good thing these
days there are so many content, maybe autobiography book that
you can find inspiration from. And I think, yeah, maybe you can
find the styles that work for you.
But again, just a reminder, commanding probably is not the
right thing to do in most of the organizations these days.
So let's move on to the technical site a little bit.
So in the beginning, we mentioned about technical debt.
Another point in your book you mentioned is about development
standards. So tell us why it is important
for technique to take care about development standards.
Yeah, so standards are really important because every company
has a coding style or a code library of just like plugins and
yeah, all kinds of stuff. I have worked at places that
prescribed to the point where comments were sent back in code
review. If there was like a typo
misspelling in a comment, not the actual code, like that's not
what I do, you know, Like, I'll tell you, it's there.
But that doesn't have to be fixed, like, right then.
But standards overall provide us with a way to write code on a
team that looks like one person wrote it right?
So it's all the same kind of style overall and just the
overall kind of architecture, right?
Every company should have a prototype so that when you start
a new project, you don't start from scratch.
There's already something like to use.
And that, I think is the most important part of having
standards is creating that prototype, that project that
people can just load and go. Yeah, so I think the usual
stuff, right? Like code conventions, like your
lintas, right? Or maybe even guidelines how you
do stuff right. Code reviews, maybe peer
reviews, right? So I think importantly, as a
lead developer, right, I think you should take this role even
if nobody cares about it. But I think you should take
charge and set the standards because the code base that has
different flavors of how people writing it, right?
So I think it's very very confusing and it won't be
maintainable in the future as well, right?
So apart from standards, of course the development process,
right development process is also very important.
How can lead developer also take charge on this part?
Yeah. Some companies have a overall
process, and then each project has completely different
processes. I hate that.
I'm just like every project should have the same process
because then you know if I'm on multiple projects and they all
have different processes then I'll get confused really easily.
So making sure that everything is aligned to your
organizational standards, Listen to me sounding like a president
of tech or whatever. But yeah, it's making sure that
your process for checking in code is the same.
And you would think, what are you talking about?
There's only one way to do that. Now.
There's a bunch of different ways to check in code.
Trust me, I've seen people push right to master or yeah, main.
Like don't ever push right to the main branch, especially in
production. That's why we have standards to
avoid these small errors and to help the team have a guide to
success. Yeah, so I think it's a valid
point, right? So if you have a process that is
too confusing, right? So I think it creates a lot of
variants and sometimes mistakes could happen, right?
And I think you also brought up a good point in your book that
you need to understand a different perspectives of your
stakeholders before you probably set up the process, just like
what you mentioned pushing to main branch directly.
So maybe tell us how people should, you know, incorporate
different perspectives from different stakeholders and
incorporate that in the standard and process.
That is a great question. I think that everyone has
expertise to learn from. So learn from managers, learn
from PMS, learn from designers, right?
Everyone can participate in the dev process.
And actually that really, really helps because in almost every
company I've worked for, people were like, afraid of the devs.
You know, we're all people. There's this like mystery about
us being able to control computers and just like make
things happen with code. But you don't have to be afraid
of us. And then as leads, if you show
them that by asking advice of people who are not technical,
when you do that, you will uncover things that you would
have never thought of because you are technical.
But yeah, like I have worked with people who were in HR and
all kinds of other things. If you work at a tech company,
like you're in tech. So anyone that works at a tech
company has expertise that you can use.
Absolutely. Yeah, so I think talking to
people again like learning from others, even just ask, I think
it will open up a lot of new different perspectives.
So engineers or developers doesn't have to be tough people
to collaborate with, right? We are all good humans anyway,
right? So I think another important
thing in any software development team is about
documentation, right? Technical documentation, API
documentation, architecture documentation.
Whatever that is. No matter how we emphasize about
documentation, it will always get neglected, it will always
get outdated. So I think it's also partly a
main responsibility of the lead developer, right to actually
make sure that the documentation is done and also updated.
So tell us a little bit more about this area.
I think this is my favorite topic.
That's why I'm smiling so much. This chapter in my book was
like, well received. Everybody has said like this is
the best chapter. Writing in a book about writing
technical documentation was very meta, but it is so important
because people really need one place to go for the process and
for especially known issues. That is something that I always
have. And onboarding.
When you are onboarding new devs, how do they set up a
machine? How do they start a project?
All of these things are so important to keep your team
productive. And for me, like, I just like
writing technical documentation. Honestly, for each project you
should have the architecture, the features, the priorities.
I guess each team member's role as well is always helpful.
How to contact people? Yes, I do put that in technical
documentation because if you have questions, you would have a
list of a whole bunch of people to ask.
But yeah, and then it really helps to set the team up for
success, because they aren't asking the same questions every
time. And if people are asking the
same question over and over, put it in that document so that
people don't have to ask it again.
But just be kind of cognizant that technical documentation can
get out of hand. You can have too much of it,
actually. I'm actually experiencing that
right now, but just sort of keep it concise to the point,
readable quickly, because of course no one will ever read
every single word in a technical document.
They will scan right for a specific error or like term.
So just kind of chunk it in a way that is easily consumable to
the reader. Nicely put, right, easily
consumable. So I think another tips probably
is like there are so many AI tools this day that can help you
also auto generate documentation.
Of course don't assume it's perfect, accurate all the time,
right? But it gets you started.
It helps you start, you know a lot of groundwork so that you
can improve it from there on. And I think the nice things
about those tools is that you kind of like consume it at the
same time and also kind of like tweaking it so it's like you are
the first reader of the documentation, right?
So I think that's helpful as well.
In my view, you brought up a little bit about maintenance in
the beginning, right? It was also one of your pet
peeves probably in any kind of a software development team.
In your book, you mentioned about preventive measure.
So preventing something before it happens.
I think this is really important, especially if you
have running systems in productions, right, serving
customers, real customers, doing transactions and things like
that. How can a lead developer be more
proactive in doing all these preventive measures?
Yeah, so for me, my main experience isin.net, right?
So I always knew I was like, OK, so the caching has to be
handled, the app pool has to be restarted at night and all of
that making sure that any maintenance tasks that can be
automated and scheduled are. But unfortunately they can't all
be. So in those cases, you know,
sometimes even if I didn't like really want to on like a
Saturday, I would run a process like a batch that would take
hours and I would just kind of check on it and stuff.
But yeah, hopefully because that was a long time ago.
So hopefully now everything's automated and capable of just
telling you, hey, I had an error e-mail or whatever.
Yeah, but just the importance of maintenance and making sure that
everything is working correctly and clean and making sure the
one thing that has gotten me so many times is disk space.
There are some error messages that will never point you to
hey, you're out of disk space, it'll be something cryptic or
whatever. Just check the disk space.
Like periodically put like a task or like a note to just
remind you to at least check or write a script to tell you if
something is out or like a problem occurs, stuff like that.
Yeah. So I think these days there are
plenty of tools, right? You can write automation, you
can integrate agents, you can, you know, use maybe the cloud,
right? Or you can even use bots, right?
There are so many bots that you can integrate with maybe your
chat tools or whatever Productivity Tools that you use,
right? So I think there's no reason why
you cannot automate some of these maintenance tasks, but I
think it's really important, especially if it relates to
reliability of your system or making sure that the customer is
still happy using your system, right.
So another thing that is equally important when we go to the lead
developer, especially in a new project or a software
development task, is that to provide estimates.
I think sometimes this is the most tricky question, right?
How should the lead developer approach this question?
You know when they are tasked to estimate a certain project, a
certain maybe stories in software development team these
days, right? So any tips here about
estimation? Yes, do not estimate alone.
Ask your team, because when you estimate tasks, you're probably
estimating them for other people and you have the expertise.
So the time it would take you to finish something would not be
the same time that it would take a junior to finish something.
So for every single task, have like a meeting, right?
And just talk through the approach overall.
Hopefully you are estimating in points and not hours.
I hate estimating in hours. There's a reason we have story
points because we are horrible at estimating off of hours.
But like with story points, it's a ratio of complexity.
You aren't estimating in hours, you're estimating a task on how
complex it is in relation to other tasks, which makes it a
lot easier to estimate because like it could take me an hour to
write like a function, right? But will it work?
Have I tested it? Have I done everything?
And definitely incorporate local testing as well, which a lot of
people skip that and I don't love it.
Yeah, developers can be so confident, right, in their own
skills or maybe in their familiarity with the domains or
stuff that they have dealt with. Always do testing first before
you even push it to production. So some people even go straight
to production socially. As we reach the end of our
conversation, I have one last question for you, which I
normally ask for all my guests, which I call the three technical
leadership wisdom. So you can think of it just like
advice you want to give us to listeners here.
Think of it like mentorship from you to us.
So can you share maybe 3 technical leadership with them?
Sure. Number one, everybody feels like
an impostor at times. We all do.
Like I completely do. I have written a book and it's
going to be published and I can hold it in my hands, but I still
feel like sometimes I don't know what I'm doing.
We're all trying to figure it out.
So just keep in mind you are not an impostor.
You have excellent skills, you can keep improving and learning,
and then #2 would be the only stupid question is the one that
you don't ask. And if anybody ever makes you
feel like you asked a stupid question, then they're a stupid
person. So don't worry about that #3.
Failure is the best teacher, it really is.
Don't be afraid to fail. Just don't, because you'll learn
so much. Yes, it hurts for a while, but
you'll learn. And then in the future, when you
fail again, you'll be like that was spectacular.
Yay, I learned so much. Well, really unique wisdom
indeed, right? So you cover about impossible
syndrome, You cover about Stupid question, right?
So I think the last one is about failures.
I think it's really, really beautiful, right?
I agree. Failures is the best teacher
ever, right? If you think in your past,
right, were the biggest failure, I'm sure you will think that's
your biggest learning as well, even though it's painful, right?
But I think we all agree that all the failures that we went
through are the best teachers for us until this point in time,
right? So Shelley, if people love our
conversation, they want to reach out, or maybe they want to find
more about your resources or your courses, right?
Is there a place where they can find you online?
Yeah, sure. So I'm on LinkedIn.
I'm also on Twitter. I'm not calling it X at S
Benhoff. I have a podcast as well.
It's TRS and Tech. And then I'm also on Tiktok and
Instagram at TRS and Tech as well.
Nice. So I'll put it in the show notes
as well. So for people to refer to your
places online. So thank you again so much for
your time. Shelly, I love this
conversation. I hope a lot of developers out
there learn more about the developers role.
And maybe the last thing is, like, when can we expect you to
finish the book? Yeah, my editor's asking me that
too. I should have it wrapped up at
the end of this month, I think at the end of the year, so it
should be published online in full pretty soon.
You can access chapters one through 8 right now online, but
then it'll be printed as an actual book that you can buy in
stores in the spring. Yeah, hopefully it aligns with
the release of this episode as well, so good luck with the rest
of your publishing process. Thank you so much.
Thank you for listening to this episode and for staying right
until the end. If you highly enjoyed it, I
would appreciate if you share it with your friends and colleagues
who you think would also benefit from listening to this episode.
And if you're new to the podcast, make sure to subscribe
and leave me your valuable review and feedback.
It helps me a lot in order to grow this podcast better.
You can also find the full show notes of this conversation on
the episode page at Technically journal dot dev website,
including the full transcript, interesting quotes, and links to
the resources mentioned from the conversation.
And lastly, make sure to subscribe to the Shells mailing
list on Techly Juno dot dev to get notified for any future
episodes. Stay tuned for the next Techly
Journal episode, and until then, goodbye.