@mhoye reporting back on this, there was some conversation about developing the skills to be present and ask analytical and guiding questions in a conversation that starts with a leader saying "I only want x..." To play out the consequences of a or b approach. It was emphasized that these decisions are never moved at the end of the day by statistics but are moved by storytelling
Post
@grimalkina waves from across campus
I'm going to take some running notes.
Please do not use this thread to yell at me, argue about AI. Thoughtful dialogue is welcome but not anger.
First up is Eirini Kalliamvakou, GitHub, talking about developer identity shifts. Since I studied AI threat from a social identity perspective in 2024 this is interesting to me! I think identity theory needs to be brought in far more than it has been in DevEx
For instance, we know that strongly internalizing an essentialist identity can be harmful for people's ability to face change. Those are interesting mechanisms we can test for and potentially help reduce people's distress by changing, imho.
Her (qualitative, ~22 or so samples) research belies the idea that AI superuser developers see themselves as managers. Thinks the metaphor more appropriate is creative director of code, doing a lot of active cognitive work. My thought: thank God someone is saying this
In my experience with hundreds (and in my research thousands) of developers, rarely do I find people who simply don't care about learning, who don't want to do interesting work, and who don't have a high need for cognition.
@grimalkina Has there been any research on improved communication of the theory used by creators of the software?
I recently read Peter Naur's "Programming as Theory Building" and have wondered about off beat ideas like "spoken programming for better theory transfer?"
I'm interested in any attempts at improving the transfer of theory to new team members.
@shapr similar as this thread I think
Me and the two psychologists from jetbrains had a couple of very interesting exchanges about this but all agreed we are often facing the assumption that all devs' mental models are homogenous, that individual survey measures are all EQUALLY accurate/biased vs software metrics (this is not true imho), and other gaps between our fields. Honestly I wish I had time to write a paper about this it's becoming a negative space I'm noticing
@grimalkina Reality checking versus superstition for the individual developer or dev team, perhaps?
At work we learn what we experience in the context we find it. Sometimes the context encourages understanding, and sometimes it encourages explaining away the "why" without checking.
This morning's CoffeeOps peer discussion highlighted operations "game days", rehearsing failure scenarios, as a way to exercise and transfer working knowledge, to work across teams in the response, and test assumptions. Sometimes the incident response books get confirmed, and sometimes rewritten.
@jmeowmeow can you restate the question for me? Is it something like, how can we encourage people to do more reflection and check their understanding? Or is it understanding the features that encourage "explaining away the why" ? Both?
@grimalkina More the first question: How do we encourage practitioners to test assumptions about what matters in their work?
And partly the second question, as you point out: What systems and cultures encourage explaining away the why and how of working routines?
Both of these questions touch on superstitious or unexamined beliefs about work routines.
@jmeowmeow got it thank you!
@grimalkina How do we make the positive changes we want to see palatable enough to leadership that we can start building incentives around them?
@grimalkina How do we make the positive changes we want to see palatable enough to leadership that we can start building incentives around them?
@mhoye reporting back on this, there was some conversation about developing the skills to be present and ask analytical and guiding questions in a conversation that starts with a leader saying "I only want x..." To play out the consequences of a or b approach. It was emphasized that these decisions are never moved at the end of the day by statistics but are moved by storytelling
@mhoye I would also say my talk touches on this too: I argue that community response and tangible impact for developers makes research highly "reusable" in part because people can see the many many personalized actions they can take in response. Paradoxically sometimes to get to this you have to ignore the leaders and develop research very closely to the real problems of practitioners, but then AFTER research that authenticity translates to a lot of actionable suggestions.
@mhoye I had a few but not many follow-up conversations. I think I was most interested in whether grad students would think about putting community based methods into practice but to my disappointment basically every conversation with a grad student was "I want to study x and I've already decided the method now tell me how to make it work" which basically to me is a failure state sequence, just speaking honestly.