The Pragmatic Engineer

Replacing a $3,000/month service with a buggy DIY version. Navdeep Singh, founder of NeetCode, on why it doesn’t make sense to fix it: “I have this service that I was paying $3000 a month for. It was for code execution. I thought I could write my own version of this within a month or two, but the $3000 a month, the opportunity cost of that versus other things I could be working on, there were other more impactful things that I could be doing. But I thought, okay, with vibe coding, maybe I could get this done in less time, maybe a couple of weeks if I'm lucky. I actually got it done in two or three days. It did take coding skills. If I didn't know how to code, I would not have been able to do it, but I got it done in three days, and then I deployed the service. Now that I'm managing it, it costs me $200 a month versus $3000. But there's a bug in the service. I think there's a memory leak or something. And so what happens is I have this service deployed - every couple days, one or two instances will crash. So there's clearly an issue, there's a production issue. I could spend the time to go into that and fix it. This is one of those things where it's like you get into vibe coding and you run into an issue and it's like, okay, now you're going to have to actually dig into the details to really understand where the issue is coming from. So I think it would actually take me much longer than three days to find the issue. So I haven't even bothered with that because I'm like, well, okay, if one instance goes down, I'll just have several instances running at the same time. I'll have four. So if one goes down and it doesn't happen that frequently. So it's an interesting trade-off where the engineer in me hates that because there's an issue, fix it. But the business value makes no difference. There have been practically zero outages. I have less outages than LeetCode and I'm like a couple people doing it. So I just think it's like a trade-off and people could argue one way or the other, but I think it just makes so much sense right now for me to not fix it.” Learn more about coding interviews, big tech and entrepreneurship with NeetCode on The Pragmatic Engineer podcast • YouTube: https://lnkd.in/eGPTQbZ7 • Spotify: https://lnkd.in/eHJnpTrM • Apple: https://lnkd.in/eSsMiEP2 • Summary and transcript: https://lnkd.in/eAx2AiaC

"I have a love-hate relationship with programming". Navdeep Singh, founder of NeetCode, on getting hooked on coding and why this doesn't always translate to loving a software engineering job: #1 - Neet loved math and physics, but coding didn’t come naturally “I was studying electrical engineering when I was in college because I really liked math, I really liked physics. I know a lot of programmers, a lot of programmers don't like math, but they really like programming. And so when I got into programming, I was just taking an intro to C class, it was required for electrical engineering. I didn't really want to take it, and I was not very good at it initially. I remember trying to learn `printf` and the `%s`, `%c`. I don't know why I looked around. Everybody around me was learning it so quickly. And to me it was just a very different way of thinking. Even though it's kind of related to math, you'd think it'd be easy to pick up, but it really wasn't initially for me. #2 - Neet got hooked on programming when he realised the problems you can solve with it Then a couple of months went by and we learned about variables, conditions, loops, functions and all these kind of concepts. And then something just kind of clicked where it's like initially programming felt kind of boring. It's like you just have variables and numbers, but then when you introduce all these things, then you realize there's this infinite complexity that can be introduced. And you see that with all the software that is built today where it's like you took these simple primitive things, these zeros and ones, and all of a sudden you just have this enormous universe of software solving insane problems. Once I really started enjoying programming, I just fell in love with it. And I was like, okay, I'm going to do this for the rest of my life. I'm going to love it. #3 - Programming as a job might mean you don’t work on the problems you enjoy Then I went through a transition where, once I got into the real world, I realized that programming is not something you can just kind of do the way you enjoy. It's a business at the end of the day. So that in a lot of ways took some of the fun out of it for me, where it's like you don't get to work on the languages that you like, the problems that you enjoy solving. You have to focus on the business problems. I have a love hate relationship with programming because of that reason. And I think a lot of people do.” Learn more about coding interviews, big tech and entrepreneurship with NeetCode on The Pragmatic Engineer podcast: • YouTube: https://lnkd.in/eGPTQbZ7 • Spotify: https://lnkd.in/eHJnpTrM • Apple: https://lnkd.in/eSsMiEP2 • Summary and transcript: https://lnkd.in/eAx2AiaC

AI is changing how software is built: unfortunately, it is also resulting in lower quality and more bugs at times. Very happy to partner with Antithesis for the season: probably the most powerful way to find bugs before customers do, by running your software in a hostile environment, and perfectly reproducing every issue found.

