‘Enhancing DevEx, Code Review and Leading Gen Z’ with Jacob Singh, CTO in Residence, Alpha Wave Global

This blog was originally published in the Typo blog.

In the latest episode of ‘groCTO Originals’ podcast (formerly: ‘Beyond the Code’), host Kovid Batra engages in a thought-provoking discussion with Jacob Singh, Chief Technology Officer in Residence at Alpha Wave Global. He brings extensive experience from his roles at Blinkit, Acquia, and Sequoia Capital. The heart of their conversation revolves around ‘Enhancing DevEx, Code Review and Leading Gen Z’.

The discussion begins with Jacob’s reflection on India and his career break. Moving on to the main section, he explores the evolving definition and widespread adoption of developer experience. He also draws comparisons between tech culture in Indian versus Western companies and addresses strategies for cultivating effective DevEx for Gen Z & younger generations. Furthermore, he shares practical advice for tech leaders to navigate the ‘culture-market fit’ challenge and team structuring ideas from his hands-on experience at Grofers (now ‘Blinkit’).

Lastly, Jacob offers parting advice to developers and leaders to embrace AI tools like Copilot and Cursor for maximizing efficiency and productivity, advocating for investing in quality tooling without hesitation.

Timestamps

• 00:06 — Jacob’s introduction
• 00:39 — Getting candid
• 04:22 — Defining ‘Developer Experience’
• 05:11 — Why is DevEx trending?
• 07:02 — Comparing tech culture in India & the West
• 09:39 — How to create good DevEx for Gen Z & beyond?
• 13:37 — Advice for leaders in misaligned organizations
• 17:03 — How Grofers improved their DevEx
• 22:04 — Measuring DevEx in multiple teams
• 25:49 — Enhancing code review experience
• 31:51 — Parting advice for developers & leaders

Links and Mentions

• Jacob on Linkedin and Website
• Kovid on Linkedin
• Watch this episode on Substack and YouTube
• Listen on Spotify, Amazon Music, and Apple Podcasts

Episode Transcript

Kovid Batra: Hi, everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest. He’s currently a CTO in Residence with Alpha Wave Group, which is a VC group. He comes with 20-plus years of engineering and leadership experience. He has worked with multiple startups and orgs like Blinkit as a CTO. He’s the guest whom I have met and he’s the only guest whom I have met in person, and I really liked talking to him at the SaaSBoomi event. Welcome to the show, Jacob. Great to have you here.

Jacob Singh: Thanks. Good to be here, to chat with you.

Kovid Batra: Cool. I think, let’s start with something very unique that I’ve seen experienced with you, that is your name. It’s Jacob Singh, right? So, how did that fusion happen?

Jacob Singh: Just seemed like fun, you know? Just can’t, since I was living in India anyway, I figured Smith is harder to pronounce, so.. I’m just kidding. My dad’s from here. My dad’s Punjabi. So, you know, when a brown boy and a white girl, they love each other a lot, then, you know, you end up with a Jacob Singh. That’s about it. There’s not much else to it. I grew up in the States, but I’ve lived in India on and off for the past 20 years.

Kovid Batra: Great, great. Perfect. That’s rare to see, at least in India. Most of the generation, maybe half-Indian, half-American are in the U.S. But what did you love about India? What made you come here?

Jacob Singh: Good question. I was trying to escape my tech stuff. So, I sort of started very early. I taught myself to code as a teenager and started my first business when I was 18 and I’d done pretty well. And then, when I was like 21–22, I just sort of decided I wanted to do something different, do something in the social sector, helping people. So, I took a job with an NGO in West Delhi and sort of shifted for that. That was the original purpose. Why did I stay? I guess there’s something dynamic and interesting about the place. India’s changed a lot in 20 years, as everybody knows. And, I think that’s been continuously exciting to be a part of. It doesn’t feel stagnant. It doesn’t feel like, I mean, a lot of changes are not in the direction I would love, to be honest, but, you know, but it’s an interesting place. There’s always something happening. And I found that, and then eventually you build your community, your friends and your family and all that kind of stuff. So, this is home. Yeah, that’s about it.

