#243 Nikhil Nandagopal cares deeply about the problems we solve

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Nikhil Nandagopal 0:00
One of the main things I tell Junior folks is you have to fall in love with the codebase. And the only way to do that is to actually try to debug every single method, debug every single kind of path flow, put breakpoints, put logs, and actually go go through it step by step, try to make a couple of changes, see how it gets impacted. And, and we try to give people enough time and space to actually play around and get comfortable with the environment. Because only once you're extremely comfortable in the environment that you've been given, that's when you're able to really uncover the problems, you're able to really feel like you can make a change, you know, without having to worry that hate won't pass the test cases are just not going to pass the code review.

Tim Bourguignon 0:39
Hello, and welcome to developer's journey, the podcast, bringing you the making of stories of successful software developers, to help you on your upcoming journey. I'm your host Tim Bourguignon. On this episode 243. I receive Nikhil Nandagopal. Nikhil can speak to both sides of the internal development tools conversation, from building out logistics operations for India's largest e commerce company, to helping a travel company grow to 5 million users, or scaling a food service from 50 to 50,000 daily deliveries. Nikhil is a co founder of AppSmith and open source project that helps developers build and maintain internal business and operation tools quickly. You might remember my conversation with AppSmith other co founder Arpit Mohan, it was showing number 208. Nikhil, welcome to DevJourney.

Nikhil Nandagopal 1:30
Thank you so much, Timothy, it's really kind of great to be here and just talk to you about AppSmith and my entire journey. Through looking forward to this conversation.

Tim Bourguignon 1:37
I am as well, and I'm thrilled to have you on. But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the DevJourney lights up. If you would like to join this fine crew, and help me spend more time on finding phenomenal guests then editing audio tracks, please go to our website, DevJourney.info and click on the "Support Me on Patreon" button. Even the smallest contributions are giant steps toward a sustainable dev journey... journey! Thank you. And now back to today's guest. So Nikhil, as you know, the show exists to help listeners understand what your story looked like and imagine how to shape their own future. So as usual on the show, let's go back to your beginnings. Where would you place to start off your dev journey?

Nikhil Nandagopal 2:33
Um, well, I think, you know, funnily enough, I think my dev journey started probably in high school. I was always, you know, in love with computer games, you know, played computer games as early as you know, Doom or Dave. And, you know, even something as simple as Minesweeper, you know, on Windows would just get me excited. And funnily enough, I was actually pretty terrible with programming when it was first introduced, I just couldn't, I just struggled a lot with the core concepts, you know, like for loops, if statements, and I had missed a couple of classes, and I just wasn't able to pick up. But I really attribute a lot of where I am today to this one teacher, who, you know, just never gave up on me. And, you know, truly went above and beyond to introduce these concepts to me, and, you know, make me fall in love with programming. And I remember, one of the first defining moments that I knew that I really loved programming was, when we actually ended up building a simple version of Minesweeper on Java. It was just a small applet program. And, you know, my my love for video games, I was able to kind of combine that with programming. And I think it was the first time I saw a real world application of what could be possible with all these statements and for loops. And that got me really excited. You know, that's when I knew that, hey, this is this is what I would really want to do, you know, for the rest of my life, because I could just see the impact I could have on the world and on myself. And, you know, that just got me excited. And I think the excitement never died since then.

Tim Bourguignon 4:05
Those are awesome to hear. I love how we all kind of need an application, need to see how this projects on the world and then think holy moly, I can do that? And then it starts and blossoms.

Nikhil Nandagopal 4:23
Yeah, absolutely. You know, in fact, funnily enough, during COVID office was stuck at home and I actually built a couple of personal apps just like helped me, you know, order food from like a local grocery store or just have like a small reminder checklists at home and everyone was just so delighted by the fact that I could have these nifty applications ready quickly, you know, for for us to use and I think like, you know, applications really make the world go round today.

Tim Bourguignon 4:50
Yes they do, yes they do. But coming back to this teacher, do you know what he saw in you? If you were not one of the top students at that time and still he saw something didn't he?

