The Biggest Dev Lies

This video was sponsored by jam.dev. More on them later.

I recently watched a really interesting interview with one of DoorDash’s engineering leads who was involved in the migration of their monolithic application to microservices.

Surprisingly enough his thoughts on the entire process would probably be categorized as hot takes in the industry these days, but, when you really think about it, he is making a lot of sense.

Back in 2020 when this migration happened, DoorDash had 20 million active users, and here you have this guy saying that their decision to move to microservices was not based on scalability issues. So you have a web app arguably in the top .1% when it comes to traffic that can handle all that load with a monolith. But we are being told that your random app built for a B2B use case needs microservices to easily scale in the future. Something doesn’t add up, and it is not the first time this is happening.

Here are 5 of the biggest lies we are told as web developers and how you can protect yourself from falling for these narratives.

1. You should worry about scalability

Back to the DoorDash example, their shift to microservices wasn’t about handling technical complexity or scalability issues. Instead, the driver was a business need for better collaboration. With a monolith, managing one codebase gets increasingly tricky as your team size grows, especially if we’re talking hundreds or even thousands of developers.

A large team on a single codebase means frequent code merges, conflicts, and a constant risk of unfinished work making its way to production. This is why big companies adopt practices like a ‘release train,’ a strategy with a fixed release schedule that helps multiple teams align without having to rush code.

In DoorDash’s case, moving to microservices let different teams handle their own release schedules. So, instead of coordinating hundreds of developers on a monolith, each team could build, test, and deploy independently, without impacting others. It streamlined release management and cut down dependency bottlenecks since one team’s success wasn’t tied to another’s readiness.

However, you’re essentially trading one set of complexities for another. Yes, release management becomes easier, but all that complexity is transferred to development now. Suddenly, you have a larger system to maintain, dependency graphs to track, new tools like gRPC or Rabbit MQ in the tech stack, and entire teams dedicated to manage all these services in the cloud.

So, the next time someone mentions that microservices are the go-to architecture for ensuring performance or scalability, especially for your regular app serving a few thousand users, just know they have no idea what they are talking about. Sure, microservices are a valid solution for complex collaboration and management situations, but there is no reason to associate them with words like scalability or performance. Before looking at the second lie, let me tell you a few words about today’s sponsor.

jJam is the fastest way to capture and fix bugs. With just 1 click, anyone in your team can send complete bug reports containing screen recordings, screenshots with annotations, instant bug diagnostics and all the session details you might need directly in one of the many popular issue trackers you are probably using.

We all know how frustrating the back and forth between QA and Dev can be so if you’re an engineer and you would rather spend your time writing code than responding to comments in Jira, send your team Jam.dev.

2. Big Tech implies Competency

Ok, the second lie might earn me some hate in the comments, but hear me out. While big tech companies have their critics, let’s be honest—most of us still dream of landing a job there.

The perks are great, but more importantly, you get the chance to work with top-tier talent and people who set the standard for the industry.

And sure, FAANG companies are known for their rigorous interview processes and sky-high expectations. You have to go through endless rounds of technical challenges, system designs, and behavioral questions just to get your foot in the door.

It’s easy to assume that all this effort leads to industry-defining competency and innovation. But here’s where the lie comes in. Big tech may be competent in many areas, but it’s far from being perfect.

In fact, even the most respected companies can make some pretty basic mistakes. Take for instance the recent 100 million dollar fine Meta got for storing hundreds of millions of passwords in plain text. Think about that for a second. You have one of the biggest companies in the industry doing junior level mistakes. This gets even worse when you realize the number of people, reviewers and processes Facebook has in place when it comes to development. So this was not a junior mistakenly pushing some faulty code in production. This was a long chain of devs and managers failing to impose the most basic security standards.

