There are few types of developers I've encountered throughout my programming career:
over-engineering devs
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.
happy path = done devs
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.
let's try that new shiny OSS library devs aka hype devs
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.
so we're creating user-facing application devs
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.
let's write that ourselves devs
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...
we should have eslint for that devs
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.
endofunctor devs
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.
Top comments (6)
As an overengineering hyped happy-path endofunctor DIY dev, I am very offended.
๐
๐
I wonder, who makes technical decision in a company, what stack should be used, and stuff.
Such decision should be mix of:
๐
Thank you.
Good reference.