Tips for Junior Developers
I often talk to junior engineers and find myself giving the same advice. Therefore, I decided to write a post about it.
There are many online resources about coding or finding a job in the tech sector. This post is not one of those. It is focused on soft skills, which I think a junior developer should have.
Your biggest goal is to learn and grow. Most habits you pick up in the early days of your career will stick.
Let's get started. 👉
✅ Be reliable
The first piece of advice I find highly important is reliability.
ALWAYS follow up on your task commitments.
Don't leave TODO comments in your code, fully complete your work. Leave your code better than you found it.
When you find that you can't finish a task on time, don't hide it. As soon as you think you can't deliver, ask for help.
You have to show that you are reliable. It is the most important thing to do.
Your teammates will quickly learn if they can count on you. The more people count on you, the more critical projects you are given.
🤔 Be curious
Be curious and ask questions. Don't be content with not understanding things. This is a nasty habit.
Try to review other people's pull requests. If you don't understand something, ask. Often, you aren't the only one who doesn't understand. If you are too shy to ask in public, ask directly via private chat message.
I love working with juniors who ask questions. They are good at spotting overly clever code tricks and unnecessary complexity.
One of the best ways to learn is by working with other people. Ask people if they want to pair program with you. I've learned a lot from pairing with other developers.
💤 Work on boring tasks
In your early days, you will work on many "boring" tasks like bug fixes or minor UI changes. You should try to find joy even in boring tasks.
Fixing small bugs will show you how systems are built and how to avoid writing them in the first place.
Once, I was tasked with keeping our application free of runtime exceptions. This was a very useful experience. It showed me how the system was breaking. I built many internal tools to handle errors and started designing my code to be more robust.
For small repetitive tasks, think about how to automate them or use them as training for your editor skills. I learned my Vim shortcuts by doing a lot of CSS fixes.
🏆 Take ownership
By ownership, I mean taking the initiative and actively participating in scoping and estimation, not just executing your tasks.
Try to be involved in time estimations -- often, you won't be consulted (this is a mistake on your team's part).
Don't rush to estimate. Take your time to think about the problem. Consult your team members.
A common mistake is to provide a time estimation that's as low as possible and then not deliver. Be honest and conservative.
...and no, doing an all-nighter to finish a task on time is not proper time planning.
Estimates are tricky; don't hide when you're behind. Embrace it, raise the issue, and look for help.
🚫 Handling "No"
You will be full of ideas, this is great. However, you will often be told "No".
"No" is essential in product development.
This can be quite painful. Don't get discouraged. Understand the reasoning behind the "No".
Sometimes the idea is just not right or has already been tried. Other times, "No" is "we don't have time right now" because of other priorities.
Show, don't tell. If you have an idea, implement it and make a demo. The ability to present your ideas well is a valuable skill.
Programmers tend to disagree a lot in abstract and agree when they see the working code.
When I tried to convince my team at Product Hunt to switch from a standard RESTful API to GraphQL, I didn't just say "Let's move to GraphQL."
Instead, I implemented a very complex page with GraphQL in a separate branch. I gave a presentation showing all the problems GraphQL would solve for us and presented a migration plan. I didn't hide any of the risks associated with GraphQL.
Again, don't get discouraged even if your prototype is rejected. Understand why it was rejected.
📖 Read “The Pragmatic Programmer”
I'd encourage you to read is The Pragmatic Programmer. I think every programmer should read it. I used to gift this book to every new engineering hire at Product Hunt.
Conclusion
Many of the habits and skills you build at this stage in your career will stick, so put extra care into nurturing the right habits.
To wrap it all up, I would like to recommend an excellent book that
On the technical side, master your editor and the programming language you are working with.
Last but not least, take care of yourself. Work hard but don't overwork. Get enough sleep every night.
You can ping me on Threads, LinkedIn, Mastodon, Twitter, or just leave a comment below 📭