Chris Jarling

I recently was the onboarding partner for a new team member at work, which means I'm showing them around and are the dedicated person for them to ask any questions. This experience made me think about the other times in life where I did teach people something: The times I worked with less experienced developers, the times I was an assistant at university and gave courses for students or the times I wrote about my learnings on this website. It made me realise why I enjoy teaching: Because I always learn something in the process.

This is not a new insight. Learning by teaching has proven to increase the understanding of a subject in students. Einstein said if you cannot explain something simply, you did not understand it (and in order to teach someone something, you have to be able to explain it in a simple way, at least initially). Or take this quote by Joseph Joubert:

To teach is to learn twice

All of this points in the same direction: In order to teach something effectively, you have to obtain a thorough understanding of the matter. Or, in reversal: In order to obtain a thorough understanding of something, bring yourself in a situation where you have to teach it to somebody. You don't even have to actually teach it so someone. It's enough to you pretend you are. I think in the case of this blog, I'm often times pretending to be teaching someone, because for all I know, nobody is reading this. And it definitely works.

I think our school system did enough damage to me to have a negative associoation of the word "teaching". When I think of it, I think of a power disparity and one person forcing the other to do what they want or else. This is not what teaching actually is, and it's important for me to write this down: Teaching is the transfer of knowledge from one head to the other.

I also think there is a distinction to be made between onboarding a person and working with a less experienced person in your field. Onboarding someone is vague. It's a lot of implicit knowledge that has to be shared. We all aim to have good documentation, but in every company I've worked in, this was an unreachable goal. There always was an effort to document everything, but we always fell short of our goal. I think that's okay. It's a byproduct of a company moving and changing.
However, that means that the knowledge that is transferred during an onboarding process, to some degree, is implicit and exist only in the heads of people. That makes the process harder for the new joiner and the person onboarding them, since sometimes you can't point to a resource that explains what you talked about. There is a lot of trust involved from the start.

The result is a difference in what I learn as the onboarding part. In general, it's one of the following:

• The new team member has a question I know the answer to, but I could not find the answer written down anywhere. Documentation is missing and should be added.¹
• The new team member has a question and I can not give a brief and percise answer. I do not fully understand this area myself and need to look into it. I like doing this together with the new team member, it's a nice experience to learn something new together.

When writing here or working with less experienced people, things are a little different. I never made up a new programming paradigm or created a groundbreaking algorithm. That means in almost every case, there is documentation available for what we are talking about. This can be actual software documentation, or a blog post or a video. It can be as little as a code snippet in a gist. But there is always reference somewhere that can be checked to challange what I say. So one learning that frequently happens is uncovering my false understanding of something. It's easy to say "Look, you just said X, but looking at this resource, it clearly states Y". Very straight forward (but sometimes hard to accept – which is a different exercise).

Another learning that happens in this constellation is identifying holes in my understanding. It happens that the other person asks a question that I do not know how to answer, either at all or in a satisfying depth². Writing things down here is more extreme even. If I can't write them down I don't know them. This is what this website is: It's a reference, yes, but it's also always a test of my knowledge and my understanding of what I learned.

This post is no different, by the way. It's me trying to explain the concept of teaching to learn.

Footnotes

1. This should be done by you directly, because it will be forgotten otherwise ↩

2. In this situation, please admit that you don't know and either come back with something or find the solution together. Do not pretend you know because you feel like that as the "teacher" you have to. People will notice and it provides no value to anyone ↩