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.