Junior Developers
Quit Frustrating Your New Developers - Tips From a Teacher

Summarized using AI

Quit Frustrating Your New Developers - Tips From a Teacher

Miki Rezentes • May 24, 2016 • Kansas City, MO

In the talk titled "Quit Frustrating Your New Developers - Tips From a Teacher," Miki Rezentes emphasizes the importance of effective teaching and training strategies for onboarding new developers. Drawing from personal experiences as a software engineer and educator, Miki shares valuable insights on reducing frustration for new hires and enhancing job satisfaction.

  • Understanding the Teacher's Role: Miki highlights that teaching is a two-person activity, where both the trainer and new developer must actively engage in the learning process. If a new hire is unwilling to learn, it’s a sign of a poor hiring choice.

  • Three Teaching Opportunities: Miki outlines three key phases in the developer onboarding process: 1) onboarding (6-8 weeks), 2) ongoing education and mentoring, and 3) addressing routine questions. Each phase requires tailored approaches to information transfer.

  • Types of Knowledge: Developers need to learn three categories of knowledge: tools of the trade (programming languages, design patterns), domain-specific knowledge (industry compliance standards), and company processes (policies and development practices).

  • Reducing Unknowns: The discussion stresses that teaching aims to minimize unknowns for new developers. If a new hire feels uncertain, it indicates gaps in the onboarding process. Miki advocates for checking in regularly to clarify their tasks and blockages.

  • The Iceberg Analogy: Miki uses this analogy to explain known and unknown unknowns, illustrating how junior developers may lack awareness of their knowledge gaps, while experienced developers learn to navigate these unknowns over time.

  • The Seven Laws of Teaching: Miki introduces classical teaching principles and relates them to software development. Key laws include: 1. The teacher must know their material (Law of the Teacher); 2. The learner must be engaged (Law of the Learner); and 3. New knowledge should relate to what learners already know (Law of the Lesson).

  • Promoting Psychological Safety: It’s crucial to foster a supportive environment where new developers feel safe to ask questions without fear of judgement, encouraging open communication and relationship building.

  • Effective Communication: The importance of avoiding jargon, establishing common language, and developing a glossary for new hires is highlighted to ensure comprehension and clarity.

  • Structured Feedback Cycle: Miki stresses the necessity of clear expectations and evaluation standards so that developers understand their goals and receive constructive feedback.

In conclusion, Miki encapsulates that effective teaching and mentoring in software development not only help newcomers thrive but also enhance the overall team environment. A structured approach to onboarding and continued education can lead to improved satisfaction and productivity for both new developers and the team as a whole.

Quit Frustrating Your New Developers - Tips From a Teacher
Miki Rezentes • May 24, 2016 • Kansas City, MO

Your team gains a new developer. You are responsible for bringing them up to speed. While not everyone is a natural teacher, everyone can be taught basic teaching fundamentals. We will take a look at principles anyone can use to become a more effective trainer/teacher. Better teaching technique makes the training process more effective and enjoyable. Effective training reduces new developer frustration and increases job satisfaction for everyone.

RailsConf 2016

