Don't Let Code Reviews Destroy Your Career (My Google Story) | Ep #50
===
[00:00:00] Hey guys, and welcome back to Easier Said Than Done. I want to tell you about the first time that I submitted a pull request. What a Google is known as a change list.
[00:00:08] The first time I submitted a pull request at Google, okay? My stomach. Was it not? I can still feel and recall and, re-experience that moment, right?
[00:00:16] So every one of the red diffs on the screen from the change request, from the change list, it really felt like I was exposing myself to criticism and judgment, like I was just standing in the light. No place to hide, you know? And, and worse, I was really terrified that someone would think I was not good enough to be there.
[00:00:33] I mean, after all, I was a 39-year-old ex-lawyer, right? I'd been a lawyer till I was 37, and I'd only just learned to code a couple of years before. And here I was at Google, like it was just psychologically quite intense. And so that that little voice in my head. Well, it was not so little. It was really loud.
[00:00:51] Everyone was stuck on this nasty loop, right? Again, they're gonna find out. They're gonna find out that you have no idea what you're doing. They're gonna see that you're not good enough. You don't belong here. And I, and I felt like a fraud. I was surrounded by these people who actually just normal people.
[00:01:04] But in that moment, they looked and seemed to me like genius coders which is a myth by the way. One of my colleagues at Google also did a very famous stock in this. The, you know, about the, the myth of the genius code, but I felt like a fraud surrounded by people I thought were genius coders that just seemed to get it.
[00:01:20] And I remember feeling, I remember feeling so clearly, like, I just don't belong, like. What have I done?
[00:01:25] Welcome to Easier Said Than Done with me, Zubin Pratap, where I share with you the tens of thousands of dollars worth of self development that I did on my journey from 37 year old lawyer to professional software engineer. The goal of this podcast is to show you how to actually do those things that are EASIER SAID THAN DONE.
[00:01:43] And I remember feeling, I remember feeling so clearly, like, I just don't belong, like. What have I done?
[00:01:48] How am I gonna survive here? Right? And the
[00:01:51] fear of not being good enough and worse that everyone else would see it instantly and wonder, Hey, how did you get into Google? Right? Like, that was the narrative in my head.
[00:02:01] It was so difficult. And even after I left Google and I left in really good terms. I left in a very positive way because I've done really well. My team got great performance reviews, but I wanted to work remotely. That's why I ended up going into one of the best companies in the Web3 space.
[00:02:14] Great team, a lot of ex Fang engineers and stuff. And I was surrounded by brilliant people again and again, that feeling of not being good enough followed me there. Right. And, maybe it always will. Sometimes I think maybe as long as I'm constantly stretching myself to go to the next level, it probably always will.
[00:02:30] And by the way that, you know, that advice out there about fake it till you make it? I think it's a terrible idea because if you don't have the skills, you can't fake it. But with the skills then what you're doing is you're not really faking it, but you still have to deal with your inner game, your self-belief, your psychology.
[00:02:44] So today we are gonna dive into how to ditch all that fake it till you make it rubbish mentality. You know, we want to level up your skills and I'm gonna share with you, I'm gonna help you learn how to get the most out of a code review process 'cause. Especially initially, it'll be very uncomfortable. Right? And this advice that I'm gonna share with you are these insider perspectives.
[00:03:03] They apply guys, whether you're in big tech or not, it doesn't matter, right? What I'm going to share with you are the meta principles that apply to your entire coding career. So
[00:03:13] in my first month at Google, I was completely overwhelmed. Right. It was a new engineering environment, new team. Everything was new, right?
[00:03:20] And you know, it's the world's most gigantic monorepo. Okay. Like, it's just a lot of text. And the end of my first month, I started working on my first change to the code. Like there was so much time just set up and training and I, I was writing code in Golang, a language I knew nothing about at the time.
[00:03:35] And it involved. Writing Kubernetes applications and making changes to something in that. And again, I knew nothing about Kubernetes. It was hard. Everything was hard. This is when I realized
[00:03:45] that reading code is so much more important than writing code. When you come into a company, when you get into a real world situation, when you leave the tutorial world and move into, real company, it's not the writing code that matters.
[00:03:56] In fact, my previous job was a tiny startup, so there was a lot of writing code, but the moment you get to a big company and. You're having to read a lot more code than you write, you know? So, I've done a lot of other podcasts on this and other, other LinkedIn posts on this as well. Anyway, for this particular first change that I was making to the code, I worked very late.
[00:04:15] Obviously, I tried to polish every line I could. And keep in mind, this is what, 2020? I think so, you know, it. The Gen AI movement, the Gen ai breakthroughs hadn't yet happened. There was a lot of AI enabled tooling at Google, but it wasn't the way we use it now, right? So, I had to, you know, literally go through every line, every little character and make sure I understood what was going then and get it right and, you know, so anyway, I reviewed my own change a hundred times, and then I sent it for a code review to the code reviewers, you know, to get LGTM looks good to me from a code review.
[00:04:49] And all of this is. You know, there's this solid process. I'd never seen anything like it. It was, so a lot of it was automated, but a lot of it just needed you to know how to use the automations. Right. And the code review I got back was brutal. Honestly. It was really, and okay, maybe it wasn't brutal. ahhh coders are very direct.
[00:05:08] Right. And I'm still getting used to that. So maybe it felt really brutal. I, I actually think that was it. I don't think she was being particularly. Intend. I don't think she's intending to be brutal in any way. Just terse direct, very engineer like. Right. But I still remember one of the comments that said, this is inefficient.
[00:05:24] And I think it said, check blaze target's history in the. The name of the application, which is another application that wasn't directly related to mine, but which I was interacting with. And again, keep in mind, world World's largest code base here, right? So all these terms are new to me, very new to me, and there's no, not no explanation, not much more guidance.
[00:05:43] And you know, that can happen a lot, right? When you're in a bigger company. I didn't realize it then. I hadn't thought about it. But when you're in a bigger company, heck, even if you're in a company with 50 engineers, other engineers are not gonna know from your. Change request necessarily, whether you're relatively junior or not, depending on the change and depending on what you put in it.
[00:05:59] But a lot of the times the changes can be pretty small you know, and very targeted. And so they're not gonna know whether you experienced or not. So they're going to assume all sorts of knowledge, history, background, and prior knowledge that you may not have. They don't know that you don. They don't know that you're new.
[00:06:13] They don't, they may not even know you're new to the company, right? So in this example, you know, no explanation, no real guidance, and it felt less like a technical discussion and more like a personal attack because I was contributing a piece of code to a, a code base that the code owners, the, the, the maintainers of that piece of the monorepo were really another team, right?
[00:06:32] And so I really felt kind of adapt at first, and my confidence just immediately evaporated immediately. Right now. Before I go on too much more about that, I want to tell you something about Google's development infrastructure. Okay? Now, keep in mind that at this point in time, I was self-taught ex-lawyer 37, you know, learn to code to 37.
[00:06:50] By 38, I had my first dev job and I was 39, so I had only. One year of professional development experience and a small, very fast growing startup, but very small. There were four people, and that was my experience before Google, like completely different from Google. So I'm gonna read to you what someone with 20 years of development experience felt when they first started at Google, right?
[00:07:11] So let me share with you. The experience of somebody who was 20 years as a developer before they moved into Google, just to let you know, just even with two decades of experience, how new and overwhelming and massive things can be for a developer.
[00:07:24] Right. And there I was with 12 months of experience behind me. So let me share my screen for those of you who are listening, and I'll read this out, right. So this is from someone who, you know, from 2016 to 2018, there were senior swe. And they, and so they recounted this experience after starting at Google, right when an engineer first joins Google.
[00:07:44] And I'm reading here. So for those of you listening, when an engineer first joins Google, they start with a week or two of technical training on the Google infrastructure. That is correct. I worked in software development for nearly two decades and I've never even dreamed of the development environment Google Engineers get to use.
[00:07:59] I felt like Charlie Bucket on a store of Willy Wonkers Chocolate Factory. Astonished by the amazing and unbelievable good goodies available at any turn. Now, I will quickly add there. For someone 20 years of experience, they understand why all these things exist. They have always wanted them because they've been around so long, they've seen the pain points and problems.
[00:08:15] For someone as new as me, I didn't even know why we had this fancy tool, like it was just completely new. Guys in my team, we didn't even use GI or GitHub because GitHub wasn't big enough for the size of the code, like. I can cannot even begin to tell you how big the scale of things that Google are. Right.
[00:08:31] And how sophisticated, therefore complex to someone new it is. Anyway, back to his reading, the computing infrastructure was something I Star Trek. The development tools was slick and amazing, the process process and he italicized this process. The process was jaw dropping while I was doing a hello world coding exercise in Google's environment.
[00:08:49] Even a 20-year-old developer has to start there in a new environment. So yeah, while I was doing a hello world coding exercise in Google's environment. A former colleague from the IE. Team Ping on Hangars chat probably because he'd seen my tweets about feeling like an imposter as a Swede. There you go.
[00:09:05] It happens even at that level. He sent me a link to Clink which click, which I did code from Google's core advertising engine in. Appeared in my browser in a web app, IDE Now let me just pause and tell you. A web app ID is not like vs. Code. It's like what vs code does now, which is vs code in the cloud where you can access vs code in the browser.
[00:09:23] But Google's had this for over 10 or 15 years. Google has their own internal iDE called Cider, right? And so they use that in the browser because the code is just too big to fit in a machine, so they have everything done in the cloud, the build, the writing, everything right? So anyway, so the code appeared in in, in a web app Id, Google's engineers have access to nearly all of the code across the whole company.
[00:09:47] Remember what I said, the world's largest mon repo, right? This alone was astonishing. In contrast, I'd initially joined the IE team so I could get access to the networking code to figure out why the office online's team website wasn't working. Neat. I can see everything I type back. Push the analyze button.
[00:10:03] He instructed I did. And some sort of automated analyzer emitted a report identifying a few dozen performance bugs in the code. Wow, that's amazing. I, gosh. Now push the fix button. He instructed this isn't some sort of security red team exercise. Right? I asked, which is actually quite funny because that's exactly what I would've asked in that position.
[00:10:20] He assured me that it. I pushed the button, the code changed to fix some unnecessary object copies. Amazing. I effused click submit. He instructed I did and watched the system compile code to run in the cloud, determined which test to run and ran them later that afternoon. An owner of the code in the affected folder typed LGTM, which is Google's approved changes by typing an acronym for Looks good to me.
[00:10:43] LGTM is looks, looks good to me. On. And so they did that on the chain list that he had submitted. And my change was live in production. Later the day I was in a word gobsmacked that night. I searched for the entire code baseball misuse of an ie cash control token and proposed fixes for the instances I found.
[00:10:59] Now why am I sharing that with you? Well, it was really the beginning part that was more important, right? That for the point I'm trying to make, which is Google's infrastructure, actually all of big tech. I, I understand it's the same at Amazon. And another big tech company, they have massive infrastructure because.
[00:11:13] They are bigger than some of the biggest. Clients or customers they have, right? And because they're so much bigger than a lot of other big companies in the world, they need customer infrastructure now, as you can imagine, that is incredibly intimidating. So back to my code review, that single extremely uncomfortable bit of feedback that was not uncomfortable 'cause it necessarily criticized me, but it put me in a position of
[00:11:35] really feeling exposed and completely incompetent and like I had no idea how to fix the problem, right? So that single experience taught me so much because I had to then fix my attitude in psychology to get the most out of it, and to actually successfully complete that code review, which I did later on.
[00:11:53] Hi, if you want a no BS insight into how to change your career, whether to code or something else and how to actually get job opportunities in tech, then please subscribe and like.
[00:12:01] It's no BS because I have zero incentive to mislead you. I just want to help you and give you tons of value so that you will consider working with me to get to your next career.
[00:12:10] Take a look at the
[00:12:11] description text below to learn more
[00:12:13] about the training I offer.
[00:12:14] Also, you may find my newsletter. Interesting. I've linked to it in the description. I only mail about two, maybe three times a week, and it's pretty focused. It's usually around industry trends, things I've learned from other developers, the common habits and pitfalls that I see in my students that affect their ability to succeed, that prevent them from actually succeeding, case studies and insights from that, so you'd probably find it quite useful. And hey if you don't, you can always unsubscribe later. No problems.
[00:12:40] But I do post content here regularly and by subscribing and liking and hitting that notification bell you will get to know when I post new industry insights for you. You'll also know within about three seconds if you want to learn more, but at least you won't miss out.
[00:12:52] Oh, and please follow me on LinkedIn too. I pretty much post there every single day. Just look for my name, Zubin Pratap. All right. So please like, and subscribe to this channel and let's get back to the episode.
[00:13:01] that single extremely uncomfortable bit of feedback that was not uncomfortable 'cause it necessarily criticized me, but it put me in a position of
[00:13:09] Really feeling exposed and completely incompetent and like I had no idea how to fix the problem, right? So that single experience taught me so much because I had to then fix my attitude in psychology to get the most out of it,
[00:13:23] But it forced me to learn how to separate my code from my ego and turn. Ignorance and the dark energy of my imposter syndrome into fuel. It's a lesson that I've honestly carried with me through every big tech company that I've worked at since, but, but there's a catch.
[00:13:39] There is a catch.
[00:13:42] Understanding how to extract all the juice and growth out of code review is not a technical skill. It is very much an emotional and attitudinal skill. It's a choice , but it's a choice that must be renewed every day. So then that way it becomes a lifestyle and this lifestyle of right attitude, right thinking, right choices, and right action is what I end up teaching in the Inner Circle program a lot because it guarantees success no matter who you are, where you are, what you do, not just in coding and career change, by the way, but everything in life, right?
[00:14:13] Right. Choices and right action come from right thinking. So let me share with you the five lessons I learned from that deeply uncomfortable experience in that code review. And as you are taking this. In. I really want you to imagine yourself using these five points that I'm talking about to turn any painful feedback you get in code into your greater source of growth.
[00:14:34] Okay? Look, we all want to become better engineers. The reward is obvious. We get more interesting work. We get to work with better people. We have greater impact and, and the confidence that comes from the pursuit of mastery. We get all of these things and of course of, you know, we get the benefit of climbing up that intellectual ladder to, to the next level, the financial ladder to the next level, and the self-belief ladder to the next level, right?
[00:14:59] But
[00:14:59] the path to confidence and competence is 100% paved with criticism, negative feedback,
[00:15:06] and those kind of things, and many developers get derailed by it. In my case, the code review was not being nasty, you know? It felt nasty, but I don't think they were being nasty. And you will, in real life, encounter nasty people.
[00:15:19] That's gonna happen over the course of your career. I know I have several times, right? And it's the lessons that I'm about to share with you now that helped me to not react defensively, to not let my ego take over, and most importantly, allowed me to extract the lifelong lessons hidden inside that.
[00:15:36] Negative experience.
[00:15:38] So here are the five lessons that I believe I truly believe double my ability to grow from code reviews. Number one, your code is not you. This separation is the most critical step.
[00:15:49] The reviewer is critiquing a single piece of work, okay? Not your intelligence or your value as a person.
[00:15:55] Detaching your identity from the code you write is a really valuable superpower because it allows you to analyze the feedback objectively instead of emotionally with a bit of detachment, a bit of separation. 'cause remember, your goal is to improve the code, not to defend yourself or to please other people.
[00:16:14] Number two. Always assume good intent on the part of the other person, and then seek clarity.
[00:16:19] So I, I'd said earlier today that I received a brutal, brutal review, but then I corrected myself and said, oh, maybe it wasn't brutal. Maybe it just felt brutal, right? Because I am assuming good intent here. And so what we wanna try and do is assume good intent, seek clarity.
[00:16:34] Reviewers can often seem harsh. But they're off actually just focused on the same thing that you are, right? The, the health, the code health, the quality of the project, the quality of the code, and just like you, they're trying to do the best job they can do, which as a reviewer is drive for that, that increased code optimization or that increased code health, right?
[00:16:52] This is a very core philosophy at the big tech companies. They're not. They're not trying to be mean. They're simply prioritizing directness to improve the outcome. They improve the quality of the code. Now, the wrong response to that is to argue or get defensive, and I know it's easier said than done.
[00:17:08] Heck, that's why this podcast is called Easier Said than Done. Because we talk about these things, right? The wrong response is to get defensive. The right response is to ask, once you've mastered yourself and put that separation between you and the code, and the code reviewer in your head, the right response is to ask.
[00:17:23] Hey, thanks for the feedback. Could you elaborate on your reasoning behind the suggestion? Could you explain why you feel this way? You know, these are the kind of sentences you can use, or you may disagree with them. You may think they're wrong, right? Then disagree with their analysis or their conclusion, but not directly with depth.
[00:17:38] For example, you can say, I'm not sure I follow your conclusion. I'm not sure I follow your reasoning. I'm not sure I understand where you're coming from on this. Could you help me understand my approach here was X, Y, Z? Can you help me understand why that would not be the best outcome here? You know, invite them to discuss, right?
[00:17:57] This transforms a potential experience that could feel confrontational into a collaborative experience. And when you've implemented a change or you need to push back, it's very important. It's your responsibility to explain your reasoning clearly and politely. Don't assume that your reviewer knows more than you.
[00:18:16] Often they won't. Okay. Now, if you're submitting to someone's repository where they're the owner, yeah. You, you'd expect them to know at least as much as you, probably more than you on the actual code, but they may not know some of the context behind your change. They may know their code base really well.
[00:18:33] They may not know the reason for your change really well. So that could be a source of pushback. And as an author of the change, if you are requesting someone to change their code, you are the one closest to the codes that's being submitted as the change. And so your input is very valuable and it is your responsibility.
[00:18:49] Number three, code review is. Unstructured mentorship,
[00:18:52] guys, so many people out there, especially these aspiring devs, want more mentorship. More mentorship. This is it. This is unstructured, informal mentorship. It's the best kind too, right? Because sometimes this mentorship is uncomfortable, like good mentorship often is uncomfortable.
[00:19:08] I know my students at the inner circle often feel that way when I hold the mirror up to them, right? Heck, sometimes. You know, an uncomfortable code review can feel like a personal attack. If it touches an insecurity or a nerve that you know exists, that happens, which is why your self-awareness is a crucial piece of this puzzle.
[00:19:24] And this is also a core principle of high performing engineering teams that I've seen, right? A senior engineer. We'll give you basically free personalized lessons on how to improve your code or avoid specific pitfalls or how to adopt a better design pattern, how to write more maintainable code, more readable code, more testable code, or how to think about a problem differently.
[00:19:44] So valuable. All that problem solving is, is there in that code review. Right? And none of these things guys, are things that you learned in colleges or bootcamps or YouTube. That's, that's why they're in your review, right? You learned about it because someone else. Was thoughtful about your code and took the time to tell you that knowledge goes into your vault forever.
[00:20:04] You can't afford to reject it just because it wasn't delivered gently or in a way that you'd like. Sure, you can ask or hope for that, but at the end of the day, you're throwing the opportunity out. If you say, Hey, they delivered it in a rough way, I'm just gonna throw the baby out with the bath water and not learn from it.
[00:20:19] Look, they're not looking. For you to deliver perfect code just better than what you've got there right now. And sometimes oftentimes in fact, there are multiple right versions, right? Sometimes even a one line comment can be a roadmap to improvement that triggers off a whole lot of thinking and research and self-reflection and just, you know, you wanna read other types of code like that, right?
[00:20:41] It happens so many times to me that I'd end up just reading other people's codes. Because of somebody else's comment sent me down this, this curiosity rabbit hole in a positive way where I was learning a lot, right? The world just expanded. So one of the most important things that I learned is that the quality of the code is everyone's responsibility.
[00:20:59] The teams, you, the author, and the reviewer. Okay? Everyone shares their responsibility in, in maintaining the building, the edifice. That is the code. Okay?
[00:21:07] Number four. Thank you is your strongest response.
[00:21:10] Now, I know it's hard to do that when you feel like you're being attacked, right? So when you feel defensive, the most powerful thing you can do is pause and type.
[00:21:18] Thank you for the feedback, or thank you for the thoughtful feedback. Thank you for your perspective. Thank you for the detailed feedback. Let me look into this. I'll work on this. Let me investigate more. That's the right thing to do. Okay. It immediately deescalates tension and signals to your team that you are coachable, that you're professional and that you're dedicated to quality.
[00:21:37] The very traits of a senior engineer. I can tell you from experience, this is the expected practice at the highest levels of tech, you should reply to every single comment, even if it's just to say. Done. Thank you. Act acknowledge, right? This shows respect for the reviewer's time and keeps the conversation flowing.
[00:21:59] Okay, number five the last one, you get to control the narrative in your head. You can let a bad review make you bid for weeks or years. That is entirely your prerogative, but really does it help you?
[00:22:11] Okay. Or you can fix the code, learn the lesson, let go of your emotions and hold on to the evolution that came from it, your growth.
[00:22:20] And
[00:22:21] that way you'll be a better engineer by lunchtime.
[00:22:24] Look, you get to decide whether this is the story of your failure or your inadequacy, or the story of in, of the growth opportunity that you came into this role to achieve. Right? You came, you took the role to earn a certain amount of money to grow, to be surrounded by people who are better than you.
[00:22:41] And then when you get the gift of their
[00:22:43] feedback, we take, they tend to take it negatively. I get it. It's human response, but. It's Why are we there, right? The ultimate goal guys isn't to be right. There are so many different variations and opinions of what is right in engineering. The goal is not to be right or to win arguments.
[00:22:59] The goal is to deliver impact. Raise your learning. You've gotta be a bit selfish about it. Raise your learning, build your credibility, and become a valued member of the team because that is a skill that you'll see in future jobs. Will come with you, it'll follow you. You don't want the harsh feedback to follow you.
[00:23:16] You want the growth to follow you into your next role and your next rung on the ladder. Okay? Because harsh feedback is inevitable and it is uncomfortable.
[00:23:25] So look, I just wanna conclude by saying that I wanna share with you actually how I've internalized, you know, these five lessons, right? There will always be people more experienced than you.
[00:23:36] Thank God. Okay? Thank God. And if you're lucky, you will get to work with them. And if they criticize your code, that is a real opportunity. I truly have learned to appreciate this myself, and it still feels uncomfortable. Don't get me wrong. It's not that I'm sitting there Pollyanna and completely comfortable being criticized, or my code being torn apart.
[00:23:55] It's rarely torn apart, but you know, the, my baby's being, I'm told my baby's ugly and I have to do something about it. It never feels good, of course. I feel shaken. I feel miserable. Lots of old self-doubt and insecurity will come back when I get negative feedback. That's just normal. But I've been through it so many times now.
[00:24:11] I've been through this dance a few times, so I also know that once that sting settles and you, you take stock of what you've learned, you have what remains after that is something that far outlasts the pain. You'll have growth, you'll have learning. No one can take that away from you.
[00:24:29] And that, my friends, is how you become an engineer who doesn't just write code, but an engineer who loves the growth and learning that comes from being an engineer.
[00:24:39] Okay, I really hope that was helpful. Like and subscribe and I will see you next time. Take care.
[00:24:44] Just subscribe, you know you gotta do it.
