Test Driven Development & Developer Advocacy - Interview With Gui Ferreira

Hi, my name is Nick Cantino and I'm a principal software engineering manager at Microsoft. In this video interview, I got to sit down with Gue Ferrer who's a fellow dome train author, YouTuber, and a developer advocate. Now, Gee has been developing software for years now, and we talked about transitioning into a different type of role. And we also got to touch on things like TDD and what that means from his perspective. I thought it was really cool to hear. where we hadn't rehearsed it ahead of time or talked about it ahead of time, but he defined having tests as things for developers that allow us to have peace of mind and build confidence. And when I talk about testing, that's the number one thing that I also say. It's for building confidence. So, I think there's a lot of awesome takeaways from this video. He's an excellent content creator, excellent course author, and I think that you're really going to enjoy this conversation. So, sit back, enjoy, and we'll see you next time. Well, Ghee, u if you don't mind, uh you could you give the audience a little bit of background for uh you know, kind of where you started, how maybe like the day that you realized like I'm getting into software and then kind of where you're at now. >> Yeah. So, um just as a frame of context, I I'm from Portugal and when I got into tech, it was quite by accident to be honest. Um I was I came from a household without a lot of possessions. So my parents always told me to me and my brother that um they could support us till the second uh year is the 12th grade. >> It's before university let's say I try to match with other systems. >> Um so they couldn't pay for university. So they always told us that um they would support us until that day. So it's basically when we turn 18. Um then we would need to to work. Um so that led me to to take a decision somewhere in my education to take something that we have here that is a professional course. So instead of being something generic where you learn about math, um English, physics, things like that, uh you would focus on a given profession. Okay? >> And I was looking in my um town the options that I had and I had basically three options. One was um about um tourism. The the other one is it was about something around communication. it was kind of like marketing and things like that. And the third one was um it so I took that as kind of like a leap of faith. Uh I didn't know what was programming to be honest. >> Uh but I was lucky because I really got into it. Um >> thanks. Okay. >> Yeah. I fall in love when um I had my first programming classes to be honest. So I was somewhere 16 something like that, >> right? >> And and I stuck to it. I got my first job and eventually I decide to to keep studying. I got into university. Uh I was working during the day, uh studying during the night. Um it was quite hard. But so I'm I'm a professional developer since 2006 >> and I got into a a job. My first job it was withnet. At the time I was building web forms with net 2.1 something like that. >> No first I started with vb.net >> and quickly moved to awesome >> quickly moved to C. Um, so I was in a a part of a team where most people were building things with Microsoft Dynamics. I think that was the name at the time. >> Okay. >> Uh, and I was the only one me and my boss building things like APIs with C and things like that. Um, so then I kept studying. I moved jobs to to a different company because I was in a kind of like a consulting gig. So I wanted to see the other side to be in the IT of the company. So I moved to a different company to be kind of like the system analyst or project manager whatever you want to call it. Um it was not my thing. So then I got the opportunity to go to um to a startup to build something from the ground up. Um I was the most experienced developer there. So I had to leave a lot of things there and I stayed there for a long time for eight years I think. So >> nice. Okay. >> Um what is uncommon for for this field. >> Yeah. >> Yeah. And eventually I wanted to do different things. Uh and I wanted to be in a position where I could build software for a huge enterprise for demanding software, scalable software, all of that. So I went to work uh at uh fintech. Um and then when I confessed I was not expecting I moved to to my previous company um to perform a role that was not something that I was expecting that is being kind of like a developer advocate for open source. >> Interesting. Okay. >> Yeah. It was something that I I knew I wanted to try, but I couldn't find that in Portugal. Uh, and remote was hard as well. So, when that uh when I saw that uh opportunity on LinkedIn, I got in touch with someone that I knew there and I got there. Uh, eventually the company was sold. there was a huge layoff and I took that as a as a chance to to try to be um an educator is best word that I used to describe what I do nowadays. So basically I'm I have YouTube, I do courses, workshops, talks, all those things because >> and that is your full-time like that is what you do for yourself. Awesome. >> Yes. Um I'm trying to survive this way uh to pay the bills >> because somewhere in my journey I was extremely convinced that I wanted to be a manager. >> Mhm. >> But I was not aware that um being a manager was more than what what I was expecting. So there was one part that I loved on the job that is helping someone to grow, >> right? And there was another part that I that I don't like that is that managing part and um I need to approve um holidays and things like that. Yeah. >> So I realized that if I wanted to help others to grow, there's something better than being sit oneonone sometimes. Maybe it's better to do it through content to courses to conferences to be a mentor all of those things. So I know that that is what I want to do in my career. So I'm trying it. >> That's awesome. Um so thank you for sharing that because even you know at the beginning uh this this sort of path that you have to pick to go down, right? That's a very interesting framing. I I guess like you know obviously based on us being from different countries the fact that like if there were three sort of professional areas to go into one of them being tourism to me I was like I'm like oh that's very odd and then I'm thinking like yeah actually that's not very odd at all depending on where you are in the world that could be a huge >> you know field to be in. So >> Portugal most I think that um we don't export a lot uh so most money that comes from abroad comes from through tourism. Um, right. That's why there's a lot of schools that have that as one of the main um professions that they will teach you. >> Very interesting. Yeah. Like when you said it, I was kind of like thinking in my head, I'm like, "Ah." And then it kind of clicked like, "Yeah, that totally makes sense." But also super cool that like you said, leap of faith, right? You're like, cuz some people are like, "Oh, you know, I was born with a keyboard in my hands at the terminal. Like I knew I was going to be a programmer." Other people it's like they switch after they've started their career. But for you, it was like, I have, it kind of looked like three options. I'm going to pick one. And it just happened to be >> I got it. >> It was pure luck to be honest. I could have picked the decision to go with another one and I wouldn't like it likely and I would do my best, but it wouldn't be something that I would show up every day trying to be a bit better. >> Sure. >> Um, yeah. >> Yeah. Very interesting. I wanted to I wanted to dig in a little bit about the startup kind of landscape versus the fintech. But I wanted to mention one thing before that. >> Um and I'm saying it out loud so I don't forget because I have a bad habit of tangents. So here's the first tangent. Uh I was talking with Scott Hansselman the other day and one thing that he said that I thought was super interesting and really resonated with what you just said was uh he had said and I don't know the exact quote even though it was recently but something along the lines of uh we were talking about career paths and he said I don't think my thing is computers and I'm sitting there going like what the heck do you mean your thing's not computers like Scott Hansselman like you are like you are the computer guy you are the 3D printer the I'm going to hack things together like and he's like, "No, I don't think my thing's computers." He's like, "I think uh I think I'm a teacher." Like, "I think I'm here for teaching." >> Yeah. >> And I was like, "Holy crap." Like, "Yeah, like that actually makes sense, right?" Um and the, you know, so that kind of resonated when you said it when Scott was saying that to me, I was thinking even for myself like I think my thing is still software. Like I I love the idea of thinking software is just like infinite Lego bricks. But I I do feel very fulfilled by uh by helping educate. Like there's something about that when people can say, "Hey, that really helped me." I go, "Wow, like that feels good." So >> yeah, I've been thinking about that because we tend to put labels, >> right? >> Um in what we do. So even nowadays, if someone that's not from the field asks me what I do, I will likely say I'm a software engineer. I'm a developer. I'm I'm something like that. >> Sure. >> Uh because I'm still that but I still build software. But there's one part part of my job that I think it's more important than that than delivering bits is teaching others. >> The problem is those labels. It's quite hard to assign a label that says I'm a developer teacher. That that doesn't exist. Um I'm a developer educator, something like that. You you can't even find a role model out there that uses a label like that, >> right? >> Um so that that's why it's it's hard. I I still don't know. For example, my daughter, she's seven. And when I decided to go in this path to work in this thing, she asked me, "What do you do now?" >> And I it's hard to me to explain to be honest, right? >> Um it's not as tangible as saying I build software for this company. And it's you had mentioned doing like developer advocate work and in my head I'm like I wonder if that's close but at the same time that almost seems like >> the goal is not uh to educate in general. It's almost like to and I know I I don't want to do an injustice to that uh that job title, but it almost seems like a marketer for the language of the tech versus like an educator. >> Yeah. I I always define that role at least the way that I positioned myself on the company doing that role as the I would represent the the software out there but I would represent the community inside. Okay. >> Right. >> So I don't want to know how we build this thing. Okay. What I want to know is that it's good for the others out there to have success with it. uh because I'm I would I'm the ultimate um representative of them when we are taking important decisions. So it's not you can take it as a marketing thing, you can take it as um as a sales thing. Um and usually that's one typical discussion in in developer relations that is where this role should fit in. you will see someone in developer relations uh reporting to marketing or to sales or sometimes to tech and that will change the way that you act >> naturally. Your your responsibilities end up being aligned to like who you're reporting to really. >> Yes. >> Before we continue on, this is just a quick reminder that I do have courses available on domain. If you're just getting started in your programming journey and you want to learn C, you can head over to do train. I have a getting started in C course. It's approximately 5 hours of content taking you from absolutely no experience to being able to program in C. And after that I have my deep dive course which will take you to the next level with another 6 hours of content so that you can start building basic applications. Head over to dorain and check it out. Let's head back to the video. And I have seen that in myself as well because in my role uh since it was connected to open source I was also doing a bit of governance inside things like um are we using uh open source correctly? are we >> using licenses that we can all those types of things. >> And while while I was there um I moved from one manager to another and that changed the focus of my role as well because one person was more focused with one aspect of my job and the other one was focused on another one >> and that naturally will change the way that you act because they are your managers. They somehow they define um the pipeline of work that you have. They will leave things into you if when they see it. >> So, yep. >> Very interesting. Um and so the the part I wanted to come back to because I I think that people that have experienced this kind of thing uh like I don't think everyone has this opportunity or or has gone through it but the startup versus something like fintech like >> um this is a super like open-ended question I'm curious about from from your experience though >> could you talk about some of the dynamics like that you had at like startup life versus then going to fintech because for some people that are watching this uh I think or or listening to it. The this idea of like, okay, I want to go for my first job and like, you know, I I want to be at the at big tech or I want I want the the big company name. Like, I'm just curious. You you obviously did both. Like, what what were your experiences like at each place? >> Yeah. Often when that question comes is from the perspective of uh where will I learn most? Is it on a startup? Is it on um fintech or a huge company? And I usually say that you can learn a lot in both of them depending on how you behave. Okay, you can not learn anything on both of them if you are not looking for knowledge. Um the thing is in a startup you will learn a bit of a lot of things. you need to do a lot of things. Um I used to say I used to say that if I had to take the trash out I would do it. Um and I think I have done that sometimes. Uh but when you compare that to um to a fintech for example, you still will learn a lot but it's more of a specific thing. Okay. So because usually you will have a domain where you will focus and you will be working on that. However, if I had to recommend someone to take the decision, do I go first with a startup or uh with something like a big tech, I would say first take the chance to go to a a startup because early in your career you can take more risks. If things go wrong is it's fine. you will find other thing and also you will learn so much about a lot of things that will build you kind of like a foundational knowledge that then you can build on top and also you can use that opportunity to find out what you do you really like for example uh on that startup I on boarded some people that were was their first job and it was quite interesting for example with um since you are in a startup you can't hire uh someone only for UI, someone only for back end or things like that. Everyone is full >> stack. Yeah. >> Yes. >> But it was quite interesting to see some people being extremely good on the UI and leaning into that and others that couldn't touch it. >> It was kind of like a natural thing like if the brain didn't work that way. And I know at least one person that was so good with UI that eventually when he left, he goes to a big uh company. I think it's a bank. Um and he's only doing UI because he realizes that that was the thing that he really likes. So he built a career around that. But first he got all the knowledge about how to build software by doing a lot of things in the day-to-day. One important thing is that startup life can be extremely hard. Usually um work life balance is not the thing. Um yeah because there's not a lot of people there's a lot of things going on fast. You you are in survival mode and when things go wrong uh it's hard to say no. when you are in a in big tech you you can have an healthy relationship with your job in my opinion. U but I learned a lot in fintech as well because I moved from building software for a thousand people to building software with millions of transactions per second. The scale is different, right? Like it's I mean usually very different >> and the responsibility as well. Even if you are one in the middle of 2,000 developers, one mistake might have a lot of impact, >> right? >> And you gain that feeling in every single thing that you do. Yeah, that's uh I've uh I've tried to explain this and I don't know if I have a great way to do it, but the sort of the the current career I have and previously I worked in digital forensics prior to Microsoft >> and for us digital forensics uh was like we had you know close relationships with the customers you would hear with like they would our company would bring in people to speak to the developers and sales and marketing team about how they were using our software to help catch pedophiles and solve cases and like that feeling was like this is incredible that we're having such an impact. Um, now at Microsoft, the difference is not like we don't have an impact, but how it looks is different. So, for example, I'm on a routing team within Substrate >> and we serve trillions of requests per day. Like, it's the it's not the it's not that there's no impact or whatever or you know, one company had no impact versus the other, but the impact you have just looks very different. And I think uh for some people and it it's not necessarily just a startup versus big company kind of thing, but I think you uh you want to sample some things to figure out like what motivates you and what kind of makes you feel good, right? Um I know for some people if you're working on a platform team, if I said, "Hey, look, we're serving trillions of requests. This is for people across the planet." If they're not interacting or feeling like they're getting that response from a customer, that direct feedback, they might not feel as engaged. whereas other people might say I don't care about that knowing that we have like such a huge impact across the planet like that's really what's cool to me and I think you said a really interesting point about being in startups and kind of sampling a little bit of like everything going on around you I think that's a huge value ad that >> I don't think a lot of people consider that >> I don't know how is it in your in your team and maybe being an engineer manager you are responsible for what I will say u But I have the feeling on working on some big companies that one of the biggest problems sometimes is that developers lose uh touch with um end user >> and often they are so protected to spend their time just building stuff that they don't understand how things will be used. And often that it's because of either the relationship um with um manager or the product owner that don't want developers in touch with um the users >> and I had that experience and that is one of the things that if I didn't have work in a startup maybe or and in a consulting company I wouldn't understand if I start right away in big tech um the impact of what you do. Okay. For example, on my first job, I was kind of like a consultant and I recall going to meetings and having the the client looking over my shoulder to what I was doing. Um, and going there when things went wrong, um, when things don't didn't work and those are amazing learning opportunities, >> but yeah, no, I think you're you're spot on. Uh, at least from I say spot on from my experience at least. And uh I think to to exaggerate that too if we take a a big company um and on a platform team right so like who are the customers like we have almost two two layers of customers one is always going to be the end user that's like why does our business exist like there's end users right so um we have that level of customer but for a platform team you have customers that are basically internal teams that you're supporting so uh on the routing team that I'm on for example example, our first line of customers that I would say are all of the partner services that need to route requests >> or have or have external clients, external customers having their requests routed to these services. So >> I think a couple things happen in in big companies and again generalization. So it's not like a a rule that's carved in stone, but I think in bigger companies, you start to get more specialization of skills. And one such thing is you can have people that are truly like product owners that are like my responsibility is to go figure out these types of interactions, what's important for the users. Um, and then that kind of starts to isolate some developers from that. Yeah, >> generalization, but I think that can happen. Uh I I have absolutely experienced even switching to this team that I'm on now at the beginning of this year. >> There were like I kind of joined after a planning cycle had been finished. So it was kind of like me jumping into it and saying, "Hey, look, like you guys already know what you're supposed to be doing. I'm catching up here." And as I was onboarding and understanding more, I started to realize that like I have awesome engineers and in some cases they were like like here's what I was told to do and like I understand it and I'm going to go build it. But they didn't understand why, which is seems kind of weird, but I I remember having I held a meeting for one of the feature crews that I own and >> I had been talking with one of the product owners and uh some thoughts came up and I was like, "Hey, like this isn't going to be an immediate action like we have to shift gears, but we should talk about this as a within our feature crew to see like how that might shift our our priorities coming up in the next few months." So, kind of like a brainstorming thing, but like selfishly it was a little bit for me to kind of uh catch up on things. And I talked with one of the engineers the next day in our one-on-one and I said, "Hey, what did you think about that conversation? It seemed pretty interesting. Like, what do you think?" And he said, "I wanted to say thank you for holding that meeting." And I remember being like, "Why? Like, you're you're one of the more senior engineers. Like, why?" and he and he said like I he said I knew what we were building but I didn't fully understand >> like the implication of why and I was like holy crap okay like um and it was just a reminder you kind of said it right but that as an engineering manager like I need to make sure that uh I would hope at all times I want my engineers to know like here's why you're building it and having you said it as well for like startups and small companies I feel like you get a lot more of app because you're almost forced to see it. >> Yes. Do you work with a product owner in as part of your team or not? >> So, right. Yeah. Right now, so the previous team I was on, so I worked in deployment before within Substrate and I would say the engineering managers were basically the product owners. We had >> Okay. >> We did have product managers at the time and they mostly acted as like I would call like project managers. So they really helped us a tremendous amount with cross teamwork like to keep everything organized. >> Uh in the last year that I was on that team there was a bit of a reorg where the product managers truly did become more like product owners. And now on my current team I would say it's a it seems like it's kind of weird but also it's very healthy. Like the the product managers we have do act like the product owners but I work with them on it. So like we kind of own it together which is nice. >> Yes, that that's also the idea. Um I had that discussion the other day with a friend of what in fact a product owner should do. Um because it's one of those things that usually we take it with the experience that we have with by working with someone, >> right? Uh but then we see the the role being performed in several different ways and I'm always curious to see if it works or not. Uh to be honest because sometimes I see that the problem is that one of hiding the reasons from developers. Um that's the thing. It's completely different when you you see someone using your software or understand why they need it. I I have an excellent example by the way. Um, I got I I think it was two months ago, something like that. I went to to the doctor with my daughter and um the doctor was complaining because he wanted to to prescribe some meds and they have now a system where they need to pick from a predefined field the the frequency that the med should be taken. Uh, and he he only could do something like um twice a day, three times a day, things like that. And then the the system would print saying you should take it at uh imagine midnight, then 8:00 a.m. things like that. And he didn't want to he wanted me to to use the maths, I think, three times a day, but he didn't want me to wake up my daughter in the middle of the night just because of that. So it was fine to adjust a few hours but he couldn't do it because the developer that built that form or the team that built that form didn't know that. So you get a list of requirements. It says that for this type of M you should have the frequency predefined and they don't even leave a an option other or something like text field that where that you can use to write down what you want. They just split the interval in 24 hours four times. Okay. It's it start at midnight 6 a.m. Yeah. >> And it it's reasonable if we think as an engineer. Right. >> Right. >> But now we think as a user and if we see the the frustration that it creates in the in a doctor um you understand that that is a mess, >> right? >> Unless you have that contact, you will not get it to be honest. >> Interesting. Yeah, that's uh yeah, I feel like you know back to the the idea around startups, my my experience at least was very much as you were explaining where by by being in a smaller company, you know, you're you're wearing many hats. That phrase gets used a lot, right? So, you're wearing many hats and >> as a result, yeah, you get pulled into all these different things. But I feel like, you know, one of one of the biggest benefits was just feeling a lot more connected to understanding like we have value that we need to ship to customers. And maybe I'll I'll kind of wrap up this uh this uh uh section with this thought, but this idea of like uh and may I want to hear your experience on this too, but um like basically coming from school, you know, we have all these ideas about what code is supposed to look like, right? It's all like here's the patterns, here's the theoretical, like here's how code gets written. >> And I I found that uh like I quickly had to learn it's it's not it's not just about having perfect code. It's like how are you getting value to customers and having to balance that where you'd have like we were a startup, we were hiring more people and you'd have people coming on saying like that the code's not perfect yet and it's like it doesn't matter how perfect it is because the the end users aren't reading the code like we need to be able to uh fix the critical bugs. Uh we can't spend two months refactoring and rewriting something and not shipping value. So it forced us all of the time to be having these really difficult conversations around like yes we need to balance like fixing tech debt and addressing these things so that they don't go off the rails but like you have to be delivering value if we don't our company does not exist. So I curious what your experience was like that. >> I have a lot of things that I could say there. Um one thing that I think is not acceptable at all is this idea that we developers we tend to have that um we believe that is acceptable that's if someone asks us when this refactoring will be ready we say um whenever is ready and if the other sides asks what do I get from it we basically say kind of like the same thing but Sure. >> Um, and we think this is reasonable, uh, but it's not. And there's also a lack of respect, uh, by what pays your wages. Usually, for example, I've worked in some companies where it was the the legacy system that no one wants to work with that was paying 90% of the the bills. Um it is what it is. We like to do sexy things and um to play with new tech to build things perfectly as we believe. Uh but often it's not what we are looking for and I've learned that in on that experience that I told you that um I worked in the other side like kind of like a system analyst. We used to build some software, some internal tools and especially when you are building for internally sometimes we have the natural tendency of let me grab Visual Studio and build something and often it can be solved with um spreadsheets maybe >> and yeah you you solve the problem um it it's I think that is the reason why so many people is scared about things like AI replacing developers because we got used to the idea that being a developer is the part of writing the code is typing. Um but there's the other part that I believe we spend more time there but we usually don't put as much effort on learning on improving on that side that is how will I solve this thing in the most efficient way in a way that is beneficial to the to the company >> right I feel like that's the engineering part of software engineering is like figuring out these tradeoffs balancing these things properly >> and then the the vehicle that we use for that is generally code, right? It doesn't always have to be. In fact, I think some of the best solutions are when you can say, "We don't need code for this." Like, we can solve this by getting the answer we need to the problem without having written code and nothing else to maintain there. But yeah, that's a I think that's a really interesting point, especially on the AI part, like like if Yeah, if if your if your only job as a software engineer was how do you make more code? >> Yeah. You'd probably want to be pretty worried. Yes. Yes. >> Very interesting. Um maybe on a good segue into like because I don't know if if this changes from your experience from smaller companies over to say something like fintech but testing right um I can remember >> in our early startup days we didn't have tests. In fact, we didn't have, you know, builds like we so we made desktop software and one of the interns had like his machine was the build machine. >> Mhm. >> And we would say, "Okay, it's the release date and we'd say it's time like you know, open Visual Studio, build it, copy the folders around, >> and I can remember days where we would upload it. Our our founder would pull down from the website and he would go run it and he was like, "This isn't the right build." And we were all like, "Oh no." like you know we kind of lived through these things and that whole process literally included no testing like the the testing was the founder pulling it down and going looks good right he would go so it was a search engine he would go run the search and say he have a b like he would do the baseline comparison to make sure that it was only net new things and fixes >> but there was no automation per build you wouldn't commit something and it runs this suite of regression tests it was like cross your fingers And when it's release date, the the founder is going to tell you if it's right. >> Yes. Uh I see that and I see myself on that as well. I think that the best way to answer that is >> for example um somewhere in your career you have learned about um dependency inversion for example inversion of control >> and you learn about that and someone will tell you that it's important and you should do it and things like that. >> Yeah. Okay. I'll keep that in the back of my head and like >> Yeah. and and eventually you will do it and um yeah until the day that in fact you suffer by the fact that you haven't done it on that day >> you are changed >> and the same thing happens with testing to be honest for a long time I testing was not my thing at all I until I suffered a lot with it >> um I I I think I have told this story many times. Uh especially if someone has watched one one of my talks. I I was 27 when I was diagnosed with a chronic disease. Um that causes a lot of back pain and other things that can be a bit worse than that. Um and when I was diagnosed with that I had tried to change some things in my life and eventually I realized that one of the triggers was uh stress >> and it was at the time that I was working on a startup with no work life balance and all of that >> is no stress there right not at all >> exactly and as you can expect when you need to deliver things with aggressive deadlines test is not a thing okay we we had some tests But I I wouldn't feel safe to be honest. >> Yeah. You're you're going to end up taking shortcuts and >> the the thing that you know the thing that you're not compromising is like is the perceived value to the customer. Right. >> Exactly. >> So, hey, we can we can put the bug fix in like we ran it. We all as developers and product owners are like, yeah, it's doing the thing. Like, did we write tests? No. But we all saw it work. Like, yeah, press the button. Let's go. that that's the that's the spirit. So, and it was at that time that I had to deal with a lot of stress and I was feeling it with my health that um I paid more attention into to testing and I gave him a a serious look. You know that when you learn something because you feel that you need to learn or when you learn something but in fact you invest in it you you stick to it you try it and you dig into the topic is what I have done and that changed everything to me. I will not say that on that company I could have the impact that I wanted. uh it it takes a long time once you you start the path without tests in mind to get into a place where you feel confident with software but I can say that after that experience I I could push anything to production feeling confident to be honest and even nowadays I feel that because of my relationship with testing and with everything that I learned but I can tell you that I wouldn't be such an advocate for testing nowadays is if I hadn't suffered what I have suffered in the past. Okay, because now I get it. Yeah, it's the thing. So I think it's uh Kent Beck that says that um is the al creator of not the creator but the one that make TDD the the thing and it says that we we are paid uh to write code not to write tests and that is true but I think that tests are above all a tool for us not a tool for the others okay it's about >> me as a developer have um peace of mind above all and feeling confident and also it's a productivity tool in my opinion. Okay. Uh I don't I don't feel that running my debugger every single time that I do a change to see and clicking some buttons to make sure that everything is fine. I don't think that is productivity when compared to writing an automation test for example. Um my relationship with testing comes from that side to be honest from that experience of suffering and needing to go through it and finding a solution for that. Uh and I understand why many people don't like it because from the outside it looks like sometimes a waste of time um until you in fact you suffer with it and you need to do it the same thing as dependency inversion. Yeah. No, and I I like those examples a lot, but I think it's uh it's it's almost it's like I don't know if it's just like a human thing, but uh you probably see this come up a lot where people are, you know, have newer developers and stuff and they'll say, "Hey, like can you just like tell me how to like tell me the the three secrets to being like a senior developer?" And it's almost like look, you unfortunately even if I could tell you that, you're going to have to make the mistakes to actually value them. um which is like you know we learn the hard way and I wish it wasn't the case but uh your example of like you have to kind of feel the pain before you go okay like we got to make some changes here uh that completely resonates with me the example that I have to share there like we were on so I was managing teams uh very early on at this previous company and uh a lot of the so it's pretty small team that I had to work with we were doing a lot of prototypes And at one point there was a very big software release and they kind of said hey like can you pause the prototyping because we have this very big release. Can we can we leverage your team to basically go in and like help these other teams to go you know uh make some progress in different areas. Absolutely makes sense. >> It's a really good business justification right this thing makes the money. The prototypes are for the future and we're we're on a deadline so no problem. So what we were doing as our small team was they would give us some part of this UI to go work on. And so we have our pieces carved out. We'd work with our product owner. We'd go deliver stuff, uh, land it, and we're like, "Awesome. This is great." Then what would happen is like a week would go by and we were working on the next part. And when we would go to land that stuff, everything that we had done before was broken. And we would have the other core team going you guys are messing all this stuff up. Uh so they were their stuff was getting broken and they were breaking our stuff. So we're putting code into the same areas >> and I remember like they kept getting frustrated and we kept getting frustrated and they said we're changing and what we started doing cuz this is all like mostly UI stuff. We just said we're putting tests in on everything we're doing. Like I don't care what part of the UI it is because a lot of people are like oh then you have to go structure like you need clickable you know tests that are going to run and we're like we're designing stuff so we don't necessarily need it. We'll do whatever we can to get the regression coverage >> and we started doing that and then basically the other team stopped breaking us so we're happy but they kept saying you're breaking our stuff and we said how do we know? How can we possibly know that we'll be breaking your stuff if there's nothing to tell us? So then we started saying, "Look what we're doing. We're writing these tests. You guys, like if you want, you can come in and go touch our code. Touch it as much as you want because now we have full confidence that you can't even push the code up to break our own stuff because there's tests there to tell you this is broken." And that was a huge learning for us. And we we took that kind of principle on everything we did going forward to just be like uh even if we don't need to test everything like line by line you know 100% coverage we're building stuff to be testable. So that was our big takeaway. >> Yeah. And the 100% is not the thing that you are looking for but um the confidence and um writing to be testable I think it's the sentence for architecting to be testable doing everything to be testable is what important is important >> and when you have when you have that ability then you can make decisions right if you say I'm writing things to be testable you're in a position to say and I I should have called out I love that you keep saying confidence because I have found that when I'm trying to explain testing to other people. My go-to phrase is this is to have confidence and I don't care like how you want to go test or I don't know your architecture your application but at the end of the day if I can say you want to test for confidence that should guide you in the direction but um yeah like just I can't remember what I was saying because I did a tangent again but yeah the whole idea is just like you know building stuff to be testable gives you this flexibility to say is it time to put the tests in like or or can we maybe take a shortcut? We'll come back and add tests or um we don't even know maybe this part of the code uh might not live long. We're kind of doing a a feature test or a prototype and at least it's testable. If we need to cut it out, >> sure, like we didn't maybe we didn't spend extra time, but hey, this is living a little bit longer than we thought. It's starting to be more solidified. Yeah, this is becoming a core part. Go add the test now. build more confidence around it. So that's been sort of my experience in that realm. >> Mhm. Especially when you you need to get back to to something that you have built long time ago or someone has built long time ago or as it have happened to me um being on call you the middle of the night if something goes wrong and you need to do a quick fix >> without tests I would be worried right. Um I can you can make something even worse because you are uh wake up in the middle of the night so you are not fresh. Yep. >> And you need to react fast. Um so that's why I think it's worthy to invest in in testing. Um I will not argue if you should test first or test after. You need to have a safety net is my is my opinion. >> Yeah. And you I mean from your own experiences and correct me if I'm wrong but I'm feel like from your own experiences and different types of projects you might have a preference to say hey I'm going to test first like if you love doing TDD y >> and that works well for you you'll probably say yeah I test basically everything first but uh perhaps for other people in different projects if that's not what works well for them like as long as you build the confidence right >> and I have learned that we we all think differently the the process of building code is different And sometimes one technique might not uh stick to to you uh as other technique. I have um a colleague that the way that he used to type code it was so different than the way that I usually used to think that doing pair programming with him was quite strange but it was the way that um the brain worked for him. For example, >> I came to the conclusion that some developers start kind of like the from the bottom up. So if they know that they need a method to do something and another method to do something, they will first do those leaves of the code and eventually they build a method on top to >> uh to relate every single thing. and others start from the top and they start creating placeholders and eventually they drill down into the place okay where they fill the gaps and those two things are two different mental models. So the same thing happens with testing. Testing first, testing after. Um that's why some people don't click when they apply a strategy. Other times is because they don't stick to it as well. >> Right. >> Yeah. >> Yeah. Yeah. That that's a valid point too. I think uh like honestly for me I I test uh almost everything I do is tested after but there's absolutely certain types of problems where I'm like I know from my experience I need to test first because >> I I just know myself well enough that this is a type of thing where I'm like you're going to be wasting so much time trying to code it unless you're putting these systems in place to to test first. But I think like I think the idea of TDD is great, but I think my my probably my biggest complaint when people talk about TDD is it's kind of like anything where people say this is the only way to do it and if you don't agree then you're wrong. And I'm like I just don't know if you can make claims like that like so broadly. >> No, you you can't. And unfortunately when there are techniques that it takes so much time to get it and you go through a lot of pain to get it um and some people during the process it doesn't work out from them. So they are in the other side of the camp. It's natural that you have arguments like those ones and is unhealthy. Um, to be honest, I I'm a fan of testdriven development, but I'm aware that saying you just don't get it um is not a way of helping anyone. >> Sure. >> Uh because that's in fact a learning process to to get there. And I don't say that it's better than other thing because the best developers that I worked with I think that 90% of them didn't do TDD at all. Uh the way that I put it is that TDD it's a it's a practice is a tool that you can use and on my personal case it was the tool that made me be better. >> Sure. almost at that level, the level that they are because some people need tools and frameworks and processes to come up in the in terms of quality and I was one of them. Um so it might work for you, it might not. It's not the only way of doing it. Uh otherwise we wouldn't be able to to build software because most people don't do it. Right. >> Sure. Yeah. The the proof would be that everything else fails, right? But the >> Exactly. >> I know. I think that's a a good way to put it. And I would say even, you know, for people that are like, I don't like it or it doesn't fit, like it, yeah, it could absolutely be a thing you maybe you genuinely don't understand it or you haven't practiced it. So that's, you know, it's to, I guess, to rule it out as you just don't get it is not helpful. Um, but yeah, might be something you want to practice and try. And even so, if you do try it and you've given it a chance, you're like, it doesn't really fit as well for me. Like I think at a minimum you learn about some patterns and practices that you you could take pieces of and say well here's the value and maybe when this scenario comes up I can apply it. >> I think that you for example I don't apply TDD in every single problem that I have to solve. >> Sure. >> There are some places where the value is there and it's quite natural to do it. other places if you do it you are wasting your time you are wasting hours to be honest um but understanding that in this particular case it's a valuable tool I don't feel confident with this code let me write the test first it might be helpful that's why I say that it's a valuable uh skill to to be aware that it exists how do you practice it doesn't mean that you need to to buy the t-shirt saying I love TDD is not is not the thing. Um but also I have learned oddly enough by finding the the way that TDD works for me made me write tests better >> and now I also can teach how to write tests better even to someone that will test after >> because sure >> you'll learn a lot when you try to write tests first. Okay. because it's unnatural. >> It's not it's like that thing that um crossing our fingers, right? If you are used to do this, eventually doing this feels unnatural, right? >> Yeah. >> Uh and we have learned to write code by writing the hello world. No one told us to first write a test and we do that for a long time and eventually someone comes and says no, if you want to be a great developer, you need to first write a test. No, it will not be the way that things will work. >> Yeah. >> And I think there's a lot of people that you know if you're you go through a lot of your development in the beginning and you're not writing any tests then someone says hey start testing even if it's after they go well I have to rewrite all of this code like everything that I just wrote I have to rewrite so that it can be tested and then it reinforces like testing sucks. It's so much more work. Why would I ever do this? But to your point, if like one of the big uh lessons that you can learn from testing first is like how are you going to write code that can be tested so that if you're going to test after you're not like hey I spent two weeks writing this code now I got to go write tests because I put the PR up with you know 10,000 files changed and the first comment is test question mark and you go guess I have to change all of these files. Um you you learn to do these things ahead of time and that way if someone says tests you go oh yeah let me just go add them not let me go rewrite everything I just did. >> Exactly. >> That is true. >> No that's that's awesome. Well thanks for the the insights about TDD there because it's it's uh like I said it's really cool to hear someone saying I love TDD and use it a lot but also acknowledging because I think it's important for other people to hear like it's not the only way but it's still a valuable tool. Um, >> yeah, we all have different tools that we use in our day-to-day and we don't need to use the same to be >> to be successful. You might use notion, I might use Apple Notes or Obsidian. We can achieve the same things by doing things differently. >> As long as we're all using C, it's all that matters, right? >> It's it's all good. >> No, that's cool. I wanted to I wanted to spend a little bit of time uh sort of at the end of our conversation here talking about uh the work that you're doing now. course creation, content creation, because like for myself, I haven't been doing it as long, but uh it's been a shift in terms of like, you know, I want to be helping educate, putting content out there to help others. Um, and for you, this has been lit literally a career shift into this space. So, um I don't know. I don't have like a specific question, but like could you maybe talk about some of the the shift in perspective to being able to say, okay, I'm not just writing code to ship it to a customer, but now I'm trying to create whether it's more code or content to try and explain concepts and maybe how you balance all of these different things like what to focus on and all of that. Mhm. So that's the first thing that everyone will usually think when some they see someone that does what what we do. Not your case because you you still work um in a big company doing your your job. Um is how do you stay update? Um is that in fact knowledge that is applicable? Is that in fact um something that is useful? And that's fair fair to think about that. What is important to to consider in my opinion is if that author has experience in the past that sustains the things that he's saying. >> Okay. Um for example, I don't have a linear career progression. So it seems uh complete strange if you look into my career path but I know that I have a diverse set of experiences that gave me different perspectives to talk about u new things and also you still need to keep developing um applying things trying out things. The difference is that since you will be talking about that you need to dig deeper than usually you would do in your day-to-day. For if someone asked me to, okay, let's bring open telemetry into our project, >> right? >> Um, I would go to the uh getting started, I would apply it. Eventually, I need to do a small improvement because I'm looking for something. I would Google it, do it, but I wouldn't take the time to go deeper and understand the why something exists. Uh, what's the best way of putting that in practice? And also once you have done that to to deliver a course you have the other part that is how will I deliver this information in a way that it sticks to to that person. Um and that's the most challenging part but worse than that to be honest is the imposter syndrome. >> Yeah. um that I used to say if you if you think that you have imposter syndrome sometimes you need to think about those that will are doing something for um hundreds of people or thousands of people uh that are from a profession where we used to criticize every single line of code. So you need to know how to deal with that to overcome that imposter syndrome. But above all, you also need to learn how to ignore some comments. Uh because some people are a bit rude to be honest. Um and you need to filter the thing what you what you are getting from the outside. >> Um but then you will take pleasure from different things. you will take pleasure not from um building an elegant line of code but from one coming up to you and writing a comment on YouTube saying I tried to understand this so many times and now finally I got it. There's nothing better than that to be honest, >> right? >> Uh in at least in the way that I approach my profession. So I would say that we keep doing every single thing that I used to do, but then there's this part of um researching a bit deeper and trying to find ways to deliver that information in an effective way, >> right? >> Yeah. No, that's that's super helpful. Thank you for the framing there. I I've talked before even for people that are trying to learn things, right? I uh you know, you don't have to necessarily be a content creator or an expert in an area, but I I like letting people know like, hey, if you're going to dive into something and learn about it, one way that you can like almost test your effectiveness of how you learn that topic is try to teach someone else about it. Don't try to pretend to be an expert on it. That's not what I'm saying. Like don't spend a week like learning something and then say, "Hey, I'm an expert now. I'm going to go charge people for it because like people can see through that." But um if you say like, "Here's this thing I'm learning about. here's like my takeaways and my ideas. Like I think that you get a couple of awesome things about sharing that kind of stuff. One is you can get feedback from people, >> but the other thing is this process of here's what I think that I learn and I understand. If I have to try now and articulate it to a different group of people, maybe other people that have never seen this kind of thing, you go through this like this mental gymnastics of how do I explain this now? Yeah. >> And you start to quickly realize and I'm sure you've had this the imposttor syndrome part where you go now if I go to explain them it's like why does it feel like I can't explain it? Like if I had to go use it in Visual Studio and make a program I could do it in a second but now I have to find a way to explain it. Do I actually know what I'm talking about? >> Oh no. And that's an a valuable skill for any developer to to be honest. I know do you run any type of uh knowledge sharing session in your team? Yeah. >> Yeah. Not uh so we do I don't currently run like a dedicated one but there is a lot of like hey if you've been uh you know building out feature areas like this is something the whole team has to work with for on call let's say so like it would be good if other people were brought up to speed. >> Yes. I I used to be the one uh pushing through those sessions and sometimes trying to manage them um in many of the companies that I worked on because I really like this idea of getting knowledge and sharing it back. So I always have done that and it's so hard to find someone to come up and uh share the things that they know. Um and also I realized that by the fact that we tend to not do that as much, we get to a point where we are not comfortable to share what we know and we can't um explain it in a clear way. You might know it but you think that it's so obvious that everyone will get it. For example, if you build content online, you know this thing that I will say, we often get um criticized by the type of code that we uh put in demos. >> Yep. >> It's too simple or this doesn't happen in the real case or this is not enterprise software. Uh there's this mistake, there's this and that. And I get all of that. But if I try to come across um with a message and I I need to bulletproof that code to be deployed in S SNP500 company, I would bring so much complexity that I wouldn't deliver the message that I want. Sometimes >> making your first YouTube video, right? >> Yeah. So I forgot what I was adding to with this conversation, but that process of understanding what really matters is something that is useful for everyone that is a developer because what we do is communicating through code. >> Right. >> Right. And if we can't communicate um to our peers in a small session to explain something, I think we are losing something. Right. >> I have seen some companies where to pro in order to progress in your career you need to to also be the mentor and pushing with new knowledge and things like that. Uh so eventually in your career path if you are not perceived as someone that can guide others to a different level um you will not be promoted. So that's why I believe that it's also important even if you don't want to be a content creator or things like that being used to to share to yeah >> to express your ideas and you can do that through blog posts. You can do a an internal blog an internal newsletter. You can do um small conversations like meetups and things like that. Um but doing something is something that takes you to a different level in my opinion. >> Absolutely. Yeah. And the this idea so I love the idea of you know the the mentoring ability to help level up other people around you like uh basically anywhere I've worked that's been a big aspect of like uh you know moving ahead in your career. The the other thing that feels less tangible but is uh exactly aligned with that is like not only just helping say other junior people around you and uh helping them move forward but uh when we're talking about impact and influence generally it's going to involve depending on the size of the company other teams and stuff and being able to talk with other stakeholders and work on bigger projects like if you're unable to communicate ideas effectively those starts those types of things start to suffer. and you have a lot of friction and you're like why is it so hard to work with this team or these people just don't get it >> and it's like you know communication goes it's you know at least two sides when you're communicating stuff so >> it's easy to sit there and say it's just their fault like they obviously don't get it but like >> hey man like maybe it's maybe it's a little bit of you too. >> I agree with that. I really it's one of those skills that um for some reason due to stereotypes and things like that we got used that it's normal >> uh to be to not be a good communicator being a developer. >> That's right. >> Um but it's something that everyone can improve. Um and you don't need to be uh Anelman. you you you can still be a normal developer and doing something a bit better. >> Yeah, absolutely. The the communication part goes a super long way. So, it's uh it's cool to hear that you kind of had that uh same experience and that and with content creation, you've kind of realized like sorry, I shouldn't say it made you realize, but uh it is reinforcing this uh this idea, right? So, >> no, that's awesome. Uh well, G, I wanted to say like I'm I'm I'll absolutely get links and stuff from you after to make sure I can share out, but um you got courses and stuff. You want to give a audience a bit of an idea uh what courses you have available, uh different ways they can reach out to you and find you and stuff, and then I'll make sure that I grab all of that from you to to jam in comments and descriptions. >> For sure. So, um courses, I have my courses on domain.com. Uh no I have uh three courses there. Um one on test driven development, another one on clean code and another one on open telemetry. That is most recent one um regarding um other stuff going on. Uh I have an YouTube channel with my name. Just look for it. You might find me or a Brazilian singer that has beautiful love songs. Um >> either one would be good then is what you're saying. subscribe to both that's my opinion u and um bes so you can find on me on YouTube I have um a lot of things about software development there uh many of them innet other things that are a bit more generic in terms of being a developer um and also I I have a newsletter that I usually only publish um push something once a month so you can find that on my website as well. My name me so gif.mme me and yeah you can find me on LinkedIn, Twitter and those things. I'm not on Tik Tok to be honest. >> What? No Tik Tok. Okay, >> no Tik Tok. I need I need to move start dancing. >> Cool. No. Well, thank you so much. This is a really awesome conversation. I I do appreciate your time, your insights. It's really cool to hear your journey. uh obviously very successful content creator and it's really cool to see that you've been able to take things that you've you know done professionally and help educate other people and you know from your experiences just you know make other developers better. So that's that's awesome to see. >> Thank you Nick. It was awesome. Um I hope we can have another one like this. >> Yeah. >> I would love to do that. That would be great. Yeah. >> Okay. Thanks so much. We'll see you next time. >> Byebye.