A summary of the "situationist" faction of personality psychology, which holds that behavior is strongly influenced by the situation. Knowing someone's personality type adds little value when predicting how they'll behave in a new situation. Small changes to the environment can have disproportionately large effects on behavior. "Making predictions is hard, especially about the future." – attributed to Neils Bohr.

Not an episode that suggests ideas for people to try in software projects. Instead, I am reacting to the book /Communities of Practice/, whose ideas are not explained well enough that I can use them confidently in an episode. I suggest how the book could have been improved by using more examples, some counterexamples, and more stories. If you want to be a better explainer, this might help you.

"Legitimate peripheral participation" is based on observations about how novices learn in the presence of experts. The novel bits are that novices learn better from fellow novices than from experts, that we need to pay attention to the difference between teaching and learning, that passive observation is underrated, and that toy projects (code katas, "advent of code", etc.) are perhaps not all that useful – at least to novices. In the "applications" section of the episode, I offer an...

Julian Orr tagged along with ~1990-era photocopier repair technicians and made some observations that seem to apply to modern software development. This episode discusses his 1996 book, /Talking About Machines/.

In this episode, I hope to give you some helpful hints about *actually* improving the lives of the users of the software you create. Or, if you’re the kind of “change agent” or “coach” I used to be, the lives of the, uh, victims of your consulting.

We in software are prone to "Seeing Like a State". It's easy to adopt that perspective despite good intentions. How can you realize that's what you're doing?

An introduction to the core ideas of Scott's /Seeing Like a State/. Three examples. Nothing about software yet.

In episode 12, I used the chapter in /Image and Logic/ about Monte Carlo methods to argue that analogies of software development to engineering are not helpful. Glenn Vanderburg pushed back: it's not *engineering* that's the problem; it's our misunderstanding of engineering. I invited him on the podcast to make his point.

How two books influenced Danish software designer Mark Seemann to get the non-rational part of his brain working on his side.

Why *are* teams stuck in hierarchical and commercial exchange economies, when they'd be happier and just as productive if the example of the previous episode were the default? A discussion of totalizing systems and "system justification": forces that push against change. An argument from examples that humans are way more free to choose than we believe. A suggestion for a certain kind of cross-fertilization.

David Graeber claims every society contains a mixture of variations on three types of economies: hierarchy, exchange, and "baseline communism". The context for software teams is a combination of hierarchy and commercial exchange. There are alternative combinations available if teams prefer them.

An introduction to gift economies, based on the writings of anthropologist David Graeber. A critique of Eric Raymond's "Homesteading the Noosphere", which – I claim – misrepresents gift economies. Interesting tales of variant cultures that might better fit open source projects, if analogies must be made.

A comparison of how Monte Carlo analogies and software analogies played out. Plus: a suggestion that Galison's "trading zone" analogy in /Image and Logic/ has an important flaw.

Galison's definition of a scientific tradition is continuity over time of skills and technology, people, and standards of evidence. How does that apply to software? Some stories about the early days of both particle physics and Agile.

A brief episode. Thomas Kuhn’s 1962 book /The Structure of Scientific Revolutions/ was enormously influential. In /Image and Logic/, Galison argues that Kuhn was wrong because he was too focused on theorists.

Galison uses the metaphor of cultures meeting to trade to describe how, say, experimentalists and theorists collaborate. He describes procedures, machines, and diagrams as akin to pidgin trading languages.

Peter Galison's book, /Image and Logic/, has several themes. One traces the multi-decade competition between two traditions in experimental particle physics. I discuss how he thinks traditions work, then use that to investigate a failure of mine.

Imre Lakatos intended to give rules for when scientists would be *rational* to switch to a new research program. At this, he probably failed, but I think he provides good heuristics for how to *persuade* scientist-like people to make a bet on something new.

Episode one described the idea of “boundary objects.” In this episode, I interview James Shore as he describes how he’s used the idea in his own work as an old-school Agile consultant. Juicy descriptions of creating good-enough shared understanding.

Final episode on Fujimura's "packages": how the theory part of a package can cause harm. Interview with Elisabeth Hendrickson and Chris McMahon, who don't think jUnit and TDD caused harm. (Quite the contrary!)

Why did so many biologists shrug and accept the proto-oncogene theory of cancer, while most programmers rejected TDD – and rather fiercely? Using an idea from Richard Rorty, I suggest that (part of!) the reason is because two different kinds of theory were at play. Part three of a series.

What characteristics make a tool or technology successful? This is the second of four episodes on Joan Fujimura’s idea of “packages” for spreading theory and technology together.

The first of three episodes discussing how Joan Fujimura's ideas about technology and theory diffusion apply to test-driven design and other approaches to doing software.

Boundary objects are an idea from the sociology of science. They are about how people use ambiguous nouns – or things – to coordinate the work of people with different backgrounds and interests (like, say, programmers and product owners).