AI is a great tech debt assistant. Navdeep Singh, founder of NeetCode, on how AI reduces the cons in makes moving fast and cleaning up later: “Over the last six months we've been cranking a lot of features out, a lot of code out. Most of it has been written by AI at this point, and before that really wasn't the case. I was actually a really big AI hater for a long time, and people still sometimes think I am. If I'm pro AI, they're like, ‘NeetCode you changed, what happened? Now you're an AI shill’. But it's not that. I just try to be pragmatic about it because I was still using the tools before, but they just weren't as good. Now they've gotten to a point where the work that I'm doing… which is mostly CRUD, usually there's not that much crazy interesting stuff other than the code execution service, that's probably the most interesting one. The first few years when I was writing most of the code - very, very bad code quality - I used TypeScript, but I was not using real TypeScript. I had a lot of `any`s. I had a lot of bad code. I was putting inline CSS. I was just doing all sorts of stupid stuff just to get stuff done as quickly as possible because I knew the entire codebase. I knew certain tech debt, I could just deal with. And so it was a trade-off for me just to move quicker. But with AI now, I've gone back and I realized that trade-off was so worth it because I cleaned all of that up with AI, because that's what it's for. It can clean up a lot of sloppy code, it can refactor a lot of things. And if I really wanted to now, I could probably migrate to other tools very quickly with AI. So, to go back to the trade-offs, I think it's just about thinking you might make the wrong decision, but even if you make the wrong decision, you can go back and then try to correct it just by thinking about it.” Learn more about coding interviews, big tech and entrepreneurship with NeetCode on The Pragmatic Engineer podcast: • YouTube: https://lnkd.in/eGPTQbZ7 • Spotify: https://lnkd.in/eHJnpTrM • Apple: https://lnkd.in/eSsMiEP2 • Summary and transcript: https://lnkd.in/eAx2AiaC

"The best sales pitch in the world". Navdeep Singh, founder of NeetCode, on how getting a Google offer gave his YouTube channel credibility and made it explode: “I was making these tutorial videos. I was like, I'm studying this right now. I got nothing better to do. I might as well help some other people. And I found it very difficult because there weren't really tutorials at the time. There were just a lot of forum posts of these really complex solutions. And I'm sitting there banging my head against the wall trying to understand it. Most people didn't understand the solutions because it is very hard to. I think most people just looked at the algorithm, kind of had a high level understanding of it, didn't quite know why it worked, but it was good enough. Usually if you saw that question in an interview, you could probably pass the interview. This goes back to deep thinking, which I think was a skill that is more of a personality trait for me. But I think it helped me a lot with the LeetCode stuff. I went really deep into things, but at the time felt kind of meaningless where it's like you make this video for 50 people watching and you did a great job, but clearly it's not worth the several hours it takes to do that. But I kept doing it ‘cause I enjoyed it. About a year after I started making the videos consistently, I did get into Google. I was very fortunate to do that, the interview process was pretty easy at that point, thankfully. So I kind of backed off the videos. I was like, this was fun, but I'm at Google now. I made a video telling people like, ‘hey guys, I got into Google, you might not see me as much anymore’. Funny enough, after that, the channel went exponential because I think it added so much credibility. It's like, okay, this guy didn't make these videos after he got into Google, he actually made it before, this is what he did. And then he got in. So it's like the best sales pitch in the world. I proved it. I went from zero to one.” Learn more about coding interviews, big tech and entrepreneurship with NeetCode on The Pragmatic Engineer podcast: • YouTube: https://lnkd.in/eGPTQbZ7 • Spotify: https://lnkd.in/eHJnpTrM • Apple: https://lnkd.in/eSsMiEP2 • Summary and transcript: https://lnkd.in/eAx2AiaC

At Amazon, he learned not to ask questions. Navdeep Singh, founder of NeetCode, shares how Google saw this fear as independence and promoted him quickly: “I was kind of in Amazon PTSD mode. That was my first real professional experience. I extrapolated that to be everywhere in big tech or even just professionally in general. So I was like, okay, you're supposed to not ask questions. You're supposed to not talk to people. You're supposed to not even be friendly. You're supposed to just work and just be as intense as possible. At Google, people were very friendly to me, and so I reciprocated that, but I didn't ask questions. I was very scared to, so I worked on my own for the most part. I was given a project from my manager that turned out to be more difficult than it was supposed to be. I was still in the mode where I was like, I just got to get it done. This is my project, I have to do it independently. And so I was very fortunate in that I did have a very supportive manager, a very supportive team. And because I chose to do pretty much all the work by myself, the manager and team saw me as independent, which is what you need to do to get promoted from junior to mid-level. And so I was very lucky to get promoted very quickly because of that. That helped me build my confidence a lot. That made me realize, okay, I can start asking questions now, which is funny, after I got promoted is when I was more comfortable asking questions when you'd expect that from a junior engineer more.” Learn more about coding interviews, big tech and entrepreneurship with NeetCode on The Pragmatic Engineer podcast • YouTube: https://lnkd.in/eGPTQbZ7 • Spotify: https://lnkd.in/eHJnpTrM • Apple: https://lnkd.in/eSsMiEP2 • Summary and transcript: https://lnkd.in/eAx2AiaC