Kovid Batra: Perfect. Perfect. Talking about the family, I was just talking to you on LinkedIn. I found that there was like a one-year break that you took in your career and you were just parenting at that time. And honestly, that’s very different and very unique to a culture, to an Indian culture, actually. So, I just wanted to know how was your experience there. I’m sure it would have made you learn a lot of things, as it does for a lot of other parents. But I just wanted to hear about your experience with your kid.

Jacob Singh: Hopefully, it’s not so uncommon. I think it’s starting to change especially the role of men as fathers in India. I think it’s traditionally, like my dad’s father, he just saw him for tea, you know, and he was reading the newspaper and he’d meet him once a year on his birthday and take him to a quality restaurant for a coke, you know, that was their relationship. I think things are different with Indian fathers these days. I think for me, you know, we were just, perfectly honest, was going through a divorce. Difficult. I needed to be there for my daughter and I was, you know, sort of taking half the responsibility in terms of time with her. This was eight years ago. And I think my parents had also divorced. So, I was kind of, my dad was a very active part of my upbringing and did all the things, did all the dishes, cooked all the meals, you know, was around. He was also working as a programmer and did all that, but he was at home as well. And he found ways to make it work, even if it had meant sacrificing his career to some extent. He was working from home when I was a kid in the 80s. So, he had a giant IBM 880, or whatever computer, a little tiny green screen, a 300-bot modem, you know, to connect and send his work up. So, that’s how I grew up. Turned out to benefit me a lot, uh, when it came to learning computers, but, um, you know, he would convince him to do that cause he was good at his job, and he’s like, I have to be there for my kids. And he made it work, you know? I think we all find those times where we need to lean into family or lean into work in different proportions, you know?

Kovid Batra: Hmm. Great. I think amazing job there honestly, Jacob All right, that was great knowing you and thanks for that quick intro. Moving on to the main section of our today’s podcast, enhancing the developer experience. So, that’s our topic for today. So let’s start very basic, very simple. What is developer experience according to you?

Jacob Singh: What is developer experience? It’s an interesting term. I guess it’s, you know, the day-to-day of how a programmer gets their job done. I guess the term would be everything encapsulated from, how their boss talks to them, how they work with their teammates, the kind of tools they use for project management down to the quality of documentation, APIs, the kind of tools they use on their computer, the tools they use in the cloud that they work with, et cetera. And all of that encapsulated is how effective can they be at their job, you know, and the environment around them that allows them to be effective. I guess what I would define it as.

Kovid Batra: And why do you think it’s trending so much these days? I think what you mentioned and what I have also read everywhere about developer experience is the same fundamental that has been existing all the years, right? But why is it trending these days? Why do you think this is something up in the market?

Jacob Singh: Good question. I guess, I mean, I’ve been around for a while, so I think in the earlier days of the industry, when I first started engineers were a little expensive, but they were also looked at as like a commodity that you could just use. Like, you put them on a spreadsheet, you pay the engineers, you get the work done. They weren’t considered really central. They were considered sort of like factory workers in an expensive factory, to some extent. I think it was more so in the 80s and 90s, right? But like, it’s still trending more and more in the direction of engineers kind of being very expensive and being decision-makers, moving into C-level positions, having more authority, seeing that, like, if you just look at, you know, the S&P 500, you look at the, you look at the stock market and you see that the top companies are all tech companies and they command most of the market cap. I think those days are over. So now, it’s very much that if you’re able to execute with your engineering roadmap, you’re able to win the market. It’s considered the basis of a lot of companies, sort of strategies, whether they’re a tech company or not, and therefore the effectiveness of the developers and the team plays into which developers will join you. And when they join you, how likely are they to be engaged and to be retained? And then, how effective, you know, is each developer because they’re a rare commodity because it’s hard to find good developers. There’s so much demand, et cetera, even in recessionary times, most of the layoffs are not engineering teams. And so, the effectiveness of each engineer and their ability to motivate and retain them becomes paramount to a company strategy.

