These are the transcripts of the final series of Programmers’ Stone talks. When used as part of a stimulating work environment with good technical leadership, they can produce a step function in programmer usefulness. However, when the team is part of a larger organization, a peculiar hostility will develop towards the team, which will eventually prevent it from functioning.

I now argue this hostility is caused by a mismatch of the stress level of the team and the organization. By destressing, the team falls out of step with the “dopamine economy” where people help each other maintain their addictive stress levels by providing stressful exchanges. The talks really just work by stimulating the students’ juxtapositional faculties. The mother hen aspect - providing good reason to be self-confident - was also going on at the same time, and without that the talks will not stimulate juxtapositional thinking, because the team will not be in a neurological state to access it. Until the neuroscience connected up, it wasn’t possible to state that pre-condition.

The original talks didn’t refer to the addictive loop of stress and dopamine. Instead they were descriptive, and talked about two observable cognitive strategies. The true human normal strategy with juxtapositional thinking is mapping - building interconnected mental maps. The state which is restricted to focussed attention and has an unhealthy fascination with proceduralism, is packing. Notice that the whole point of doing the talks was to help people who are packers become mappers. It is now much clearer that everyone is born a mapper, and it is only ever a matter of regaining mapping.

The Programmers’ Stone

Hi, and welcome to The Programmers’ Stone. The purpose of this site is to recapture, explore and celebrate the Art of Computer Programming. By so doing we hope to help the reader either become a better programmer, understand what less experienced programmers are struggling with, or communicate more effectively with other experienced programmers.

We know from work with individuals that by doing this we put the fun back into the work and greatly extend the boundaries of the possible, so building much smarter and stronger systems.

The present structure is planned around an eight day course, delivered two days a week for four weeks. Each chapter corresponds to the course notes for one day’s material. The eighth day should be free discussion, so no prepared notes, meaning that there are seven chapters.

We’d very much like to hear from you!

Alan & Colston

alangcarter (at) gmail (dot) com
colston (at) constructiveconversations (dot) com