Because tech changed my life financially, I've invested time into helping people like me join the tech industry. For example:
- I teach women of color and non-binary people of color HTML, CSS, and JavaScript; then, I connect them with apprenticeships or programs that help new developers get job-ready.
- I'm also that annoying person that tells all my friends and Lyft drivers to do a coding boot camp and switch careers into tech.
However, I recently lost my motivation to continue helping people get into tech. I've debated with myself if I'm even doing a good thing.
You probably think that the answer is obviously yes; it is good to help people gain more money and potential for career advancement, but I've realized that it's not that simple.
After my friends or mentees land jobs, they report back to me that they're struggling with impostor syndrome. As they recount their stories to me in detail, I realize they're dealing with emotional abuse, isolation, ageism, racism, sexism, and gaslighting in the workplace. Corporate culture often masks bullying with the label "impostor syndrome." It's not impostor syndrome when your coworker tells you that you don't belong.
Their experiences were similar to those in this thread.
After listening to my friends' and mentees' experiences, I felt (and sometimes continue to feel) an overwhelming sense of guilt because they traded money for happiness and self-esteem. I felt like I set them up to endure work trauma.
I had to remind myself that it was not my fault. The root of the issue is that engineering teams do not understand how to support early-career developers, especially those from underrepresented backgrounds.
My Junior Engineering Experience
I empathize strongly with their work trauma because, during my first two years as a software engineer, I constantly felt:
- Embarrassed
- Anxious
- Incompetent
- Like I didn't belong
- Like I should quit tech altogether
Initially, I blamed myself, so I tried hard to change the situation and prove my worth by staying up late completing work to keep up with my coworkers and enrolling in college for Computer Science, but to no avail. Eventually, I realized I needed a new team and a new company to foster my technical growth and confidence. Unfortunately, by the time I moved to a new company, I only had a few months of energy left in me. I started strong, but after a couple of months working there, the burnout and disenchantment returned. Even though they treated me kindly, I didn't want to code anymore. I couldn't even open a new instance of Visual Studio Code.
To truly recover from burnout, I took some time off from work. During my funemployment, I assessed the experiences of my friends and my experiences, to determine how teams can better nurture junior engineers.
How to nurture new engineers
Step 1: Recognize that your responsibility is to teach
Each developer is also a teacher, whether they want to admit it or not.
Perhaps you are a(n):
boot camp instructor,
developer advocate,
engineering manager
mid-level developer
You will eventually have to teach a less experienced developer. Software engineering is a team sport. Your teammates' wins are your wins too, but we often forget that. We want to complete our tickets (or issues) without any distraction. We view helping our coworkers as a distraction rather than progress because helping coworkers is not prioritized or measured. Peer mentoring and teaching are vital components of a well-oiled software engineering team. As developers, we should place a higher value on good teaching, mentoring, and empowering.
Step 2: Create Room for Growth
My husband and I learned to code at the same coding bootcamp at the same time, but he seemed so much happier at work, and I couldn’t identify why. Was he a million times smarter than me? Possibly, yes. (don’t tell him I said that). Working from home allowed me to eavesdrop observe the dynamic between him and his coworkers. They made space for him to grow. They were nice to him. They didn’t dismiss him while he spoke. They encouraged him. They were direct with him. He knew what steps he needed to take to get promoted. By watching their interactions, I learned that you could create room for junior developers to grow by:
Listening as much as you speak
As a mentor, you may feel tempted to share all your knowledge. That can be overwhelming, and you may be ignoring the junior dev's needs. Listen to figure out what they want and need because their growth is not about you.
Making support accessible and available
Assign designated mentors who genuinely want to answer questions and prioritize helping junior devs. Hold office hours, so the early career developer can feel safe asking questions at a designated time. This way, they're reassured that they're not taking your focus away from engineers' primary tasks.
Setting clear goals and expectations
Most junior developers don't want to be junior forever. They want to know what milestones they can reach to grow. Express clear expectations so they know what to strive for.
Step 3: Lose the ego
I'm the Director of Programs at G{Code}, a free program designed to give young women and non-binary people of color first exposure to coding to uncover interest and aptitude in tech in a supportive, inclusive, and safe environment. Over the past three cohorts, I've had to unlearn past teaching methods and bad habits I picked up from the industry. While I had previously learned to "fake it until I make it," I now realized that:
Vulnerability is a catalyst for growth
Tech is rooted in elitism and academia. We pretend to know it all but be honest -- you don't know everything. By saying the words, "I don't know. Let's look it up together", you reduce the pressure from new developers that feel they HAVE to know it all.
I shouldn’t ask if they’ve Googled it
Everyone loves to ask that question. Of course, they've Googled it. Because asking for help requires swallowing your pride, it's often the last resort. Instead, I empower them to solve problems independently by asking the following questions:
- What's your goal?
- What have you tried?
- What did the result look like?
This approach is less condescending and more effective.
My teaching style is not always compatible with their learning style
The way I want to teach is not always the way they learn best. I have to learn to adapt to their learning preferences and provide various mediums and resources for them to absorb the information. I learned this after I tried to teach people the way I learned things, and I was met with blank faces. Remember that there are visual learners, hands-on learners, auditory learners, and more. Communicate with your mentee and ask them how they would best like to learn a concept.
Step 4: Exercise patience and kindness
When I started working at Botany, my manager Andy Cunningham indirectly taught me to support early-career developers. Through the following practices, Andy helped me to slowly regain my confidence (which is still a work in progress):
Allow developers to reflect between tasks
After completing tickets, it's great for developers of all levels to write notes or blog about what they learned from the tasks. We often move on to the next assignment and completely forget how we solved the previous task. Blogging between engineering tickets sounds like a time-sink, but it's an investment. When people write things down, they retain the information. And if developers forget, at least they can look back at their notes for the solution. By recording the steps taken to resolve a problem, developers can engineer solutions more quickly in the future.
Give empathetic code reviews
Slack's Engineering team has an excellent blog post on giving good code reviews. The authors state, "If you see a problem with the code, try to put yourself in their shoes and try to help them see the problem without making them feel like a screw-up."
Take your time to read the code and provide thoughtful advice. Let them know when your suggestions are blockers or nitpicks. Remember, you and the person you are reviewing are smart individuals who can learn from each other, which is why you work at the same company. Don't write feedback that implies you're more intelligent than them.
Don’t place blame
In the summer of 2021, an HBO intern made the mistake of sending test emails to customers. HBO Max wittily admitted that it was the intern. Although they tweeted that they were helping the intern, the tweet didn’t make me feel good. It made me wonder how the intern felt. Perhaps, the intern laughed it off, but deep down, they felt embarrassed.
If an early career developer makes a mistake, avoid blaming them even as a joke. When a new dev makes a mistake, it means there aren't enough guard rails in place for the new dev to avoid making this mistake. Therefore, the leaders of the team are responsible. Instead, try to:
- Set up guard rails
- Let them know it's not their fault,
- Tell them about a time you made a similar (or worse) mistake in the past to help them feel better
- Offer to help fix the issue
- Fix the issue with them without acting like you're their savior
- Provide advice on how to avoid the mistake in the future (when the time is right)
How Companies Can Create a Nurturing Environment
Embed kindness into your culture
Give positive reinforcement to all employees, especially junior employees and junior developers. Genuinely highlight their achievements even if it's small to you. People are more likely to perform better if they are clear on what tasks they're doing well.
Hire kind engineering leaders
There is a tendency to ignore arrogance if an engineer is brilliant and productive. Unfortunately, those engineers are more harmful than helpful to the company's culture because they often try to elevate themselves rather than their coworkers. Hire developers who advocate for each other.
Implement better processes
SCRUM and Kanban encourage devs to focus more on completing tickets than helping each other. It's up to us as an industry to devise processes that prioritize helping coworkers grow as much as the product. Before revolutionizing an engineering team's entire workflow, companies can help early-career developers work confidently by writing clear, detailed tickets and documentation.
Fortunately, I see our industry improving little by little, and at GitHub, I've experienced compassion and encouragement.
In your opinion, how can we be better champions for new developers?
