This rigid definition into two different groups of people is pretty absurd if you just spend a minute thinking about it: in what other areas is it really reasonable to define human beings into personality binaries? The common response to this is always "well, it's a scale", like when people say they're a mixture of being introverted and extroverted -- another binary that does not stand up to scrutiny and seems to push the goalposts every time you poke at it, because most people do enjoy being alone occasionally, just like most people do not improve their mental health by avoiding others.

If someone identifies as halfway between a "stable" and a "volatile", that doesn't make them "a little bit of both", it makes the scale useless, because like a flatlander in 3D space it's obviously unaware of an entire dimension of human character and psychology. And yeah, of course these terms are created to "simplify" and "further discussion", but do we really need to put on a red or blue armband before having a discussion?

The picture painted here is one of the "risk takers" and the "risk avoiders", and while it tries its best to paint a fair picture it's pretty obvious it comes from a culturally American idealization of the Maverick, the risk-taking, 48-hour-working engineer who "gets it done(tm)" -- and I get it, that is valuable, and I've worked in companies filled with people who repeat phrases like "it's the way we've always done it", just as I've worked with people who got burned out re-factoring code, didn't care to document it and then quit, all in the name of this creative explosion the post seems to imply -- but if I can take anything from this post, it's not that these are natural laws of character that will repeat until the sun goes out, but rather that anyone solidly in the "stable" or "volatile" camp needs to work on their character progression to learn more from the other camp.

Nobody is born or raised into a role and then doomed to play it out for the rest of their life, we are very complex meat-bags that change over time, especially so in collaboration with others, so for anyone who feels like trying out the "Camp A" and "Camp B" advice when resolving conflicts in your workplace or when putting together managerial strategy, I'd implore you to maybe think again and tread a bit more carefully.

If success isn’t defined and these paths are left to individuals, then it seems like you have a problem with project scope and product management.

Most engineers and managers believe this. Nobody agrees where that place is located.

In a proper engineering discipline, the only place for hacking towards a goal is within the confines of the lab.

Yes, but in professional software engineering[1] where the roadmap exceeds 12 weeks, and the cost of a bug is non-zero, and you realize that in software engineering we do far more Reads than Writes to the code), then there are also dominant and dominated strategies[2]. Prototypes should be crafted from large blocks like low/no code solutions or generation... But once we have validation typically this is where good software architecture, and systems architecture come into play. Both the properties of the code that is written eg SOLID[3], and also the emergent properties of a collection of implementations.

All of this feeds into the total ROI of the engineering process. Quality issues lead to both churn[4], and slower roadmap (which means you lose out to competitors). People tend to think that "just make it work" is faster, but time and time again I've seen that only to be true in approximately the 6-12week time span. Hacky is fast until it needs to change, until someone else has to read it, until you realize there is a bug.

As well, it turns out that expertise in doing things well makes you faster the next time you go to do it well. I sometimes wonder if people doing things hacky/poorly is only faster because they've practiced it so many times? Often times well structured code is easier to read/write, fewer lines, easier to test, easier to morph into the next evolution. As we practice coding styles that give us these properties, we get faster at it.

So while yes there are tradeoffs, I don't think there are very many ways to take on lower quality implementation for time speed ups, both short and long run. Yes of course there are features you just don't need (your blog doesnt need to use CRDTs to update your post). And that tends to just having discipline in your Executive/Product team-- only ask for something if you have the research to make you think it will work, and the spine to stick it out to implementation. Engineers can also focus on stopping making bespoke software for prototypes. Pre GA mock ups should probably be using almost entirely light weight proxies for the product -- ui mock ups, generated code, SQLLite/PostgREST, low/no code solutions etc. to get strong data about usage patterns, user's needs etc.

[1]: "Software engineering is what happens to programming when you add time and other programmers." via https://research.swtch.com/vgo-eng .. I don't really care what you do in your spare time or on v0.0.0, but when we're on a journey as professionals to craft tools that 1000s to billions will rely on there's something more than just "it compiles, works on my machine"

[2]: https://martinfowler.com/articles/is-quality-worth-cost.html

[3]: https://simple.wikipedia.org/wiki/SOLID_(object-oriented_des...

[4]: (which means you cannot pay high CAC because you'll lose them before recouping cost)

But there's value in recognizing and categorizing instances of behavior in these terms. It's hard to effect change over something you don't understand, and giving it a name is a useful step to understanding.

The blog post itself describes a common evolution from volatile to stable through the course of an individual career, so I’m sure the author would agree that no person is predetermined as one or the other for life.

Lastly, I think ideas like volatile-stable have _explanatory_ value more than _predictive_ value. It can help defuse a tense situation to see that a team is falling into a common, age-old trap and then let the creativity of the whole team figure out how to solve it.

I don’t think we disagree as much as you seem to think we do. :)

Instead, I’d recommend really working on recommendation #1 which is working on communication specifically…

1. Tighten the feedback loop for them. We all get the idea of using logs for engineering. People need the same for their performance. This means being willing to have difficult conversations and providing accountability.

2. Discuss in an open forum ways in which to solve the underlying problem and get commitment from the team as a whole to try new things like mob sessions or pair programming.

3. Most importantly, there has to be clear goal-setting. Meaning the team should be a part of that process to decide what they are attempting to accomplish and what their scope will be. This can be helpful for making sure no one is too far afield.

ONLY ONCE THE TEAM HAS DONE THE THINGS ABOVE

And if the engineers choose to not engage in good faith and work in the interest team would I consider termination or moving them to another team.

I changed roles a bit ago and had to spend some time thinking through the battle scars situation that Rands calls out. It's definitely a bias to be aware of when moving on from a volatile, scar-inducing period to something new. I've repeatedly caught myself thinking don't want to do that again but sometimes doing that again is a phase of growth that still needs to occur for a new company or product. Not everything can be skipped because you're wiser this time around and I've had to work to navigate insight from having been there before vs. holding back the team due to baggage.

The new volatiles callout is great too as these teammates frequently need to experience the situations and see the cookie crumble before they can internalize and truly believe the tips others tell them.

It seems like there is not much evidence for this in the literature, and lots of evidence that extremely common practices around collaboration reduce productivity and creativity of orgs