00:00:17.000
Okay, cool. I guess I'll go ahead and get started then. Hi, and thank you all so much for coming to my talk here. I'm Kwo, and I started at New Relic just about a month ago. This is my first developer job. For my talk today, I'm going to first give a bit more context about where I'm coming from and my intentions for this talk. I will then dive into what I see as the main challenges of being a junior developer, and I'll share my tactics for how to overcome these challenges. There is a lot that I want to cover, but if you're taking notes and happen to miss something, I have written a post for the New Relic blog that went up this morning that you can reference. I also have a link to my slides at the end.
00:00:40.520
So, how many people here are junior developers? Okay, awesome! And how many of you did something else professionally before you worked as developers? Nice! We are amongst our own people here, right? Very cool! For me, being a developer is probably the fourth or fifth career I've had at this point. It's hard to keep track. Some of the other jobs I've had in the past include things like product specialist and tech support. I used to work in a biology research lab, and I also did some copy editing on the side. The thing is, compared to people who have been coding since they were kids, I am literally decades behind. This makes me feel like I have so much to catch up on.
00:01:12.439
However, something I've realized is that being a developer is essentially about constantly learning new things. And guess what? I'm pretty good at that! I'm very practiced in picking up new careers and starting over again and again. So despite what my parents think, I like to think that my previous lack of direction is now an asset. Another thing I’ve realized over the last few months is that a lot of our roles can actually have nothing to do with coding. If you've spent a lot of time doing something besides computer science, that means you have more experience in the non-coding portions. You can leverage those skills and experience to help your team while you get better at the technical aspects.
00:02:09.479
My thesis is that just because you switch careers, it doesn't mean you're starting over entirely. In fact, you can still use those other skills you have. You may already know the different tactics I'll be talking about today, so I hope to prompt you to consider new angles and get excited to apply them as a junior developer. There will be sections that are actually more targeted toward mentors, but if you have a mentor and they aren’t here today, maybe you can bring some of these ideas back to them and discuss them. For any senior developers that might be in the audience, I hope to help you remember what it feels like to be on the junior side of a mentoring relationship and think about ways you can help your protégés feel valued in a very concrete way.
00:02:41.920
I think there are two big reasons why it's hard to be a junior developer. First, there's a ridiculous amount to learn. How many people feel like that? Yeah, like pretty much everyone here, cool. Second, I think it's really hard to know how you can help your team and not just feel like this helpless little baby bird. Here, I'll talk a little bit about these challenges and how to handle each of them. My three-step, foolproof plan for tackling the fact that there’s a ridiculous amount to learn is really all about not trying to do it all on your own. Getting people to want to help you in the first place can sometimes be a bit of a hurdle, depending on how supportive the environment you happen to be in is.
00:03:25.520
I've been really lucky at New Relic, but I think there are always things you can do even if you feel a bit more isolated. People fundamentally aren’t all that different wherever you go. A lot of this boils down to building relationships, but I prefer to think about it as simply getting to know people and making friends because, of course, friendship is magic. I personally find this pretty hard because I'm actually a pretty strong introvert. I fully expect to spend most of tonight huddled in a ball, trying to recover from today. But you know, many developers are also quite introverted, and it can be difficult to get the conversation going, even if both parties really want to connect.
00:04:58.560
Luckily, at my last job, I worked with PMs in engineering and came up with a few hacks. What I do is try to remember small details that people have told me, especially about their lives outside of work. Sometimes it's actually easier for me to remember these details than people’s names. But usually, people are pretty forgiving once I tell them I remember talking to them for like two hours about their love for antique banjo collecting or something similar. This makes for much better conversations than your typical small talk. Another little trick I use is that I sometimes mentally prepare stories to get a conversation going. For instance, right after a weekend, I’ll try to think of something interesting or odd that I did, so I have a non-generic answer ready for when someone asks how my weekend went.
00:05:51.639
Otherwise, I just freeze up and say 'oh, good,' which is a boring answer and doesn’t really start a conversation. Does anybody else have that knee-jerk reaction sometimes? Yeah, totally! With a story to tell, what I find is that this can prompt questions and get some back-and-forth conversation started. Helping break through awkwardness is also something that mentors can do a lot to help with. Mentors are really great for guiding newbies around team culture and history. They can help make introductions and give advice on how to approach other people, like what the two of you may have in common or who is a good person to ask about what.
00:06:56.679
Also, if your company has a support team, you should definitely make some good friends there. Support tends to be chronically undervalued, but those team members probably know way more about the product than you do. If you think about it, they're very practiced at explaining the product to newbies like your fellow customers. When I worked in tech support, sometimes engineers would shadow us so they could learn how customers actually used our product and use that information to inform design decisions they might have. I definitely always preferred the engineers who were really eager to learn from me.
00:07:52.239
Another key component to getting people to want to help you is to demonstrate that you value the time they’re taking to help you and that you took a reasonable amount of time to get as far as you could on your own. Each time someone helps you, you’re able to learn new tactics and push yourself just a little bit farther before you need to ask the question again. When you do ask for help, you can also inquire, 'If you're busy, who else could I talk to about this?' When someone does help you, always end by asking something like, 'Is there somewhere I could have found this answer on my own?' If the answer is no and there isn’t any good reason it doesn’t exist already, you should add it.
00:08:47.440
When you have someone's time, try to think of ways to extend what you're learning from them at that moment. That way, you'll be prepared when a variation of that same question arises again. Lastly, to encourage people to want to help you, something as simple as showing appreciation really goes a long way. Great mentors and teachers would likely do it regardless, but it never hurts to make people feel valued for helping you. Noticing when people have gone out of their way to assist you encourages more of that behavior.
00:09:38.800
If you are working at a big enough organization where not everyone is familiar with each other's roles, you can also let people’s managers know when they’ve been particularly helpful. Most managers appreciate hearing good things about their reports, and this also helps everyone feel valued for the good work they do for the team. We've covered step one: getting people to want to help you. Step two is making it easy for them to help you.
00:10:10.560
There are a few different ways you can do this. I think one of the hardest parts of learning is letting people see inside your head and understand where you're at right now. But this can be really challenging in a field like programming where sometimes you might not even have the vocabulary to express what it is that you don't understand because you don't fully grasp it.
00:10:30.880
Great teachers can draw it out from you, even if your questions are vague. However, most of the people you work with likely aren't highly trained teachers. So there are ways that you can make it easier for others to help you by articulating the premises you're working off of and the logic you're using, so that together you can narrow down what it is that you don’t understand or what’s missing. You can say things like, 'You had me up until this point' or 'I thought you said this, but then this happened, and I’m confused.' A solid way of describing the issues you're facing is by saying what you’re trying to accomplish and why so someone can jump in if that’s not even the right goal to aim for in the first place.
00:11:50.080
Also, describe your current problem and what you’ve already tried. Sometimes people might jump in quickly with their idea of the answer to your question, but it’s still good to be prepared regardless. And if you’re a mentor, consider that you should confirm your understanding of the question before you attempt to answer it. When I worked in tech support, the most effective clients would include all of this information upfront in their tickets, which saved us a ton of time on trying to figure out what the actual question was.
00:13:00.440
Remember that just having the courage to say 'I don’t know' is a strength. Exposing your own ignorance feels really scary, so I always practice saying things like, 'Wait, I don’t even know what that word means.'
00:13:45.560
I say this all the time, but it’s vital to understand what people are talking about. The sooner I admit to people that I don’t actually know what’s going on, the sooner I can begin learning. Of all the advice I received when I started at New Relic, my favorite was that one of the best things mentors can do when junior developers are confused is simply validating that feeling. Being honest and saying, 'This is confusing for me too,' without fail makes me feel better when someone I expect to know the answer admits they don’t know either. It then shifts the experience into a team effort to figure out how to get out of this hole of ignorance together.
00:14:48.680
It’s also great because when you’re working with someone who also doesn’t know the answer, you frequently pick up new debugging techniques you can apply next time. Now I want you to reflect on the last few times you asked someone for help. After receiving help from someone, how many of you have heard them say something like, 'Did that help?' A few people? Yeah, I hear this all the time and I realize this is because most of us are fairly needy and want validation.
00:15:38.440
Therefore, my favorite feedback I receive is usually from people telling me they actually used any advice that I gave them. So when you tell people specifically what it is they did that helped you, they'll know what they can do more of. For example, it really helped me when you walked me through how to use these tools with this example or it really helps me to be the driver when we pair program because I absorb more than just shadowing.
00:16:20.560
One perspective I really like regarding mentoring relationships comes from a book club we had at New Relic called 'Managers as Mentors.' The idea is that mentoring shouldn't revolve around the traditional mindset of a one-way transmission of information. Instead, it's the mentor's responsibility to create a safe environment and eliminate barriers to learning, allowing mentees to express their fears and not fear failing. This way, they can learn much more and at a faster pace.
00:17:57.760
I can personally relate to moving from working on my own projects, which no one depended on, to contributing to something that people were actually paying money for. That was pretty terrifying! We have this notion of failing fast, but it's very hard to apply when you don't feel secure. What helped me was all the support from mentors sharing their stories about how they messed up too and the idea that it's not a question of if you’ll break production, but when. When you do make mistakes, your team should have processes in place to facilitate quick recovery from errors and methods to avoid the same mistakes in the future.
00:18:54.120
If none of these processes already exist, you should help establish them, because if just one person can ruin everything, that’s a big issue for the whole team. I'm also a big proponent of having a direct conversation upfront about someone’s learning style along with the other person's teaching style. This way, you can sync those up and discuss any mismatches ahead of time, preventing potential conflict. It’s great when mentors show they're open to feedback along the way to continue adapting their teaching style to help juniors learn most effectively.
00:19:46.440
It’s also very important to talk about how you prefer to be interrupted. My mentor at New Relic, David, told me that I could interrupt him pretty much any time. Because he was clear about this and directed with me if he couldn't help me immediately, he always provided me with other resources to explore. This gave me more confidence to approach him or others rather than bottling it up until our designated weekly meetings.
00:20:40.720
When I started, David's desk was right next to mine, so even when I was engaged with others, he could lightly listen in and jump in when it was clear I was missing something fundamental. As my mentor, he had a better understanding of my knowledge level. He could guide others in helping me too. If as a mentor, part of your philosophy is to allow people to struggle, it’s also important to make that clear upfront.
00:21:43.520
This is beneficial because it allows juniors to understand that you are intentionally doing this out of faith in them, rather than setting them up to fail or having misplaced expectations. Just reminding juniors that you expect it to be hard significantly alleviates any feelings of imposter syndrome they may have, where they feel things should be easier than they are. But that's not the case; it’s supposed to be challenging.
00:22:27.440
Finally, I think it’s ideal if you can assign some responsibility for deadlines to junior developers. The junior developer's role is to keep everyone updated so no one is surprised by how much work is left to do on a project. A couple of months ago, when I was overwhelmed because it felt like it was taking forever to learn the basics of D3, one of our project managers told me that reshuffling resources was his job, allowing me to go back to learning and struggling. He assured me that if any project deadline was at risk, the burden wouldn't fall entirely on my shoulders.
00:23:21.680
Now that we’ve covered the first two steps, we are about halfway through. So, I’d like for you all to humor me for a moment. If you could all just sit forward in your chairs a bit, thank you. Go ahead and put your arms behind your back and try to stretch, pulling your shoulders down and back slightly. Just try to counteract some of the terrible posture many of us probably have when we’re hunched over a computer.
00:23:56.720
Alright, back to where we were. The final step in tackling the enormous amount of learning is much like tackling any other gnarly technical problem: narrow your scope. Mentors are extremely helpful here, as they can help prioritize what to learn next.
00:24:21.680
For example, one of my goals is to build a Rails app from the beginning. I know it's important to deliver recommendations at the right time. If a mentor expresses excitement about another new topic to add to a junior developer's plate and impulsively blurts it out, it can sometimes feel like, 'Wow, this must be particularly important,' and it makes me think I should know it already, which can lead to a cycle of self-doubt.
00:25:09.120
You also need to match your learning style with a tutorial style. This is important because a lot of programming tutorials are very simplistic, like: Step one, draw some circles. Step two, draw the rest of the owl. How many people have encountered tutorials that are like this? Even in more detailed tutorials, there can be differences in whether the work is goal-oriented or not.
00:25:51.760
For me, it’s actually harder to stay motivated without a specific goal in sight. I prefer structure, and a free-form approach can lead me to boredom. I took calculus in high school, which was engaging, but it wasn’t until I took physics in college that I realized, 'Oh, that’s what calculus was designed for!' This is just my perspective, and others may feel quite differently.
00:26:51.520
In terms of content, I believe the highest value areas to focus on include team processes for code reviewing, version control like Git, and specific product knowledge, rather than getting too caught up in honing general programming skills. This might be a bit controversial, but I believe that optimizing your tools, environment, or learning numerous keyboard shortcuts are less essential at the outset. Sure, keyboard shortcuts are fun and helpful, but let’s be honest: how fast I can type is not the limiting factor in how quickly I can complete a feature.
00:27:45.639
That wraps up my thoughts on tackling the first challenge of having so much to learn as a junior developer. Next, I'll discuss how even junior developers can contribute to their teams immediately. Knowing how to help your team can be challenging because you might feel like you’re slowing down your team’s productivity with how much assistance you need. How many of you have felt like that? In one of the first conversations David and I had, I essentially asked him, 'How did you get stuck with me?' But to his and New Relic's credit, he quickly reassured me that he wasn’t stuck with me; he wanted to learn to be a good mentor.
00:28:34.860
That realization made me understand that even my ignorance could be beneficial to the team by giving them chances to practice mentoring. Also, even as a junior developer, your technical contributions still matter. Yes, you may be working on features that someone else could build faster, but in a world where there are never enough junior developers to fill all the open developer positions, it's not necessarily a choice between a junior developer building it slowly and a senior developer doing it quickly. It's about having something built versus having nothing at all.
00:29:42.760
Don’t forget, everyone started out at some point, and you won’t remain at your current stage forever. As my Southern friend likes to remind me, 'No one comes out of their mama’s womb knowing how to code.' Just think about that for a minute. Moving on to some of the non-technical ways you can immediately assist your team: first, I firmly believe that questions are essentially the junior developer's superpower. And as we all know, with great power comes great responsibility. Fresh eyes are beneficial, but you can determine how to provide valuable insights through skillful questioning.
00:30:32.720
Good questions have tremendous value in highlighting assumptions and helping the team avoid dead ends, which ultimately benefits everyone by allowing you to move faster. Questions like, 'Are we working on the right thing?' or 'Is there a reason we’re doing it this way?' are important. This is something I experienced in my previous job where misunderstanding requirements stemming from an off-hand comment in a client email could lead to frustration.
00:31:43.760
You want to ask questions in a way that doesn’t put others on the defensive. If someone reacts negatively, that’s probably not a good sign. Express humility, expressing that your inquiries come from a desire to learn, rather than assuming you already know the answer. You can also consider what questions non-engineering team members, such as sales or support, might raise. Getting answers earlier on can help your team loop in other departments when necessary.
00:32:49.200
We are now two-thirds through the outline. On the other side of asking questions, providing constructive feedback is vital too. If you've previously had another career, this is a skill you’ve likely already honed. Offering useful feedback to the right person in the appropriate setting at the right time can be challenging for many. In my experience, at tech support, we often conducted quality reviews of each other’s work to enhance the customer support experience, and we would perform general peer evaluations every few quarters, which helped me refine my feedback phrasing skills.
00:33:42.960
Before giving feedback, I like to take a moment to think about what would be beneficial to the person receiving it. What do they want? What are they aiming to achieve? You earn extra points for offering up solutions along with your feedback. It can be tempting to nitpick just for the sake of finding something to say, but it’s more valuable to focus on providing logical, constructive feedback.
00:34:34.080
One approach I've adopted is to consistently give positive feedback whenever the chance arises. I don't mean insincere compliments but rather highlighting the good things and contributions made. It’s often easier to complain about issues rather than voice good things happening. My hope is that this habit will help foster a positive reputation for me. Therefore, when I eventually do provide negative feedback, it will be more seriously considered.
00:35:27.040
Conversely, sometimes good feedback can simply mean stating, 'I don't have an opinion on this topic.' In this way, you can withdraw from the group discussing a subject, making it easier for whoever is attempting to reach a consensus. Now that we’ve discussed two strategies for assisting your team, the last area of focus is making your team shine to other teams.
00:36:23.160
This task isn't very difficult, and it helps your team feel good and other teams feel positive about collaborating with yours. One frequent area this can occur is during demo or review meetings your team may have. You can give impactful demos simply by being thoughtful and prepared. Think about why a change matters to your audience and why they should care. Showcasing the before-and-after can be effective. For example, consider grabbing screenshots to compare the old and new or gathering metrics to illustrate why what your team did is significant.
00:37:30.080
Demos can also help ensure full credit is given for everything your team has accomplished, including aspects that might not be readily visible. You can address corner cases or conscious decisions made in the project and the implications for support and usability. I prefer to overprepare, so I often create a script, which can be a literal, word-for-word script or merely a list of what I want to present in an orderly manner.
00:38:25.520
Doing a run-through beforehand ensures I know what needs to be pre-loaded onto my computer, making the demo efficient and less error-prone overall. Efforts to be responsive, thorough, and empathetic create a strong impact. I'm really proud of the time a member of our New Relic support team told me I was her favorite engineer to work with, mainly due to my responsiveness.
00:39:09.040
This approach helps people feel heard and breaks down stereotypes that engineers neglect other people’s concerns. This way, when your team needs support, they'll be there for you too. In conclusion, this wraps up my thoughts on figuring out how you can help your team as a junior developer. Now, I want to touch on a few caveats and pitfalls to avoid.
00:40:02.240
I'm hoping that mentors in particular will help keep an eye out for these. Sometimes, there's an issue in the tech community of undervaluing non-technical skills, and much of what I've discussed today revolves around leveraging non-technical abilities to advance. However, be cautious not to allow others to assume you are just the secretary, which I don't mean to disparage secretaries at all; it's just not the role I aspire to.
00:40:48.640
There's also a phenomenon dubbed the 'Girl Scout tax,' which arises from the stereotype that women are expected to be helpful. Unfortunately, this leads to many women failing to receive recognition for their contributions because it’s assumed they were just being helpful. This is one of those unconscious biases we may exhibit, and we should strive to be mindful of it so that everyone can be acknowledged and valued for their efforts.
00:41:54.800
You don’t want to find yourself sidelined or pigeonholed into a role you’re not interested in. Everything I've discussed today operates on the premise that you're willing to do what’s best for your team in the short term, but you should also promote what’s best for everyone in the long run, which includes your development as a coder. Finally, keep your focus on whatever your long-term goal is, like improving your coding skills, working on larger features, or gaining insight into the market and industry.
00:42:39.440
This way, you can select activities that will actively push you closer to your goals, avoiding tasks that only serve to divert you. Here are some recommendations for further reading. The first two are quick and easy reads: 'Team Geek,' written by a couple of Google engineering managers who co-founded Google's engineering office here in Chicago, and 'The Upside of Down,' which is a good read if you feel hindered by a fear of failure. The other four are blog posts that I've found interesting and rich in valuable advice for junior developers.
00:43:18.400
Here’s the complete outline of everything I’ve discussed today. I believe there are two main challenges for junior developers: First, the issue of the overwhelming amount of information to absorb; the three-step plan is to get people to want to help, make it easy for them to assist, and narrow the focus of what you’re aiming to cover.
00:43:47.760
Second, the problem of not knowing how to assist your team; always remember that asking good questions is the junior developer superpower. You can also contribute significantly through providing constructive feedback and helping your team present themselves positively to other teams.
00:44:24.560
In conclusion, we frequently discuss the benefits of diversity in teams, but when you bring diversity to your team, it can be challenging because traditional narratives may not recognize your particular strengths due to their differences. As my first boss told me, we can and should work on our areas for growth, but it’s genuinely your strengths that you can rely on the most to advance your objectives.
00:45:18.320
So to all the junior developers and career switchers out there, I just want to say you deserve to have confidence in yourself. Place your assurance in your proven ability to learn, rather than your current level of coding knowledge. It’s just a matter of time, and I hope I’ve helped you decrease that timeframe. Thank you!