Nikhil Nandagopal 5:03
Yeah, um, I'm not, I'm not sure. You know, what you saw on me, I think, I think that she, she sought in programming to be honest, she herself really loved the subject that she was teaching. And she really wanted to get that across to everyone out there that how impactful and how powerful it could be. So she could see that I was struggling with it, because I probably had missed out on a couple of core concepts somewhere along the way, and I wasn't able to connect those dots. But, you know, she was, she was just so passionate about getting the point across that, hey, this is something amazing, something that, you know, you can really use, you know, to your advantage in the future. And that kind of passion is just infectious. You know, and, and once once those dots clicked, I think that that passion kind of just got transferred to me as well.

Tim Bourguignon 5:51
So that is really cool. That is really cool. That that is teaching at its best, really living for the passion and wanting every pupil to just get it.

Nikhil Nandagopal 6:00
Yeah, absolutely.

Tim Bourguignon 6:03
Awesome. So at that point, you decided, yeah, this is going to be something for me for the rest of my life. I don't remember how you pronounce it. But but that was kind of kind of what you say. So how did you decide where to go from there? Was it? Was there a path that you had to follow? Were there many paths? How did you choose?

Nikhil Nandagopal 6:23
Yeah, I think there were a couple of different parts, you know. And I think, for me, fundamentally, I just realized that I had to understand programming a lot better. I was confused between, you know, should I become like a game developer? Should I, you know, get into like core computer science. And I think, eventually, I kind of realized that game development didn't, hadn't advanced enough, and didn't have some of the core capabilities and technologies that point in time, that would be needed. And that would probably make it like a viable career option. But eventually, I kind of figured that I want to study computer science at a very fundamental level, and just understand how the programs run, you know, what made them tick? What can I actually do with them? The future? I mean, I probably just scratched the surface level, I weren't know, what else could actually happen. So I kind of figured that, you know, I kind of did the probably the most Indian thing, which is when I went to like an engineering college. And, yeah, I think I learned a lot more about a subject there. But I think the, what really changed me is that was the people around me, like one of my close friends ruin, he really shaped my understanding of development and what's possible, because he was honestly much further along in his development journey at that point in time, and I was lucky enough to have interacted with him. And he showed me how it is possible to build websites on Drupal. And, you know, even I remember the collaborated and we built this really fun computer vision project together, where, you know, you could play Pong, by the computer camera, detecting any object in front of it, as you know, as a Pong piece, and it would convert like a window into the pong ball, and you could play Pong with your friends or using the Windows on your system. And it kind of opened my eyes up to all the different types of possibilities that are actually unexplored out there. You know, and, and soon enough, even mobile developments are becoming popular, you know, towards my fourth year of college, that's when, you know, slowly Android and, you know, iPhones began to get introduced, you know, and become sort of mainstream in India. And, you know, there was suddenly a surge of need for Android developers at a point in time. And I think, the honest, it, what it really gave me was the exposure, you know, I'd say that, that's, that's really the fundamental thing that changed. I went from being somebody who understood how to use if statements and for all looks to bring simple textual applications to someone who could now apply all of that to something real world. You know, I think one of the first actual real world apps we built was the small ecommerce application on on the Android smartphone, that we actually submitted to like the Mobile World Congress, and we got selected for that. And, and that was like a really big deal for us, you know, because we were just a couple of kids from India, trying to work with the Android SDK trying to figure out you know, the nitty gritties of it. Almost no guidance, very few two tutorials back then. And, you know, that's what made it fun and exciting. We were we were like exploring the unknown. And, you know, and, and the returns are great from that, you know, like we just we just saw the impact we could have on people all across the world.

Tim Bourguignon 9:44
That is awesome. You mentioned two things. You mentioned the fact of having something real worldy so that you could use yourself so that's really has an application, but also the exploring the unknown, finding out something that most of others don't know. I'll use kind of your your your lighthouses in where you want to go and deciding on which subjects to pick?

Nikhil Nandagopal 10:11
Yeah, I think, you know, at that stage, it's really important to just discover the problems or the areas that you want to fall in love with. And, you know, if you don't have that extra, extra exposure at that point in time, you might, you might think that, hey, you know, this is something that I really love, right? And this, this particular area is really awesome. But you don't realize that there are so many other things out there, you know, there's a whole ocean of possibilities, because it was still such a, like, you know, develop software development itself was in still such a nascent stage. There weren't as many startups as there are today, there weren't as many widespread applications. And I think that's, that's like extremely important to be able to explore all these different areas before you really realize that, hey, this is this is an area that I really love. And I kind of want to commit to.