Kovid Batra: Right. Makes sense. So, according to you, I’m sure you have had the experience of seeing this shift in the West as well as in companies in India, right? When you see the culture, particularly talking about the tech culture in a company, like maybe, for example, you work with a company like Blinkit, which is huge today in India and you must have worked with other companies in the West. How would you compare, like, how are teams being led in these two different cultures?

Jacob Singh: Well, I would say those kind of, you know, anything I say is going to be a gross generalization, and it’s going to be incorrect more often than it’s correct. I think there’s more difference between two Indian companies than there is between any given American or any Indian company, you know. There’s a lot of variation. But if I’m being put on the spot to make such generalizations, I would say that one big difference is the age and maturity of engineers. So, like, when I was 29, I got hired as an IC, a Principal Engineer at this company called Acquia. They kind of acquired my startup and I joined there, and, you know, we had PhDs on the team who were ICs, right? Our VP Engineering, you know, had 25 years of experience in the field and was, you know, sort of. You know, one of my colleagues was like heading R&D for the RFID team at Sun. You know, like the very senior guys were still writing code.

Kovid Batra: Yeah.

Jacob Singh: It’s like, very much just like in the weeds writing code. They’re not trying to be managers and an architect. They’re just like a programmer, right? I got my first team, like to manage, like I got a small team like at 25–26, but really I got my first team of like really qualified, expensive engineers when I was like 32. Whereas here, I’m a VP Engineering at Grofers at like 29. It’s like managing a 100 people. It’s very common to be much early in your career. Engineers with 3–4 years of experience are sort of talking about, “I should be an SDE-IV”. So, the whole like, that scale is different. You have a much younger audience. In the States, at least when I was coming up, there’s a lot more earning your stripes over a long time before you go into management. Whereas here, we have a lot more very junior managers. I think that’s a big difference.

Kovid Batra: Okay. And that’s interesting, actually.

Jacob Singh: That creates a lot of other dynamics, right? I mean, you just have like, generally you know, you have more, I would, and I hate to say this, probably going to take shit for this, but having been an engineering leader in both places, I feel like you have more like discipline and like professionalism issues here, generally, which is not to do with Indians. It’s just to do with the age of people. Like, they’re 24 years old, they’re not gonna be very professional, right? Like a lot of your team.

Kovid Batra: No, totally. I think, we are not generalizing this, but as you said, it’s probably about the age. In one of my podcasts, I was just talking to this fellow from Spain. He’s leading a team of almost 30 folks now.

Jacob Singh: Yeah.

Kovid Batra: And 50% of them were early hires, like early 20 hires, right?

Jacob Singh: Yeah.

Kovid Batra: And he’s that guy. And then I was talking to somebody in India who was leading a 50-member team there. Again, 50% of the folks were like junior engineers in their 25–26. And both of them had the same issue of handling Gen Zs. So, I think from where you are coming, it’s totally relatable and I think we touched on a very good topic here. How to create a good developer experience for these early-age, 25–26-year-olds in the system? Because they’re not stable, they are not, So again, I am also not generalizing. A lot of good folks are there, but they’re not like in the right mindset of sticking to a place, learning gradually and then making that impact. They just like really want to hop on fast on everything.

Jacob Singh: Yeah.

Kovid Batra: So, how do you handle that? Because that definitely is a pain for a lot of us, not just in India, but across the globe.

