00:00:12.090
For our first talk, part of our job as engineers while we advance in our careers is to understand that we need to teach and share knowledge. It's not as easy as it seems because I know that I might have the knowledge, but that doesn't mean I can teach it to someone else. At least in my personal experience, it might get a little bumpy. You might think you know something, but believe me, you don’t know it until you try to explain it to someone else.
00:00:20.740
So, Betsy Haibel is going to come to our rescue today. She’s going to tell us about some educational techniques, specifically "dialogic teaching" in her talk "Teach by Learning; Lead by Teaching." Welcome, Betsy!
00:01:20.970
So, good morning everyone, and welcome to "Teach by Learning and Lead by Teaching." I’m repeating this so that the recording can pick it up. Today we’re going to be talking about an educational practice called dialogic teaching. As Monica mentioned, we’ll discuss how to use its principles to work more effectively with developers of all levels. This is not just about teaching newer developers; it’s also about convincing developers who are on the same level as you.
00:01:35.230
These concepts are similar in practice, and I want to start by explaining why this talk is important to me. I founded my own company a year and a half ago, but in the job before that, I worked at a financial technology startup where about half of our developers were fairly new to programming.
00:01:59.320
Now, a lot of you are probably wincing right now and thinking, "Oh my god, that’s so many junior developers; that sounds like a disaster!" But it wasn’t. In fact, that company outcompeted a startup with easily twice our staffing and funding levels for all kinds of major contracts, including a contract with one of the largest banks in America.
00:02:20.740
If I were an arrogant jerk, I would credit the outcome to my brilliant contributions as the startup's principal architect. However, I prefer to be self-aware and honest. My job as architect wasn’t about having all the brilliant ideas; it was about making sure that everyone else’s brilliant ideas fit together into a coherent piece of software.
00:02:38.470
Let me assure you, these brilliant ideas came from developers at all levels. A few months ago, I was getting dinner with some folks I had worked with at that company, back when they were junior developers. Trust me, none of them is in that junior category anymore.
00:03:05.200
After a few beers, one of these developers got a bit sentimental. He started talking about how he was really happy to have worked with me. He said I had never made him feel worthless just because he knew less than I did. This felt really awesome at the time, but later that night, as the beer wore off, I started to feel really mad. My friend said that like it was something that made me special, which meant that a lot of people had made him feel worthless before.
00:03:29.080
As a profession, we are terrible at helping other developers get better. We have a tendency to be condescending. This is bad on its own, but it also means that we don’t teach effectively. This is a talk about dialogic learning. Dialogic education was pioneered by Paulo Freire, a Brazilian literacy educator who began his career in the 1940s. In 1964, after a military coup, Brazil’s new dictator exiled Freire because he was teaching his students to think as well as to read, and military dictators tend not to approve of that.
00:04:05.609
In this talk, I will apply some of Freire’s theories to developer education. However, taking these theories out of their original context does dilute them, and I want to issue a disclaimer. When white people like me from wealthy countries, such as America and Germany, take other people's work out of context, it often transmutes into god-awful hippie nonsense, which is disrespectful and makes the ideas less effective. I encourage you all to read Freire’s work directly. I'll warn you that the English translation is dense and difficult to read, possibly because of the book rather than the translator.
00:04:36.360
Now, instructors trained by Freire wouldn't start by teaching people reading; that's the really interesting part of the method. Instead, they would ask people about the words they use every day. Instructors would use discussions about words to learn about the lives and subcultures of the people they are working with and facilitate open-ended discussions with students about how the words they use influenced their thoughts.
00:04:57.270
This little literacy let learning how to read words, as well as speak them, become a vital and relevant topic. It was connected to their ability to figure out the world around them, rather than being imposed on them by a social worker from afar. By starting off by showing respect for the people they taught and connecting their experiences to the material they were trying to teach, they could teach incredibly effectively.
00:05:30.270
Before Freire’s work was stopped by the military junta, he had developed techniques that let illiterate adults learn to read and write in only 45 days. Before we dive into the hows and whys of bad developer teaching, let’s look at the other side: the hows and whys of effective learning.
00:05:58.480
There are a lot of reasons someone might want to learn something. Maybe they want to pass a math test or get a job as a computer programmer. But maybe they just want to go to a museum and learn about dinosaurs because dinosaurs are awesome. The biggest reason we learn as adults is different than when we are younger. We learn things because we suddenly realize we need to know them. The British feminist scholar Natalia Sidar calls this phenomenon "emergency learning." Emergency learning is the learning you do because you suddenly discover there's something you really need to know.
00:06:39.470
Most of us learn how to unclog toilets on an as-needed basis. Day to day, as developers, we practice a lot of emergency learning—like when we open Google to figure out why our specs are failing, or when we frantically skim the Postgres docs, hoping to find an index type that will simplify a query. Or when we look at example after example of form elements’ styling on CodePen, searching for a way to customize select boxes.
00:07:11.830
A lot of these examples imply that emergency learning is always short-term, but I want to emphasize that it isn't necessarily true. Natalia Sidar coined the term when discussing how women have to learn to understand the patriarchy. Emergency learning is understanding how sexism affects us, but this understanding is a lifelong process.
00:07:45.280
Someone could realize they're bad at databases and set a project for themselves to get better at SQL. Alternatively, someone might recognize their front-end skills are weak and say, "I know, I will learn React." These aren’t short-term projects at all; these aren’t the kinds of projects you can solve just with a quick Google search. But these projects still count as emergency learning.
00:08:11.440
Emergency learning is characterized by the fact that it happens in response to a need. Practicing emergency learning means being in a reactive mode, which narrows your focus. If someone decides, "I'm bad at front-end development; I will learn React to fix this," they won’t necessarily seek out front-end resources unrelated to React. The focus becomes solely on how to learn React, rather than approaching the problem in a more holistic way.
00:08:40.560
It’s important to note that while this focus can be limiting, there’s also a real problem underneath it. Whether it’s React or that clogged toilet, preparedness is key. When most of the developers we are working with are practicing emergency learning, they generally have a goal in mind that stems from a real problem they are experiencing.
00:09:18.194
When we teach people new information about programming in the abstract, we may feel we're helping them, but unless that information directly connects to their goals, it might not come across as helpful. Instead, it may seem like we're teaching random things that aren't connected to the problems they are trying to solve. This assumes that the other person wants to be taught, and often they might have a different goal in mind.
00:09:45.860
Many of you may know of Avdi Grimm, known as the Ruby Tapas guy. He shares a story about a time at RubyDev Camp, a small conference in America where about 70 developers go into the woods for three days with no internet. The first day of Dev Camp is always a code retreat; that day, developers do six pairing sessions with different developers, usually working on the same problem—traditionally, a version of Conway's Game of Life.
00:10:10.840
During one pairing session, Avdi guessed that his partner was more junior than him because he's the Ruby Tapas guy, and he assumes he knows everything. A big part of Game of Life involves figuring out whether one cell in a grid is a neighbor of another cell. Avdi had a standard solution for that part of the problem, so when he and his pair got to neighbor detection, his pair started frowning at the screen.
00:10:47.780
She began deleting and retyping the same function several times. After offering to share his standard solution, her response was, "Okay, but let me try to get this version to pass the test first." So Avdi started sketching out his usual solution on a piece of paper, typing and sketching away.
00:11:12.780
After five minutes of going through this process, he looked up to see a beautiful solution on the screen that he had never seen before. This situation was interesting because they were both working separately instead of collaborating. Avdi had made assumptions about their relative skill levels and roles that distorted the pairing.
00:11:49.170
What’s important to recognize is that the person you’re pairing with always brings different experiences, skills, and contexts to the problem. No matter how junior they are, you can learn from them. This is a two-way process. In the rest of this talk, we're going to explore what this means when working with developers, regardless of their skill level.
00:12:33.290
To facilitate this discussion, we’ll make two arbitrary divisions: one focused on working with early-career developers versus those who are at approximately the same level, and the other focused on teaching new things versus encouraging better practices. We’ll start with teaching new things to early-career developers.
00:12:55.970
New developers need to learn things, so we screw up all the time. We center our goals, go into teacher mode, stop listening, and start asking lots of condescending, leading questions. We may even get frustrated and grab their keyboard, knowing we're not supposed to do that. Instead, we may become passive-aggressive when they make mistakes we don't like.
00:13:21.890
Our goal when working with early-career developers should not just be teaching them mechanical skills, like how to create mock objects in RSpec, as they can read the docs for that. We make it about ourselves when we say, "I know this thing that you don’t," which doesn’t help junior developers become better thinkers in computer science.
00:13:39.680
We can only do that if we treat them as their own person with their own goals. They may not code as well as we do yet, but they are still valuable. It’s crucial for us to avoid automatically entering teaching mode when working with new developers since that reinforces existing power dynamics.
00:14:03.660
This can push any good ideas the other developer has out of the conversation. If you’re teaching, the information tends to only go one way, turning discussions into monologues rather than dialogues. It instead focuses on how awesome you are for knowing things instead of empowering the other developer to solve the problem you are both working on.
00:14:36.770
If you think a developer may be less skilled than you, start by figuring out their actual skill level unobtrusively. This process will also benefit you by helping avoid incorrect assumptions. There are effective and respectful ways to assess someone’s skill level.
00:14:59.150
Pay attention to what they are doing. Read their pull requests and watch them code. Doing this gives you insight into their approach, how much experience they have, and allows you to avoid making incorrect assumptions about their knowledge. Asking their opinion about things will also tell you a lot about what they know and understand.
00:15:30.730
When working with a newer developer, behavior-driven development or similar methodologies can be very helpful. When working with fast feedback loops, it’s useful because it forces us to work on one small chunk of a problem at a time.
00:16:01.900
This helps us break down the problem so that when someone is learning something new, they don’t have to process a lot all at once. Keeping the problem small allows them to tackle it on their own. This way, you can act as a walking textbook, and they can ask reference questions. This keeps the interaction collaborative and focused on solving the problem.
00:16:26.610
There will be times when they get stuck. This is true for all developers, not just the newer ones. When this happens, help them refine their next step into a manageable task so they can tackle it better. When you want to guide your pair in a specific direction, treat your opinion as your own perspective rather than the absolute truth.
00:16:57.510
Use phrases such as "Here’s how I usually do it," or, "I’ve had bad experiences with this approach, so let’s not spend too much time on it, just in case it doesn’t pan out." You should also acknowledge your own mistakes and ask for their help when navigating those mistakes.
00:17:23.390
Remember, junior developers often lack confidence because they may perceive that the code senior developers write emerges fully formed. This misconception leads them to believe their confusion stems from their own lack of ability, rather than the complexity of the situation. Letting them blame themselves for your mistakes can be detrimental in the long term.
00:17:47.050
They will learn to hide their own mistakes, which ultimately makes them worse developers. To combat this, you should openly call out every typo and misstep you make, explaining decisions made and changes in direction. This honesty will clarify to the junior developer that you're responding to external stimuli, rather than making code happen by magic.
00:18:11.530
Now, there are certain situations where it’s acceptable to switch to teacher mode. This often happens when someone struggles with something that shows they know what they want to do, but don’t yet know how. One big indication is when they repeatedly tweak the same few lines of code in a circular manner.
00:18:34.910
In these instances, ask for permission before teaching. A simple phrase like, "Can I show you a trick?" gives you a chance to use your expertise to aid their learning without creating an uncomfortable power dynamic.
00:18:57.820
Sometimes, when working with a junior developer, they may express discomfort with a technique you're using. It’s easy to think, "Oh, they don’t know anything and perhaps I should go into teacher mode." However, remember that your aim in this interaction is not just to create beautiful code; the goal is to create code that you can both maintain.
00:19:21.900
Your pair is the best authority on what they can comfortably maintain. If this means your code will be a bit more repetitive, that’s okay. As the more experienced person, you have the capacity to adapt to different coding styles, which is a responsibility you carry.
00:19:46.860
Also, question whether you might be overengineering. A junior developer's confusion could stem from your own code being overly complex, rather than them genuinely not understanding.
00:20:10.820
The most important thing to teach a newer developer is not the material itself but technical judgment and the confidence to trust that judgment. To build that confidence, present your opinions as opinions, acknowledge mistakes, and actively engage with the feedback your pairing partner gives you.
00:20:35.150
You can’t learn how to persuade your peers to implement practices you believe are better until you learn how to teach them new concepts respectfully and safely. In the end, teaching developers is not only about instructing junior developers; many of the techniques that benefit newer developers will serve you well with peers as well.
00:21:02.070
However, there are differences to keep in mind. Experienced peers already know many things, and they will need to learn newer things simultaneously. This distinction is crucial because when someone is put in a position where they have to learn a lot of new things at once, they often struggle to grasp the problem, as most of their cognitive load is taken up by what they don't know.
00:21:24.850
The relationship you have with a peer developer might give them more opportunities to feel offended, assuming they don’t know something they actually do. Instead of assuming a lack of knowledge, ask, "How much have you worked with this technology?" to gain a better understanding.
00:21:55.700
Developers who have been in the industry for a while often develop habits and opinions about certain technologies. As you teach them something new, they'll evaluate it based on their previous knowledge and experiences. It can lead to preemptive conclusions, often negative ones, where they dismiss an approach because it's different from what they already know.
00:22:24.480
If you notice a peer jumping to conclusions, instead of rebutting those conclusions, ask about the reasons behind their opinions. Their responses can provide you insights into their values regarding coding and what their goals are when learning something new.
00:22:51.320
Helping them find a path towards accomplishing their goals, while keeping their comfort with writing good code in mind, will enhance their understanding of the value of this new knowledge. Understand that sometimes their code will not align with your stylistic choices. Your responsibility is to model teamwork and collaboration.
00:23:17.400
Recognize that learning something new can be intimidating for experienced developers, who are used to feeling in control. They may revert to the same feelings that junior developers often experience. If you're teaching something that requires changing fundamental techniques, it can be particularly daunting.
00:23:39.770
In those situations, it’s essential to exhibit empathy. Adapt your methodology to support their learning process, allowing time for them to engage with concepts they're more comfortable with while gradually introducing new material.
00:24:01.070
Sometimes, frustrations can arise when you feel like the developer doesn't appreciate the approach you're advocating. In such cases, it’s helpful to reflect on whether your values align with the learning objectives of the project. Consider asking yourself if the aspects you value about your approach matter to the project’s goals.
00:24:19.640
When working to propose a new practice, like a new API design or a new pattern, remember the importance of a respectful dialogue that encourages open discussion rather than forced compliance. The aim is to engage in a cheerful exchange about the benefits of a new approach.
00:24:43.720
Rather than dictating, clarify how this new technique could better serve the current project compared to the current methods. Demonstrating respect for their input while fostering an environment where everyone can contribute is essential in achieving effective teamwork.
00:25:05.480
Knowledge among developers isn’t a continuum, and it’s made up of different aspects. My business partner Jennifer has outlined a framework for understanding breakdowns in communication between developers.
00:25:14.900
When communication falters, it could be because someone misunderstood your message, disagrees with you, or perhaps they agree with you in principle but aren't willing to implement your suggested approach.
00:25:36.120
When discussing best practices, it’s easy to assume misunderstandings and conclude that individuals disagree because they don’t understand. If this happens, it can lead to an inclination to double down and explain again with the hope that it will resolve the disagreement.
00:26:00.110
But if they have previously tried your approach and did not find it beneficial, you may need to reevaluate your stance. This doesn’t mean you're wrong or they’re right, but it underscores the importance of actively listening to the concerns they express.
00:26:31.770
Don't respond to their concerns too quickly; instead, work with them to navigate those issues together. Through this process, you are likely to explore solutions that nurture the concerns they've elucidated because they will be engaged in solving those specific problems.
00:26:49.960
This leads to an investment in the solution they've created since it was developed based on their own concerns. Collaboration not only fosters buy-in but can also identify nuances you may have previously overlooked.
00:27:14.520
Let’s return to the situation of introducing TDD into a Rails project that hasn't previously utilized TDD practices. Sometimes failures arise because Rails has inherent difficulties in integrating TDD, leading to frustrating experiences.
00:27:41.090
There may be technical reasons hindering the implementation of your solution, so collaborating with your partners can unveil the reasons why your methodology may not fit into the existing framework. Many times while working with developers, they might point out challenges you are blind to, and these conversations can lead to better understanding and synergy with the team.
00:28:02.780
We’ve discussed several areas: teaching early-career developers new concepts, teaching peer developers new things, encouraging better practices in developers, and motivating early-career developers to adopt best practices.
00:28:21.050
The secret to teaching newer developers better practices lies in giving them the exact same space and respect you would afford a more experienced developer. Sometimes you may need to give them more context to understand why adopting a best practice is beneficial in a given scenario.
00:28:49.440
Nonetheless, the core lesson to teach newer developers is not any one specific technique or best practice. The focus should always be on developing their technical judgment and helping them cultivate the confidence in trusting that judgment.
00:29:17.060
To foster that trust, you need to exhibit confidence in their abilities as well; if you’re not convinced about the superiority of the method you’re trying to teach them, it's essential to recognize that there may be valid reasons for their skepticism.
00:29:40.720
With that said, I am Betsy Haibel. You can find me on the Internet at various platforms and also learn about my company, Cohere, which specializes in development consultancy focusing on engineering education.
00:30:01.680
In conjunction with Octagram, we’ve released a course titled 'Mastering the Object-Oriented Mindset in Ruby,' focusing on applying object-oriented techniques in Ruby on Rails applications. We are also in the process of releasing another course called 'Untangling Asynchronous JavaScript,' which we recently completed filming for.
00:30:19.880
Thank you for your time! Are there any questions?
00:30:39.520
Hi, I loved your talk and have a question about how to handle interactions with individuals who have a challenging mindset. For example, what if they think they already know a lot or are not patient at all?
00:30:57.210
The sharp realization here is that jerks will be jerks, and you can’t change that. Instead, you can only try to cope. In the process of coping, sometimes introducing your ideas in a way that seems unobtrusive can help. You might pretend to let them have their way, which may feel against your principles, but it can be effective.
00:31:14.600
Sometimes, you just have to ask yourself if you’d rather be right or get your solution in place.' Thank you!
00:31:29.260
Thank you for your talk! I have a question about the connection between the beginning and the later parts of your talk. At the start, you mentioned context, yet I feel there should be a third dimension related to existing biases, especially with interactions among more senior and junior developers. This is crucial when working with underprivileged individuals.
00:31:56.210
You raise an excellent point. My talk about pairing with people who don’t look like you touches on many of these important aspects. There’s a difference between knowledge and an individual’s unique experiences, and it’s essential to recognize that everyone's contributions can be valuable regardless of skill level.
00:32:26.210
In my experience, modeling different communication styles—those that are more collaborative—can disrupt traditional dominance-oriented conversations. It’s worthwhile to embrace the contributions of underrepresented individuals without undermining their expertise, creating spaces that celebrate diverse perspectives.
00:33:11.950
Thank you for that! Now regarding remote learning, I'll be sharing ideas about adapting in-person interactions to online contexts. There’s a real connection; both learning methods require adaptability and engagement. We will alternate between teaching as well as implementation strategies using practical experiences.
00:33:35.440
For example, imagine going from two partners presenting austere ideas to those interpreting and applying their thoughts to real-world scenarios together. This engages participants actively. We aim for a dialogue, encouraging instances where differing views arise about the best practices and how to engage meaningfully.
00:34:01.000
Thank you, everyone!
00:34:20.000
Are there any more questions? Alright, thank you, Betsy! Here’s a small gift for you.