00:00:09.530 Good afternoon! My name is Miki Rezentes. Can everyone hear me okay? Awesome! So, welcome to the talk. I work at Speedily in Durham, North Carolina. I'm a software engineer, and my Twitter handle is @MikiRez. Feel free to reach out.
00:00:17.670 At Speedily, I develop on ActiveMerchant and also work on other projects. I also wrote a library for Android Pay decryption of tokens, so I have some software credibility, I guess. Anyway, a little background on myself: I married young and had five children. I homeschooled for 16 years. From the time I was 18, I've been tutoring or teaching math for money, which has always been rewarding.
00:00:30.510 I've coached roughly 15 high school sports teams, two of which have won state championships. All of this is just to say that I'm used to being in charge and having most of the answers. It's a great place to be.
00:00:43.379 However, roughly six years ago, I returned to school to finish my degree because I was planning to go back to work. My husband was working from home with the kids, and that marked the beginning of my journey back up the totem pole and experiencing being at the bottom again. It’s very enlightening to put yourself in the position of the learner. So, I suggest that anyone in a teaching position take the opportunity to experience being the learner at some point. You’ll realize many things you might not want to be as a teacher.
00:01:19.290 In this industry, specifically, you have to conquer your fears because there are many moments where you’ll have to admit you don’t know something. It can be scary to admit that. So, I recommend engaging in something with a low fear factor. It doesn’t have to be intense, but it should be fun.
00:01:39.900 When I first started putting this talk together, I realized I wanted to make it applicable to any new developer that came to your company. However, as I went through it, I found that I was projecting some of my preferences onto all new developers. While you might not be able to avoid this tendency, I’ll share my preferences with you. That way, if you see those heavy threads, you’ll know where I’m coming from.
00:02:07.560 One preference I have is that I need regular feedback, clear evaluation criteria, and defined expectations. If I don't have those, I'm unhappy, and I tend to get unhappy a lot. You’ll notice that if I’m not growing, I’m also unhappy. I love working in teams, so when I feel isolated, I’m unhappy too.
00:02:24.990 I believe that training is a two-person activity. If you’re in a position to train someone and that person is not willing to put in the effort to learn, then you’ve hired the wrong person. This talk is not for you — you should go find a hiring talk to understand how not to hire those individuals.
00:02:51.030 There are three basic teaching opportunities you will encounter when onboarding someone. The first teaching opportunity is onboarding, which generally lasts about six to eight weeks, depending on the company. The next opportunity will be continuing education, training, or mentoring, which is ongoing throughout an engineer's career. Engineers should be learning continuously, ideally with someone to guide them, especially as they reach senior levels. Finally, you'll have routine daily questions.
00:03:26.400 I’ll break down the types of knowledge into three categories. First, there's tools of the trade knowledge, which includes your programming languages, design patterns, data structures, and databases. This is the kind of information you can find in a wiki or through academic learning — we'll call these 'tools of the trade.' Next, you’ll need to teach domain or industry-specific knowledge. For example, at Speedily, we process credit card transactions, so I need to understand PCI compliance. Finally, there are company policies and development processes — essentially company-specific information. These three types of information are crucial to understand.
00:04:22.860 There are two types of new developers: experienced developers new to your team, and junior developers who are new to the field. They clearly have different needs, but the teaching principles remain similar. Junior developers will require more help with the tools of the trade.
00:04:47.250 An overview of teaching and training reveals that the point of teaching is to reduce unknowns. If your training introduces unknowns, something is wrong with the process. As you continue through this talk and beyond, always ask yourself if you are reducing unknowns because it’s crucial. For instance, when onboarding someone, you will often have casual conversations where you'll ask how they're doing. However, if they answer, 'I don’t know,' that indicates there are unknowns that haven’t been addressed.
00:05:13.460 For example, if a new developer expresses uncertainty when asked how they're doing, I clarify that I want to know three things: Do they have something to work on? Are they blocked? And is there a question I can answer for them? This helps eliminate their unknownsand makes them more comfortable and productive. The idea is that every time you address an unknown for a new developer, they become more productive.
00:05:50.440 Most of us are familiar with the iceberg analogy in education. We have known unknowns, which are things we know we don’t know; for instance, I might not know the distance from Earth to Pluto. Then, there are unknown unknowns, which are things we don’t even realize we don’t know. For example, my eleven-year-old daughter has no idea what a data structure is. The visual representation of the iceberg is misleading, though; the 'bottom' is far too small to represent how much we actually don’t know.
00:06:16.620 Junior developers are blissfully unaware of how much they don’t know, which can be beneficial in a way. Experienced developers, on the other hand, encounter a problem, solve it, and realize that they were able to resolve an issue even when they initially had no idea how, which adds to their confidence. They need time to stick around and understand that becoming a software engineer is about navigating unknowns and figuring out solutions.
00:06:54.850 When assessing the effectiveness of your teaching, you must ask yourself two essential questions: Are you reducing unknowns? It's surprising how many people teach for long periods without ever addressing unknowns. The second question is: Is your developer acquiring more problem-solving skills? Junior developers typically have fewer problem-solving skills than their more experienced peers. However, regardless of experience, they will face new challenges when switching tech stacks or companies, requiring them to learn different problem-solving skills.
00:07:42.760 For example, I started at Speedily and faced issues getting my environment set up. I couldn’t run specific processes and thought, 'Is Postgres running?' I assumed it was, but it turns out it wasn’t. The key point is that even someone who isn’t a junior developer might need guidance in unfamiliar areas. They should learn to consult resources, so I always encourage junior developers to 'Google it' before coming to me.
00:08:05.520 Now, let’s discuss the seven laws of teaching. I was a teacher, as you saw from my bio, and teaching is one of my favorite activities. The seven laws of teaching might seem straightforward, but people often get them wrong. This is taken from a book written in 1884 that all classically trained teachers should read. I will go through these laws and apply them to software development.
00:08:46.610 The first law is the Law of the Teacher: The teacher must know the material they wish to teach. It’s vital that you know your lesson thoroughly, clearly, and familiarize yourself with it. Since there are three types of teaching opportunities I mentioned earlier, let’s look at them individually, starting with onboarding. Many people mistakenly think onboarding is a one-person show; it’s not. Onboarding should be a team or company effort.
00:09:27.570 If you don’t know what you’re supposed to teach during onboarding, you can’t onboard someone effectively. This means you need help. Typically, during onboarding, you should focus on teaching company-specific information alongside computer science and domain-related content, which are also important.
00:10:05.920 After completing the initial onboarding phase, the new developer should have a firm understanding of what the company is about. They shouldn't continuously discover new company details along the way. Documentation is key to a successful onboarding process. For example, my lead, Ryan, is diligent about documentation. If he touches something, it's documented. This ensures that new team members always have resources available.
00:10:43.530 Once I joined, three more developers came aboard. We realized that we were all doing the same things during our first six weeks without an official onboarding process. Therefore, Ryan created a new engineers handbook which has proven invaluable. It includes information on setting up machines, work assignments, and what to expect in terms of office hours, among other things. This handbook helps answer many unknowns and allows new hires to get started coding while becoming familiar with the company.
00:11:48.200 Additionally, it's crucial to help new developers understand how your development process works, your team's working agreements, and whether there's a definition of 'done.' Understanding the style guide is also beneficial if you have one and should be introduced during onboarding. Even if you don't have a style guide, I recommend creating one to set clear expectations.
00:12:52.540 Knowing how conflicts are handled in the team is important for new hires to understand. Addressing potential conflicts before they arise can help ease the stress of joining a new company since new developers often feel overwhelmed already.
00:13:36.430 Next, let's talk about continuing education and mentoring. This aspect should be unbounded and can last weeks, months, or even years if they enjoy being part of the team. The point of ongoing education and mentoring is to guide developers from their current skills to mastering those skills and pushing them to the next level. Developers want to grow, and it’s reassuring to them to know that someone is helping them in their career journey.
00:14:17.660 Make sure your developers understand the career ladder and what levels they need to achieve to advance. Having clear evaluation criteria is important as well, so they know what to aim for. If they aren’t motivated to improve, that’s a sign you might need to reconsider their place on the team.
00:15:00.360 Reviews of style guides can be an excellent part of the continuing education process. For example, when I worked with a JavaScript style guide from Airbnb, I learned the reasoning behind various style decisions, which helped me form my own opinions. It’s important for developers to develop strong opinions about coding protocols and styles but to also hold these opinions loosely.
00:15:56.200 Having a core book list and recommended reading is also essential. Every company values certain resources, and providing these can help ensure everyone is on the same page when discussing topics. When I homeschooled my children, we read the same set of core books. It was helpful at the dinner table since we could reference the same material regardless of the subject matter.
00:16:45.300 The last piece I'd like to touch on is the importance of answering routine questions effectively. When addressing these, you need to have answers ready or know how to find them. Teaching new developers how to solve common issues will help them feel more confident. Throughout this process, remember to continue reducing unknowns and demonstrate problem-solving skills.
00:17:26.050 The second law is the Law of the Learner: The learner must attend with interest to the material to be learned. Therefore, you must gain and keep the attention of your students. You cannot teach effectively without their engagement. Hiring people who want to learn is crucial, but you must also create an environment conducive to learning.
00:18:05.450 This environment should encourage questions because questions expose unknowns. You can't address unknowns until someone brings them up. Foster an atmosphere where asking questions is considered good practice. If newer developers see more experienced developers asking questions, it will encourage them to do the same.
00:18:51.650 If experienced developers are not asking questions, it could mean that they haven’t reached their full potential or they are just really good at Googling. The first situation is concerning; the second is acceptable. To enhance this, we created a Slack onboarding channel at Speedily, allowing new team members to discuss issues in a private setting without fear of exposing their unknowns.
00:19:29.650 Imposter syndrome is common in our industry and can come from any level of experience. I scripted a talk on this topic with talented actors, showing how everyone is just figuring things out as they go. Many people in the field often don’t realize how uncertain things can be, and Google conducted a study examining effective team qualities. Psychological safety was a major factor.
00:20:11.130 Psychological safety means that team members can take risks without feeling embarrassed or insecure. It's important to cultivate an environment where asking questions is encouraged, so if team members feel insecure about seeking clarification, your team's climate might not be healthy.
00:21:12.810 I also believe that the number of regular interactions someone has with their team can improve their psychological safety. For example, a developer might have many interactions with their team, some of which are questions, but they’re not measured solely by questions. It’s essential to foster environments where new developers feel they can interact without excessive pressure.
00:21:53.480 Team-building events can help create stronger relationships and increase comfort among team members. Try to make your interactions inclusive — not everyone enjoys the same activities, so offer diverse options so all members can participate comfortably. Value these interactions, as they contribute to overall team cohesion.
00:22:41.000 The Law of the Language states that the language used in teaching must be common to both the teacher and the learner. Avoid using industry-specific jargon or acronyms that might confuse new developers. When using terms that might not be understood, take the time to define them.
00:23:38.000 At Speedily, we developed a glossary of terms specifically for new hires, which proved to be really helpful. For example, if a student isn’t familiar with a word or concept, you should explain it in simpler terms they can relate to rather than using more jargon. This ensures clarity and comprehension.
00:24:23.000 The Law of the Lesson states that new knowledge must be learned in terms of previously known truths. Always start with what your students already know, advancing to new material step by step. If you begin teaching new concepts before confirming their existing knowledge, they’ll likely struggle.
00:25:15.890 When I was teaching math, if a student struggled with a problem involving fractions, I would first check if they could work through simpler fraction problems. If they couldn't handle the basics, covering advanced topics would be ineffective.
00:25:59.030 Good teaching is about providing information that connects with what someone already understands. If learners can relate new information to what they already know, they are more likely to grasp it.
00:26:57.450 The Law of the Teaching Process, meanwhile, emphasizes that teaching ought to stimulate a student's mind to grasp the desired thought or master desired skills. It’s crucial to encourage students to be discoverers rather than just passive recipients of information.
00:27:44.760 I believe a valuable part of teaching is helping students learn how to ask the right questions. You make them more effective learners because they can figure out what to ask and how to find answers themselves. However, it’s quicker and more satisfying to provide answers than to teach someone how to inquire properly.
00:28:26.140 While there are short-term gains to simply answering questions, long-term, it can create dependence and is ultimately harmful for the team. Therefore, utilize a method called question-answer flow when teaching.
00:29:23.310 An example might be a question that asks students to define mathematical operations. Effective educators repeat this validation of knowledge so students retain the information they learned. Additionally, when addressing complex subjects, it’s important to guide through the logical approach rather than providing answers directly.
00:30:05.370 Depending on your teaching style, ensure it’s clear and grounded because familiarity will help with retention. When teaching, especially software concepts, talk through your process so others can learn your thinking method.
00:30:46.670 The Law of the Learning Process states that students must reproduce the learned material. Encourage learners to think out loud and express what they learn in their own language. This acknowledgment becomes easier when you accommodate various learning styles; some students benefit significantly from working through problems in different contexts than their colleagues.
00:31:41.800 The Law of Review and Application emphasizes that teaching isn’t complete until there's a review of material and its application. Constant review and adjustments deepen understanding. This often occurs through discussions and project reviews, which can solidify what developers have learned.
00:32:19.690 Effective feedback ensures that expectations and evaluation standards are clear for developers. If expectations aren’t spelled out, they can lead to confusion, frustration, and unsatisfactory performance from team members.
00:33:05.310 When working on a project, make sure your evaluation criteria are clear and transparent to everyone involved. After I coached a volleyball team, I realized that having the same benchmarks consistently communicated led to better performance because the players understood what was expected of them.
00:33:48.710 To sum up, remember that a structured feedback cycle is crucial for new developer onboarding. They should feel comfortable voicing any issues, and it should facilitate open communication that is beneficial for both parties. In conclusion, although learning to be more effective teachers takes time, it ultimately leads to better understanding for everyone involved. Thank you for joining me; any questions?
00:34:23.310 You've been great. Thank you!
Explore all talks recorded at RailsConf 2016
+106