Diverging claims about what it means to be a programmer, developer, designer, hacker, and so on pulls uninitiated beginners in contrary directions.
One exercise I’d start with is to get people to write down a problem that they want to solve, perhaps with a data set they are currently working on, or a problem that they saw somewhere else and want to replicate it. Then ask them to write down how much time and effort they think it will take them to solve this problem. For those that have done time-series analysis and Fourier Transforms in Excel, it might be motivating for others to make this pain visible.
Then, after some significant amount of learning, and practicing has gone on, ask them to review what they have written down, and re-estimate the time and effort they will need to solve their problem again. What have they gained? Are they any closer? Or are they further away?
Take a poll. Some people may already have solved their problem. Others might have a better idea of what they need to learn next, or what API documentation to read. Other people may have realized that they bit off more than they could chew. If that is the case, allow them to rephrase it. I recommend reflecting on these problems as a group, capture them on the wall with stickies if you want to.
Not only does this give people something practical and relevant to work towards, but is an important exercise in framing and re-framing a problem. You might even note that this is even semi-scientific in nature; can you update your hypothesis now that you have more information? If you can’t, maybe you need to revisit your own expectations and devise a new, more manageable experiment first.
I don’t think that people need to walk away with any concrete solutions per se, but the intellectual process of refining a problem into solvable chunks is not only a necessary skill, but can be highly motivating.
We’ve discussed already that non-experts will not be able to estimate the extent of their own abilities or the amount of time needed. I think it would be very motivating for people to say, “The way I used to do this took me 10 hours, and now I can do it in minutes”, or “I thought this was beyond my wildest dreams, but I can see what the path might look like”
In the few occasions that I have asked people about their motivation, I find their curiosity is a misguided. "I'm interested to what what kind of features Python has", as in it has a fixed set of buttons on the user interface. The person has only served as a passive witness to technology, not actively participating in it.
As we discussed with the concept map exercise, it can be hard for people to learn new concepts without having context to strengthen the connections between nodes. Familiar problems, meaningful data, examples of pre-existing workflows can serve to make programming feel like an extension of one’s work, opposed to a digression from or alternative to it.