List

How to be a Better Junior Developer

How to be a Better Junior Developer

by Katherine Wu

In the video titled "How to be a Better Junior Developer," Katherine Wu, a junior developer at New Relic, shares insights on navigating the challenges faced by junior developers, particularly those transitioning from non-computer science backgrounds. The talk is structured around two primary challenges: the overwhelming amount of knowledge to learn and understanding how to contribute effectively to a team. Wu emphasizes the value of leveraging non-technical skills to aid in learning and team collaboration. Here are the key points discussed:

  • Understanding Challenges: Wu identifies two main challenges for junior developers: the vast amount of technical learning required and the difficulty in determining how to assist the team.
  • Learning Strategies:
    • Get Help: Build relationships and network within the team. Wu suggests remembering personal details about colleagues to foster connections and to approach other team members respectfully for guidance.
    • Make It Easy for Others to Help: Clearly articulate your current understanding and specific areas of confusion when seeking assistance from others.
    • Narrow Scope: Focus on prioritizing what to learn next to avoid feeling overwhelmed.
  • Contributing to the Team: Wu asserts that junior developers can contribute effectively through their unique skill sets by:
    • Asking Questions: Quality questions can uncover misunderstandings and drive clarity, benefiting the entire team.
    • Providing Feedback: Constructive feedback is essential for team improvement and communication.
    • Making the Team Shine: Demonstrating team efforts in meetings through preparation and attention to detail can enhance the team’s visibility within the organization.
  • Caveats and Pitfalls: Wu highlights the risk of undervaluation of non-technical skills and the 'Girl Scout tax,' which may lead to misconceptions about women’s contributions in tech.
  • Final Thoughts: All developers, regardless of their journey, deserve to feel confident in their abilities to learn. The aim is to utilize existing skills while fostering a positive learning environment where asking for help is encouraged. Ultimately, junior developers should focus on their learning journey and the contributions they can make as they grow into their roles.

By understanding and applying these principles, junior developers can more effectively navigate their early careers and leverage their diverse backgrounds to become valuable members of their teams.

Are you from a non-C.S. background? What about someone you mentor? Many junior devs' top focus is building technical knowledge. However, they already have other skills that can help them in their roles immediately! Some of these include helping their team focus on the right tasks and working well with stakeholders like PM and support. This talk will discuss the non-technical contributions junior devs can make now and how their senior dev mentors can help them ramp up more quickly as a result.

I studied Biology in college and was all set to attend medical school and fulfill my mother's dream of my becoming a doctor. Instead, I got a job at Google in tech support. After five years at Google, I took a sabbatical to attend Hackbright Academy. Now I'm a junior developer at New Relic.

Help us caption & translate this video!

http://amara.org/v/FG0m/

RailsConf 2014

