My Advice to Junior Developers
I talk to junior engineers a lot and find myself giving the same advice. So 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.
So let's get started. 🚀
Your biggest goal is to learn and grow. Most of the habits you pick up in the early days of your career will stick.
The first piece of advice I find highly important is reliability.
ALWAYS follow up on your task commitments.
TODO comments in your code, fully complete your work. Leave your code better than you found it.
When you find out that you can't finish a task on time, don't hide it. The moment 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.
By ownership, I mean taking the initiative and actively participate in the scoping, estimation, not only in executing your tasks.
Try to be involved in time estimations -- often, you won't be consulted with them (this is a mistake on your team's part).
Don't rush to estimate. Take your time to think about the problem. Consult with team members.
One mistake that everyone does is to provide a time estimation that's as low as possible and then don't deliver. Be honest and conservative.
...and no, doing an all-nighter to finish a task on time is not a proper time planning.
Estimates are tricky, don't hide when you're behind, but embrace it and raise the issue, look for help.
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 was already 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 is a valuable skill.
Programmers tend to disagree a lot in abstract and agree when they see the working code.
When I was trying to convince my team at Product Hunt to switch from a standard RESTful API to GraphQL API, 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 problems GraphQL will 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 code prototype is rejected. Understand why.
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 request changes. 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 too clever code tricks and unnecessary code complexity.
One of the best ways to learn is to work with other people. Ask people if they want to pair program with you. I have learned a lot from pairing with other developers.
In your early days, you will work on many "boring" tasks like bug fixes or minor UI changes. It would help if you tried to find joy even in boring tasks.
Fixing small bugs will show you how your systems are built and how to avoid writing them in the first place.
Once, I was tasked with keeping our application clean of runtime exceptions. This was a very useful experience. It showed me how the system was breaking. I built a lot of internal tooling to handle errors and started designing my code to be more robust.
For small repetitive tasks, you can 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.
To wrap it all up, I would like to recommend an excellent book that I'd encourage you to read is The Pragmatic Programmer. I think every programmer should read it.
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.
If you’re too lazy to thoroughly read all paragraphs one by one, here is the essence of this post.
A lot of the habits and skills you build at this stage in your carer will stick.
- ALWAYS follow up on your time commitments
- Try to have a positive attitude
- Be pro-active, curios and learning (even from tedious tasks)
- Don't get discouraged when people say "No" to your ideas
- Read the The Pragmatic Programmer
- Take care of yourself
If you have any questions or comments, you can ping me on Twitter.