Jacob Singh: No, no, I’ve heard this a lot, you know, and I’m not really sure. I mean, I’m far from Gen Z. I was actually having this exact same conversation with the CTO of an Indian unicorn, a pretty large one, who was talking about the same thing. He’s like, “How do I motivate these?” This seems like the younger guys, they don’t really want to work and they’re constantly, you know, making noise and they think it’s their right to work from home. They think it’s their right to work 20–30 hours a week. They don’t want, they don’t want to advance and follow all this sort of stuff. I guess my advice to him was maybe a bit generic and maybe incorrect. You know, I think there are differences in generations, but I think some truths are fairly universal and I’ve uncovered a couple of things which have worked for me. And every manager has their own style and because of that, and every company has its own culture and its own goals. And so, there’s a thing that’s ‘culture-market fit’. So, certain leaders will do well in certain kinds of companies, right, who have certain kinds of cultures made for the market they’re in. This is not generic advice for everybody. But for me, I like to work in startups and I like to work in you know, startups, which are working on, I would say, kind of top-line problems which means not efficiency-related problems so much as innovation-related problems. How do we discover the next big thing? What feature is going to work with customers? Et cetera. And in such places, you need people who are motivated by intrinsic, they need intrinsic creative motivation. Carrot and Stick stuff doesn’t work. Carrot and Stick will work for a customer service team, for a sales team, it’ll work for an IT team at a Fortune 500 who’s shipping the same things over and over again, but for creative teams, they really need to care about it intrinsically. They need to be interested in the puzzle. They want to solve the puzzle. You can’t sort of motivate them in other ways. And I think this applies to the younger generation as much as the older ones. You know, the best thing to do is to, basically, it’s a very simple formula, it sounds cliché but figure out where the hell you’re going, why you should go there and everyone in the team should know where you’re going and they should know why they’re important to that strategy, what they’re doing that’s important, you know, and they should believe it themselves that it can work. And then, they should believe that if it works, you’re gonna take care of them. And if you solve those things, they will work hard and they will try to solve problems. A lot of companies think they can shortchange that by having a crappy strategy, by having, you know, a lot of program management, which removes people from the real problem they’re solving by treating people as numbers on a spreadsheet, naturally, you’re going to get, you know, poor results when you do that.

Kovid Batra: Totally. I think very well answered, Jacob. I think finding that culture-market fit and finding the place where you will also fit in naturally, you would be easily able to align with the folks who are working there and maybe lead them better. I think that that analogy is really, really good here.

Apart from that, do you think like not everyone gets that opportunity to find the right place for themselves, right, when there is a dearth of opportunities in the market? What would be the advice for the leaders that they should apply to them when they are not in the culture-market fit scenario?

Jacob Singh: Leaders? You mean, if a leader is in an organization where they don’t feel like the values of the tech team aligned to their value, whether it be engineer or CTO or something?

Kovid Batra: Correct, yes.

Jacob Singh: Good question. The best thing to do is probably to quit. But if you can’t afford, I mean, I say that a bit flippantly. I’m not saying “quit early”. I’m not saying “don’t try”. I mean, if you really have a true values alignment problem you know, then that’s hard to get over. If it’s tactical, if it’s relationship-based, you can work on those things, right? If you feel like you have to be someone you don’t like to fit in an organization, then that’s unlikely to change if it comes from the top, right? There’s a very cliché saying, but you know, “Be careful who you work with. You’re more likely to become them than they are to become you.” And so, I would say that. But to get more practical, let’s say if you can’t, or you’re feeling challenged, et cetera. Your question was basically, okay, so let’s say you’re a VP Engineering or Director of Engineering and you’re unhappy with the leadership in some way, right?

Kovid Batra: Yeah. So, no, I think it makes sense. The advice is generic, but it definitely gives you the direction of where you should be thinking when you are stuck in such a situation. You can’t really fight against it.

Jacob Singh: Yeah. I will say a couple of things. This is also the same conversation I had mentioned earlier. This also came up with the typical thing of leadership not trusting tech. You know, they don’t think we’re doing anything. They think we’re moving too slow. They think we’re, you know, sandbagging everything, etc. And to solve that, I think, which is not a values problem. That’s the case in almost every organization. I mean, there’s never been a CEO who said, “Oh, man! The tech team is so fast. They just keep.. I can’t come up with dumb ideas fast enough. They keep implementing everything.” So, you know, it’s never happened in the history of companies. So, there’s always that conflict which is natural and healthy. But I think to get over that, that’s basically a transparency problem, usually. It’s like, are you clear on your sprint reviews? Do you do them in public? Do you share a lot of information around the progress made? Do you share it in a way that gets consumed or not? Are you A/B testing stuff? Are you able to look at numbers? Able to talk numbers with your business teams? Do you know the impact of features you’re releasing? Can you measure it? Right? If you can measure it, release that information. If you can give timely updates in a way which is entertaining and appropriate for the audience that they actually listen those problems tend to go away. Then it’s just, the main problem there is not that people don’t trust you. It’s just that you’re a black box to them. They don’t understand your language. And so, you have to find, you know, techniques to go over that. Yeah.

