6 Tips For Junior Devs
--
Since the beginning of my career as a Software Dev in early 2018, I have constantly sought growth and challenge in my day-to-day.
I have attended many tech conferences, networked with dozens of world-class engineers, and consumed hundreds of hours of tech-related content in my spare time.
On top of that, I graduated with a Software Engineering degree and wrote a couple of successful Medium articles. I’ve built many side projects, contributed to open source libs, and even tried building a bunch of tech startups.
Nothing of that would have taught me anything about how to be a developer had I not learned it the hard way on the job, working with a living software and real people.
By now, I’ve worked in multiple companies (been fired from one too), working on different parts of the technology stack. I’ve done QA automation, Back-end, Front-end, and DevOps, and now ended up as a Junior Site Reliability Engineer.
Some say that my experience is way above the Junior position.
Yet, I still proudly hold on to this title, believing that a title is worth as much as one’s professional maturity.
Why do we hire Juniors?
Having Juniors onboard is extremely important for the growth of any tech company.
They bring new perspectives, challenge your internal convictions, and can deliver great ROI, given you put sufficient effort into extracting value from them the right way.
Seeing your Juniors grow is one of the most rewarding things you can do for yourself professionally and personally, and they will be grateful for it.
Your Juniors force you to keep learning and changing.
In this article, I want to share six pieces of advice I to give to any up-and-coming Junior Dev. Follow these, and you will be off to a great start in your engineering career.
If you have a Junior in your team, reading this may help you direct them in the right direction to becoming the great engineers and colleagues you want them to be.
#1 You shall seek a mentor
You must look for one yourself. Don’t expect the company to provide you with one, or don’t assume the senior on your team is one.
Ask them if they want to mentor you, and if so, respect their time and actively manage your calendar to fit theirs. If not — find someone else, even from outside of your team. It’s critical for your well-being as a Junior.
It’s best if it’s someone you personally get along with, who shares similar values.
Mentoring is not about code reviews, or explaining things you can learn by googling. That you must seek from other engineers, or on your own.
Find someone that will teach you the most important things —how to be efficient, how to ask the right questions, who to ask them, and how to maximize your own value-add for the organization.
The goal of mentoring is to transfer tacit knowledge, which comes from years of experiences, observations, and reflections — not books.
Open up to your mentor personally, share your best ideas with them, and watch them riping those apart by their immense experience. And then actively listen — that’s how you’ll grow. A good mentor will care for you to succeed and will be patient with you, even when you are completely wrong.
#2 You shall not refactor
Many Juniors, especially ones that have covered solid ground programming-wise, have lots of great ideas for improving the code.
But when building Software, the code itself is just a part of the story. There are things outside the code that are not communicated to you — context is always scarce, and the seniors are rarely available to explain it to you.
Sometimes, the code you read makes no sense, and extending it feels wrong— it takes real skill to not pull the trigger.
As a Junior, you must build features as defined, that’s it! Keep your eyes on the prize, even if sometimes you sacrifice your own ego to get there.
Refactors are only worth-while if they solve a tangible problem that prevents you from adding value.
All code ultimately exists to solve problems. If you can’t clearly specify which problem you’re solving with a refactor, and justify its value towards the bigger problems you are solving with your team, you should not execute on it.
Refactor on your own time as an exercise, then ask your colleagues to review your code if they have time, but never let unrefactored code slow you down from delivering value.
Your job is to understand a complex system and change it so it can support additional functionality. Not to make you feel good looking at it.
#3 You shall master your stack
In every organization, there is always a finite amount of tools used to fully operate the product.
You don’t have to become an expert in all of them, but you must continuously seek improvement in the ones in your proximity— especially the programming language/major framework you use. They are your bread and butter.
As a Junior, you are often bombarded with names and concepts that confuse you. Never stop acting on those unknowns — whenever there’s something you’re missing: research and ask!
When we learn, we are less productive and have lower throughput, but that is expected of you as a Junior, so take advantage of it.
It makes a world of a difference having a Junior that is actually interested in what everyone is doing, instead of the one that is constantly talking about topics completely unrelated to their job.
Listen to other engineers — which systems are they continuously talking about?
What was that Jenkins thing, and how does the change I made end up on the user’s Mac? This introduces you to operational responsibility and makes you a valuable asset for the company.
What is the latest release of the framework you are using, and where is the industry going with it? Knowing these shows you are up-to-date with the latest trends and can begin to argue for reasonable improvements to the software.
The code you build is the code you have to live with. There’s always more frameworks and languages you can consume before you become useless in all of them — so you must specialize.
#4 You shall follow the team process
You must seek to understand how the world works in your team and follow the process exactly as-is. Things can always be done better, things can be changed, but don’t be the odd one out, creating friction and confusion within the team.
Just because you’ve read how to do Scrum in the book, or watched a talk about it, doesn't mean that it is immediately applicable to your work environment.
Understand the process, be humble, and find ways to excel in your responsibilities within the box you are in.
Seek what is expected of you by asking your manager, and make it your priority to be a good fit. Also, don’t be late for meetings, don’t forget to set up your calendar, and don’t forget to change your Slack status when eating lunch.
#5 You shall communicate progress and blockers
So many times I’ve spent endless hours on an island of solitude, working on my little feature.
Just to learn that things changed and I must redo everything from scratch.
Or to fail to execute on my intuition due to unexpected blockers, which I’d catch early by asking one of my colleagues.
Or to end up in a merge hell after someone has just merged a +2000/-1000 PR across 10 files I worked on.
I could keep going…
Letting your team know how and what you’re doing is crucial. Learn to predict when it’s necessary to sync with others. Learn to communicate frequently and sufficiently.
Give others an opportunity to chip in, and you’ll see your productivity sky-rocket.
Even better — ask more experienced developers to pair-program with you. Working side by side is the best way to learn implicit context, priorities, internal processes, and expose you to tips/tricks learned from years of experience. It shows you a direction for your professional growth too.
#6 You shall question yourself first
As a Junior, you will question things. You will see areas for improvement and be criticizing how the world works.
Sometimes you will confront people about it, and that is all right — you can’t learn to resolve conflicts without ever having one.
In fact, if you wish to grow as an engineer, you must learn to properly argue for your own beliefs and communicate your ideas properly.
Any time a Senior pushes your ideas back, reflect deeply on why that is the case — think why they would do so, and what is that you might not understand. Be intellectually honest and prepare to radically change the way you think about the world.
Never blame anyone but yourself, and make every failure count. It’s easy to say — they are just stupid, they don’t understand, they don’t listen.
Don’t ever let yourself fall into this Me vs Them mentality.
Make it your personal priority to always be on the same page with your co-workers, bosses, and managers, and put the triple effort in understanding their point of view first, before you start endlessly defending your own.
Wrap Up
I hope you’ve found this helpful!
As with any advice though — take whatever makes sense to you, and run it through your internal processors first before you start applying them to your life. By simply keeping them in mind when making decisions you’ll be well equipped for the future.
I highly recommend reading The Differences Between a Junior, Mid-Level, and Senior Developer. This was a game-changer for me understanding seniority in engineering.
Take care out there!
