Phil Alves on Development and Code Reviews

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season of interviews and we're talking someone new this time. We're going to be speaking with Phil Alves and we are going to talk development. We're really going to talk about development and doing it right with the mindset or with the background of somebody that didn't start out as a developer. Phil has sort of grown into this from a non-technical, didn't go to college type of an approach, which gives us some, I think, fresh insight into what really matters about being better developers, about creating better code, about doing the things we do as developers better. But I don't want to take any of his thunder away. So let's go ahead and dive right into our conversation with Phil. Well, welcome back. And today, you might have guessed it, we're starting a new interview. We're going to be speaking with Phil Alves today. And I guess I'm just going to dive right into it and let you go ahead and give us an introduction to yourself and we'll go from there. Yeah. So I run two software companies at the moment. One is Dev Squad, which is my consulting firm. We're about 90 employees and we build SaaS products for other people. And I also have my own SaaS product, DevStats, which connects where developers are doing their job and help development teams to be more productive and to remove blockers. So those are the two companies that have been running currently. I have many businesses for the years. I started working when I was 17, a software developer, but I come from a family of entrepreneurs. So I didn't look for a job after I learned how to code. I look for clients. So I only had one job in my whole career and I had many, many clients and I built many applications and I'm really enjoying also now having my own product. So that's kind of me to let show. Excellent. So I guess let's start with, where did you learn your programming skills? How did you sort of get into the software world? Well, I'm going to date it myself here, but when I started, the easiest way was through books. We didn't have that many videos. We didn't have that many video courses. So I bought a book on PHP, how to build applications in PHP. Then I would read the book and try to do on my computer and wouldn't work because my version of PHP was different from the version of the guy that wrote the book. So later I had to learn to like change the versions and learn what was different. But basically I'm a self-taught developer. I learned through books and then also as my first business grew and we started hiring people, I hired people that went to college and they taught me a lot. So like my senior developers have taught me a lot along the way. Yeah, that's the way it goes. I'm also one of the goes back to originally it was like you had to find a book and then yeah, it was the same thing. Although sometimes you'd luck out and they'd have a CD in the back that actually had the exact same version that they were working on. Sometimes they didn't and that could be a little bit challenging. Sort of like today when you go Google something and you realize that you're getting an answer from 15 years ago and it really doesn't apply anymore. Yeah. It's a little more frustrating when you buy a book to do that. And the extra problem for me was I'm from Brazil and I didn't speak English at the time. So I was buying a book that was translate and so they also had issues with translation and the book was probably like two years old by the time it got translated. So they add to the complexity and so I figured learning English would help me learn how to code and that's kind of like what I did later on. Excellent. Yeah. And that's, I like how you leverage the workers, the team that you brought in with the senior developers and that. I think that's some of the things that sometimes, especially now as people are all remote or a lot of cases people are very remote, is you sort of lose that connection and that ability to learn from your co-workers when you're sitting next to them and going through stuff day in and day out. Yeah. We have to be so much more intentional about learning from your co-workers. That's one of the things that I track at both my companies. I think especially a code review, it's a process where developers can learn from each other and where they should jump on a call and like do some programming, but it's not as natural when you're in the remote world. You have to be a lot more intentional about it or that's not going to happen. And it's a challenge because things change too quick and now we have to learn how to do that. And that's also, I think, why all the big companies are telling people to come back to the office is because they haven't figured out how to be as productive working remotely. They haven't figured out how to get people to learn and to pass the knowledge. And I guess they figure instead of keep trying, they will just bring everyone back. Yeah. And I think that's part of it is there's more to being productive than being individually productive. As a team, it helps to be more productive and to grow as well. Yeah, for sure. And like to learn from somebody else. I think that learning, like I like to say, the more you know, your job should be to bring other people up to actually do the work. And so that I feel like we have to figure out how to do that in the remote environment. Now you mentioned it's a long time favorite of mine is the idea of code reviews. Tell us about how you see them and how your teams, how you guys leverage that to make the most out of learning what it is that you're building and then also to build better code. Yeah, I think it's the most important ceremony in software development. It's code review. We have daily, we have sprint planning, we have sprint review, but I don't think any other ceremony is more important than code review because the code review is where the team gets to really collaborate and to work together. And they help each other grow. They help increase the quality of the code. And I'm looking at things like you want to make sure that people doing review are actually catching issues. You want to make sure that code reviews are not too big, like the people actually sending pull requests often. And we want to see people growing and communicating well in the interaction. So it's one of the things that actually my software tracks, that stats, it's how is the process in the collaboration of the team going and is the team getting better? And I see all the time developers that didn't have that culture, they come and they work at my companies, they're like, oh my gosh, in three months here, I learned more than in three years in my career. It's because when you start to collaborate, you start to learn. And code review is the place where developers collaborate. That's my opinion. So how do you keep them? Because I agree 100%. One of the things I've run into in code reviews is it, like, it's just two things I want to talk about is one is flying through it. It's just sort of like, you know, it's like a rubber stamp kind of thing is people not spending enough time in the review side of it to actually review. And the other side, which is sort of a, I think the same side of that coin is people being, you know, taking it personal where it's like, hey, you know, you need to, you could change this or you could do this better. How do you work with that to make sure that you get the essentially like the right balance of focus and also the right discussions that come out of the code review? Yeah, I think to avoid the first problem of people just clicking the green button, you can look at cycle time. Cycle time is a metric of how long things are taking. If your code review is taking 30 minutes, there's no real code review being done. And then you can talk to your team about doing code review, but many times people are not doing code review for the second problem they describe because when there is code review, people take it personally. They just don't understand how to handle. And I think it goes back to culture. You can't have a culture of insecurity. You know, like you have one thing that I try to train my people to do is to like, accept the feedback and say, thank you. Let me digest your information. And maybe you, hey, I digest this information. The point they make doesn't make sense because of this. If this, what do you think? But I think most of the fights in code review come from insecurity. And that has to be addressed in a personal level. The person, there's no reason to be insecure. And that's another thing that I say that the more experienced you are, the more willing you are to say, I don't know. If I have a person that doesn't have the ability to say, I don't know, or to take feedback from someone else, I know that person might be a good developer, but they're not a senior developer yet. So that's important. And especially as you have a culture where senior people are saying, I don't know, they're being humble, the other people starting being a little bit less insecure and understanding and taking the feedback as a place to grow. Yeah. And I find that those are the best environments that you also get those, the junior people or the newer people in the environment, giving them that comfort, you're able to think outside the box a little bit more. You'll get people that'll have a very different background and they feel comfortable enough asking questions that otherwise they may think it was a, quote, stupid question, but it's actually someone's like, no, that's actually a great question. Sometimes we need to answer that as opposed to just say, well, we just always do it that way and moving on. For sure. For sure. But yeah. And again, I think a team that cannot manage conflicts is not a high performing team. If you're thinking about building software products and you're thinking about building a high performing team, you have to be able to navigate those conflicts without people getting mad and taking it personal. And I really have discussions. I think it shows level of maturity of a team. And there's the only way to get there is to start doing and to start addressing the problems that you might have along the way. Now, one of the things you said, one of your products is really it is to become a high performing team. It's tracking stats and finding ways to be a better development team or better developing team. How did you, how'd you come about that? And then maybe talk a little bit about that. What are some, some good stats to track and some ways that a team can set some metrics so they can, they can measure those and improve. Yeah. So the idea came from building many software products. I understood the unfair advantage of the product, especially the founder. It's the knowledge that the founder has about the industry. And for the longest time, I want to build a product, but I didn't know what to build. I couldn't build a product for the construction space, for example, because I don't know enough about construction. And I have been running development teams for a very long time. Since my first business, I grew and I had hired developers. And I, and I want to figure out a way to, to better run those development teams and to take them to high performing. So there were some researches that come out like the Dorametrics research and the space framework research. And those research were very powerful. And then from those research, many software applications were built to help people track those metrics. I used some of those softwares and I, and I thought like they weren't look at the things in the way that I would want to look, want to look like many times they were too complex or too simple. And so I decided to build my own software in that space. And I thought the unfair advantage you'd be like on my consulting firm, I had almost a hundred developers and I have years and years of developing teams and trying to do that, like without the help of a software, but in a more informal way. And I thought that would help me build my own product. And talking about metrics, the first thing that people see when they log into my, my application is their benchmark. So the way that works, they're going to connect their, their GitHub and they will connect their their GitHub or whatever their Git repository is, whatever, and their Jira. And then from there, I'm going to benchmark where they are against industry standards in six numbers that I, that I believe are the six most important numbers. And the way they come up with those six numbers, I think that's also important in software is to bring your outside experience. One of my hobbies, I'm a pilot. And when you're flying an airplane, you have the six instruments, they're the most important instruments. And if you're looking at those, you're not going to die. And so I started looking at every single metric available for developers. And what are the six metrics that we can look at that would really help understand that the team is, is going in a good direction. And so those metrics are PR cycle time, how long it takes from when I start coding to until the code gets merged. And then we talked into like the code review time and things like that issue cycle time. That's the time from when I issue goes to in progress to done on Jira, because maybe the issue might have many PRs, but how long does it take to get an issue done? Plenty of accuracy. How are you planning? Like how much of what you say would do, you actually do. If you're doing 100%, that's a problem is your team is not safe to take, to make, take risks and to make good bets. But if you also, if you're below 80%, there's room for improvement. So you want to be in that sweet spot 82 to 95% of how are you planning. Then I look at changing file rate. What basically of everything that we build, how often do we break stuff? Every time that we do deploy and how often are we breaking stuff? Again, if nothing is breaking, probably means that you're moving too slow. Unless depending on the kind of software that you're building, like if you're building some kind of medical software, better not be breaking. But for all other kinds of software, if you never break, it's a problem. That's why Facebook come with that move fast and break things. But you also wanted to track that. I like to see that below 15% of the things that we release actually break anything. And then look at code review size, because again, if the size of the code review is small means actually code reviews haven't done and the quality of the software is going to be high. And look at deploy frequency. How frequent are you deploying the software to production? Those are the six most important metrics in my opinion. And then from there, the software track many, many other metrics. But those are the benchmarks where people would see from where they start. Now some of those sound like they could easily be particularly like production deployments and stuff like that, that they feel like they're more a team level metric than an individual metric, or is there a way that you found to really link that to an individual? Or do you also do a two tiered approach where you're looking at the individual developers and how well they're doing, but also how the team is doing? Yeah, the other metrics are actually on the team level. And I think that's how you should analyze your development team, because you're trying to be a high performing team, not a high performing person. But I do have ways to go deep into look at how one person is doing. And then I'm looking at things, for example, how many code reviews have you done? What's the depth of your code review? Like how many PRs have you merged? So there's other metrics that I look at the individual level, but I think my benchmarks are all team metrics, because I want to know the team, it's going well. But there's other ones, for example, in the individual level, I look, how many days per week are you actually committing? Because that's the small piece of work that you do. Are you committing often? How many issues you resolve? How, again, are your collaboration metrics? How many reviews have you done? How many comments have you posted? What's the size of your PRs of the things that you build? What's the change in your own personal change in failure rate? But for example, you're not going to have a cycle time alone, because if you're working a team, there's like many pieces that's going to go through. The cycle time is the cycle of the team. And, but that's important to know, because I want to see my most senior person spending more time mentoring than writing code, because again, his job is to bring things up. So when you go down on the individual metric, you can look, and if you have a senior person that's really just delivering a lot of features, it could be a problem for your progress long-term. But if you're not tracking, there's no way for you to be like, okay, where is the value? But now if I look at my senior person and say, look, senior person, he reviewed this and this person, did a pair of programming with this and this other person. Now I can prove the value of that person without actually having to, that person still having to be delivering features every single day or emerging his own PRs. Yeah, I think that's a key thing is, particularly for seniors. And that's, you mentioned earlier about, you know, certain people, you see them as not a senior developer if they're not, you know, if they're not giving back. And I think that's part of it is that it's, you know, that ability to take your skills and your experience and scale those out to other people, to train others and bring that whole team up instead of you having to, you know, do everything or do all of the, in this, you know, maybe in this case, coding specifically, it's more about you sharing out your knowledge so that other people can do code at the level that you can. Yep. So you've got, you know, you've got a big company. How do you, how do you sort of break that up? And it sounds like you, you know, you've got, I'm assuming it's not one team. So how do you look at, particularly in a case like that, when you've got multiple teams, how do you look at both the individual teams, like, you know, making high performing teams, but also are there things that you do that can be, you sort of go across the board, or do you have to really focus on each team when you're looking at creating high performing teams? Well, there's the industry standard metrics, right? So the research, the Dora metrics research and the space metrics, space framework, those are research that was sponsored by Google and Microsoft. They brought the benchmarks. And so I believe everything starts with the benchmark. So I have many teams, like basically that have squads, high performing squad for each of our customers. And so there's more than 20 squads at the moment. And what happens, there is the individual thing. They have to look specifically at each project, but the benchmarks are there to guide you. Like you can know from the benchmark, if your cycle time is too long, if you're not planning well enough, regardless of the complexity of the product, that's where I start. And I hold all my teams against that, the benchmark. When you've got, and this may be geeking out a little bit, but when you've got that number of teams, do you sort of take advantage of that sometimes and test out some ideas and test out some metrics and that? So you sort of say, Hey, I'm going to take these couple of teams and I'm going to treat them or measure them this way, but I'm going to take these other teams and do something a little different. So you can do AB testing and things like that, and really find out how to refine those stats and those metrics that you're tracking. Yeah. When we have a new metric, I might distract the metric with one squad and see how much that made the squad improve. But also the metrics that we have, each team might need to focus on a different one. For example, we might have a team that they're planning accuracy is like 50%, but you look at every other metric, maybe their cycle time is short, they're deploying to production all the time. A lot of things are happening. They're a very productive team, but they just can't plan. And if they can't plan, they get stakeholders mad, even though they're working their ass off and they're delivering more than most teams. So on that team, we work with planning accuracy and how can we plan better? So we will work in different metrics with different teams, but everything starts from the big picture where we are and what's most important to work on this quarter and what are the things that we have to look at, the OKRs that we have to create for this team. Now with that, do you end up finding yourself sometimes, I guess for lack of a better word, working towards that or tuning the team for the customer? Because customers are a little different in what their expectations are and what they're looking for in that. Do you sometimes find that the metrics are great for an overall team, but you're maybe going to adjust your focus based on who the customer is or the project is that they're working on? Yes, but I think there's a two-way street and especially customers that never built software before or customers that built software before and were taught bad behavior, that has to be addressed. That has to be understood. If you expect your team to never be wrong and to do everything that they say they would say all the time and never have bugs, you just don't understand software development. So you either learn to manage your emotions or you're going to be lied to. So you have to be really transparent and we are transparent. Because the size of my company, we can afford to work with the people that understand how software development works. And if someone does, then they can leave and they're going to find someone else to replace them. So that's the two-way street where the team has to be adapted. Also the client, they have to understand the software development. It's going to be a process with ups and downs and things like that. Definitely. Now, have you seen, you've been in this for several years, have you seen a trend for the customers to be more or less, I guess, software knowledgeable as they come into these projects or is it about the same as it was when you started? No, it's a lot better now. But it's also the kind of customers that we work with nowadays is different. When you're starting, you have to work with everybody that comes to the door. And most of those people are very inexperienced and they also don't have enough resources. So they're stressed. Right. And so they all trickle down to the team. As you're working with people, they're more established, they're more sophisticated. They understand that better. And even if they never did software before, they're more coachable. And so I think it got easier as we got bigger, because we got better customers. That's just the reality. Yeah. Sometimes I guess it does help to just say no, because then you suddenly have, if you can say no to the bad customers, then you only have good customers. It makes it a lot easier. Yeah. I think that's what consulting is about. It's about working with people that can actually make an impact. And I think good companies are very selective with who they work with. A company that's taking everybody, a service company, I think it's a red flag. Yeah, I think so. I think for any company, if you're selling to everybody that comes to the door, probably service companies even more so, because there's just a, some people are not a good fit for your product and they may not know that. And if you're just going to sell to them anyways, then you're asking for trouble basically. And that's that kind of case. If they don't know what they're, particularly with software, I think if you don't know what you're doing and you're like, Hey, I need somebody to explain it all. But then you're also not going to be open to listening to them. Then it's just, it's a, it's a relationship that's not going to work. And it's always going to be best for you to walk away as a, as a provider in that situation. For sure. Sure. And we will pause there, but don't worry. We're coming back for part two, next episode. We're going to continue our discussion and we're going to continue to dig into what is it that, that makes a better developer? What is it that you can do to not only make yourself a better developer, but those in your organization and those that you're working with better at what they are doing to make sure that there is that, we'll say that accountability, that focus on quality, that camaraderie basically that allows you to build each other up and to grow into a better team, growing individually, but also growing as a team with your ability to work together as well. And we're going to talk more about that with Phil next time. It's something that he does very well. So, you know, go ahead and put your notes down for now, but we're ready to come back and add some more notes to that notebook in the next episode. That being said, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. Please check out school.develop-a-nor.com. That is where we are starting to pour a lot of our content. We've taken the lessons, the things that we've learned, all of the things that make you a better developer, and we're putting it there. We have a range of courses from free short courses up to full paid boot camps. All of these include a number of things to help you get better, including templates, quick references, and other things that make us all better developers.