So You’re a (Junior) Developer – Here's How to Learn

The web is littered with advice for Junior, Mid, and up-and-coming Developers, and I’ve found a lot of it to be really helpful. The challenges for new developers are real. Imposter syndrome is real. There is a lot to learn, and many people who are much, much smarter than myself have described eloquent roadmaps for navigating the developer path.

One of the most common recommendations is to “commit to learning” or something similar. Most developers would agree that this is essential, though it’s perhaps a bit vague, so what follows is my attempt to outline some best practices for learning on the job. As per usual with these things, take what’s useful and ditch the rest.

Before diving in, let me mention that in addition to the plethora of material available specifically for developers, there are somewhere between twelve and thirteen trillion articles, videos, and Ted Talks out there detailing various learning hacks and deconstructing the learning process.

A bedrock theme in most of them is this: some learning is unconscious, intuitive, and happens automatically – despite your weekend’s best efforts to inhibit or alter your higher cognitive functioning. Experts seem to agree, though, that the most effective learning (for an adult intent on gaining competence at a new task) is intentional, purposeful, self-aware, and consciously undertaken.

Process over Product

Most of the time in software development, the default is for things to be broken, so get used to that feeling. Clients don’t phone panicked in the middle of the night to tell you how well things are working. Your Pull Requests are unlikely to be met with unbridled enthusiasm. Your first attempt at a solution will very often fail miserably.

So one key is to focus on “the getting there” rather than on memorizing whatever the unique solution to a given problem happens to be. You will continuously be confronted with novel situations. In order to tackle novel situations, you must get better at generating insight…i.e. you must get better at approaching problems, not necessarily at solving them. It’s like taking a road trip. Memorizing the pattern of left and right turns that got you to one particular destination will not often be useful for getting somewhere else.

It’s not your job to know exactly how to get there in advance (though it’s fun to be psychic). It’s your job to head off in the right direction and then read the signs and make sensible decisions along the way.

Don’t Ask Questions… Yet

First, struggle. Finding a problem you cannot immediately solve is almost always a gift. It creates tension, and in this tension lies the possibility of growth. Don’t rush to Stack Overflow or consult your peers to relieve the tension too soon. Try things. Make things up. Consult official documentation.

Then seek answers from colleagues and online forums.

Break things… Mostly

It’s understandable to be cautious as a new developer. Breaking other people’s apps is scary. One of my big mistakes early on was being too fearful of breaking things, even when I was working locally, or on a staging server.

You will learn at least as much, and arguably more, by failing than by succeeding. (You don’t automatically learn from failure or success — intentional follow-up afterward is where the learning actually occurs – see “review your work” below.)

Ok ok, this is all within limits…one can have a healthy fear of production servers… but even then, encourage yourself to dive in, and recruit a more experienced colleague to spot you if need be.

Review your work, every time.

Keep records: Error logs and victory logs:

• Give yourself an exit interview after every medium/big ticket/feature/sprint
• Note your errors or stumbles
• Note your victories - especially the close calls where you weren’t certain but took a leap and ended up being correct. Several studies have recognized the increased impact of giving critical attention to your successes vs. only reviewing your failures.

Articulate actionable takeaways

• Keeping records or seeing your errors is useless if you aren’t articulating the superior actions you wish to take next time around -- in actual words, not just feelings. Peer feedback, PRs, etc. are great…but at the end of the day you are responsible for your learning, and your compassionate and critical self-review is an essential piece of the puzzle.

Don’t just seek mentors … Create them

We all want Gandalf to show up and give us a map to adventure, words of wisdom, and maybe a magical something or other (...don’t we?), but that rarely happens. And you certainly can’t make it happen. One thing you can do is take an active role in making mentors out of the people around you. After all, your colleagues have accrued knowledge and -illions of experiences that have immense value to you – part of their journey to becoming great mentors is learning to access those experiences and communicate them. Give them opportunities to do so.

Tell them what they’re good at, to you. I told one developer recently, “I have a question for you, because I think you have strong opinions about design patterns”…

“I do?”, he said, sounding amused.

His opinions and knowledge about design patterns and architecture best practices have been really illuminating for me, and by telling him so, and framing him as my resident expert on the topic, I invite him to own that aspect of his expertise, to see his thought process with a bit more clarity, and to be vocal about those opinions. In other words, in small ways, I coach him into being the mentor I need.

And don’t always ask the most senior people. Someone closer to your own experience level is often likely to explain the issue in ways that are more accessible to you, or to ask follow-up questions that mirror a slightly more complete version of your own thought process, rather than describing a masterful and jargon-filled view from above, like a senior developer might do. This trait is well observed in children, who very often learn more effectively from other children than they do from adults.

Finally, humans are storytellers (and story-listeners), so encourage your peers and seniors to tell their stories and they will naturally become better mentors. You can do this by asking questions beyond “How do I do X?”

For example:

• “How did you know..?"
• “Why did you...?"
• “If you were going to abc, what ‘gotchas’ would you watch out for?"
• “What’s the worst deployment mistake you can remember making?.”
• “I’ve heard you guys talking a lot about xyz recently…what’s going on?"
• “Huh?” Don’t be afraid to look clueless. Humble thyself!

Answer questions

Teaching is a critical step on the path to mastery, and it’s never too soon to start. The moment you’ve experienced a cycle of breaking-struggling-succeeding-reflecting … you have a story to tell. Tell it! Share your stories with others on the team, answer a forum question, speak at a meet-up, write a blog...

Don’t always wait for more senior people to jump in when team members ask for assistance. You may not have the answer, but more often than you might think, your thought process can help senior devs see their problem with new eyes. This is a critical part of problem-solving – it’s about perspective just as often as it’s about knowledge.

Repeat

This never, ever stops.

Well there you have it, a few ideas for enlivening your learning process. Remember that trial and error is the fundamental learning process, so get out there and make some errors! And then reflect on them, engage with them, articulate them, and use them to fuel your growth.