Here are a couple of rules of thumb I follow you may find helpful.
1. Does the person complaining complain a lot, or do a few things bother him? My wife and boys have high pain thresholds, so when they complain, I pay attention. My father could complain about a few common problems, but it was time to pay attention when he complained about a new pain.
2. Unfamiliar pain can be hard to understand. If your father does not often have leg cramps, it's worth paying attention, even though he may ascribe it to another cause. I think he was telling you, "This pain is unfamiliar to me."
3. It's almost impossible to get any rest in the ER or the short-stay unit; he may not have wanted to complain to the doctors for fear of being held longer. Also, ER docs are very different from a hospital ward. They are very focused and quick to take action on problems that may kill you but are less concerned about pain or comfort. Their goal is to keep you alive for the next 20 minutes, hour, or four hours and get you out of ER - either back home or into a regular hospital bed.
I understand the "dirty work" model but would like to offer a different perspective. There is value in architects who can visualize and document an ideal case, then run simulations based on what they can imagine might go wrong to at least verify their basic assumptions.
But you need to pair them with people who can imagine what can go wrong and develop test examples. Of course, it's possible that the "pessimists" are too pessimistic, but I think it usually runs between 4 to 1 and 9t to 1 (80-90%) that the failure modes they can imagine must be dealt with.
And you also need people who are very good at debugging: documenting the failure, developing hypotheses for what might be happening, and changing one thing at a time to verify or disprove each failure hypothesis in turn.
So I understand your "dirty work" metaphor, but I think you need three kinds of skills--and one person rarely has all three:
1. Confident optimism that can imagine new architectures and approaches. If you can imagine a way to eliminate or dramatically reduce the "dirty work," it's a better start than a stoic willingness to "embrace the suck."
2. Constructive pessimism that can identify potential flaws or areas of improvement in a current design or process.
3. Patient, systematic exploration of options and hypotheses.
Thanks for the lengthy response, Sean. I might take a while to digest.
I've been stewing on Dirty Work for a while now. While I am satisfied with the definition I wrote in the earlier piece, I feel that a definition, no matter how well written, is in itself insufficient to move people to embrace Dirty Work.
So I've been stewing on what would be the biggest improvement towards getting people to move towards Dirty Work.
I have no proof but I'm settling on the various easy narratives that we tell ourselves and other attractive activities we indulge in to avoid confronting Dirty Work head on.
The story regarding my father's admittance is, I thought, a more concrete way to introduce this point. Perhaps, not as good as I thought in my own head.
I haven't read all the links and considered all your points, but there's one point I thought I wanted to clarify
> If you can imagine a way to eliminate or dramatically reduce the "dirty work," it's a better start than a stoic willingness to "embrace the suck."
So one of the 4 conditions I thought to define Dirty Work is that it MUST be necessary.
If it was possible to reduce or eliminate, by definition, it's not necessary and hence not Dirty Work.
Of course, there's a difference between actually necessary Dirty Work and mistaking what's unnecessary to be necessary.
Therefore, in real life we often have situations such as:
This established way of working is Dirty with high certainty
versus
This other way is theoretical but then that would drastically reduce the effort on the former if it actually works. Sadly, it's unproven.
In this situation, the real Dirty Work now is to do the proper cost-benefit analysis comparing the both ways, assuming efficiency matters.
After that, the next piece of Dirty Work would be to right-size an experiment to try out the theoretical way without impacting on deliverables, etc.
And then, the next piece would be do a post-experiment evaluation, and so on.
Now that I have written this much, it seems that working out the intricacies of Dirty Work and going through sources provided by you is pretty Dirty Work itself ha!
Here are a couple of rules of thumb I follow you may find helpful.
1. Does the person complaining complain a lot, or do a few things bother him? My wife and boys have high pain thresholds, so when they complain, I pay attention. My father could complain about a few common problems, but it was time to pay attention when he complained about a new pain.
2. Unfamiliar pain can be hard to understand. If your father does not often have leg cramps, it's worth paying attention, even though he may ascribe it to another cause. I think he was telling you, "This pain is unfamiliar to me."
3. It's almost impossible to get any rest in the ER or the short-stay unit; he may not have wanted to complain to the doctors for fear of being held longer. Also, ER docs are very different from a hospital ward. They are very focused and quick to take action on problems that may kill you but are less concerned about pain or comfort. Their goal is to keep you alive for the next 20 minutes, hour, or four hours and get you out of ER - either back home or into a regular hospital bed.
I understand the "dirty work" model but would like to offer a different perspective. There is value in architects who can visualize and document an ideal case, then run simulations based on what they can imagine might go wrong to at least verify their basic assumptions.
But you need to pair them with people who can imagine what can go wrong and develop test examples. Of course, it's possible that the "pessimists" are too pessimistic, but I think it usually runs between 4 to 1 and 9t to 1 (80-90%) that the failure modes they can imagine must be dealt with.
And you also need people who are very good at debugging: documenting the failure, developing hypotheses for what might be happening, and changing one thing at a time to verify or disprove each failure hypothesis in turn.
So I understand your "dirty work" metaphor, but I think you need three kinds of skills--and one person rarely has all three:
1. Confident optimism that can imagine new architectures and approaches. If you can imagine a way to eliminate or dramatically reduce the "dirty work," it's a better start than a stoic willingness to "embrace the suck."
2. Constructive pessimism that can identify potential flaws or areas of improvement in a current design or process.
3. Patient, systematic exploration of options and hypotheses.
Some related blog posts:
Unfamiliar Pain: https://www.skmurphy.com/blog/2008/11/23/unfamiliar-pain/
Innovation: the Trick is Managing the Pain https://www.skmurphy.com/blog/2015/04/16/innovation-the-trick-is-managing-the-pain/
Constructive Pessimism https://www.skmurphy.com/blog/2016/09/07/constructive-pessimism/
The need to counterbalance excessive pessimism https://www.skmurphy.com/blog/2020/10/12/skmurphy-perspective-counterbalances-excess-pessimism-or-optimism/
Thanks for the lengthy response, Sean. I might take a while to digest.
I've been stewing on Dirty Work for a while now. While I am satisfied with the definition I wrote in the earlier piece, I feel that a definition, no matter how well written, is in itself insufficient to move people to embrace Dirty Work.
So I've been stewing on what would be the biggest improvement towards getting people to move towards Dirty Work.
I have no proof but I'm settling on the various easy narratives that we tell ourselves and other attractive activities we indulge in to avoid confronting Dirty Work head on.
The story regarding my father's admittance is, I thought, a more concrete way to introduce this point. Perhaps, not as good as I thought in my own head.
I haven't read all the links and considered all your points, but there's one point I thought I wanted to clarify
> If you can imagine a way to eliminate or dramatically reduce the "dirty work," it's a better start than a stoic willingness to "embrace the suck."
So one of the 4 conditions I thought to define Dirty Work is that it MUST be necessary.
If it was possible to reduce or eliminate, by definition, it's not necessary and hence not Dirty Work.
Of course, there's a difference between actually necessary Dirty Work and mistaking what's unnecessary to be necessary.
Therefore, in real life we often have situations such as:
This established way of working is Dirty with high certainty
versus
This other way is theoretical but then that would drastically reduce the effort on the former if it actually works. Sadly, it's unproven.
In this situation, the real Dirty Work now is to do the proper cost-benefit analysis comparing the both ways, assuming efficiency matters.
After that, the next piece of Dirty Work would be to right-size an experiment to try out the theoretical way without impacting on deliverables, etc.
And then, the next piece would be do a post-experiment evaluation, and so on.
Now that I have written this much, it seems that working out the intricacies of Dirty Work and going through sources provided by you is pretty Dirty Work itself ha!
It's like writers thinking they should be perfect or write the perfect thing - it always seemed like conscientiousness that would kill creativity.