Kovid Batra: Yeah. Makes sense. Great, great.

All right, coming back to enhancing the developer experience there. So, there are multiple areas where you can see developer experience taking a hit or working well, right? So, which are those areas which you feel are getting impacted with this enhancement of developer experience and how you have worked upon those in any one of your experiences in the past with any of the companies?

Jacob Singh: You said “enhancement of developer experience”. What do you mean by that?

Kovid Batra: So, yeah. I’ll repeat my question. Maybe I confused you with too many words there. So, in your previous experiences, you must have worked with many teams and there would have been various areas that could have impacted the developer experience. So, just to give you a very simple example, as you talked about the tooling, the people whom they’re working with. So, there could be multiple issues that impact the developer experience, right? So, in your previous experiences where you found out a specific developer experience related problem and how you solved it, how it was impacting the overall delivery of the development team. Just want to like deep dive into that experience of yours.

Jacob Singh: Yeah. So I think a big one was I can talk about Grofers. So, one of the things we had when I first came to Grofers, we had about 50–60 people in tech, product engineering, data, design, etc. We had them into different pods. That was good. Someone had created like different teams for different parts of the application. So, it wasn’t just a free-flowing pool of labor. There was the, you know, the shopping cart team and the browsing team and the supply chain, like the warehouse management team, the last mile team, it was like, you know, four or five teams. But there was a shared mobile team. So at the front end, there was, there was one Android team, there was one iOS team, there was one web team, which again, is very common, not necessarily a bad idea. But what ended up happening was that the business teams would, they wouldn’t trust the tech deadlines because a lot of times what happened is there’d be a bunch of backend engineers in the shopping cart team, they’d finish something, and then they’d be stuck on the front end team because the front end team was working on something for the, or the Android team was working on something for the browsing team, right? The iOS team was free, so they would build that shopping cart feature. But they couldn’t really release it yet because the releases had to go out together with Android and iOS, because, you know, the backend release had to go with that. So, we’re waiting on this one. Then we’re waiting on the web one. There’s this cascading waiting that’s happening. And now, the shopping cart team is like, “We’re done with our part. We’re waiting on Android. So we’re going to start a new feature.” They start a new feature. And then again, the problem starts again where that feature is then waiting on somebody else, waiting on the QA team or waiting on somebody else.

So, all of these waiting aspects that happen ruin the developer experience because the developer can’t finish something. They get something half done, but it’s not out in production, so they can’t forget about it. Production is a moving target. The more teams you have, the more frequently it’s changing. So, you have to go back and revisit that code. It’s stale now. You’ve forgotten it, right? And you haven’t actually released anything to customers. So, the business teams are like, “What the hell? You said you’re done. You said you’d be done two weeks ago.” And you’re like, “Oh, I’m waiting for this team.” “Stop giving me excuses.” Right?

Kovid Batra: Right.

Jacob Singh: That team’s waiting on the other team. So, I think one of the big things we did was we said, we took a hard call and said, at the time, Grofers was not quick commerce. At that time, Grofers was like DMart online, cheap discounting, 2–3 day delivery, and we scaled up massively on that proposition. And, uh, we said, hey, people who care about the price of bread being 5% less or more, do they own iPhones? No, they do not own iPhones. That’s like 5% of our population. So we just ditched the iPhone team, cross-trained people on Android. We took all the Android engineers and we put them into the individual teams. We also took QA, automated most of our tests, and put QA resources into each of the teams, SDATs, and kind of removed those horizontal shared services teams and put them in fully cross-functional teams. And that improved developer experience a lot.

And it’s kind of obvious, like people talk about cross-functional teams and being able to get everything done within a team, being more efficient, less waiting for the teams, but it has another huge benefit. And the other huge benefit is motivation-wise. You cannot expect, like I said earlier, you want your engineers to care about the business outcomes. You want them to understand the strategy. They don’t understand why they’re building it. But if an engineer has to build something, send it to another team, get that team to send it to some other team, get that team to send it to some other team, to a release team to get released eventually, right? And then, the results come back three months later. You can’t expect that engineer to be excited about their metrics, their business metrics and the outcomes.

