Constructivism
How Software Engineers learn
Since my first post on Coaching vs. Mentoring, I’ve been working on a follow-up. I’ve been digging deeper into the origins and fundamentals of mentoring. Etymologically, the term “mentor” comes from the name of a character in Homer’s Odyssey:
The word was inspired by the character Mentor in Homer's Odyssey. Although the Mentor in the story is portrayed as a somewhat ineffective old man, the goddess Athena assumes his appearance to guide young Telemachus in his time of difficulty.1
Ironically it was Athena in Mentor’s form, not Mentor himself, who proved to be the critical advisor at Telemachus’ time of need. Perhaps the moral is that true mentorship should rely more on a trusted relationship than a mentor’s identity.
While that could be an interesting idea to explore on its own, my research on the origins of mentorship didn’t yield much of interest beyond that takeaway. However, thanks to a particularly comprehensive book, I learned about a pedagogical approach that has surprising relevance to how Software Engineers learn and develop their craft.
Constructivism
In my research, I borrowed a few books from the Toronto Public Library2. I found one book in particular to be a detailed resource on the topic: the Wiley International Handbook of Mentoring. The book highlights the connection between mentoring and constructivism. To define the latter:
An approach to learning that holds that people actively construct or make their own knowledge and that reality is determined by the experiences of the learner.3
By its nature, mentoring takes a constructivist approach. Mentees construct their understanding in a self-driven manner, with the support of a mentor. This is in contrast to, for example, taking a course with a predefined curriculum, lesson materials, instructions, etc.
Constructivism resonates with how I initially learned to code. I’ve found that the most effective way to start learning Software Development is to simply start coding. Books on software have become far more useful once I’ve begun to understand the practice in my own way, by actually doing it.
Facilitated Play
Reading about constructivism led me down a Wikipedia rabbit hole where I discovered Jean Piaget, a pioneer in the field. I then realized that I’d heard of Piaget before. A few months ago, I listened to a radio interview which explored contrasting approaches in early childhood education. The following is a paraphrased excerpt from that interview on how constructivism could apply in this context:
Draw two parallel lines on the ground with chalk. Now children imagine it to be a road and their play develops around this. At one point, the play gets “stale” — you notice some children begin to lose interest. Now draw two additional lines, perpendicular to the first two. Their interest returns, as the children learn to handle an intersection. When the play gets stale again, add a stop sign. Some children are able to read the sign, or recognize its shape and meaning. These children then explain it to the others. Thus, they incorporate it into the game. In this way, the play is facilitated such that the environment is interfered with minimally yet progressively, so as to keep it “fresh” and focus the learning around the subject matter at hand.
This example of facilitated children’s play reminded me of how day-long workshops in software are organized. Let me walk you through some examples.
Global Day of Coderetreat
Coderetreat is a full-day event for practicing software development. Away from the pressures of ‘getting things done’, developers focus on and develop specific aspects of how they build code to explore good software development techniques. Developers work together to build code and share their experiences. Coderetreat uses a software problem with just enough complexity to create rich learning without overburdening the developers. By repeatedly building an implementation, adding additional challenges, and changing work partners frequently, Coderetreat is a framework for continuous learning how to build software better.4
The Global Day of Coderetreat is a day when software engineers around the world take part in one global, distributed, coderetreat. The universal starting point for the coderetreat is Conway’s Game of Life. Each satellite coderetreat then chooses additional constraints such as Object Calisthenics to keep participants engaged and learning over the course of the day.
The constructivist aspect of coderetreats is the minimally-defined set of constraints. There are no lecturing instructors, or lesson material to cover. Only exercises to follow (variations on implementing the Game of Life), and principles to keep in mind (such as the Four Rules of Simple Design). Participants fundamentally learn from their own experience and that of their partner’s (all coderetreats adopt a Pair Programming approach).
Hackathons
Several years ago, I mentored at a hackathon run by Ryerson University to help charities with their technology challenges. The hackathon kicked off the day with three charities presenting their top challenges to the participants, who then organized into teams to ideate and implement solutions. Real-world challenges faced by actual organizations helped to focus and motivate the teams over the course of a gruelling 24-hours (the hackathon’s time limit). On the other hand, the teams were open to explore solutions in an unfettered manner, as no constraints were set on the solution space (in theory, no code needed to be written by the participants).
Again, elements of constructivism are apparent in the hackathon format. Minimal constraints are set: the presented challenges along with a 24-hour time limit. Learning happens of its own accord — while solutions to challenges are implemented by the participants.
Wrap-up
I expected this post to be about the origins of mentoring. In my research, I stumbled upon the constructivist approach to teaching and learning. Consequently, I found a connection between this philosophy and how most of the learning in Software Engineering occurs (or perhaps should occur). I’m curious to hear what you think.
In a follow-up post, I will use the common context of constructivism to explore the universality between how children and adults learn.
If you live in Toronto, consider getting a library card — it’s free!