Tim Bourguignon 10:59
what is your strategy? You mentioned this, this ocean of possibilities? What are your strategy to explore, but not drown into this ocean? Because it's, it is wide? So how do you find out quickly, what you like or what you don't like? And skim a little bit? The branches of a tree?

Nikhil Nandagopal 11:17
Yeah, I think that's a really great question. I have been guilty of falling too deep into some of these areas every now and then. But I think, especially, you know, when you're young, right, I mean, what's the harm and falling too deep sometimes, you know, it's, it's kind of okay to, you know, really swim to the depths and figure out that, hey, okay, maybe I'm kind of bored of this. And I eventually do want to move on. And I don't think I've placed to me restrictions on myself at that point in time, whether it was like trying to delve into computer vision, or trying to, you know, build websites or trying to learn about, you know, Android development or trying to build my own games, I did all of these different different types of things. But I think maybe if there was one limiting factor that I had to really impose on myself was that I knew that if I wanted to do this, in the long run, I had to be able to build a sustainable career out of it. So if there were options that I didn't see, as long term viable career solutions, that would probably be one limiting factor I put on myself and said, Hey, okay, you know, maybe game development, I don't see that, that's going to be a great path. As much as I love games, I don't think that I will be able to build a sustainable career out of this. So I probably can't take that path, even though I have dabbled a little bit here and there. But I don't think I can go up completely into it right now.

Tim Bourguignon 12:35
Do you regret some of those decisions, realizing after the fact that it might have been a viable career? We just didn't realize it at that point?

Nikhil Nandagopal 12:47
Not really, I think, you know, I think I constantly discover new things. And you can sometimes feel like, oh, there is a path that you know, was not taken. But I think I'm really happy with where I am. And, you know, wherever you've gotten to, and, you know, the type of interests that I have today. And I couldn't have come this far and, you know, found these interests if I if I hadn't traveled this path. So it always seems like hey, the grass is greener on that side. And there's no harm in even sometimes walking over that site and checking it out. But you know, that I don't think it's a path of regret. I think there's still a lot of time to explore all these areas.

Tim Bourguignon 13:26
I see. I see. I was more hinting at maybe my experience, I have a list somewhere of the, of the the projects I envisioned, and which I said, Well, there's no business model here, and then left them out. And afterwards, they became startups that I'm using now. Shameless, say where I was, I was wrong. And that's fine. I mean, that's fine. I probably didn't have the bandwidth to do it back then. But I dismissed them. And maybe too quickly, so.

Nikhil Nandagopal 13:56
Oh, absolutely. I mean, to be honest, App Summit is probably one of those projects. To build it. At least twice. Back in the past. Not successfully. We just gave up somewhere in the middle. But yeah, here we are again.

Tim Bourguignon 14:10
But you did it. So so let's go slowly but surely there. So how did you enter the professional words with big air quotes? Because you are coding already? For real? During your studies, but how did you find your first job? And how did you progress? How did you explore the possibilities and slowly but surely build this sustainable career you were talking about?

Nikhil Nandagopal 14:36
Yeah. So I think this was one of the big choices. I think I had to make, you know, I mean, I just graduate. I mean, I was about to graduate college, and I think there were a couple of companies that had come to our college as part of our campus placement program. And I had to figure out, you know, which which company really made sense in which where I would be able to grow right And it really came down to two options. In the end, there was this, you know, there was a tried and tested, popular company that, you know, was well established was definitely not going anywhere. And, you know, I had a great offer from them. But I also had an offer from this really small startup, that would have actually required me to, you know, move downs and not not in move cities, like, I would have to actually go to a pretty remote location, and work out of there, where, you know, I actually didn't even know the language, they don't have the people, it would have been a whole new experience for me, right. And I didn't make these, you know, these choices. And eventually, I think I went with the startup, even though it put me, you know, fairly outside of my comfort zone. And looking back, I think, one of the things that I mean, that I told everyone at that point in time was like, Hey, why are you doing this crazy thing? Like, why are you going and working with this, you know, unknown company, in the middle of nowhere, was that I just really loved the passion of the people over there. And what they saw in me, they saw that, you know, they want to build a lot of things they want to, they want to kind of give me great opportunities to grow and to, you know, kind of contribute and make me feel like I'm part of that team. And, you know, I really wanted to optimize for that, at that point in time, because I knew that it didn't matter. You know, how well established the company was right now, it didn't matter where I was right now, what what mattered was where I was going to be, you know, five years, 10 years down the line. And I just knew fundamentally that I didn't have the skill sets at that point in time, to be where I wanted to be. So the only thing going through my head at that point in time was, hey, what, which opportunity is going to take me, you know, the skill sets and the opportunities to grow and learn in that particular direction. And that's actually how I started out, you know, making money, other software for a living. And it was just a simple service based company, out of the small town called carburetor. And that's where it really kind of kicked off. And I think that was probably my first, my first break.