Kovid Batra: Right.

Jacob Singh: If you put everyone in one team, they operate like a small startup and they just continually crank that wheel and put out new things, continually get feedback and learn, and they improve their part of the business and it’s much more motivating and they’re much more creative as a result. And I think that changes the whole experience for a developer. Just reduces those loops, those learning loops. You get a sense of progress and a sense of productivity. And that’s really the most motivating thing.

Kovid Batra: Totally makes sense. And it’s a very good example. I think this is how you should reshape teams from time to time based on the business requirements and the business scale is what’s going to impact the developer experience here.

But what I’m thinking here is that this would have become a very evident problem while executing, right? Your project is not getting shipped and the business teams are probably out there standing, waiting for the release to happen. And you started feeling that pain and why it is happening and you went on solving it. But there could be multiple other issues when you scale up and 50–60 is a very good number actually. But when you go beyond that, there are small teams releasing something or the other on an everyday basis. How exactly would you go about measuring the developer experience on different areas? So, of course, this was one. Like, your sprints were delayed or your deliverables were delayed. This was evident. But how do you go about finding, in general, what’s going on and how developers are feeling?

Jacob Singh: Well, we hit those scaling things and like you said, yes, people are delayed. It sounds obvious, but it’s mostly not. Most leaders actually take exactly the opposite approach. They say, “Okay. No more excuses. We’re going to plan everything out at the beginning of the quarter. We’re going to.. You plan your project. We’ll do all the downstream mapping with every other Android, iOS, QA team required. We’ll allocate all their bandwidth ahead of time. So, we’ll never have this problem again. And we’ll put program managers in place to make sure the whole thing happens.” They go the opposite direction, which I think is kind of, well, it never works, to be honest.

Kovid Batra: Yeah, of course.

Jacob Singh: In terms of measuring developer experience as you scale. So, we got up to like 220 people in tech I think at some point in Grofers and we scaled up very quickly. That was within a year and a half or something, that happened. And, you know, that became much more challenging. I honestly don’t love the word ‘developer experience’ cause it doesn’t mean anything specifically cause there’s sort of your experience as an employee, right, HR kind of related stuff, your manager or whatever, there’s your experience, you know, as an engineer, like the tools you’re using and stuff like that, right? And then your experience, like, as a team member, like your colleagues, your manager, your kind of stuff like that, right? So it’s slightly different from an employee in terms of, it’s not about company confidence and stuff or strategy, but more about your relationships. So, there’s different areas of it. For measuring, like, general satisfaction, we use things like Officevibe, we use things like continuous performance improvement tools, like 15Five. we brought in OKRs, a lot of things which kind of are there to connect people to strategy and regularly check in and make sure that we’re not missing things.

All of those were effective in pockets, depending on usage. But by far the most effective thing, and I know this might not be the popular answer when it comes to what type of sells, although I do like the product a lot, which is why I’m doing this. I think it’s a cool product. A lot of it is really just like 1-on-1s, just making sure that every manager does a 1-on-1 every two weeks. And making it like, put it in some kind of spreadsheet, some kind of lightweight thing, but making sure that new managers learn they have to do it, how to do them well, how to, you know, connect with individuals, understand their motivations and like follow through on stuff and make small improvements in their lives. Like, that’s the cheat code. It’s just doing the hard work of being a manager, following through with people, listening to them.

That being said, data helps. So, like, what you guys have what you guys built, I’ve built small versions of that. I wrote a script which would look at all the repositories, see how long things are sitting in PR, look at Jira, see how long things are sitting in wait. You know, build continuous flow sort of diagrams, you know, sort of just showing people where your value, team is getting stuck. I’ve, like hand-coded some of that stuff and it’s been helpful to start conversations. It’s been helpful to convince people they need to change their ideas about what’s happening. I think those are some of the ideas.

