Software engineers early in their careers often ask me, "How can I level up quickly?"
In other words, how can I become an effective contributor in the shortest amount of time possible? How can I familiarize myself with our massive codebase? How do I learn all the things I should know?
Starting a new job can be stressful, even as a senior engineer, and it can be especially overwhelming when it's your first programming job. So, let's look at four strategies for leveling up as a junior developer so that you can hit the ground running.
1. Ask lots of questions
First, ask questions – lots of them. And perhaps more importantly, don't be afraid to ask questions. Working up the courage to ask questions can be hard, because doing so means admitting that you don't know everything. But why should you? Software engineering is such a broad field that it's impossible for anyone to know everything about everything.
Asking questions, especially in an open forum like in one of your company's Slack channels, puts you in a vulnerable position. You may wonder, "Will others look down on me because I don't know this thing? Will I lose credibility as a software engineer?" In those moments, it's important to remind yourself of a few things:
First, everyone has to start somewhere. Even software engineers that have 30 years of experience were once in your shoes, trying to get their bearings in this expansive industry.
Second, if you have a question, it's highly likely that several other people also have the same question. Having the courage to ask will help you as well as your colleagues.
Third, impostor syndrome affects everyone. Everyone at some point feels like they're not good enough, that they don't deserve to be where they are, that if their colleagues realized how little they knew, they'd be exposed as a fraud. Don't listen to that voice.
Fourth, when you ask your question in a public forum, it becomes documentation you can refer back to later. That's why I always encourage engineers who send me private messages on Slack to instead post their questions in public Slack channels. Then, the whole team or organization can chime in to help answer, other people who may have the same question are benefitted, and the conversation is searchable for others who have this question in the future.
Now, a note to engineers on the receiving end of the question: The vulnerability created when someone asks a question in a public forum places a sacred trust in your hands. It's up to you to determine the culture of your company. Is this company and team a place that is psychologically safe, where people are free to ask questions without being berated or looked down on? Be wise in how you respond, lest you create an environment in which your colleagues are afraid to speak up.
When Google conducted research to determine which factors contribute to a high-performing team, psychological safety was the number one contributor. Team members need to feel safe and that they are able to be vulnerable around one another.
So, that being said, what sort of questions might you ask as a junior developer in order to be more effective? Here are a few examples:
- Can you give me a walkthrough of our app's architecture? What frameworks and libraries do we use?
- Can you give me a walkthrough of our codebase directory structure? Where does the code live? How is it organized?
- What does the development process look like? What type of Git workflow do we use?
- What does the release process look like? How does new code get into production? How frequently is new code released?
- Why was [Feature X] implemented the way it was?
- Why do we use [Library A] rather than [Library B]?
In fact, these are all fantastic questions for anyone to ask when starting a new job, not just junior developers.
2. Ask for help when you need it
Along similar lines, it's important to ask for help when you need it.
Wrestling with a difficult task is a crucial part of learning how to problem-solve and troubleshoot. If someone is always there to hold your hand, you won't be able to progress as quickly. But, there comes a point where it's wiser to accept that you need help.
An excellent rule of thumb is: If you get stuck on something, try for 15 more minutes, and then, if you're still stuck, you must ask for help.
This puts a time box on your task. It also requires you to spend a little more time on the problem before asking for help, so you aren't allowed to immediately give up. What's more, you may be motivated by the time limitation to figure it out, because maybe you really don't want to have to ask for help!
If the 15-minute time limit has expired and you still feel stuck, you must ask for help. You may think it's noble to continue struggling along on your own, but remember that you're being paid for the work you do. It's not fiscally responsible for you to spend hours and hours on something without making any progress, especially if a colleague can give you a quick pointer to get you unblocked. Your teammates can be a great resource for you and are there to help.
Whether they know it or not, experienced teachers and mentors will often use Vygotsky's zone of proximal development theory as well as scaffolding when helping junior developers. The zone of proximal development (ZPD) is "the distance between what a learner can do without help, and what they can do with support from someone with more knowledge or expertise." Scaffolding is the technique of providing guidance to a student to help them operate within the ZPD.
So, a helpful mentor gives the junior developer just enough guidance to enable them to complete their task, or the mentor provides just enough information to unblock them in whatever phase of development they may be.
3. Be continuously learning
The field of software engineering is constantly changing. New languages are created, once-popular libraries and frameworks are dethroned by newcomers, and design trends come and go. In order to keep up in this fast-paced world, you must be continuously learning. Software engineers don't just attend college or a dev bootcamp, graduate, get a job, and then never learn anything new again. Learning is something we do every day.
The "10,000 hour rule" was popularized by Malcolm Gladwell's book, Outliers, back in 2008. This rule states that it takes roughly 10,000 hours of doing something to become an expert at it. While it makes sense that the more you practice something, the better you'd get at it, the 10,000 hour rule has been debunked by others several times since the book's publication.
It turns out that what's really important is not just how much you practice, but how you practice. There is a difference between "practice" and "deliberate practice."
When learning to play a musical instrument, you have to be deliberate in how and what you practice. If you're learning a particular song, you don't just run through the song over and over. It's not effective to simply play it from start to finish each time. There will likely be sections of the song that are more challenging than others. If you are engaging in deliberate practice, you might play the same four measures over and over until you nail them, and then move on to another part of the song.
The same concept applies to software engineering. Don't just muddle through things. Be deliberate in what you are trying to learn.
If you feel like you struggle with writing unit tests, go watch a Pluralsight course for two hours on unit testing with Jest (or whatever testing framework is relevant to your programming language).
If you are trying to learn React, go read the docs – the React docs are actually really good!
Make it a point to understand some of the basics of the technologies your company uses. Get familiar with AWS, Heroku, or whatever IaaS/PaaS providers you use. If you're a frontend developer, learn the UI framework or library your company uses, like Angular, React, or Vue. If you're frequently working with databases, learn about the differences between SQL and NoSQL databases as well as their respective strengths and weaknesses.
In other words, take time to "sharpen the saw." This term, coined by Stephen R. Covey, is the last habit in his book The 7 Habits of Highly Effective People. To quote Dr. Covey, "We must never become too busy sawing to take time to sharpen the saw."
It's easy to fall into the trap of only completing task work during work hours. After all, you're on the clock, and your employer is paying you to be there, so you should be "working," right? However, that type of thinking is short-sighted. It's like trying to cut down a large tree with a saw for hours while never taking time to sharpen the saw. The time you spend sharpening the saw is time not spent cutting down the tree. But with a sharper saw, the more effective your cuts will be. You'll actually be able to cut the tree down in less time than it would have taken to cut the tree down had you not stopped to sharpen the saw.
Good employers recognize this truth, and they actively encourage employees to spend a few hours each week doing some intentional learning. Don't feel guilty about taking time to read an article or watch a video tutorial during work hours. When you do these things as part of your deliberate skill-sharpening practice, you'll become a far more effective engineer than you would be if you solely focused on task work 100% of the time.
4. Participate in code reviews
Finally, participate in code reviews. All respectable software companies have a code review process in place to help keep the code quality of their codebase high. Code reviews are generally thought of as a gate-keeping practice – you want to make sure that good design patterns are used, that the code is clean, that it is adequately tested, and that potential negative consequences are avoided.
But, perhaps just as important, code reviews also serve as a knowledge-sharing process. When you create a new merge request and ask others to review your code, you are inviting them to give you feedback. There may be all sorts of things they'll come back with: ways you could refactor your code, a better data structure or design pattern to use, violations of best practices you haven't learned yet. Code reviews are one of the best learning opportunities out there, and they're baked right into the development process!
Code reviews can be a somewhat emotional experience. You are asking people to critique your creation, so it's easy to let your ego get involved. When that happens, take a step back and remember: Even if some of your code is bad, that doesn't make you a bad developer. Take your ego out of the equation and remember the end goal of producing high-quality code and sharing knowledge.
When preparing a merge request, always be respectful of your reviewers' time. They are taking time out of their day to help you, so be sure you have good commit messages, a helpful merge request description, and have already reviewed the code yourself. As a reviewer, nothing is more frustrating than reviewing code with no context or seeing commented-out code and badly formatted code everywhere. The best advice on this subject I've read comes from Michael Lynch's article How to Make Your Code Reviewer Fall in Love with You.
On the flip side, don't be afraid to also review other engineers' code, even code from more senior engineers. No one is perfect, and senior engineers make mistakes too. By reviewing code from engineers with more experience, you'll be able to see how they write code, structure code, name variables, and tackle difficult problems. By observing and then emulating the coding style of your more senior peers, you can quickly level up the quality of your own code.
Google has excellent guidelines for the code reviewer and also for the code author whose code is being reviewed. I'd highly recommend reading both.
Conclusion
If you take away only one thing from this article, I hope that you remember to be intentional in your learning. Find out what you need to know and what you want to know, and focus on those things. Be deliberate in your practice. Be curious. Have a hunger to learn. Adopting this mindset will put you on the right path for a long and successful career.
Best of luck to you!
Top comments (18)
Not to bash your ideas, but the I never had a good experience by asking questions during the intern. The senior developer got pissed. I had to learn the hard way to keep grinding and shut my mouth. It's like I could ask once in a day only.
Just because that was your experience doesn't mean Jr. Devs have to look forward to this type of response from a senior.. they gatekeep any true progression that way. Sr devs should always be a beacon of trust and help, otherwise they have no place in a team setting. They can be asshole freelancers all they want, it wouldnonky free up more jotmbs at the very least lol
Sorry to hear that was your experience. Senior engineers (or anyone, really) would be wise to react in a better way than that. The unfortunate truth is that there are toxic workplace environments and toxic employees out there, and it sounds like you found one.
I had the same experience but later realized both a senior dev and the team lead who both have had 10+ years of experience in this company had no idea how the platform they were using works. At least in part this is why they were unable to help when I had questions.
This is a great piece! I agree wholeheartedly with points 2-4, but might challenge one (1) just slightly.
I think it's safe to suggest that there are inevitably questions that must be asked in every organization across all levels of seniority and disciplines. Questions are fundamental to:
However, I personally have found that an important skill to have as a Software Developer is not perfecting the act of asking questions, but rather discovering how to answer them oneself. I truly believe this is an acquired skill whose attainment isn't always obvious or easy, but once mastered essentially turns into @Tyler's third (3rd) point of continuously learning.
Khoi's comment here (one I resonate with dearly) begins to resolve itself within individuals that make it a point to learn whatever it is that sparked a question in the first place.
Thanks for the piece @tyler , and apologies for the unsolicited challenge!
Thank you Stephen, that’s a great insight! I think you’re right that there are these different categories of questions, some that you absolutely should ask and really wouldn’t be expected to know the answer to, and others that you need to figure out on your own. Learning how to answer your own questions yourself for those things just outside your current circle of knowledge is an important skill to have.
Thanks Greg! That's a great point you've highlighted. So much of getting better at what we do involves our behaviors, processes, and meta-skills. I agree that it's a bit short-sighted to say things like "if you want to succeed, learn these 10 frameworks."
Really great tips here. Thank you for sharing.
Thank you!
Thank you for this article and in particular linking to Michael Lynch’s blog entry: it’s a gold mine!
It's so good! It's become my new favorite article on best practices for code reviews.
I really wanna a very big Thank to you..... Wow you just answered my long await research♥️🌟
Thank you! I'm glad it was helpful to you.
Amazing. Definitely gave me a good structure for my first dev job.
Thank you!
You're welcome! Thank you for reading.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.