If we are briefly going to play astrology-for-engineers then I guess I'm what would be called a "stable", but I kind of take issue with the dichotomy this post paints up in order to achieve what every tech writer seems to want to achieve these days: to be the person who Named Something.
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.
Thank you for this comment. I was reading the article and couldn’t agree more. Theres a place for hacking towards a goal theres a place for reliability. If you can only do one, then you are only half an engineer.
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.
> hacking towards a goal theres a place for reliability
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"
You're right to be wary of pigeonholing people: thinking that Alice "isa volatile" and Bob "isa stable", and viewing all interactions with them through that lens, will be more harmful than helpful.
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.
I dunno, man. I'm a (very) volatile person (in this dichotomy) myself and these days I'm aware of it. That wasn't always the case. But it really will piss me off if someone were to static my a$$ about something I really want to do. Now, this is not me saying I should obviously get to do it, this is me confessing to how I would feel about it.
I don’t think we have much disagreement here. My first two recommendations totally connect with needing to help people who are too firmly entrenched in one end of the stable-volatile spectrum.
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. :)
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.