Kovid Batra: Thanks for promoting Typo there. But yeah, I think that also makes sense. It’s not necessary that you have to have a tooling in place, but in general, keeping a tab on these metrics or the understanding of how things are flowing in the team is critical and probably that’s from where you understand where the developer experience and the experience of the team members would be impacted.

One thing you mentioned was that you scaled very rapidly at Grofers and it was from 50 to 250, right? One interesting piece, I think we were having this discussion at the time of SaaSBoomi also the code review experience, right? Because at that scale, it becomes really difficult to, like even for a Director of Engineering to go into the code and see how it is flowing, where things are getting stuck. So, this code review experience in itself, I’m sure this impacts a lot of the developer experience piece, so to say. So, how did you manage that and how it flowed there for you?

Jacob Singh: Well, one is I didn’t manage it directly. So, like Grofers is big enough that I had a Director of Engineering sort of, or VP Engineering for different-different divisions. And that level of being hands-on in terms of code reviews, I wouldn’t really participate in other than like, you know, sometimes as an observer, sometimes to show proof, if we’re doing something new, like we’re doing automation, I might whip up some sample code, show people, do a review here and there for a specific purpose about something, but never like generally manage those, like, look at that. Grofers was really good this way. I think we had a really good academic culture where people did like public code reviews. There wasn’t this like protection shame kind of thing. It was very open. We had a big open-source culture. We used to host lots of open-source meetups. There was a lot of positive sort of view of inquiry and learning. It wasn’t looked at as a threatening thing, which in a lot of organizations is looked at as a threatening kind of thing. And the gatekeeping thing, which I think we try to discourage. I think we had a lot of really positive aspects of that.

Vedic Kapoor was heading DevOps and Security infrastructure stuff that I work with a lot. He’s consulting now, doing this kind of work. He did a lot of great, sort of workshops and a lot of like a continuous improvement program with his teams around this kind of stuff where they do public reviews every so often every week or whatever. The DevOps teams made a big point of being that service team for the engineer so they would kind of build features for engineers. So, we had a developer experience team, essentially, because we were that size.

Well, the review process, generally, I mean, I gave this rant at SaaSBoomi, and I think I’ve given it often. I think PRs are one of the worst things that’s happened to software engineering, in the last 20 years.

Kovid Batra: Yeah, you mentioned that.

Jacob Singh: Yeah, and I think it’s a real problem. And it’s this funny thing where everyone assumes that progress moves forward and it never goes backwards. And then they, the younger generation doesn’t necessarily believe that it could have been better before. But I’ll tell you the reason why I say that is that, you know, Git was created by Linus, by the creator of Linux because they needed, well, they needed something immediately, but also they needed something which would allow thousands and thousands of people working at different companies with different motivations to all collaborate on the same project. And so, it’s the branching and the sub branching and the sub-sub branching which Git allowed people to simultaneously work on many different branches and then sort of merge them late and review them in any order they wanted to and discuss them at length to get them in and had to be very secure and very stable at the end of the day. And that made a lot of sense, right? It’s very asynchronous and things take a very long time to finish. That’s not how your software team works. You guys are all sitting on the same table. What are you doing? Like, you don’t need to do that. You can just be like, “Hey, look at this, right? There’s a different way to do it.” Even if you’re on a remote team, you can be like, “Let’s do a screen share.” Or, “Can I meet you tomorrow at two or whatever, and we’ll go through this.” Or like, “I had some ideas, paste it in Slack, get back to me when you can.” You know, “Here’s my patch.” Whatever. And I think what ends up happening is that this whole, the GitHub, and for open-source projects, it’s huge. Git is amazing. Pull requests are amazing. They’ve enabled a lot. But if you are a team where you all kind of work on the same codebase, you all kind of work closely together, there’s no reason to send up this long asynchronous process where it can take anywhere between a couple of hours to, I’ve seen a couple weeks to get a review done. And it creates a log jam and that slows down teams and that reduces again, that loop. I’m big on loops. Like, I think you should be able to run your code in less than a second. You should be able to compile as quickly as possible. You should be able to test things as quickly as possible that you should be able to get things to the market and review them as quickly as possible. You should get feedback from your colleague as soon as possible. And like, I think a lot of that has gotten worse. So, engineers like learn slower and they’re waiting more, they’re waiting for PRs to get reviewed, there’s politics around it. And so, I think that that process, probably should change. More frequent reviews, pairing you know, sort of less formal reviews, et cetera. Yeah, and TDD if you can do it. It’s kind of the way to get much faster loops, productivity loops going, get things out sooner.