Tim Bourguignon 17:14
That is awesome. I liked how you framed it saying "I optimized for," because I have the feeling way too often we don't frame the the employment opportunities or the opportunities that we have, in terms of, we have a choice, we have a choice in optimizing for this or optimizing for that, or, or choosing to go this way. Because and, and highlighting it this way really brings the what you want to learn and why are you making this decision? I really like how to present it this way.

Nikhil Nandagopal 17:46
Yeah, absolutely. I think there's always a choice. And if you try to optimize for both, you're just being sub optimal for both. If you really, if you really believe in one path or the other, you have to make a trade of

Tim Bourguignon 17:57
exactly exactly like like when you're developing for something first, you have to optimize in one direction. And then you realize maybe it has drawbacks on some other factor. And then you can start and optimize the next one and see how that turns out. But optimizing for everything at the same time just doesn't work. That is cool. So how long do you stay in this in the startup? And did you get what you were up to optimizing for?

Nikhil Nandagopal 18:21
Oh, yeah, absolutely. I stuck around for almost two years. And I think I definitely grew immensely as a developer. Over there, I got, I got to work on a wide array of things. In fact, I actually got to work on games, I got to work on Android applications. And it was my first true professional foray into mobile development. And it kind of set the tone for most of my career, because it was it was it helped me become sort of an expert in, you know, one technology that was so new, that there weren't many, you know, thought leaders at that point in time in that particular area. And it had helped me kind of push my career a little bit ahead. And it actually led to the next opportunity where I ended up working with this other company that was actually in the service space. And, you know, unfortunately, I don't know if it's right to say this, but service companies tend to sometimes embellish on the type of people who are kind of working with them. Like, for example, I was probably just, you know, two years of experience at that point of time, right. But, you know, I remember working on this really large project that was for this massive for this massive travel giant, and it was basically just me leading the entire team with with barely two years under, under my belt, and it was a pretty defining moment for me because it was sort of like a trial by fire. I had to figure out so many different things for which there really was no rule books, because especially Android was very, very new. With a paradigm like even things like virtualization, were hardly being discussed in the software community, and there weren't very good tutorials for it. And I had to figure all these things out on the fly. And it made me realize that, you know, software development is so much more than just trying to write code and trying to build applications, it's so much of it is just trying to understand the problem, and that you know, your users or your business is trying to face and trying to develop a good solution for those problems that actually fit the use cases. And it kind of opened up this whole new light bulb or thought process in my mind that, Hey, I can't just be someone who is writing code, and, you know, shipping features for the sake of it. You know, I, if I'm, if I have to be a leader, I need to be someone who's actually delivering value to the end users of the software. And, you know, I have to figure out the fastest way and the best way to do it, I don't want to be constantly changing requirements, or changing the software or not thinking it through and having to redo things, because that's the biggest urge we have as developers, right? Like you, you hate redoing things over and over again. And that was a lightbulb moment that when I had to kind of lead this team to build this huge mammoth of software that I'd never done. And there were tons of rewrites and tons of mistakes that I that I did make at that point in time. I just realized I had to get a lot better. And, you know, I think that that that was that was another kind of defining moment for me.

Tim Bourguignon 21:30
So does that mean, you stepped into the the product or the user experience or user research side of things? At that point?