00:00:17.000 okay cool I guess I'll go ahead and get started then um hi and thank you all so
00:00:23.119 much for coming to my talk here uh I'm Kwo and I started at New Relic just
00:00:29.199 about months ago and it's my first developer job there uh for my talk today
00:00:34.879 I'm going to first give a bit more context around where I'm coming from and
00:00:40.520 my intentions for this talk um I'll then dive into what I see as the main challenges for being a junior developer
00:00:48.600 and I'll talk about my tactics for how to overcome these challenges there is a lot that I want to cover but if you're
00:00:55.079 taking notes and happen to miss something I have written a uh post for the new Relic blog that went up this
00:01:01.199 morning that you can reference um and I also have a link to my slides at the
00:01:07.360 end so how many people here are junior
00:01:12.439 developers okay awesome cool um and how many people did something else
00:01:18.520 professionally before they worked as developers nice okay so we are like
00:01:24.400 amongst our own people here right very cool um for me being a developer is
00:01:30.400 probably like the fourth or fifth career I've had at this point it's hard to keep
00:01:36.079 track some of the other jobs I've had in the past are things like product Specialists tech support I used to work
00:01:42.520 in a biology research lab and I also did some copy editing on the side so the thing is compared to people who have
00:01:49.719 been coding since they were kids I am literally decades behind um this makes
00:01:56.960 me just feel like I have so much to catch up on um however something I've realized is
00:02:03.719 that being a developer is essentially about constantly learning new things and
00:02:09.479 guess what I'm pretty good at that I'm really practice at it with picking up a
00:02:14.879 new career and starting over and over again and so despite what my parents
00:02:20.760 think I like to think that my previous lack of direction is now an
00:02:28.519 asset the other thing I've realized over the last few months is that a lot of it can actually have nothing to do with
00:02:35.879 coding if you've spent a lot of time doing something besides computer science
00:02:41.480 that means you have more experience for all of the non-coding portions and that means you can leverage those skills and
00:02:48.599 that experience to help your team while you get better at the technical
00:02:54.599 aspects my thesis is that just because you switch careers doesn't mean you're
00:03:00.040 starting over entirely and in fact you can still use those other skills that
00:03:05.680 you have you may already know the different tactics I'll be talking about today so I
00:03:11.920 hope I can prompt you to consider new angles and get excited to apply them as a junior developer there will be
00:03:19.319 sections that are actually more targeted towards mentors but if you have a mentor and uh you know he or she doesn't happen
00:03:25.760 to be here today maybe you can bring some of these ideas back to them and discuss
00:03:30.959 for senior any senior developers that might be in the audience I hope to help you remember what it feels like to be on
00:03:37.760 that Junior side of a mentoring relationship and think about ways that you can help your proteges feel valued
00:03:44.680 in a very concrete kind of way I think there are two big reasons
00:03:51.200 for why it's hard to be a junior developer first there's a ridiculous
00:03:57.319 amount to learn how many people feel like that yeah like pretty much everyone here
00:04:03.959 cool second I think it's also really hard to know how you can help your team
00:04:09.920 and not just feel like this helpless little baby bird here I'll talk a little bit about these
00:04:17.400 challenges and how to handle each of them in turn my three-step foolproof plan to
00:04:25.520 tackling the fact that there's a ridiculous amount to learn is really all about not trying to do it all just on
00:04:31.880 your own getting people to want to help you in the first place can be a little bit
00:04:38.080 of a hurdle sometimes depending on how supportive an environment you happen to be in I've been really lucky at New
00:04:44.639 Relic but I think there are always things that you can do even if you feel a bit more isolated people fundamentally
00:04:51.639 just aren't all that different wherever you go a lot of this boils down to so-called
00:04:58.560 building relationship ships um but I prefer to think about it as really just getting to know people and making
00:05:05.479 friends because of course friendship is
00:05:10.880 Magic I personally find this pretty hard because I'm actually a pretty strong introvert um I fully expect to spend
00:05:18.800 most of tonight like huddled in a ball like trying to recover from
00:05:24.160 today but you know the thing is a lot of developers by and large are also pretty introverted as well
00:05:30.240 and so sometimes it can be hard to try to get the conversation going um you know even if you're you know both really
00:05:36.720 want to connect luckily at my last job I worked with PM in engineering and came
00:05:42.840 up with a few hacks what I do is I try and pay
00:05:48.080 attention to to try to remember small details that people have told me especially about their lives outside of
00:05:54.759 work sometimes it's actually even easier for me to remember these details than
00:06:00.160 people's names but usually people are pretty forgiving once I tell them I do
00:06:05.680 actually remember talking to them for like two hours about their love for like
00:06:11.880 antique banjo collecting or something like that this makes for much better
00:06:17.120 conversations than your typical small talk another really dorky thing that I
00:06:23.400 do um is that I actually sometimes mentally prepare stories to get a
00:06:28.639 conversation going like right after a weekend I'll try to think of something interesting or odd
00:06:35.039 that I did so that I'll have a non-generic answer ready for when someone asks how was your weekend
00:06:41.919 otherwise I just kind of freeze up and just say oh good which is kind of a boring answer and doesn't really get
00:06:48.520 conversation started does anybody else have that knee-jerk reaction sometimes yeah
00:06:55.360 totally well with a story to tell what I find is that this can them prompt questions and get some back and forth
00:07:02.440 started uh which breaks through any awkwardness there might
00:07:07.520 be helping breakthrough awkwardness is also something that mentors can do a lot to help with mentors are really great
00:07:14.879 for guiding newbies around team culture and history they can help make
00:07:20.759 introductions and give advice on how to approach other people like what the two of you may have in common or who's a
00:07:28.039 good person to ask about what also I think that if your company has a
00:07:34.520 support team you should definitely make some good friends there support tends to
00:07:40.599 be a little bit chronically undervalued but they probably know way more about the product than you do and if you think
00:07:47.280 about it they're very practiced at explaining the product to newbies like
00:07:52.319 your fellow customers when I worked in tech support sometimes they would have Engineers
00:07:57.599 Shadow us so that Engineers could learn how the customers actually used our product and use it to inform um design
00:08:05.039 decisions that they might have and I definitely always preferred the engineers that were really eager to
00:08:10.560 learn from me another key component to getting people to want to help you is to
00:08:17.400 demonstrate that you value the time that they're taking and so that you took a
00:08:22.919 reasonable amount of time to get as far as you could on your own each time
00:08:28.080 someone helps you you be ble to learn new tactics and push yourself just a little bit farther before the next time
00:08:34.880 you have to ask a question again when you do ask for help you can also ask questions like if you're busy
00:08:42.959 who else could I talk to about this when someone does help you you can always end with asking something like is
00:08:51.279 there somewhere I could have found this answer on my own and if the answer is no and there isn't any good reason it
00:08:57.600 doesn't exist already you should add it when you do have someone's time try
00:09:04.519 and think of ways to sort of push out and extend what you're learning from them at that point in time that way
00:09:11.519 you'll be equipped when a variation of that same question comes up again lastly for getting people to want
00:09:18.920 to help you something just as simple as showing your appreciation really goes the Long Way great mentors and teachers
00:09:26.880 would of course probably do it regardless but I just think it never hurts to make
00:09:33.200 people feel extra good about doing something that helps you making sure to
00:09:38.880 notice when people have gone out of their way to help you encourages more of that to
00:09:45.000 happen if you're working somewhere that's big enough where not everyone knows what everyone else is doing you
00:09:51.440 can also do things like let people's managers know when they've been particularly helpful most managers like
00:09:58.200 hearing good things about their reports and most people like their managers to know the good things they've done for
00:10:03.519 the team so it's just a nice thing to do all around we've covered step one now of
00:10:10.399 getting people to want to help
00:10:16.440 you step two is make it easy for them to help help them help you there are a few
00:10:25.320 different ways you can do this I think actually that one of the
00:10:30.399 hardest parts to learning is just letting people see inside your head and
00:10:35.920 understand where you're at right now but this can be really hard in a field like programming where sometimes you might
00:10:42.399 not even have the vocabulary to express what it is that you don't understand because you don't understand it great
00:10:50.200 teachers can draw it out from you even when you're asking pretty vague questions but most people that you work
00:10:55.680 with probably aren't highly trained teachers so there are ways that you can make it easier for others to help you by
00:11:02.560 articulating the premises that you're working off of and the logic that you're using so that together you can narrow
00:11:09.639 down what it is that you don't understand or I'm missing you can say things like you had
00:11:16.720 me up until such and such a point or I'm confused because I thought you said this
00:11:24.760 and then this but it doesn't seem to lead to this point
00:11:31.120 this is a good General format for describing problems that you might have say what you're trying to do and why so
00:11:38.360 that someone can jump in if that's not even actually the right goal to be aiming for in the first place also
00:11:45.600 describe your current problem and what you've tried already sometimes people might jump in
00:11:51.240 quickly with their idea of what the answer to your question is already but it think it's still good to be prepared
00:11:57.880 regardless and if if you're a mentor just consider that you should check to make sure you understand the question
00:12:04.920 before you go ahead and answer it when I worked in tech support the best clients actually put all of this
00:12:11.279 information upfront in their ticket which saved us a ton of time on the back and forth from just trying to even
00:12:18.040 figure out what the question was remember that Just Having the
00:12:23.920 courage to say I don't know is a strength Expos cling your own ignorance
00:12:30.079 feels really scary so I'm always practicing actually saying things like
00:12:35.920 wait I don't even know what that word means say this all the time but it is
00:12:42.480 something that's vital to understanding what people are talking about the sooner I tell people I don't actually know
00:12:48.800 what's going on the sooner I can get to actually learning and
00:12:54.800 working of all the advice I got when I started at New Relic this one is my very
00:13:01.360 favorite one of the best things that mentors can do when Junior developers are confused is even just validating
00:13:08.519 that feeling being honest and saying this is confusing for me too it always
00:13:14.880 without fail makes me feel better when someone I expect to know the answer
00:13:19.959 actually says they don't they don't know it either and then it becomes this team
00:13:25.079 effort to figure out how to get out of this hole of ignorance together
00:13:30.279 it's also cool because when you work with someone that also doesn't know the answer you'll frequently learn new
00:13:35.920 debugging techniques that you can apply yourself next time now I want you to think back to the
00:13:43.760 last few times you asked someone for
00:13:51.800 help okay how many of you after you got help from someone heard something from
00:13:58.040 them that was like did that help a few people yeah I get this all
00:14:04.959 the time and I realize that this is because most of us are really needy and
00:14:11.079 want validation that's because and so my favorite feedback what I get from people
00:14:17.040 um is usually people telling me that they actually used any advice that I gave them so when you tell people
00:14:23.639 specifically what it is they did that helped you they'll know what they can do more of for example it really helped me
00:14:32.399 when you walked me through how to use these tools with this example or it
00:14:38.320 really helps me to be the driver when we pair program because I absorb more than
00:14:43.839 when I'm just shadowing one way of looking at mentoring relationships that I really
00:14:50.079 like is from a book club we had at New Relic when I first started called managers as
00:14:56.440 mentors the idea there is that mentoring should not be about this traditional
00:15:02.160 mindset of a one-way transmission of information and instead it's the
00:15:08.040 mentor's responsibility to create a safe environment and remove any barriers to
00:15:13.519 learning so that their mentees can speak up about any fears they might have and
00:15:18.959 not be afraid of failing this way they can learn a lot
00:15:24.160 more and a lot faster I know for me making the move
00:15:30.560 from just working on my own projects that no one was depending on to working
00:15:36.000 on something that actual people were paying us actual money for was pretty
00:15:43.639 terrifying sure we have this idea of failing fast but it's so hard to apply
00:15:49.560 it when you don't feel secure what helped me was all the
00:15:55.000 support that I got from mentors sharing their stories about how they' mess things up too and the idea that it's not
00:16:02.079 a matter of if you break production but when and when you do make mistakes your
00:16:10.199 team should have processes set up in place to make it easy to recover quickly
00:16:15.759 and ways to try to prevent that same mistake from happening again if none of
00:16:20.800 these processes exist already you should try to help establish them because if
00:16:25.920 just one person can ruin everything thing that's a pretty big problem for
00:16:31.440 the entire team something I'm a really big fan of
00:16:36.560 as well is just having a direct conversation upfront about someone's learning style along with the other
00:16:43.440 person's teaching style this way you can try to sync them up and talk through any
00:16:49.399 mismatches ahead of time before there's any conflict it's great when mentors show
00:16:54.639 that they're open to feedback along the way as well so that they can continue it ating and adapting their style to match
00:17:02.079 whatever will help the junior learn best it's also really important to talk
00:17:08.240 about how you prefer to be interrupted my mentor at New Relic David told me that I could interrupt him
00:17:15.160 pretty much any time and because he was really clear and direct with me when he
00:17:20.760 couldn't help me right then and still always gave me some other resource to try I had that much more confidence in
00:17:27.760 it being okay to interrupt rather than bottling it all up and just saving it
00:17:33.039 for our designated weekly meetings when I started David's desk was
00:17:39.679 right next to mine so that even when I was talking to other people he could sort of lightly listen in and jump in
00:17:47.200 whenever it was clear to him that I was missing something fundamental as my mentor he had a better
00:17:53.760 overall understanding of where my knowledge level was at so he could help
00:17:58.919 others help me too if as a mentor part of your
00:18:05.360 philosophy is to let people struggle this is also something that's good to make clear
00:18:10.760 upfront it's really good to talk about this because that way you can let the Juniors know that you are intentionally
00:18:17.440 doing this and it is out of a faith in them rather than setting them up to fail
00:18:22.919 or having misplaced expectations just being reminded that
00:18:27.960 you expect to be hard goes really far towards dispelling any sense of imposter
00:18:33.280 syndrome where you might have this sinking feeling that it should be easier
00:18:38.360 but that's wrong it's supposed to be hard finally I think it's ideal if you
00:18:44.640 can push up responsibility for deadlines the junior developer's job is to keep
00:18:49.840 everyone up to dat so that no one is surprised by how much work is left to do
00:18:55.240 on one project a couple months ago when I was freaking out because it felt like it was taking me forever to learn even
00:19:02.159 just the basics of D3 one of our project managers came to me and said that shuffling resources is his job so that I
00:19:10.520 could go back to learning and struggling and if at any point the project deadline was in danger the burden wasn't entirely
00:19:17.799 on my shoulders now we have covered these
00:19:23.240 first two steps we are just a little bit halfway through so I just want to take a real
00:19:28.400 quick break humor me if you could all just sort of sit forward in your chairs a little bit thank you and go ahead and
00:19:36.600 just put your arms behind your back like this and just try to stretch and pull your shoulders down and back a little
00:19:43.320 bit just try to counteract a little bit of the terrible posture a lot of us
00:19:48.520 probably have when we're hunched over a computer okay cool feels better I do
00:19:54.280 this a lot when we do standups actually because it's like a good time as any to stretch and be slightly more
00:20:02.360 ergonomic all right back to where we were the final step in tackling how much
00:20:09.159 there is to learn is much like how you'd approach any other gnarly technical problem narrow your
00:20:15.960 scope mentors are highly helpful here too because they can help prioritize
00:20:21.120 what to learn next for example one of my things is that I still actually need to
00:20:26.760 build a rail zap from the beginning know that it's important to deliver
00:20:32.799 recommendations at the right time if a mentor gets really excited about yet
00:20:38.080 another new thing to add to the junior developer plate and just sort of blurts it out right then this can sometimes be
00:20:45.240 taken a little bit like wow it must be really important to be told right away
00:20:50.600 that I need to know this maybe I should know this already which at least for me
00:20:55.760 can sometimes lead to a little bit of a death spiral of
00:21:01.600 self-doubt you also have to match up learning style with a tutorial style
00:21:07.159 this is important because a lot of programming tutorials well they're kind
00:21:13.120 of like this how to draw an owl step one draw some circles step two
00:21:21.360 draw the rest of the owl how many people have done tutorials that are like
00:21:26.480 this yeah well even on more detailed tutorials
00:21:33.320 there are differences like whether the work is goal oriented or not for me it's
00:21:39.000 actually harder to stay motivated when I don't have a specific thing that I'm trying to accomplish I like structure
00:21:46.640 and being to free form actually means that I'll get bored for example I took
00:21:52.279 calculus in high school and it was fun and interesting but it wasn't until I took physics in college that I was like
00:22:00.200 oh that's what calculus was invented for but that's just me and other people
00:22:06.960 might be similar or very different also in terms of content my
00:22:13.159 personal view is that the highest value areas are things like team processes for
00:22:18.279 code review and Version Control like git and specific product uh product knowledge over more generalized
00:22:25.039 programming knowledge this might be be a bit controversial but I think less useful
00:22:31.679 are actually things like getting too much into optimizing your tools your environment or even learning tons of
00:22:38.159 keyboard shortcuts at least to start keyboard shortcuts are fun and useful
00:22:44.919 but let's be honest right now how fast I can type is not the limiting factor and
00:22:51.320 how fast I can complete a future so that wraps up my ideas for how
00:22:57.279 to tackle this first challenge of how there's so much to learn as a junior developer next I'll talk about ways that
00:23:04.279 even Junior developers can help their team
00:23:12.400 immediately knowing how to help your team is hard because maybe you feel like you're a drag on your team's
00:23:18.840 productivity with how much help you need right then how many people have felt like
00:23:26.080 this well in one of the first convers ations that David and I had I actually pretty much straight up asked him um how
00:23:34.279 did you get stuck with me to his and nurel's everlasting credit
00:23:39.720 he immediately reassured me that it wasn't that he got stuck with me but that he wanted to learn to be a good
00:23:45.919 Mentor himself so it was from there that I realized ah even my ignorance can be
00:23:52.760 helpful for the team when it gives them opportunities to practice things like mentoring
00:23:59.640 also even if you are a junior developer your technical contributions are still
00:24:05.840 important yes you may be working on features that someone else may make
00:24:11.320 faster but in a world where there's never enough Junior Developers for all the you know or just developers in
00:24:17.400 general for all the Developer jobs that are out there it's not actually necessarily a choice between a junior
00:24:23.960 developer building it slowly and a senior developer building it really quick
00:24:29.200 it's a choice between having something built and not having it at
00:24:34.960 all don't forget either that everyone started out at your point at some at some time and you won't be at your
00:24:41.919 current stage forever as my Southern friend likes to draw no one comes out of their mama's
00:24:48.279 womb knowing how to code just think about that for a
00:24:56.240 minute so onward to some of the other non-technical ways you can help your team right away first I really strongly
00:25:04.679 believe that questions are basically the junior developer superpower and as we
00:25:10.600 all know with great power comes great responsibility fresh eyes are helpful
00:25:17.000 but you can specifically figure out how to be an extra helpful set of fresh eyes with the use of skillful
00:25:23.600 questions good questions are invaluable for highlighting assumptions and helping the team avoid dead ends which helps you
00:25:30.880 all move faster questions like are we working on the right thing or is there a reason
00:25:38.720 we're doing it this way this is something that came up in my old job too because sometimes this uncovered an
00:25:46.120 actual misunderstanding about a feature's requirements where like an off-hand comment from a client email got
00:25:53.480 interpreted as a musthave item getting rid of these kinds of things saves
00:25:58.760 everyone a lot of time and disappointment has anyone here ever worked as a consultant or project
00:26:05.320 manager at all so you probably have similar stories like that
00:26:10.799 too of course you do want to ask your questions in a way that won't put people
00:26:16.039 on the defensive if someone hisses at you that's probably not a good
00:26:21.720 sign try to express humility since you're asking these questions from a place where it's because you want to
00:26:28.360 learn rather than assuming that you already know you can also think about questions
00:26:34.559 that other non-engineering people might ask like your sales or support teams
00:26:39.799 getting these answers earlier on gives your team a jump start on looping in other teams as needed and if the only
00:26:46.279 answers your team has are pretty vague that's an opportunity to dig further for greater
00:26:53.279 Clarity okay we're two-thirds of the way through the outline now
00:26:58.520 on the other side from asking questions providing constructed feedback is really important too if you've had another
00:27:05.600 career before now this is a skill that I am sure you have already practiced giving useful feedback to the
00:27:13.080 right person in the right Venue at the right time is hard for a lot of people
00:27:19.760 for me when I worked in tech support we'd frequently do quality reviews of each other's work to try to improve the
00:27:25.679 customer support experience and we'd also would just do General peer feedback every few quarters which meant that I
00:27:32.240 got a lot of practice at phrasing feedback in a way that wouldn't lose me any friends
00:27:39.640 hopefully before offering feedback I like to spend some time thinking about what would be useful to the person
00:27:45.720 receiving the feedback what is it that they want what are they trying to
00:27:51.399 do you always also get bonus points for bringing suggestions for Solutions with
00:27:56.760 you it's hard hard sometimes to refrain from nitpicking just for the sake of having something to say but it's worth
00:28:03.840 it to increase the value that people get from listening to you you just want to
00:28:08.880 have a really high personal ratio of useful to not useful things to
00:28:15.799 say something else I've been trying lately is to give positive feedback whenever there's an opportunity I don't
00:28:22.679 mean like fake positive compliments or anything like that at all but just that
00:28:27.760 it's a lot easier in most cases to complain about something than to remember to speak up when there are good
00:28:34.200 things to talk about my hope is that this is helpful in the longer term so
00:28:39.960 that I can build up a general reputation for being a positive person and any negative feedback I have will be taken
00:28:46.840 more seriously on the other hand sometimes giving good feedback can also mean just
00:28:53.760 stating I don't have an opinion on this topic so that you withdraw your self from the pool of people weighing in and
00:29:00.480 makes life a lot easier for whoever is in charge of getting the group to a
00:29:05.880 consensus so now we've covered two strategies for helping your
00:29:11.279 team lastly there's a lot you can do to make your team look good to other teams
00:29:17.159 it isn't all that hard it helps your team feel good and it helps other teams feel good too about working with your
00:29:25.640 team one of the common areas this can come up in is in any demo or review te
00:29:31.480 meetings your team might have you can give awesome demos just by being thoughtful and prepared think about why
00:29:39.080 this change matters to your audience why should they care and think about how you can show the before and after doing
00:29:45.600 things like grabbing screenshots so you can show new and old side by side or
00:29:51.080 gathering metrics to show why the thing that your team did is actually a big deal demos are also good for getting
00:29:58.159 full credit for your team for everything that they've done even ones that aren't easily
00:30:03.559 visible you can do things like talk about Corner cases and you know choices
00:30:08.840 that you either decided to do something about right now or have consciously chosen to delay so that it shows other
00:30:16.440 team shows these other teams that you've been thoughtful about your impact to them like the supportability of a new
00:30:22.480 feature you've released I like to over prepare so I almost always write a script which is
00:30:30.240 sometimes a literal word for word script but more often it's just a list of what I want to show in a particular order so
00:30:38.159 that it flows well and I don't end up having to backtrack because I've forgotten
00:30:43.679 something I also like to do a test run through so that this way I'll know
00:30:49.080 everything I need to get pre-loaded onto my computer which makes the demo really efficient and less prone to
00:30:56.919 errors in general making an effort to be responsive thorough and empathetic
00:31:03.760 really goes a long way I'm really proud of the time that someone on our support team at New Relic told me I was her
00:31:10.760 favorite engineer to work with mostly just because I was being really responsive all this just helps people
00:31:17.679 feel heard and knock down any stereotypes that Engineers don't care about what other people care about and
00:31:25.200 so this way when your team needs their help they'll be there for you
00:31:30.720 too that wraps up my ideas for how to tackle the challenge of figuring out how you can help your team even when you're
00:31:36.799 a junior developer before I finish up my talk I do want to mention a few caveats and
00:31:43.000 pitfalls to avoid I'm hoping that mentors in particular will help out with watching
00:31:48.240 out for these sometimes I think there's a bit of an issue in the tech community of
00:31:54.279 undervaluing non-technical skills and a lot of I've talked about is essentially
00:31:59.760 using your non-technical skills to help yourself move forward the thing is you
00:32:05.880 just don't want to be assumed to just be the secretary which I don't mean as a
00:32:11.039 Dison secretaries at all it's just not the job that I'm working
00:32:16.360 towards there's also a phenomenon called the Girl Scout tax which comes about
00:32:22.200 because we have a stereotype and expectation that women are helpful
00:32:27.279 unfortunately this leads to a lot of women not getting credit for the help that they provide because supposedly
00:32:34.639 that's just what women do they're helpful this is just one of those unconscious things that we probably all
00:32:41.399 do from time to time and so we should all try to watch out for it so that everyone gets recognized and appreciated
00:32:48.399 for the work that they do you just don't want to get sidelined or pushed into a role you're not
00:32:55.480 interested in everything I've talked about today is from the standpoint that you're willing to do whatever is best
00:33:01.679 for your team in the short term but you all need to be doing what's best for everyone longer term as well which is to
00:33:08.200 help you grow as a developer ultimately keep focused on
00:33:14.559 whatever your end goal is whether that's getting better at coding working on bigger features or learning about the
00:33:21.600 market and Industry this way you can consciously choose what things you'll want do that
00:33:27.440 willing bring you closer to the goal and not do things that will move you farther away from
00:33:33.919 it these are some recommendations for further reading the first two are books
00:33:39.679 that are actually pretty quick and easy reads team geek uh is written by a couple of Google engineering managers
00:33:46.080 who actually co-founded the Google's engineering office here in Chicago and
00:33:51.399 that second book The Upside of down is a good book if you feel like you're being held back by a fear of fa
00:33:58.440 failure the other four are blog posts that I also found really interesting and full of good career advice for junior
00:34:06.919 developers so here's the full outline of everything I've talked about today I think there are two main challenges in
00:34:12.960 being a junior developer for the problem of there being so much to learn the three-step plan is
00:34:19.960 to get people to want to help you make it easy for them to help and narrow the
00:34:25.240 scope of what you're trying to cover for the problem of not knowing how to help your team always remember that good
00:34:32.679 questions are the junior developer superpower you can also do a lot by
00:34:38.119 giving good feedback and making your team look good in front of other
00:34:43.440 teams in conclusion we talk a lot about the benefits of diversity but if you're
00:34:49.399 the one that's bringing diversity to your team that can be hard because the typical narrative won't use your
00:34:56.399 particular strengths that much because by definition they're different as my first boss told me we
00:35:03.960 can and should work on our areas for development but it's really your strengths that you can lean on most
00:35:10.640 heavily to get you where you want to go so to all the junior developers and
00:35:15.960 career switchers out there I just want to say you deserve to feel confidence in yourself as a person place your
00:35:23.280 confidence in your proven ability to learn over your current level of coding knowledge it's only a matter of time and
00:35:31.040 I hope I've helped you shorten that amount of time as a junior developer and to someday when you'll be mentoring
00:35:36.880 Junior developers yourself thank you