17. February, 2020
By Lars Kruse
The Full-Day CoDe Café is facilitated learning with peers and experts in cosy, relaxed ambience. It builds on the principles of situated-learning which defies traditional class-room training and emphasize actual learning over mere knowledge transfer. The CoDe Cafés strive to build communities of peers.
The purpose of the CoDe Café is to sustain learning in a community context - or even to establish such a community, if it doesn’t exist already.
This synopsis describes a specific format of this code café in a future setup.
Each instance of a Code Café is described in 5 Co’s:
The CoDe Café is bread from Situated learning which is a learning concept originally unfolded by Jean Lave and Etienne Wenger in 1991 in “Situated Learning. Legitimate peripheral participation”. It’s related to ”Constructivism” - the epistemological concept that learners construct knowledge - often credited to psychologist Jean Piaget. I first encountered this approach to learning when I studied Communication Theory at Uni back in the early 1990’ies through Donald Schoen and his book “The Reflective Practitioner” from 1989. As such the concepts which forms the pillars of the Code Café also has an undisputed reference to the concept of “Design Thinking” with its focus on problem framing and solution-focused thinking. And it’s worth emphasizing the relationship with Lean principles amplifying learning through continuous improvement, kaizen, value stream optimization and an overall holistic view of the situation at hand.
The name CoDe Café is deliberately spelled in CamelCase: with a capital C and a Capital D in CoDe. Although the CoDe Café concept was originally developed as an advanced type of hackathon inspired by the World Café conference/workshop format the word “code” is not referring to code in the meaning of a computer programming language, but to the term “Continuous Delivery” which is widely used in modern software development lingo, and which encapsulates two of the most prominent principles in Lean thinking: “Decide as late as possible” and “Deliver as fast as possible”
The context refers to the situation in situated learning. But it also refers to the café; the physical surroundings and ambience in which the learning takes place, as well as the actual collaboration tool stack that is used to enable the communication before, during and after the café.
The situation is constituted by a group of people, who have the same goal; to eventually master some technique, tool, approach or technology, and the means to achieve the goal is to apply whatever in question to a real problem.
The ambition to work on a real problem - as opposed to a simulated training situation - requires that the participants gets a voice early in the process and a chance to articulate and explore - exactly what is a real problem?
The café is a room or place that can accommodate the participants throughout the entire day, functions like:
It could actually be a full day occupation of a real commercial/public café, we have done that several times, or it could be some kind of private room restaurant or conference facility.
The collaboration tool stack should be simple and easy to use, yet effective and efficient.
A requirement would be some kind of Kanban board style planning program:
The board is used to organize the CoDe Café. The purpose of the board is to capture, describe, prioritize, estimate, log, organize and progress stories or problems. It’s main use is before and during the CoDe Café - and in-between café, if the intent is to run a consecutive series of CoDe Cafés
To support the Community, that we’re forming or extending we need a chat tool - could be one of:
The chat tool is to encourage community members to stay connected and continue joint learning, sparring and collaboration after the CoDe Café is over. But also for community leaders to have an established channel to communicate community initiatives.
If the knowledge domain of the CoDe Café is one of code - this time actually referring to a computer programming language - then the tool stack also includes a cloud hosted developer organisation with support for git repositories - could be one of:
Potentially with accompanying setups on related or supporting services (e.g. Circle CI, Docker, Cloud infrastructure providers…)
The content is the problem, or the problem-framing, or the domain of knowledge, in other words it’s the subject of the learning - the technology, approach, method or tool that the CoDe Café should facilitate learning about.
Through a series of interviews or questionnaires prior to the CoDe Café, each participant has been approached and encouraged to give a contribution to what might constitute one or more real-life problems or challenges as seen from their perspective.
This is an important part of the preparation, and an important part of why a CoDe Café is different from traditional education. The facilitators and masters/experts of the CoDe Café are expected to be so skilled, that they can facilitate or contribute to the solution of any domain related problem.
The CoDe Café is a workshop, that shall generate immediately actionably value to the participants. Each participant should be able to state something like: _”before the CoDe Café, I wasn’t able to do
The focus is on learning - not knowledge.
That’s why the content is not structured in chapters around what the instructors knows - but rather what the participants defined as problems and therefore need to learn.
Throughout the day the CoDe Café will utilize different methods, exemplified by, but not limited to:
All of the above mentioned techniques strive to provide learning through problem solving as well as insights through dialog, specifically to the problems and challenges the participants defined themselves.
The community represents the knowledge to which the learning applies. It’s formed by an arbitrarily large group of people, connected by a common interest in the domain.
The community is defined by the behaviour, events and actions that are performed. A silent community is essentially just a bunch of people, that doesn’t do anything - unless the community generates noise, it isn’t really a community.
A community needs a voice, and it needs to be facilitated, in Open Source tradition we sometimes refer to A Benevolent Dictator (BD) Governance Model - specifically referring to how one of the most successful and productive communities in the world succeed to stay productive: The Linux project.
A prerequisite for engaging and facilitating people is that they are connected and reachable - that is why we need a tool like Mattermost, Slack (or even LinkedIn of Facebook in the lack of better).
In a community, the participants should have a natural incentive to stay included in the community; they get access to “the wisdom of the crowd” to ask and answer questions regarding the domain is sometimes enough, but in young immature communities, which may even be geographically scattered it can be a real challenge by it self, to form and nurture a community to be self-sustained.
Techniques to build the community could be occasional meetings, like meet-ups, drink-ups, online “office hours” (regularly scheduled video room - or chat room meetings led by the BD of the community).
If the community has a beneficiary (sponsor) then organizing free or cheap community events where trusted lieutenants (also refers to the Benevolent Dictator Governance Model) and devotees get to meet hang-arounds and prospects. The purpose it to put faces on a crowd of “the usual suspects” that will eventually form relations, friendships, working relations, initiatives in the context of the community.
Which in turn will strengthen it.
The group of people and companies who initially put something into either the Community (the actions that act like glue to the coherence in the domain ), the Content (the Problem), the Context (the learning) or the Concept (in this case the CoDe Café concept).
For each CoDe Café you should Identify:
As mentioned, The CoDe Café concept was bread from a combination of a hackathon and a World Café - two pre-existing - but completely unrelated - concepts.
We first executed a CoDe Café in the context of a developer’s conference (Jenkins Community) I took the initiative to organize. As organizers we would like to invite to a pre-conference meetup where we would like to hack code, but with the intended goal to establish learning and without a specific agenda to meet on - facilitating the learning, rather than defining it. A workshop format lending from the World Café format.
Since the first introduction to the Jenkins Community it was executed multiple (20+) times, continuously improving and optimizing based on participant feedback and strengthening of particular learning aspects.
At some point the CoDe Café concept was expanded into the concept of a CoDe Camp - the same conceptual idea, but extended to a two-day event, and the café concept extended to a refugium with, dinner, lunch, breakfast, training, presenting and socializing all located at a conference-hotel with focus on the ambience of the place: in natural surroundings, checking out of the high-paced metropolitan surroundings.
The CoDe Camp concept was executed at more than 10 occasions both as an half-yearly internal conference format in a 50+ employees consultancy bureau scattered across 7 different geographical locations in three countries. And in an almost similar format to gather the CoDe Alliance, an informal alliance of ≈15 companies, who met half-yearly to develop common roadmaps to joint exploration and joint development of Continuous Delivery and DevOps related tools, extensions, features, methods and concepts.
As part of the same evolution, the concept was brought forward to a CoDe Academy - a four-day intense, hands-on training programme offered pro-bono to students in computer science related studies. It was executed at some of the most prestigious Universities in Copenhagen, Trondheim, Aarhus, Odense, Oslo, Gothenburg. The purpose was to introduce the Domain Knowledge of Continuous Delivery, programmable infrastructure and DevOps to computer science students, based on the analysis that these disciplines were not part of their university curriculums.