Nikhil Nandagopal 21:41
A little bit, a little bit, I think I didn't fully step into the product side at that point. But I learned that as a software developer, I couldn't only distract myself from the actual requirements, I began to kind of become more engaged with the business unit users with the designers and understand their pain points, and, you know, actually suggest better solutions. You know, if they did come and say, hey, you know, let's, let's go ahead and build this, instead of building it and actually ask them, Hey, why are we building this? You know, what's it going to drop and trying to solve? What if we actually build this other thing? I can give it to you in like, 1/10 the time Wouldn't that be amazing, right? And every now and then I would see a light bulb go off their eyes, and wow, that would be amazing. You're telling me I can get this other thing that is, you know, like, maybe slightly worse, but it's going to come in 1/10 the time when I can figure out, you know, all this business value very, very quickly. You know, that's when they realize that, hey, it's not just about telling software engineers, the requirements, there is a better way to build software. And, you know, I think I think that's a super transformative part from a junior developer to like us to like a slightly mid level one where you realize that you now have to collaborate with a lot more people, and you have to figure out how to start delivering value. So I didn't I that was my start probably thinking about product, but I hadn't, I hadn't jumped in I think that game, still a couple of years down the line.

Tim Bourguignon 23:03
I see I see. This is very, very, very important, which is saying this, this pushing back on, okay, you want us to do this, but why? What what are you trying to reach whether you're trying to figure out where you're trying to do, and pushing back on those on those solutions that the users or the customers bring? And try to see what is the problem you're really trying to solve, and then co create and feel a feel allowed to co create the solution that is really needed. And that will bring the value and not just wait for the solution to be to be handed over? And then just code it to?

Nikhil Nandagopal 23:40
Yeah, absolutely.

Tim Bourguignon 23:42
That That is cool. And I'm sure that that had been influenced in you creating your own company afterwards and feeling like being the one to be able to, to define the product, and lead the people to to create it right.

Nikhil Nandagopal 23:56
Yeah, absolutely. I think that that that naturally kind of made, like showed people that, hey, I could be the right leader, because the way I was thinking about software was slightly different from the way that everybody else was thinking about software at that point in time. And, you know, more business owners wanted to just communicate with me and interact with me because I suddenly became the guy who would solve their problems rather than the guy who just pulled yourself. Hmm.

Tim Bourguignon 24:23
That's a nice way. So at what point did you decide okay, now I need to have my own history. I need to write not a project for or not lead a project for somebody else, but do my own thing.

Nikhil Nandagopal 24:41
I think that happened a little while later. So I eventually moved on to this e commerce giant in India. And there was a industrial startup at that point in time, and there was a very, very supportive culture for entrepreneurs just budding out of that entire company. And, you know, even the directors of engineering over there were very supportive of new ideas, new initiatives inside the company, or even outside the company for that matter. And I think, as I, as I got to learn about, you know, how to build high quality software, how to, you know, do slightly better user research, how to think about products, I began, you know, wondering, hey, you know, why don't I actually try to expand my skill set a little bit, and maybe start up on my own, let me try building something, you know, that I would, you know, probably want to use. And that's kind of when we came up with the idea for levels, which was sort of menu ordering solution for pubs and bars, across India, and it eventually didn't go so well. The, we ran for about a year and a half before shutting it down. And of course, it was quite a tumultuous journey. But I think it, it was just another path of discovery, I think, like we talked about before, where it wasn't, it was a fog of war area that I, I kind of wanted to explore and just see, you know, hey, is this something that I'm interested in? And I think it was, it was the first foray into entrepreneurship that lit this bulb in my head that I really, I really love building things that I'm excited about, that I'm really passionate about. And, you know, I think it helped develop certain additional skill sets, like thinking about not just the product, but also the business, you know, how does the product eventually generate revenue? You know, what's the kind of value chain to different customers, or different stakeholders that are actually there? And how does all that value kind of eventually translate back into profits? And, you know, and, and how does the software, you know, eventually, sort of enable all of that, right. And I think, that kind of thinking, got unlocked and helped me start, you know, improving myself or developing these new skill sets. And so I took, I took some time off again, after it didn't work out. And I, you know, went back to working on a health tech startup, which was into delivering healthy food. And I suddenly got to see that I was, again, slightly set apart from everybody else. Because I was not only a software developer, I was I was still, you know, a mobile developer, I still build their app, and all of those things, but my approach to things was just slightly different from most folks in the company, the type of rapport I had with, you know, all the business units, different engineering teams, different product teams, different sales teams, was just like slightly different than, once again, we could, I could kind of see that people just gravitated towards me and liked working a lot more, because I could see the big picture between all of these different teams. And that that just naturally kind of, you know, it just showed my value to like everybody else. And so that was my second big fork in the road where I remember I was having a conversation with the head of product at that time. And he was saying, you know, you have your foot in both boats, I think it's time you jumped over the product. And I was pretty torn at that point in time, I wasn't sure if I ever want to leave engineering, because, you know, I love writing code, you know, even today, I absolutely do write code. Because it's just such a fun, beautiful part of, of my every day. But I think I realized that I also just love solving problems. And that's, that's when the kind of epiphany came that, hey, you know, what I if I ever do product, it has to be a completely technical product. You know, it has to be a product that I really love. And that, you know, I kind of want to build, and has to have, like clear impact on in the engineering community at large. Because that's what that's what I really love doing. And that's, that's when I was brainstorming different ideas. And, you know, we actually came up with the app summit with my other co founder, Arpit, who I think you've spoken to before. We were having a chat about different engineering problems and stuff we've tried to solve in the past stuff, stuff we wish we could have shipped, but didn't. And, you know, that's what we thought like, hey, you know, wouldn't it be great if we didn't have to build all these internal tools out there that are just so dreadfully boring? And isn't there a better way to do it?

