The journey of discovery
An inclusive method for helping impart my knowledge
An inclusive method for helping impart my knowledge
If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea. — Antoine de Saint-Exupery
I love the spark of knowledge. That moment of understanding, where we’re able able to suddenly make sense of something that we weren’t before; to build and transform the mental lego castle we’ve been studying. The transition between not understanding to understanding is a unique moment, and one I get to experience regularly.
I have been studying the field in which I work for ~5–6 years now, and have managed to accrue some amount of knowledge along the way. I find the longer I remain in the industry, the less I am myself attempting to resolve some issue or other and instead helping others with particularly gnarly issues that they’ve run up against. In many cases they’re issues that I’ve also hit before, and found some resolution that I can pass along.
Passing on knowledge
It’s perhaps useful to define how I mean “learning”. I am reasonably good at remembering wrote data; if I do not remember it directly, I write it in some sort of easily accessible medium, and keep references to that medium in my head. However, it is not this sort of rote learning that I find retains much value.
To me, learning happens when I’m able to make some sort of prediction based on my knowledge. For example, I can make a reasonable guess that 61 is a prime number out of my memory, and some quick mental calculations. However, more recently I’ve been learning about “Fermat”, the modulo operator and some other weird kinds of math. This allows me to put this prime number into context, to conjecture more about the nature of primes and begin to understand their value in cryptography. At the time of writing, I am on the journey myself to learn more about this topic — but it’s one that opens up a new mental capacity to understand and transform these numbers.
It is this mental transformation that I also want to evoke in others, rather than to be able to supply a given problem with a given solution by memory.
Setting sail on a journey
The knowledge I have was all largely accrued in the same way I am learning about math; it’s a journey of discovery, reading and rereading many different topics from different people.
To pass on knowledge that I have, I also need to invite others on the journeys that I travel, and to start them over some of the same seas that I travelled. This invariably starts from some known territory, where I will explain what I know and how I got there. But I will try to limit my own explanation as much as possible, instead stating the questions that I think need to be answered, and starting us together off on the journey to find the answer to them.
Amusingly, it regularly turns out the things that I thought I knew I did not, and what I knew was wrong. The answers to the questions I pose change over time, and it’s regularly the case that my learning partner and I discover new, and interesting answers to the earlier posed questions. They invariably evoke more questions, and we travel on this mental journey together for a period.
At some point, it will become the case that it’s better to direct the direction of the journey less and less. While invariably I usually sure at the answer we will arrive at, the goal of the exercise is not to supply that answer but to point my learning partner in the direction, and allow them to discover this answer, or another answer that is just as good themselves.
I progressively become more the passenger of this journey, and my learning partner the steerer. At some point, I will give away control entirely, and the learner is responsible for their own answers, and own outcome.
Making metaphors concrete
The above metaphor describes the approximate shape of how I will try to bring about learning in others, but does not go well into detail as to how to do this on a day to basis. There are a few things I would hope to express that may make the above easier to understand:
Teach by asking questions
The goal of the teacher is not to pass on knowledge directly, but to understand the gap between the learners knowledge and the teachers, and create a set of questions that will lead the learner to a given answer.
This means asking setting learning outcomes that are within the learners capabilities, but in the general direction of the desired goal. In the case of learning Kubernetes, for example, it would be something like:
Installing Docker: Let’s get this NGINX container working!
Using some pre-compiled docker setup: Can we get this project working on your machine? Oh! It doesn’t work? Let’s do some Googling!
Finding some bug in this setup, and fixing it: Ah! It looks like the database fails to update. That’s interesting. Let’s find out why!
Shaping the design of this docker setup: We have a new project! Let’s work together to fit it into containers
Deploying this docker setup on Kubernetes within a strictly defined framework: We need a new documentation service! Would you like to implement it?
Finding bugs with this framework: We need to implement backups for this service. Can you see if you can see how that works and implement the required changes?
Defining the entre framework for a project: We need to migrate ${PROJECT} to Kubernetes. Do you want to be responsible for this?
Finding bugs in the Kubernetes project itself: Hmm it looks like this container doesn’t start on
node-01. Can you look at why?Finding bugs in the Linux kernel / Docker: It looks like the container from
build-12890ddoesn’t work. Can you look at it?
This is a fairly hierarchical path of learning, and in each case it requires an increase understanding. But the jumps in knowledge are not super large, and at each stage the learner is able to contribute value to the organisation, rest and consolidate their knowledge before taking on the next challenge.
Giving away correct answers
I have been surprised an almost endless amount of times by the conclusion that fellow developers reach. However, it is not my role to be the arbiter of what seems logically correct. I will challenge the logic of a colleague, but if it seems sound and internally consistent, even if I do not understand the solution I will approve it.
Our paths to our answers are all different, and it stands to reason our answers to the same problems will also be different. The difference is good, as it means the team is diverse in its knowledge and that it’s possible to have discussions about the strengths and weaknesses of a given approach.
Allow Mistakes
Perhaps the most difficult of all the ways in which I try to allow people to learn is to let them make mistakes that I can see coming. Often, there is a particular set of knowledge that I’ve not been able to communicate across, and a learner will implement a solution that I will see a flaw.
If that flow is not going to put the security or stability of systems at too greater risk, I will allow it, and let the learner discover the limitations (or not) to ther design themselves. This sort of concrete feedback is the most valuable learning tool; far more so than any sort of guidance that I could provide people.
In Conclusion
As we grow and develop as a development team, it’s inevitable that we spend a progressively larger amount of time passing our knowledge onto new colleagues and partners. By taking some time to be deliberate about how we pass on this knowledge and to try and optimise our delivery we’re able to accelerate the rate at which that knowledge is used, and reduce the pain that our colleagues will have to endure to be as effective as possible.
Additionally, by knowing ahead of time that we are not the stewards but the partners of others intellectual journeys we build in them a facility to succeed or own knowledge, or to develop their own but equally successful mental toolkits.
I do not always succeed at doing stepping back, but I think it’s useful as a mechanism to pass knowledge across.