I recently TA’d a workshop Intro To Functional Programming With Elixir given by a co-worker. Not only did I want to help them out, I also wanted to support someone teaching as they learn, and learn something myself.
Over the past 6 months I’ve begun learning backend (via Elixir) in the way I’ve learned pretty much everything I know as a developer, by doing. Having a practical learning background means that I’ve started out in complex environments that offer a lot by way of example in real, production code — but it also means that there can be a lot of unknowns that remain along the way. The specific black box addressed in the workshop: the difference between functional and object oriented programming.
In most intros to Elixir this gets touched on at least in part, it being a functional language is one of the main attractions, but as a developer without a traditional CS background, I missed the lesson on what object oriented programming means, so knowing and leveraging the differences was beyond me. Something I really admire about my co-worker and all teach-as-they-learn instructors is the act of stepping up before feeling you’re on solid ground. It’s easy for me to eschew an instructor role for the usual reasons, telling myself “there are so many people out there who know more than me,” and “not knowing the material perfectly means I shouldn’t be explaining it to any one else.” In so many ways these mantras continue to feel true for me, but there is one caveat: they are less true in the programming world. The reality is, as programmers, we are all learning, all at the same time. If someone sits down to pair with you, they are coming to the problem the same as you. They might bring along a larger reference catalog with them, but they are still looking at, understanding and working at a problem just like you are.
In this workshop, my co-worker had a bunch of TAs in the (video conference) room, many very experienced engineers. As my co-worker went along through the talk, they allowed space for others to jump in if anything had been muddled or could use extra explaining. The majority of the time, they listened quietly along with everyone else. This was a brilliant, if somewhat intimidating setup. Shoot your shot and if there are any hiccups, there are other people around to catch them and fill in the blanks.
During the course of the lecture and in the subsequent breakout lab I found myself right in the middle of the road. I had a lot of questions, a lot of things I still didn’t understand, but I also was eager to help others who were earlier along in understanding concepts I had a better grasp on. Even things I did know, I was able to confirm them or learn new aspects to them or new applications. Even some simple things I hadn’t noticed before like syntactic indicators of functional programming made their way into my head and into an Elixir module talk I was soon to give for the second time.
I love practical explanations and drawing comparisons between concepts. I’m sure this is because of my learning experiences coming into development as I have. I’m still working on coming out of my shell on things I don’t know and filling in the education gaps as I work full time and jump into programming worlds that are new to me. One thing I’m beginning to understand more is how much avoiding teach-as-you-learn can be a real lose/lose. By the time you have a better command of a subject, you’re not as involved in the learning process around it. That means not only am I passing up an opportunity to learn and to do so in a more comfortable environment among peers where making mistakes and asking “dumb” questions feels less scary, I’m also less likely to pass on what I know and help someone else out. All this to say that I was inspired by my co-worker and the experience allowed me to rethink how I approach learning and how I could be more gratifyingly involved in teaching and improving with others.
Header photo by NESA by Makers on Unsplash