Tim Bourguignon 29:20
That is awesome. I've seen so many questions. I'm not sure which one? Well, I'll make a comment first. The what seems to be a factor and tell me if that's one or not. When you build this company levels, creating, I think was digital table ordering solutions or something like this. And it seems to me that you are not burning as you as you are when you're talking about AP Smith. It seems to be a nice idea. But another one that you would use on your own is this critical factor in in, in maybe You burning for right or not?

Nikhil Nandagopal 30:02
Absolutely. In fact, that was the actual defining moment. I think it was one of those things where I was exploring, because I wanted to explore and see what it would be like. But at the end of that journey, I realized that, hey, if I ever do this, again, it's got to be for something that I would use day in and day out got to be something that, you know, I would just be completely in love with. And oh, there was solving, I was solving a real problem, but I wasn't solving my own problem. I was solving someone else's problem. And I think that was a tipping point.

Tim Bourguignon 30:30
Okay. So how do you make sure that the problem you're solving with App Smith right now remains your problem? Or how do you prevent? No, that's not the right way to formulate it. Basically, you have the problem that you're passionate about, and you have the problem that AP Smith is solving, and this might divert, at some point, how would you go about it? If that were the case?

Nikhil Nandagopal 30:55
You know, I think it can kind of happen at some point in time. But I think that's not the case. You know, right now, because really, the solution might evolve. But I think our core values and the core why of what we're doing, that's that's just never changed. And I hope it never will as well. Because we really believe in falling in love with, you know, the problem space and not the solution space. And that's really why we started this. So if ever absolute changes to solving a slightly different problem, it will be because we suddenly fall in love with a new problem. It wouldn't be because, you know, our solution, found a new problem on its own accidentally, it will be because we suddenly realized, oh, wow, this is just so annoying. Like, you know, there's got to be a better way to do this as well. So okay, can we just use afternoon to like, make this better?

Tim Bourguignon 31:42
That sounds awesome. I think the way to frame it, and again, it comes back to to the point you you highlighted before saying, well, it might be time to to go more into the product side and more look at the problem and not the solution. It seems like you gravitated toward a place where where you can grow with the problem. And really, wherever the problem is going, you will be there and you will be having fun. And now again, as a founder of this company, really wherever the problem is going, you're there and you're having fun, and you're morphing with what is needed for the company to be successful and you to continue having fun at the same time. That's the best place to be, isn't it? Yeah, it

