Your SlideShare is downloading. ×
The Care and Keeping of Your Junior Developer
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

The Care and Keeping of Your Junior Developer


Published on

There are far more open jobs for developers than there are people to fill them. So what is the solution? Here are some strategies for shaping a junior developer into an effective, contributing team …

There are far more open jobs for developers than there are people to fill them. So what is the solution? Here are some strategies for shaping a junior developer into an effective, contributing team member.

Published in: Software
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. The Care and Keeping of Your Junior Developer Bonnie Mattson @BonMatts
  • 2. Why Junior Developers - Aren’t enough senior developers - Hiring picasso to paint your apartment - Senior developers tend to be set in their ways - With talented management, and good process, junior developers can fill some of the talent void
  • 3. Junior Developers are great! “Helping grow someone into a fully functioning member of the team makes our team stronger in the long run, and helps us pass along good process and behavior practice into the organization.”
  • 4. Overview 1. Survey 2. Positive Company Culture 3. Mentorship/Guidance 4. Clear Expectations 5. Advice for Junior developers
  • 5. Survey Demographics Gender Identity women 63% men 29% genderqueer 4% no answer 4% Experience < year 22% 1-5 years 40% 10 years 19% >10 years 19% Job Level junior 31% mid 41% senior 24% other 4%
  • 6. You are going to fail.
  • 7. Do you get imposter syndrome? “Often. Writing about whatever I was doing, and having other developers bring it up later was a great confidence boost” “I finally became comfortable calling myself a software engineer around the time I became a team lead. Until then it just seemed too rarified a title for me. Recognizing (or probably more so, others expressing) how advanced my skills were compared to my colleagues.” “Constantly. I started programming late in life compared to most, and even once I get good at it, I'm not sure it's possible to get fully caught up with someone who is my age or younger with 5 or more years of experience on me, or even someone with the same length of experience who has had the luxury of more learning time.” “ [It was frustrating] not knowing if difficulties were because I didn't understand something or because it was not well designed, broken, etc.”
  • 8. Positive Company Culture Combating Imposter syndrome! - Overall Positive environment - Diversity - A culture of sharing knowledge
  • 9. Don’t be this cat. “[I found it frustrating] when I wouldn't get something and a team member would say things like "How are you not getting this?" and becoming clearly frustrated when I wasn't getting something right away. This was so discouraging.” “ [When I had questions, I ] struggled, asked the internet. Asked senior team members as a last resort, knowing that the response I'd get would be rude and condescending.“ “ [When I had questions ] I asked people. Or, I hid in the stairwell because I was afraid to ask them, because they clearly didn't want to be asked. I hid in the stairwell a lot.”
  • 10. - No Feigning Surprise - No well-actually's - No back-seat driving - No subtle -isms Hacker School Code of Conduct
  • 11. Culture and Communication “ [I got over my imposter syndrome through] transparency and feedback. It's scary and vulnerable to open yourself up, and it is up to the senior developers and managers to lead by example and create social norms where it is safe to do so, but there is no way to get a sense of how well you are doing relative to others without both of you working out in the open.” “The most valuable-for-my-career class I took in college was actually a poetry class, where I learned to think very carefully and systematically about word choice, metaphor and creative collaborations. “ “ [I found it helpful to ] Just watch people program . . . it helps make it clear what things are ‘normal’.” “Communication is far more important than technology skill. Flat or no hierarchy means it is implicit.” “ I am lucky though because I have a great co-worker who is always available to answer anything for me. Knowing that I have that is very empowering.”
  • 12. Diversity A comfortable developer is quicker to adapt, and consequently more productive.
  • 13. Culture of Knowledge - Project Presentations - Education Budget - Company Library - Experienced programmers given time to share their knowledge
  • 14. Mentorship/Guidance - Direct mentorship - Positive feedback - Documentation - Pairing/ Code reviews
  • 15. What makes a good mentor? “I've not had any good [mentors]. Some were not available enough. Some assumed that because they were senior they had nothing to learn from juniors.“ “ [a good mentor is] someone willing to listen and take time to explain, even if they've got their own deadlines to fight. I've learned the most from sitting with some of the brightest people at the company to figure out a problem, and would consider them an excellent mentor.” “A good [senior developer] is one who sets a good example by consistently doing good work and writing good code and do helpful code reviews.” “Explaining why a certain approach works. Passion for coding. Helping think about a problem or approach.” “I rarely had someone knowledgeable to ask questions. I had to figure most things out on my own. I would have loved to have a more senior, knowledgeable person to learn from.” “A lack of ego, patience and the ability to trouble-shoot *why* a junior developer is having a particular problem and address the underlying problem (ideally while teaching the developer the skills to do that for themselves in the future.) It's all about that extra step that the junior developers might not know they should be taking.”
  • 16. Senior Devs = College Professors Teaching is part of the Job.
  • 17. Time Management One cannot mentor while also maintaining a full workload of a senior dev. Productivity will decrease.
  • 18. Positive Feedback Chart Positive Negative Specific General It was really smart how you made that method a helper and re-used it in other parts of the code. That was really DRY! Nice job! Looks Good! Your code looks really bad. That was terrible. This code does not follow the style guide for these specific reasons. Might I suggest these revisions?
  • 19. Positive Feedback Compliment sandwich! “Thank you for reporting that bug! It would be helpful if you could let us know which version of the code you found it in. The detail you did provide on recreating the bug was excellent!”
  • 20. Thoughts on Feedback “Having the right manager is really key. My original manager was great with former interns, but I had another manager come on and he hadn't worked with programmers as inexperienced as I was. At some point he gave me feedback, and while I'm usually super fond of feedback, he gave it in a subpar manner, made me stress out thinking I was going to get fired. He didn't know how to give positive comments to push me forward when I was already really down on myself because the whole experience was frustrating.” “Getting the first job with comprehensive code reviews, short, small projects, rapid iterations and realistic expectations was amazing. Feedback is the most useful learning tool, second is the chance to see the code of more experienced developers and third is trying a bunch of different things to develop personal experience. But without useful feedback, just trying a bunch of different things doesn't necessarily lead to progress.” “[A good mentor has ] patience and solid constructive criticism of code and other behaviors. Immediate or quick feedback on issues 1-2 days. Ability to mold aptitude into ownership and responsibility.”
  • 21. Thoughts on documentation “I say I found documentation useful - but that's only true when it was GOOD. Most of it was wrong or incomplete which was not helpful. People should write better. “ “The biggest struggle I faced as a junior was a lack of documentation, lack of process, lack of chain of command, and the rude attitudes of other developers with 'holier than thou' attitudes.” “There was a senior person to me on the team, but he was grouchy and mostly didn't want to be bothered. I learned a lot on my own, and wrote documentation for the next people to come along.” “People. People, people people. Searchable documentation.” “Stepping into a new position and not having any documentation for getting our software up and running. Knowing that there are small bugs I could be helping with, but not being able to access them. Bug documentation that doesn't specifically point to the problem. “
  • 22. Documentation! - Inline - Internal wiki - Requirements - Unit tests
  • 23. Thoughts on Pairing “I work at a pairing company, and after my first month of pairing and getting to know the codebase, I did a one month solo project where I built out some admin tools. It really helped to have that time to integrate the things I'd been learning from pairing and find the holes in my knowledge.” “Pairing sessions are the most helpful for tracking down and resolving difficult bugs. Both mentor and mentee will get the most of the pairing sessions if they had done some prep work beforehand. Pairing helps the mentee see ways to be more productive on the command line.” “Pairing is amazing, but I still have a hard time driving when I know significantly less than the person I'm pairing with. (I also find it challenging to be the senior pair with our new interns — both sides of junior/senior pairing are pretty challenging.)” “Pair programming was both good and bad. I needed some solo time otherwise I couldn't figure out how to do the same things that I did yesterday. However, my questions were more easily answered with pair programming.”
  • 24. Pairing! - Mutually beneficial - Juniors pairing with juniors - Set time aside for pairing -Offer and ask to pair
  • 25. Code reviews - efficient use of time - reviewee should explain work - how requirements were met - how they came up with the implementation - reviewer should provide constructive feedback
  • 26. The benefits of mentoring a junior developer “I really enjoy being able to watch their code improve, their confidence grow and building a team that shares the vocabulary to collaborate effectively. I'm good at figuring out why other people are doing what they are doing, which makes me an effective mentor. Plus they are really impressed when I can remote-diagnose their bugs: it gives me perspective on how far I have come and highlights the useful skills I have.” “They're more willing to try different approach - not stuck in old patterns.They learn quickly, ramp up - more visible progress since there's so much to absorb initially” “That time and energy is an investment which, when it starts to pay off, is rewarding both in terms of increased productivity, and having another great person to bounce ideas around with.” “I probably learned a different skill set from talking to a newer developer and finding out [their] interests and experience... and we were able to build a working relationship that way.”
  • 27. What do you wish you knew before your first developer job? “How to tie my very theoretical and abstract education into actual day to day work. They have seemed very disconnected until recently.” “Processes and best practices for certain programming tasks.”“Knowing how to use tools.” “More linux, more terminal stuff. How to cut up text files at a terminal prompt. More scripting languages.” “Process workflow. How public and private keys work. How to setup a dev environment.” [I] wish I'd known how much of the development process does not involve actual programming. “Wish I knew a little bit more devOps stuff.”
  • 28. Clear Expectations - Process! - Reasonable Goals - Well-written Requirements
  • 29. Process! - Methodology - Ownership/responsibility - Basic DevOps
  • 30. Goal Setting “ I wish I had a mentor to help me set time goals in correlation with the size and speed of the project, eg: "If you get stuck, only let yourself struggle for one hour before coming to me for help." “Structure is really important. Need to have clearly defined goals for learning.” “[I found] Tasks that are far past my skill level with little support to complete them [frustrating]. Not being allowed input on my own estimates.” “A good mentor give[s] the mentee helpful expectations : intersection of business needs and tasks where the mentee stretches himself/herself but is able to finish the task.” “[I found] projects with clear goals [helpful], or project management that lead to clear goals.”
  • 31. Reasonable Goals Do not expect someone new to complete as many tasks as you would someone experienced.
  • 32. Thoughts on projects as a junior “[I found] Very short projects [helpful. It limited the scope of the implicit project management I had to do (which is an often-overlooked skill programmers have to master).” “hunting for bugs gave me the best experience with a broad system.” “I loved when I got a chance to try something new or got something working that seemed complicated, like encryption.” “I love debugging code that mostly works. I need to be able to see the parts that are working so that I can understand why they work and solve the problem at hand.” “Building out our integration testing suite. This really helped me to learn the system and how it works.”
  • 33. Clear Requirements - Detail - What behavior is expected in minute detail - Implementation Suggestions - QA test cases written beforehand so the dev knows what they are up against
  • 34. What qualities does a good junior developer have? “Willingness to learn, to take on new tasks, go outside their comfort zone.” “Openness, willingness to learn, ability to figure things out when I don't give them all the information.” “I just get a feeling off certain people that they seem smart and willing to learn. I'm sure there is something more definable going on, but it's hard to put my finger on. It may be something about the way they approach things they don't know or are frustrating.” “General brightness, not necessarily programming skill. Curiosity, patience when problem solving, willingness to engage with a problem by breaking it down into smaller questions and not bringing too many assumptions that might lead to a quick, but incorrect solution.”
  • 35. Advice to Junior Developers “Google, read and debug code. Learning to use development tools to figure out what was going on was massively important, because then I could bootstrap things.” “Quickly adaptable is the best [quality]. I don't care if they've never written a unit test, as long as a month after they are introduced to the concept there are tests attached to every project. When I suggest using an enum someplace, I want to see that the next time that situation comes up they'll use an enum without prompting. I also want enough curiosity and independence that they are learning the whys for what they are doing at the same time they are doing it. Teaching generative principles is far more efficient than case-based teaching.” “ [A good junior developer is] stubborn. They've got the right balance of hubris and humbleness. Like they're willing to tackle the big problems, but also realize they might run their approach past a senior dev first. The ability to accept criticism is also important. You have to learn to choke down the urge to get defensive if someone criticizes your code. If you're code reviewing it's your job to be tactful about it, though.” “Everyone has impostor syndrome. Everyone makes mistakes - they won't get you fired, they're an opportunity to learn things. People around you are not programming gods.”
  • 36. TAKEOUT MESSAGE The tools that can be used to empower junior developers are useful for the entire organization, and everyone benefits.
  • 37. thank you. @BonMatts “I really wish every computer science program required enough liberal arts classes that students were all exposed to gender studies, post-modernism and basic social systems analysis. Also probably enough therapy that everyone was coming in with basic self-awareness.”