Ask HN: Opinions on Coder Infantilization?
5 comments
Everything can benefit from having a dose of storytelling to it. At the same time, the stories being presented to broad audiences are almost certainly flawed in ways reflecting the power structure, as you've detailed. Marketing teams tend to live and breathe story and so will often draw upon myths that please the key stakeholders - management and executives. Those myths then circulate into the atmosphere and at times reinforce themselves, but it is absolutely necessary to combat them and demonstrate strength.
The best way to do so is to have counterexample myths available: not just your personal story or "buttoned-down" aspirations of serious productivity, but a bit of a fairy tale, with symbolic and metaphorical aspects, and perhaps something comedic as well.
When you move the conversation away from the concrete and into the fictional you gain a lot of room to manuever and define your role: not a hapless geek or myopic code monkey, but a brave knight or a spellcasting wizard, suddenly embodying the powers of those archetypes. Indeed, there is an extant tradition of programmers using those metaphors and others as well: the ninja, the Zen master, the blacksmith, and so on. From this cast of stock characters you can adapt the specific theme you need to address into a small plot spanning perhaps a few sentences - something you can scribble down during a meeting. The result will carry far more rhetorical power than a plain argument.
As a follow-up, I recommend Nancy Mellon's "Storytelling and the Art of Imagination" as an inspirational resource and reference for getting out of literal thinking and into the myth-making frame of mind. This was the text for class on storytelling I took recently and it was a good kick in the pants - I've recommended it to friends, too.
The best way to do so is to have counterexample myths available: not just your personal story or "buttoned-down" aspirations of serious productivity, but a bit of a fairy tale, with symbolic and metaphorical aspects, and perhaps something comedic as well.
When you move the conversation away from the concrete and into the fictional you gain a lot of room to manuever and define your role: not a hapless geek or myopic code monkey, but a brave knight or a spellcasting wizard, suddenly embodying the powers of those archetypes. Indeed, there is an extant tradition of programmers using those metaphors and others as well: the ninja, the Zen master, the blacksmith, and so on. From this cast of stock characters you can adapt the specific theme you need to address into a small plot spanning perhaps a few sentences - something you can scribble down during a meeting. The result will carry far more rhetorical power than a plain argument.
As a follow-up, I recommend Nancy Mellon's "Storytelling and the Art of Imagination" as an inspirational resource and reference for getting out of literal thinking and into the myth-making frame of mind. This was the text for class on storytelling I took recently and it was a good kick in the pants - I've recommended it to friends, too.
You need people who are technical who have power to push back on the business. To have such people the business side has to want them. It’s the CTO and managers job to do both push back upwards. If a coder has a concern they should be heard out, although the decision might always be to do the technically wrong thing because of a business reason. And that’s ok as long as reasonable requests are heard and acted on enough. Not all teams and companies treat coders like infants, so moving on can solve the problem for you. Solving the problem in general is probably impossible as it’s human nature to end up with unfair power dynamics.
I think people that have condescending attitudes towards developers/coders are going to have that attitude anyway.
That being said, the importance of naming can not be overstated, you want people to want to talk about whatever it is your team is working on without making it sound like you are a bunch of misfits.
That being said, the importance of naming can not be overstated, you want people to want to talk about whatever it is your team is working on without making it sound like you are a bunch of misfits.
You may be overthinking it with the power dynamics theory. It may only be because they're making it comfy for the "young nerdy" demographics, who have the highest yield for the business.
I have 3 main ideas about these things:
1. I've seen it actively deployed to minimize the influence of coders and to dismiss their complaints or concerns about projects. This can be really annoying and sometimes has significant effects as technical advice is treated as not worth taking particularly seriously in "serious" business conversations.
2. On the flip side, it can actually be sort of useful. The absurdity of how seriously some people take themselves can become a little more evident when we're throwing around childish terms like "story points" and signing our emails with goofy team names.
3. Maybe I'm just taking this all too seriously, and these effects are mostly in my head.
Would be curious to hear opinions of the HN crowd.