Not everything has to be end to end GitOps. Robert Erez, principal engineer at Octopus Deploy, on GitOps absolutism: “What we see is a lot of people go to conferences or they read blog posts and they hear that GitOps is what you should do. What I want to point out here is GitOps is potentially not necessary for all locations, all environment teams. There's certainly a bunch of benefits to it, but the reality is there's some things you need to do outside of just GitOps, and so you might use GitOps principles in parts of your process, but some of this absolutism that sometimes exists may not be necessary. There's often a bunch of other processes you do around your actual deployment: maybe you run smoke tests, or maybe you want to send a notification when it's complete, or maybe you want to do a database update. These kinds of steps don't really lend themselves very well to this 'declarative, everything is in Git' process, and so that's why you get things like Argo workflows and rollouts come out to try to GitOps-ify this process, and that works for some people. But the reality is that I think some people get really hung up on this idea that everything is Git, so therefore they've found the tool, and so therefore everything is a nail. I think that's just not the case. So again, that difference between what you hear when you talk at conferences, where everything is Git and everything must be in this particular format, and the realities for most customers: they're just trying to ship software and they don't care what name you give it. If it's GitOps and it works end-to-end and solves everything - good. If they want to use GitOps as part of the process but then have other mechanics that are more imperative - good. It's just the reality that there's tens and tens of thousands of companies out there in the world doing software delivery, and not all of 'em are at conferences and not all of 'em are at the forefront.” Learn more about software delivery at scale with Rob Erez on The Pragmatic Engineer podcast: • YouTube: https://lnkd.in/eKuQNta9 • Spotify: https://lnkd.in/ecMi9nHy • Apple: https://lnkd.in/eHD5sd-e • Summary and transcript: https://lnkd.in/ed3QuzdG

The keynote video from Craft Conference, titled "Slow down to speed up: what changed in the last 6 months for software engineering" is now available to view. Watch it on YouTube: https://lnkd.in/e9RDcyHE Or read the extended summary in today's issue: https://lnkd.in/eXHS7zmd

How to get into Progressive Delivery? Robert Erez, principal engineer at Octopus Deploy, on the value of being able to switch a feature back off: #1 - Start with one feature flag “So start with adding one feature. It may be scary at first to kind of go, oh, it's in production, if I toggle this, I'm going to break something in production. It's nice and comfortable to know that you're kind of well to the left of the running systems and if you ship code, everything will be caught by the test. But, if I toggle it, what will happen? But it's kind of like a drug. Once you start doing it, you don't want to stop. And that's why we've got this hygiene problem for things like feature toggles. It's really easy to add them and actually end up with the opposite problem of how do you control yourself? How do you stop? So I'd say just start doing it. Add one and keep an eye on as you roll it out and you look at the results from it. The reality is I've shipped features on feature toggles where I've shipped a bug and it's one thing to ship something and turn on a feature and go, okay, cool, customers have it, it's a very different thing when you do the opposite." #2 - Why you reach for the toggle when things go wrong "If you ship something and there's a problem and you can reach immediately for the toggle and switch it back off. The amount of times kind of in the past, you have this kind of panic of, oh no, I've shipped something, I dunno what's going wrong. And particularly when you're in that state, maybe you've got called up at 2:00 AM because you've got an on-call and you dunno what the next step is to do, and you’ve kind of got a panic mind and should I build a new thing or do I somehow force a redeployment? So having the capability of being able to flick that switch just allows you to then calm right down and go, okay, I've stemmed the bleeding. Now come back and reanalyze it and understand what's wrong. So having that capability once you've sort of experienced that and realize the value that not just rolling things out, but sort of I guess rolling that individual feature back off. Yeah, you'll want to use it for everything." Learn more about software delivery at scale with Rob Erez on The Pragmatic Engineer podcast: • YouTube: https://lnkd.in/eKuQNta9 • Spotify: https://lnkd.in/ecMi9nHy • Apple: https://lnkd.in/eHD5sd-e • Summary and transcript: https://lnkd.in/ed3QuzdG

Ephemeral environments: what are they, and why are they more popular? Robert Erez, principal engineer at Octopus Deploy, explains: "What we're seeing is more the growth of things like ephemeral environments. And so this is the idea that I, as an engineer, am running some sort of feature on a feature branch and I want to kind of evaluate that it's actually doing what we're expecting it to do. So ephemeral environments is this idea that from my branch pre merge, I want to spin up a whole environment essentially from scratch, ideally with whatever dependencies are required to run this particular piece of this component that I've been building. Then I want to basically deploy my app into that as if it was a normal full fledged environment. Once that's available, if it's a web app, for example, maybe it gives me the URL and I can poke around it and hand it around and other people can evaluate. And then the moment I merge that PR, tear it down again [Gergely: Now with AI agents everywhere, that's even better because in the sense that if one of the best ways to validate, we have code reviews and AI agent generates and you look at the code, but isn't it not better to just confirm that this thing works, especially when it has a UI?] That’s right. I think even in that world where you've got AI agents building the code and validating the code, any sort of scenario where you want that AI agent to validate what it's done, you're essentially talking about ephemeral environments, even if it's not exposed to people because it's doing its own testing and poking around.” Learn more about software delivery at scale with Rob Erez on The Pragmatic Engineer podcast: • YouTube: https://lnkd.in/eKuQNta9 • Spotify: https://lnkd.in/ecMi9nHy • Apple: https://lnkd.in/eHD5sd-e • Summary and transcript: https://lnkd.in/ed3QuzdG