Last year, I wrote an article titled The Catch-22 of Being “Too Junior”. It detailed high-level conditions that companies should assess when considering hiring “junior” developers. This article follows up that post.
During my first two years as a burgeoning developer, I maintained a list of things veteran engineers did that helped me evolve as a software engineer. Here’s that list in all its glory:
Explain jargon that new developers might not know or understand.
I actually wrote an entire conference talk on this topic. Software engineering and web development have their own vocabulary, which is not easily understood. Keeping this in mind helps people in all roles of a company, from product managers to support agents and salespeople. It’s also a great way to practice empathy.
Notice that someone in your conversation circle looks confused? Don’t keep droning on! Clarify. Not everyone knows what dependency injection is.
Walk new engineers through the code base.
Learning to search through a legacy code base is an acquired skill. Imagine your first day at your first software engineering job. Did you know where your team’s files were? Probably not.
To be perfectly honest, I didn’t even know I could search an entire code base. As a self taught engineer, no one told me about `grep` in Unix or about `cmd+t` in Sublime Text — I searched through files and folders using Finder. The first time I watched someone search a code base via Sublime’s shortcuts, my mind was blown!
It’s often hard to determine how everything in a code base is connected too, so watching my coworkers trace back through methods, classes, files, and folders in a repository opened my eyes to new strategies on searching and debugging on my own.
Give them read access to your database in a way that they know what data is available to them.
When I worked in Customer Support, read access to the secondary database was a god-send. It’s impossible to figure out why a customer can’t login with their email address if you can’t see the typo in their email address stored in the database. With database access, I could see problems at a glance and remedy them on the spot. It allowed me to see the hierarchical structure of our data and made it easier to wrap my head around interactions between our customers and app.
And coding with that knowledge helps new engineers strategize how to build their programs in a more maintainable or reusable way.
Let new engineers watch you debug, and explain what you’re doing.
It wasn’t until I watched another engineer open the Network tab of developer tools that I learned of its existence. Then I realized I could use that Network tab to determine why assets went missing from my web pages.
While a plethora of resources are out there for new engineers to learn to code, I can only think of one resource that teaches how to debug code. Watching a more experienced engineer debug familiar problems exposes newer engineers to strategies that are often not taught. And we all know that most programming is truly defined by debugging. 🙂
As a follow up, pair program!
Similar to paired debugging above, pair programming taught, and continues to teach me, about best practices, new concepts, and alternate ways of approaching a problem. It’s been an invaluable resource for me to progress my development skills.
Be sure to switch up pairing and let a new engineer navigate too — they can learn a ton by realizing what they already know and can teach to others. And please, never start typing or scrolling on their computer if it’s their turn to drive!
Don’t give them lines to copy/paste into the code.
Or if you’re going to do it, at least include some explanation of what that code is doing! I’ve had coworkers paste lines of code into a chat to fix problems. It often feels dismissive, and it’s hard to learn anything lasting from those instances. It also makes me reluctant to ask questions of that person in the future.
Consider scheduling time in the future to work on the problem together and/or explain the solution. Alternatively, if you’re swamped, send them a resource that they can reference for explanation. A little more effort makes all the difference.
Explain your expectations and time estimations for projects clearly.
I once worked on a project and built an entire JavaScript autocomplete from scratch. Turns out my manager actually wanted me to use a prebuilt library. As an untrained engineer, the idea that we borrowed code from other places was completely foreign to me. I thought we wrote everything from scratch!
Detailed project requirements, even in verbal form, can prevent headaches and/or unnecessary time sinks. Communication is queen!
Ask if they’re confused about anything and explain those things. Rinse. Repeat.
Don’t “wall of text” new engineers. In one sentence, you may have referenced five concepts that a new engineer is unfamiliar with. Make sure to ask if they have any questions or if you could explain something in more detail. Then ask again a few minutes later. Asking often will feel uncomfortable at first, but can help new engineers feel open and unembarrassed to ask questions in the long run!
Show them that programming is a marathon, not a race, and that no one knows everything.
As a new developer, I felt like I knew nothing and could never learn enough to become a good engineer. Three years later and I feel exactly the same way. Remind new engineers that no one knows everything and no one ever will!
Help them remember what they’ve learned over time to validate their growing development skills. My coworker Alli once suggested keeping a list of things we learned and things we want to learn. Having those lists are constant reminders of how far you’ve come.
Make them feel like what they’re doing is important.
Because it probably is, and they probably don’t know that. Small praise goes a long way. I’m often working on horrible mobile Safari bugs that result in a one line change. It’s not until someone mentions the impact of that one line (changing the result of an A/B test being run across the entire site) that I feel gratified by those hours of work.
Recognizing that days of debugging may only result in a significant one line change or that it’s more important to write clear, maintainable code than rush to the finish line gives new engineers perspective. Not everything that’s important is hundreds of lines of code long, flashy, and new.
This list is by no means exhaustive and not everything on this list will work for everyone. But I think it’s a great place to start.
So how have we built these things into our Engineering team at Eventbrite? Stay tuned for an exciting new post about what Eventbrite is doing to help encourage and grow new (and experienced!) engineers.
Thanks to Amira, Drew, Katia, and Senna for contributing to this list!