Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Ship Code Faster by Writing Less
Transcript
- Lucas: There's this moment in every senior engineer's career where they realize the fastest way to ship a feature isn't to write more code — it's to remove it. I'm talking about code deletion sprints, and they're surprisingly common at places like Google and Meta. Luna: A sprint where the goal is to delete code, not add features? That sounds like a hard sell to management. Lucas: It does, but the data backs it up. I was talking to an engineer who led a cleanup on an infrastructure team at Google. They reduced the codebase by about 40 percent — tens of thousands of lines — and within the next quarter, deployment frequency went up by 30 percent. Bugs dropped even more. Luna: So less code meant fewer things to break and faster builds. Makes sense. But how do you even start a project like that without someone saying 'that's not on the roadmap'? Lucas: You frame it as a reliability and velocity initiative. Dead code isn't free — it costs compile time, test time, cognitive load. Every time a new engineer reads a file with 500 lines of unused imports and commented-out functions, they waste mental energy figuring out what matters. Luna: Right, the maintenance tax. I've definitely been that person staring at a legacy module wondering if anything in it is actually called. Lucas: Exactly. The smartest engineers I've worked with treat code like a liability, not an asset. You should only add it if you absolutely need it. And if you do add something, you look for an equal or greater amount to remove elsewhere. It's the one-in-one-out rule for dependencies. Luna: One-in-one-out — I like that. It forces you to ask, 'Does this new library justify removing something we already have?' Lucas: Precisely. And it scales. At Meta, there's a famous internal mantra: 'Move fast with stable infrastructure.' They discovered that cutting cruft is one of the highest-leverage activities an engineer can do. It's not glamorous, but it compounds. Luna: Let's talk about the ego problem for a second. A lot of engineers — especially early in their careers — measure productivity by lines of code written. How do you shift that mindset? Lucas: The shift happens when you realize your performance review is based on impact, not output. A senior engineer who deletes a thousand lines of unnecessary abstraction and makes the system faster has done more than the junior who adds two thousand lines of boilerplate. Good managers know that. Luna: But not all managers are good. Some still ask, 'What did you ship this quarter?' and deleting code doesn't look like shipping. Lucas: That's where you reframe the narrative. You don't say 'I deleted code.' You say 'I reduced build time by 15 percent and eliminated a recurring class of bugs.' That's a feature. That's an improvement. And it's measurable. Luna: It's almost like technical debt repayment with a clear ROI. I've seen teams adopt a 'code cleanup first' approach before adding any new functionality. Lucas: Yeah, that's a good pattern. Some teams dedicate the first sprint of a quarter to cleanup. Others do a 'clean as you go' rule — every time you touch a file, leave it a little better than you found it. The 'boy scout rule' for code. Luna: We should mention that this isn't just about deleting unused stuff. It's also about choosing simpler solutions. Like, do you really need a microservice for this? Or could a shared library do the job in a tenth of the code? Lucas: That's the deeper skill — architectural judgment. The best engineers I know have an instinct for the minimum viable solution. They don't prematurely abstract. They write the simplest thing that works, and they refactor only when the complexity is justified by actual usage patterns. Luna: We've touched on something really practical here. And I think a lot of listeners are probably thinking, 'Okay, I want to try this, but where do I start?' Lucas: Start small. Pick one service or one directory. Run a tool like 'deadcode' or 'unused' to find exported functions no one calls. Remove them. See if anything breaks. If the tests pass and the deploy goes smoothly, you've just freed up mental space for yourself and your teammates. Luna: It also builds trust. When you demonstrate that cleanup leads to faster iteration, people start to see you as someone who makes the team more efficient. That's a reputation worth having. Lucas: It's one of those things that, once you start, you can't stop seeing. You'll look at a pull request and think, 'That's 200 lines of new code — can we do it in 50?' And you'll be surprised how often the answer is yes. Luna: Speaking of the pull request level — do you have a rule of thumb for how much code is too much in a single change? Lucas: I try to keep diffs under 200 lines. If it's bigger, I break it into logical commits. A massive diff is a sign that you're doing too much at once. And large diffs are harder to review, more likely to introduce bugs, and less likely to be approved quickly. Luna: That ties back to the mindset shift: writing less isn't just about the final product. It's about the entire process. Smaller changes mean faster feedback loops. Lucas: Yeah. And it's worth saying that this isn't about being lazy. It's about being intentional. Every line of code is a commitment to maintain it. The best engineers take that commitment seriously. Luna: We've talked a lot about individual habits, but what about team culture? Can a team adopt a 'less is more' philosophy as a group? Lucas: Absolutely. Some teams have a 'code freeze' day where the only allowed changes are deletions and refactors. Others use a metric like 'lines of code per feature point' and track it over time. If it goes up, they ask why. It turns it into a shared value. Luna: I've heard of teams that celebrate the deletion of code — like, they have a 'biggest deletion' award at the end of the sprint. It sounds silly but it reinforces the norm. Lucas: That's great. It flips the incentive. Instead of 'who added the most features,' it's 'who made the system simpler.' That's the kind of culture that scales well. Luna: And it reduces burnout too, because engineers aren't constantly fighting complexity. They're working with a codebase that's lean and understandable. Lucas: There's a great example from the Go standard library. The Go team is famously conservative about adding new packages. They'd rather have a few robust tools than a thousand mediocre ones. That discipline is part of why Go is so pleasant to work with. Luna: Okay, we've covered a lot of ground. Let's bring it home with a concrete takeaway. If someone wants to start applying this tomorrow, what's the single most actionable step? Lucas: Look at your most recent pull request. Ask yourself: 'Could I have achieved the same result with less code?' If the answer is yes, refactor it before you merge. That one habit will snowball. Luna: I like that. It's immediate and self-contained. And for managers listening — maybe consider a code cleanup sprint as your team's next iteration. You might be surprised by the velocity gains. Lucas: Yeah, I think that's where the real leverage is. A team that writes less code ships faster, breaks fewer things, and enjoys their work more. It's a win-win.