Nikhil Nandagopal 32:19
really is. Because you can tinker with so many different solutions. And there's something I tell like a lot of software engineers that, you know, don't if you're getting disheartened by, you know, your your feature requirements changing, or use cases changing or edge cases changing, your business needs changing, then you fall in love with your solution, you haven't actually fallen in love with your problem, you know, and that's where a lot of the heartburn comes from that, oh, like, why is this change? Why do you have to rewrite this piece of code, why we have to refactor this module, you know, it's because you're really married to the code you wrote, and you're really married to that UI that you shipped, you're not married to the fundamental reason as to why you're doing it, and why it's such a core part of your day in and day out. And if any of merit to that, if somebody tells you that, Hey, we should make this change. And you really understand why it's a better change. For that problem, you're going to throw out your code in a second, you know, you're just going to like, go to your git branch, forget, delete the last commit, and just start start writing on top of it. Because you know, you don't you don't care about the water code, you don't care about the solution. You're just so passionate about solving that one problem, and you're happy to change your software for it.

Tim Bourguignon 33:27
So how do you ensure that people in your organization around you remain married to the problem and not the solution?

Nikhil Nandagopal 33:37
That's, that's great. We do a couple of really fun, interesting things in F Smith. So I think the first one is, every single person on there day one has to build an application and, and share it with the entire organization with their feedback. So you know, you absolutely have to like build your application and just show everyone, you know, what you thought about platform. And we know we love critical feedback. And similarly, like, almost everything you do is you know, like, if you have like a performance review coming up, for example, right, and you need to collect feedback, you absolutely have to build like a simple feedback form when absolutely and collect that feedback. Because that's the only way you're going to understand the problems that, you know, other developers out there are facing day in and day out. So that that's like, we really enforce that, hey, app building is a core pillar of who we are. And we are app builders. So that I think that's one pillar. The second pillar is you know, when when it can't be first hand feedback, the best is direct feedback from users. And their, you know, every single engineer, designer, product manager, you know, every single person in the company participates in our Air Force. So first is like a support program that we have for the community, where, you know, for one week, you can enroll and you're just basically part of the community support team. And you're basically listening to users ask Russians struggle with building their apps. See us for feature requests, see where you know, they have the worst bugs, and you know, they're really cursing the platform, or where they're even saying that, hey, this is such an amazing platform, we absolutely love it. And that really brings them closer to the users pain, and enables them to just, you know, get get attached to that, rather than, you know, the outcome of everything else. And that's where some of the best ideas come from, where someone's like, hey, you know, this user has this pain, we have the solution, but it's not a good enough solution for their pain. What if we just did this one other thing, that would be so much better, you know, that that's, that's where we really see like some of our best ideas come from.

Tim Bourguignon 35:37
That is really cool. That is really cool. So forcing people to dog feed, right from the get go build on top of it, and encourage people to build on top of the product as much as they can, and face real user feedback as often as possible. And that really helps remain in the problem space and not be enamored with, er, the solution space. That is cool. Anyways. Awesome. Yeah. Do you have some most junior developers at your company?

Nikhil Nandagopal 36:09
We do have a few. I think I'd have some, at least we haven't actually gone, gone ahead and tried to, you know, nurture a lot of junior folks, because in the in the kind of base of building a software, this complicated software, and honestly, absolute is by far the most complicated thing I've ever worked on, hands down. In the interface of trenches trying to solve that I think we ourselves were struggling to figure out like, how do we do this? Like, you know, what, how do you actually get across some of these problems? So I think we haven't done it really early on. But now we're slowly beginning to actually nurture a lot more junior folks and bring them into the team.

Tim Bourguignon 36:48
Where it would be interested in in maybe first a comment about my own experience I've been very puzzled in working with with junior level developers nowadays, because they don't have the baggage of making air quotes bad companies I've seen they come right away into companies like yours, which are doing it right, focusing on the solution on the on the problem, I really listening to the users, etc, etc. And they're doing it right from the get go. And seeing how they evolve in the system is always interesting, not having seen the bad things of top down micromanagement of cascading requirements, and really having to do one cog and not seeing the full picture, etc. And don't do it right away. This really brings different flavor to how they approach the, the our industry. And I'm always looking for advice on how to even better help them at embracing our industry and becoming becoming the seniors of tomorrow. What is your approach to this with more juniors? Maybe not juniors? If you don't have them right away? But a bit more junior developers? How do you bring them to becoming seniors?

