4 Career Advancing Reminders for Junior Devs

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

Photo by on

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? 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 , 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 do we use?
• What does the 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

Photo by on

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 theory as well as 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

Photo by on

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, , 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, 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 course for two hours on unit testing with (or whatever testing framework is relevant to your programming language).If you are trying to learn , go read the docs – the are actually really good!Make it a point to understand some of the basics of the technologies your company uses. Get familiar with , , or whatever you use. If you're a frontend developer, learn the UI framework or library your company uses, like , , or . If you're frequently working with databases, learn about the differences between 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 . 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., 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

Photo by on

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 , 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 , 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 .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 and also for the 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!