DEV Community

loading...
Cover image for Types of devs

Types of devs

Tomasz Cichocinski
・2 min read

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.

Discussion (6)

Collapse
fhammerschmidt profile image
Florian Hammerschmidt

As an overengineering hyped happy-path endofunctor DIY dev, I am very offended.
πŸ˜‰

Collapse
baransu profile image
Tomasz Cichocinski Author

πŸ˜…

Collapse
epsi profile image
E.R. Nurwijayadi

I wonder, who makes technical decision in a company, what stack should be used, and stuff.

Collapse
baransu profile image
Tomasz Cichocinski Author • Edited

Such decision should be mix of:

  • senior developers experience
  • team analysys of the tasks
  • available resources (if we want to create two native applications or use ReactNative and reduce amount of time for example)
  • importance of the task (is it PoC or core part of the business)
  • probably many more

πŸ˜‰

Collapse
epsi profile image
E.R. Nurwijayadi

Thank you.

Collapse
epsi profile image
E.R. Nurwijayadi

Good reference.