Another example I always like to share is the state of established frontend frameworks like Angular and React. These are backed by industry giants and they went through major overhauls, breaking changes, and full architectural shifts in the past 10 years. I think we can all agree that this is far from the perfect predictability and stability one would expect. To make things even worse, independent developers pop up and come up with solutions that disrupt the entire established ecosystem.

So remember that competency doesn’t come from scale, it comes from consistently getting the fundamentals right.

3. Serious Dev has to be Complex

If you were to sum up the life of your average human in 2 words, “fighting entropy” is probably a good description. Everything naturally progresses towards disorder and chaos over time. From the moment we are born, we are in a constant battle against the natural forces that drive things toward decay.

Software is no different. Your daily battle as a developer revolves around fighting complexity one way or another. It could be technical complexity caused by the addition of a new framework or library in the stack, or business complexity driven by new product requirements. However, this complexity doesn’t mean everything in development has to be hard.

There’s this misconception that good software requires a struggle and that any ‘easy’ solution must somehow be incomplete or sloppy. In reality, though, simplicity is often the hardest thing to achieve. It’s far more challenging to create something intuitive and maintainable than it is to stack on more layers or more tools under the guise of sophistication. But this belief that things have to be hard can end up driving us toward convoluted designs, overly complex systems, and feature bloat that only adds to the burden of maintenance down the road.

Let’s go back to the Door Dash example for a second. Microservices were necessary to streamline team coordination, but this doesn’t mean the architecture itself is inherently better than a simpler monolithic setup. On the contrary, I would argue that the technical solution is actually worse than before, and this is why Matt is calling microservices technical debt.

So keep in mind that the most elegant solutions often come from making things straightforward.

Ok. The next dev lie will sting a bit.

4. Software Quality Matters

If you are one of those people who think that Software quality is what really matters you’ll be in for a big surprise.

As developers, we’re trained to obsess over clean code and best practices. But here’s the truth - in the real world, software quality doesn’t matter as much as we like to think. What matters more is whether the software is good enough to keep the business running and let the team deliver on its goals. We tend to put qualityon a pedestal, assuming that it’s what makes or breaks a product. But the reality is that many successful products are built on buggy code, patched-together systems, and quick-and-dirty solutions. Why? Because product-market fit, customer service, and sales often have a bigger impact on a company’s success than perfectly architected software. A business that has a solid product-market fit will find that users are willing to put up with bugs and delays because the product meets their needs. They’ll be more forgiving if the app occasionally crashes if the core value is there. On the other hand, a perfectly coded app with no real user demand or a lack of effective sales will be just another personal project you can add to your resume.

There is a reason most successful software products out there, especially in their early stages, focused on shipping fast, getting feedback, and adapting, rather than waiting to release a ‘perfect’ product. They knew that market timing, customer support, and even just being ‘first to market’ often matter more than flawless code.

Of course, this doesn’t mean quality is irrelevant. You want a stable foundation, especially as you scale. But the next time someone insists that code quality is the most important thing, remember that ‘good enough’ software is often what drives success.

5. You’ll be replaced by AI

Finally, I’m sure you all heard this one in the past year. With the rise of advanced AI tools, there is not a day that goes by without somebody announcing that the dev jobs are dead.

I agree, it’s easy to get caught up in the hype and think that software development as a career is on its way out. But here’s the reality: while AI will certainly change how we code and solve problems, developers aren’t going anywhere. The truth is, AI will become another tool in your arsenal, a powerful one, no doubt, but it won’t be able to replace the problem-solving, critical thinking, and creativity that developers bring to the table. However, this doesn’t mean things won’t change. The most valuable developers of the future won’t be those who just specialize in one area or one framework; they’ll be generalists who can jump between different kinds of problems and employ AI to streamline their tasks. This shift means developers need to become more versatile and get comfortable working across various domains.

I’d love to hear your thoughts in the comments, especially if you don’t agree with some of the points I made. If you feel like you learned something, you should watch some of my youtube videos or subscribe to the newsletter.

Until next time, thank you for reading!