Sorry, a bit of a long rant, but yeah, PRs suck.

Kovid Batra: No, I think this is really interesting, how we moved from enhancing developer experience and how code review should be done better because that ultimately impacts the overall experience and that’s what most of the developers are doing most of the time. So, I think that makes sense. And it was.. Yeah?

Jacob Singh: I just want to caveat that before you misquote me. I’m not saying formal reviews are bad. You should also have a formal review, but it should be like, it should be a formality. Like, you should have already done so many reviews informally along the way that anyone is reviewing it already kind of knows it’s there and then the formal review happens. And it’s like in the books and we’ve looked at it and we put the comments. It shouldn’t just be like, “Here’s a 20K patch.”, a day before the deadline. You know what I mean? That shouldn’t happen anymore, I think that’s what I’m trying to say.

Kovid Batra: Yeah. No, no, totally makes sense. I think this last piece was very interesting. And, we can have a complete discussion, a podcast totally on this piece itself. So, I’ll stop here. And thank you so much for your time today, for discussing all these aspects of developer experience and how code reviews should be done better.

Any parting advice, Jacob, for the dev teams of the modern age?

Jacob Singh: The dev teams or the other managers? I guess the managers are probably watching this more than developers.

Kovid Batra: Whichever you like.

Jacob Singh: A parting advice. I would say that we’re at the most exciting time to be an engineer since I mean, maybe I’m biased, but since I started coding. When I started coding, it was like, just as the web was taking off. You know, like, I remember when, like, CSS was released, you know, that’s old. So I was like, “Oh, shit, this is great. This is so much fun!” You know, like, when it started getting adopted, right? So I think, like the sort of dynamic programmable web was nice when I started, right? Now, we’re at the second most exciting one, in my opinion, as an engineer. And I think it’s surprising to me. I work with a lot of portfolio companies at Alpha Wave. I talk to new companies that I’m looking at investing in. It’s really surprising to me how few of them use Copilot or Cursor or these various sorts of AI tools to assist in development or like everyone uses them a little bit, but not programmatically. They don’t really look into it too much. And I think that’s a missed opportunity. I still code. When I code, I use them extensively. Like, extensively. I’m on ChatGPT. I’m on Copilot. I pay for all these subscriptions. You know, I use ShellGPT. I don’t remember shell commands anymore. ShellGPT, by the way, is great to plug. Write what you want to do, hit ctrl+L, and it’ll like generate the shell command for you. Even stuff I know how to do, it’s faster.

But the main thing is, like, the yak shaving goes away. So, I don’t know if you guys know yak shaving, but yak shaving is this idea of having to do all this configuration, all this setup, all this screw around to get the thing actually working before you can start coding. Like, learning some new framework or dependency management, bullshit like that. That stuff is so much better now. You take your errors. You paste them into ChatGPT. It explains it. It’s right most of the time. You can ask it to build a config script. So, I think if you know how to use the tool, you can just be a million times more productive. So, I would say lean into it. Don’t be intimidated by it. Definitely don’t shortchange it. Dedicate some research effort. Trust your engineers. Buy those subscriptions, It’s 20 bucks a month. Don’t be so cheap, please. Indian engineering managers are really cheap with tooling, I think a lot of time. Just spend it. It’s fine. It’s going to be worth it. I think that would be my big thing right now.

Kovid Batra: Great, Jacob. Thank you. Thank you so much. Thank you so much for this. We’d love to have another discussion with you on any of the topics you love in the coming shows. And for today, I think, thanks a lot once again.

Jacob Singh: My pleasure. Same here. Good talking to you, Kovid. All right. See you.

Kovid Batra: Thank you. All right, take care. Bye-bye.

Jacob Singh: Happy hacking!