My experience with arrogant developers

Published 18 days ago

I’ve worked in many places—corporates, startups, tiny teams, and codebases with thousands of contributors. Across all that, I’ve noticed a pattern.

The companies that actually delivered value to customers—real apps, real users—were usually the ones that followed patterns that made sense: clear decisions, shared principles, and consistent direction.

The power of opinionated teams

What worked best was when someone made strong, informed decisions. They enforced a certain codestyle, chose a specific software framework, and set shared principles. That made the code more readable for everyone. And readability is everything when you’re working with other developers.

Frameworks help here. For example, Java’s Spring Boot framework is opinionated by design. If your team uses Spring Boot, you can usually read any piece of the codebase and immediately understand what's going on. You know where things live. You know what they’re supposed to do. It scales well.

Communication > Technical Skill

The best skill a developer can have isn’t technical. It’s communication. You can teach someone a new tech stack. It’s much harder to teach them how to collaborate without ego.

The developers I remember most weren’t the rockstars who pushed fancy code. They were the ones who sat with me during my first days, explained how things worked, walked me through the codebase, and made space for learning.

That’s what sticks.

The arrogant ones

And then there’s the other type. The ones I don’t remember fondly.

These are the developers who think they’re smarter than everyone—including the teams behind mature, open-source frameworks. They don’t want to follow conventions. They build their own thing—because they hate ORMs, or classes, or just the idea of not being in control.

The irony? Those frameworks they’re rejecting weren’t made by clueless people. They were built by skilled, collaborative teams. Reviewed. Tested. Used by thousands. Ignoring all that because you think your way is better? That’s arrogance.

And it shows up in small ways too. For example: the developer who insists on using tabs in a codebase that clearly uses spaces. Or complains every time linting catches a formatting issue. Or worse—goes ahead and uses tabs anyway, just to prove a point. That kind of attitude is a huge red flag. If you can't follow something as basic as an agreed code style, you're not a team player—you’re just being difficult for no reason.

And if the arrogant developer isn’t just a team member but the person leading the team? Then you're screwed. Instead of enforcing clarity and consistency, they introduce chaos, confusion, and ego-driven decisions. And the whole team suffers for it.

The ones who made it work

Now, the developers who really scaled things? They picked stable, opinionated frameworks with long-term support. They didn’t try to reinvent the wheel. Instead, they set up linting, code quality checks, clear folder structures, and CI pipelines that caught issues early.

They invested in readability. They led with principles. They made others follow—not out of ego, but out of care for the team and the product.

That’s how you scale a business and deliver results.

Final thought

If you lead a team, your job is to guide. You need to set standards. Not everyone will like it, but if you want to build something that lasts, you need more structure—not less.

And if you're a developer: your code doesn’t matter as much as how well you work with others.