Nikhil Nandagopal 38:00
Yeah, I think that's a great question. And I think it's actually kind of relevant to asthma today, because one of the biggest challenges that junior folks have is that the codebase can be quite overwhelming. It's a huge product, you know, that's, you know, built over the last three years, and it's a single codebase. So that can be quite overwhelming to deal with, especially when there can be multiple corner cases, right. And I think one of the main things I tell, you know, Junior folks is, you have to also like kind of fall in love with the codebase. And the only way to do that is to actually try to debug every single method, debug every single kind of path flow, put breakpoints, put logs, and actually go go through it step by step, try to make a couple of changes, see how it gets impacted. And, and we try to give people enough time and space to actually play around and get comfortable with the environment. Because only once you're extremely comfortable in the environment that you're that you've been given, that's when you're able to really uncover the problems, you're able to really feel like you can make a change, you know, without having to worry that hate won't pass the test cases, or it's not going to, you know, pass the code review. So I think that's, that's one of the first things that I tell pretty much everybody like you should be very, very comfortable with your entire your entire dev environment with your code base with how the different flows work. That should be step one. The second thing that I always challenge developers with is, what's your mental model of the world? And how does that relate with your mental model of the software? Right? So when you're thinking about the way the code base is structured, and the way it's architected? How does how does it reconcile with your entire mental model of how the world works? And where do you see that this this piece of software doesn't probably replicate that as well? And where are the trade offs? Where sometimes you might see that real world modeling too much might not make sense here because it's over engineering barriers. In certain cases, you might see that he So this is not enough. And this and having the separation of concerns will actually lead to much better software design, right. So I think when developers marry these two things, they're able to move through the entire codebase very effortlessly. And they're able to reconcile it with the mental model of the world because they don't know the software world yet. They don't have the mental models or software yet, because they haven't done designing and stuff like that. But they what they do know is the real world, they've experienced the real world. So that's, that's pretty clear to them. So once you're able to kind of reconcile the software world mental model with their own real world mental model, that's when you start to see that, you know, that light bulb flicker in their head and say, Oh, wow, okay, now I understand why it's designed this way. And, you know, we can probably make this change and improve it. Or if I change this one particular class, it's, there's likely another class similar to this out there, that will have a ramification. So I need to be careful over here. And that's kind of how I think about like, you know, junior devs, kind of getting on boarded and kind of leveling up.

Tim Bourguignon 41:00
This is awesome. Thank you for that. That's that's a really step by step, incremental approach. I like that. Thank you very much. Nikhil, we're at the end of our time box already. Where would be the best place to continue this discussion with you?

Nikhil Nandagopal 41:15
Well, I'm always available on LinkedIn, or Twitter. But you can also just come over to the app Smith, GitHub repo, and you'll certainly see me there. I'm also available on the Apps Smith discord channel for anyone who's up for a chat about software and how we can improve the product.

Tim Bourguignon 41:35
That is awesome to hear. And I had links to all this in the show notes, so you don't have to search for it. Just scroll down and click on it. Um, anything else you want to plug in before we go today?

Nikhil Nandagopal 41:45
No, thanks so much for your time, Timothy, I just ask all the software developers out there to check out App Smith and start a GitHub repo. Absolute will just change the way that you think about building software. It's gonna save you a lot of time. And it's going to make you build the best software possible.

Tim Bourguignon 42:01
And reach out and tell us all that go want to hear from the customers. And I want to hear your journey as well. Awesome. Nikhil, thank you so much. It's been a blast.

Nikhil Nandagopal 42:13
Thank you so much, Timothy.

Tim Bourguignon 42:15
And this has been another episode of developer's journey, and we'll see each other next week. Bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you liked the show, please share rate and review. It helps more listeners discover those stories. You can find the links to all the platforms the show appears on, on our website, DevJourney.info/subscribe. Creating the show every week takes a lot of time, energy, and of course money. Will you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation? You'll find our patreon link at DevJourney.info/donate. And finally, don't hesitate to reach out and tell me how this week story is shaping your future. You can find me on Twitter at @timothep or per email [email protected].