There are few types of developers I've encountered throughout my programming career:
They care only about engineering, system architecture but not really about the business of the created application. They like to talk about using advanced patterns like event sourcing, actor model, using message broker or message queue just to implement a simple to-do list.
They care only about the happy path. Making PM/CEO/client happy, especially if the person they are reporting to has no idea about the technical side of building things. They copy-paste existing code, add new fields to data models, and don't bother thinking twice about the consequences of their changes. What matters is just covering one simple case they have in their task.
As soon as there is a possibility to add a new dependency or blame slow performance/bugs on not so trendy library the project currently uses you know they will be the first to jump to rewrite existing code and burn old to the ground. Especially if the new library is few days old and just blows up on Twitter gaining few hundred/thousands stars in the first few days.
This is a special breed of backend developers that only care about data, security, system architecture, system resilience, fault tolerance, containers, and Kubernetes. Super happy when writing new services to cover business logic (the more complex the better) but they are disgusted when asked to expose API for "frontend" or implementing something even remotely close to user-facing UI.
Screw that OSS library everyone uses. Sure it has hundreds of contributors is used by a lot of companies in their core products but we should write that ourselves to have 100% control. Yeah, sure...
This special kind of developer creates the most impossible eslint rules to fix the JS. Ban half of the language, force conventions, have 10 times more eslint config than actual code.
Freshly after reading about category theory just have to use that Kleisli composition in your codebase. And not forget about using all of the possible custom operators to express even the simplest business logic.
We all probably know some of those developers and can recognize our colleagues among them. We can even make fun of them, but the truth is - we all should take the good parts from each one of the above and balance it. This is what makes us better developers.