How To Be A Good Junior Software Engineer
Congrats! You did it! You have become a Junior Software Engineer. Just one short year ago, I received this same honor when I joined AdHawk, and it has been quite the ride. In an effort to pass on knowledge from my past experiences, I have gathered a list of tips and advice on how you too can be a great Junior Software Engineer.
Be Vocal!
If and when you get stuck while coding, don’t allow yourself to sit too long. Absolutely work to push yourself when finding solutions, but when you find yourself idle for too long, reach out to a fellow developer. Ask as many questions as come to mind when pairing with a colleague. There are no stupid questions and clarifying things for you benefits both parties. Not being vocal can result in diminishing your growth and development output.
Seek A Mentor
Find a mentor that’s internal or external to your specific team. When meeting with that mentor, bring SMART (Specific, Measurable, Achievable, Realistic, and Timely) goals to these check-ins and report back to your mentor with any results.
Try to also bring failures to your check-ins. One of the strongest tools for learning is introspection. Discuss any difficulties you have and ask your mentor how you could grow from these experiences.
Venture Into The Unknown
Push to accomplish tasks that may feel outside of your scope of knowledge. Committing to challenges will build up your volume of experiences and deepen your familiarity with new and sometimes common problems to solve.
Teach Back What You Learn
There are a ton of different ways to turn around and teach what you have learned. You can write documentation, do a video tutorial, or write a blog post. No matter what your choice of medium, the act of teaching back compounds your educational growth. Having to clearly articulate anything forces you to analyze a problem and fill in any possible gaps in your knowledge.
Establish A Work Schedule
There are a ton of moving pieces and responsibilities we have as developers. At any moment, you could be writing a new feature, fixing a bug, reviewing a peer’s code, learning a new technology, participating in a meeting or any number of other tasks. Creating a schedule that dictates time for each type of task during a specific workweek will guarantee that you progress in each new field of responsibility.
My Typical Day
- Review pull requests (half hour to an hour)
- Work on a development card (until standup, roughly 2-3 hours)
- Standup (half hour)
- Lunch (hour)
- Continue work on development cards
- Push up a work-in-progress pull request and/or review new pull requests
Meetings will come up and be sandwiched between all of these tasks.
Force Yourself To Test-Drive
TDD stands for test-driven development. In short, TDD means that you will write tests that validate the functionality of a currently nonexistent feature or interaction first. Doing this creates a very important feedback loop of information that will clearly define the goal and scope of your task. An example of a recent test I wrote would be:
Now when running this code the first error is that path variant_path does not exist. Now, your development narrative is set. As a Junior, Test Driven Development gives me the ability to set a path towards a specific feature. This path then directs me with a route of error messages which help me fill in the gaps in any potential solution.
Push For Pairing
There is no faster way to grow as a Junior than pairing with more Senior devs. The environment that is crafted when a Senior and Junior pair will serve to reinforce the behaviors necessary to succeed for all parties involved. Seniors will need to communicate their ideas and decisions in a more generalized and succinct way. I believe all engineers can more easily write code while deep in the context of finding a solution. However, when asked to explain or validate their decisions they truly begin to understand the goal and the potential for refactoring occurs.
Juniors on the other hand will be able to have higher level decisions and common interactions quickly funneled into their experience. This allows them to skip some of the proverbial stepping stones, like having a thorough walkthrough of how to build a test first or handling errors in a more appropriate way. This establishes proper habits and improves the health of the application long term.
Most importantly the developer experience for all participants greatly improves as well. An old adage comes to mind, “Alone you can go fast but together we can go far”. The concept of mental or cognitive fatigue from being “stuck” does not occur nearly as often.
Having a pair to bounce ideas off of or possibly switch role from “driver” to “navigator” (who types versus who talks without typing) or vice versa can jump start cognitive blocks and actually increase development speed. While pairing does have an inherent cost (hours paid), the growth that occurs and the value returned in the developer’s experience greatly outweighs the initial investment.
Sharpen Your Tools
Long before I knew engineering was on the horizon, I took a series of classes during high school about graphic design. The first test we took for that class was for keyboard shortcuts. Why wouldn’t we learn color theory, or how to properly use the mask tool? Well, that’s because my instructor knew that one cannot truly be an artist without first learning to manage your tools. This lesson has stayed with me for the rest of my life. It was a simple yet very powerful message.
As an engineer your mind is one of your strongest tools and will continue to get stronger daily. However, if your development environment is not setup in an efficient way, eventually stumbling through folder structures, using your cursor instead of common shortcuts, and slow typing speeds can greatly hinder the ability to translate your solutions to code.
A Handful Of Tools At Your Disposal:
- Learn your IDE’s shortcuts (VSCode basic shortcuts)
- Zsh — a unix shell that can be used to optimize your shell interactions (autocomplete commands, command aliasing, etc.)
- Install a window manager (Spectacle is my app of choice)
Being able to effectively access my resources has saved me countless minutes (which add up over time). This has allowed me to spend the bulk of my time working to find solutions instead of fighting with my environment.
Media Media Media
Many of the most successful individuals in history recommend scheduling time to learn throughout your workweek. Elon Musk, Bill Gates, and Oprah are just a few of the proponents of this philosophy, the 5 hour rule. The rule states that an individual who wants to increase their overall success should spend at least 5 hours a week learning something new.
I’d trust their judgement! It’s no secret that there are a near infinite amount of blogs, podcasts, articles, conference talks, tutorials and more one can consume to bolster their knowledge as a Software Engineer. During your journey as a Junior you will be wading into a sea of unfamiliar terms and concepts. Do not shy away from this experience. In fact, I would suggest pressing forward into it.
A Few Resources I’ve Enjoyed This Past Year:
- The Bike Shed Podcast — Software Development podcast from the folks at Thoughtbot (high level content that may seem over your head but will valuable to hear in the long run)
- Egghead.io — Great platform with very succinct and well formatted video tutorials
- Exercism.io — TDD focused platform to teach many popular languages and frameworks
Dedicating a handful of hours to learning with these and possibly other tools will optimize your growth and push you to become the best developer you can be.
Go Forth And Prosper
Congrats again on the journey you are about to undertake. It is one that is not without peril. Much like software, habits and success are not built overnight. With these tips and a generous amount of hard work, I’m confident you will become the best Junior Software Engineer you can be.
