Cat HicksNov 29, 2022
So here's one of the things I'm super interested in that's coming out of our recent pilot research with software teams: there's a big difference between "things that are hard, but we're good at solving them" and "things that are hard, in a way that absolutely kills our motivation."
Show threadCat HicksNov 29, 2022

I think there's a lot of talk in the industry about "developer experience" and easing friction and I get that and believe in that -- but I'm always struck by how, when you ask several hundred developers if they believe they can solve hard problems....they DO believe this! They solve hard problems all the time!

But certain kinds of "hard" are a killer--cascading demotivation for people.

Show threadCat HicksNov 29, 2022
A lot of what we've studied about motivation with *students* in school focuses on helping them get over that first kind of hard -- individual self-efficacy. But developers score REALLY HIGH whenever you ask them to answer self-efficacy measures!! This is wonderful to me. What a cool gift. What a cool feature of this community.
Show threadCat HicksNov 29, 2022

This also has implications for where motivation "lives" in the system of software engineering. Yes, individual self-efficacy is always a good thing to encourage. But I am not sure it's what software teams truly deeply NEED, as much as they need support and protection against the second kind of hard.

What's the second kind of hard? Well we're working on identifying that, but there are pretty clear trends.

Show threadCat HicksNov 29, 2022
Sneak peek from our pilot research: this "second kind of hard" seems to bubble up for people when they say, "I had to repeat all this work again because no one remembered a previous project." or "yeah I solved an amazing technical issue, and then I found out I was working on the wrong part of the code because someone had changed x and hadn't told me." It's core motivational stuff about whether you feel SUPPORTED.
Show threadCat HicksNov 29, 2022
There are many important things here but one I think is vital to see: people who are capable of solving IMMENSELY difficult technical challenges will still feel this type of friction as "final straw" stuff. If you ask people about what they imagine the riskiest kind of software project, really dig into it -- consistently, people say that burnout from dealing with hypocrisy is worse than not having the technical skills or even not having money
Show threadCat HicksNov 29, 2022
A lot of things matter but it's really interesting as a researcher to ask, "which kind of hard would you choose if you had to choose." At least so far in my research, developers will choose the 'first kind of hard,' will choose to teach themselves entire new languages, will find motivation inside of ALL kinds of hard stuff, as long as they feel protected from the second kind of hard.
Show threadCat Hicks
(if any of this rings true for you or you want to share a related experience definitely please check out our survey, where you can also opt in for future research!! https://pluralsight.co1.qualtrics.com/jfe/form/SV_06TsuT7vkoM9Pdc )
Qualtrics Survey | Qualtrics Experience Management

The most powerful, simple and trusted way to gather experience data. Start your journey to experience management and try a free account today.

Nov 29, 2022 at 5:45pmWeb
Show threadwb x64Nov 29, 2022
@grimalkina my work in hackerspaces has definitely taught me that motivation, inspiration, energy, a sense of accomplishment, camaraderie, friendship, a sense that what you're doing is worthwhile, and a sense of self-actualization (doing not just interesting things but interesting things that seem to arise from within ourselves and our fickle desires) is far far far far more important than tools and languages and physical space and all the tangible things you think are important.
Show threadwb x64Nov 29, 2022
@grimalkina when I'm teaching wood shop or programming or soldering I'm usually not just teaching the skill so much as training the idea and practice of continuing forward even when things are unclear and hard: it's a life skill that's trained out of a lot of us especially in "teaching to the test." There is no single right answer or even a universal "right" or an "answer" in the sense of a fixed destination, nowhere in life outside of academia and totalitarianism.
Show threadscyNov 30, 2022
@grimalkina You might be interested in this short thread describing a related topic: https://eldritch.cafe/@AgathaSorceress/109428636157002184
agatha, fangs gf 🎀 (@[email protected])

just read a long article about software not being good and honestly at this point I'm still a big believer of the idea that most "software is painfully low quality" problems in computer science boil down to either capitalism prioritizing what's profitable over high quality, or people who don't even /want/ to be doing programming doing programming... because capitalism makes it more profitable than things those people might actually be interested in doing

Eldritch Café
Show threadfrancis nortonDec 11, 2022

@grimalkina If - as a burnt out coder turned counsellor - I do the survey, would you like me to specify my "current" role (individual contributor) or my less applicable but really current role (other).

Do you want to capture the experiences of people so burnt out that they've left the profession?

Show threadAlex FrancisDec 23, 2022
@grimalkina not a developer, but much of what you’re describing rings true for burnout in academia as well, both based on personal experience and what small amount I’ve read. I suspect a lot of „knowledge workers“ fit this pattern, scoring high on self efficacy but also depending on a strong sense of institutional support and shared purpose that can be debilitating when lost, betrayed, or undermined by shortsightedness or incompetence.
Show threadBhob RaineyDec 23, 2022
@grimalkina thanks for this thread. I've been developing for a long time now and still get motivated by true, technical challenges. Any day where I find that the best solution is a recursive function is a good day. But I'm driven to the point of early retirement by all of the trivial missteps and poor communications and anti-architectural processes that turn easy things into hard things, leaving a trail of bad blood behind them. Devs are too often set up for failure.