After years of working across engineering teams, open-source communities, product cycles, late-night debugging marathons, and “just ship it” deadli...
For further actions, you may consider blocking this person and/or reporting abuse
Hey! Great post — I really resonated with #4, “Grow the Junior” Developer.
Unfortunately, my current environment is quite the opposite. Many people already believe they are the best among the team, which creates unnecessary pressure and stress rather than collaboration.
I’m planning to change roles in the coming months and I’m hopeful to find a more supportive, growth-focused environment.
That sounds really tough, and unfortunately more common than it should be. I’ve seen how much damage “everyone has to be the smartest” cultures can do to learning and trust. Wanting a growth-focused environment is completely valid — I hope your next team genuinely supports that mindset.
Thank you, I really appreciate that. You’re absolutely right those “everyone has to be the smartest” environments can be really draining and don’t leave much room for learning. I’m hopeful the next team will value growth, collaboration, and supporting each other a lot more.
Cool post. There’s also the type: "Set up for success – doomed to fail". These are beginners who possess the drive and desire to create "cool stuff", which is certainly good, but they soon ‘burn out’ when confronted with thousands of lines of code. Unfortunately, this is a very common problem among young developers.
This resonates a lot. The desire to build is such a strong starting point, but without scaffolding and context, it’s easy for that energy to turn into frustration. I’ve seen many capable beginners lose confidence simply because the environment was too much, too fast.
This is a great taxonomy — and what I really like is that it doesn’t moralize any of the mindsets.
One thing I’ve noticed over time is that teams don’t usually fail because they have one of these archetypes — they fail when the system doesn’t constrain and balance them.
The “rewrite everything” dev becomes dangerous only when there’s no finish line. The “ship it” dev becomes risky only when there’s no feedback loop. The architecture astronaut becomes detached only when diagrams aren’t grounded in executable constraints.
In healthy systems, these mindsets are forces, not flaws — but they need structure to interact safely.
That’s also where I think modern tooling (and AI) should help most: not replacing any mindset, but making the boundaries explicit — contracts, verification, shared context — so different ways of thinking can coexist without constant friction.
Really enjoyed the framing. It reads less like “types of people” and more like “modes we all shift through over time,” which feels very true.
Yes, exactly this. I didn’t want to frame any of these as “good” or “bad,” because I’ve seen each one be incredibly valuable in the right context. The system — constraints, feedback loops, shared understanding — is what determines whether a mindset becomes productive or destructive. You articulated that way better than I did.
Really nice post! Im nr 12 now days, depending on project!
I like this post so much i made tiny quiz app for it!
ehsanpo.github.io/developertype/
This is amazing 😄 — I love that you turned it into something interactive. That’s such a perfect example of how these “mindsets” shift depending on the project. Thanks for building and sharing this!
Hahaha great read! I'm Glue Developer and Detective Developer at work and definetely the Experimenter after hours 😅
I love this combo. Glue + Detective is such a powerful way to work, and Experimenter energy outside of work is usually where the most interesting ideas come from. Thanks for sharing!