Three months ago I was hired as a full-time engineer at New Relic and made the transition from engineering intern to junior developer. In other words I’ve leveled up. I’m gaining new skills, finding new tools and fighting a lot of new bosses. There’s less structure to my projects, and (of course) more to learn and to remember as well.
I’ve found that in continuing to learn and take on more responsibility, there are some specific practices that have helped me cement my learning and integrate into the team. If you are a junior developer or a manager looking to add some juniors to your team (do it!), here are the best Developer (level 5) items in my inventory.
1. Have another junior developer around.
It’s just easier to ask questions when someone else is asking them, too. (Especially if everyone else in the room knows the answer.) My fellow developer James and I ended up pairing on a major bug. Since we work a little slower than those that have been here for awhile (and working as devs far longer), I think the solution was more firmly planted in both our heads. We can also trade knowledge. Since I’ve worked with our core application for three months, I can explain some of the details, while he has more knowledge of code design and the Rails framework.
2. Have active discussions about code and design.
James recently restarted the New Relic book club. Our first discussion, on the first half of Practical Object-Oriented Design in Ruby by Sandi Metz, energized me to code more and better. And hearing opinions (sometimes conflicting) on how it applies to our own codebase, instead of feebly trying to apply the principles to a small personal app, gave me real world examples of how to make changes to a mature codebase with daily commits from 50+ developers. These meetings are exciting for everyone in the group. The book reviews often spur us to take action on our own codebase, spend time cleaning up messes (instead of just complaining), and making sure our code is DRY, SOLID and all the other acronyms you can think of. So, the book club isn’t just for beginners. I think it helps a team spot issues and more importantly, by looking at design patterns together, share ideas and get inspired to refactor.
3. Give junior developers the same responsibilities as everyone else.
When you put your junior devs on the same footing as the rest of your team, you help them expand their knowledge of the code and the way things work. About a month after coming onboard full time, I was added to the support shift – what we call being the ‘Support Hero.’ This was great! Many tickets are common customer requests. They helped me learn what tools we use and have built, the difference between critical issues and small bugs, and who on the team is responsible for what.
4. Leave time to keep learning.
This is the best advice I’ve received so far. By doing this, I’m doing more than simply doing what is asked of me and moving on. I have time to make sure I pair, ask questions and spend time figuring out the why of a story, not just the how. Part of this effort you’ve already read about (joining our engineering book club, answering support tickets, etc.) But I also leave time to work on my own projects.
5. Keep a log.
Whenever I use something for the first time or learn something new, I write it down. This seems simple, but it’s easy to pass by or (ahem) convince yourself you’ll remember it later. Periodically, I’ll review my log to refresh my memory so that I can continue using what I learn.
As you can see, I’m still working on a lot of things. If you read my last post, you know I’ve recently completed a crash course in programming. And I’m currently catching up on CS fundamentals and the particulars of Rails. So, if you’re just starting your engineering career, or looking to hire, consider starting some of the practices above. Learning on the job is what most of us do, and good practices can have a multiplying effect on your progress and productivity.