Lessons Learned: My Journey as a Junior Developer

8 min readMay 27, 2021

The first days may be challenging, but I hope to help you to ease them. In the following article, besides sharing my personal experience, I want to share some tips and technologies with you.

First of all, let me introduce myself. My name is Or Levy, and I did my first step as a junior developer while still studying. I’ve worked a part-time job until graduation. It was a stressful and challenging period, but I will happily recommend it to every student. It’s an excellent opportunity to execute what you learn while doing so.
On the other hand, starting your first job after graduation (or you never were a student) could be less stressful but still challenging. Nonetheless, you’re starting a new career and want to prove yourself and make this job’s opportunity count! Before discussing the professional aspect, I would like to talk about juniors’ social matters and attitudes.

Be a teammate

No matter how good you are, even if you’re a rockstar developer, a natural talent, a quick learner, or any other catchword people love to put on their resume/LinkedIn, you have to be a good teammate. Why? Cause in most of the cases, when hiring a junior (an inexperienced), they will need to invest time and resources to teach you and sometimes babysit you. Nobody expects you to know how to do your job; if they did, they could hire someone with the relevant experience and knowledge. But they do expect you to be eager to learn. So, one person from your team (or more) will need to watch closely after what you’re doing and help you onboard for a couple of months. I heard more than once about interviewers who care more about Junior, who can fit the team and be a good teammate rather than someone better or wiser.

Pay attention to the onboarding program: Learning a new company’s business model could be a massive effort and a lot of knowledge to absorb. So take notes, write remarks for yourself and feel free to ask them to slow down or stop them for questions.
Try to be involved in many team activities: Team activities are not just ceremonies or company events. They could be anything: from a coffee break to an ongoing incident. Try to be interested and to seize any chance to know your peers and your day-to-day job.

“The only one who doesn’t make mistakes is the one who doesn’t do anything. “

I don’t mean you have to make mistakes, but you probably would do some, and it’s excellent. All developers will make mistakes, even seniors and tech leads; it’s human nature. It’s only a mistake if you do not learn from it. In our world, mistakes are also called bugs or errors, and there isn’t bug’s free program. Solving bugs is part of our job (some will say a significant factor), and sometimes it even harder than developing a new feature.

Retrospective: After each mistake, even the smallest one, try to do a little retrospective with yourself. Ask yourself why it happens, what did you miss, how to avoid it next time. Even share it with your peers and ask for their opinion.
Don’t go hard on yourself: Try not to criticize yourself too much. Those mistakes don’t define you, and it doesn’t matter how big you think they were. For example, my first feature has suffered from bugs, rollbacks, and even crushing production in the middle of the night. Of course, I wished for smoother deployment and to ace my first project, but you would learn way more the hard way.

Don’t afraid to ask questions!

We’ve talked about what to do after we made mistakes but, how can we prevent them? You could avoid some of those “mistakes” if you’ve just asked the right question, but it’s a known phenomenon that juniors could be afraid to do so. There are some reasons it could happen:

We want to be independent and execute the task without any help: we want to show others we can do it on our own, to prove we’re self-learners and capable of it.
We don’t want to bother other co-workers too much: asking many questions could make you feel disturbing. It’s an unpleasant feeling, and you may think it could affect how the other co-workers think about you.

You should feel comfortable asking questions. Some people are your “go-to” for all your questions. They need to free some time to support you and even be glad to do so, though I can’t always ensure the last one. Moreover, asking the right questions could give you some more credit in your co-workers’ eyes and save both of you a lot of time.

Prepare your questions: Find the balance between trying to execute the task independently and reaching for help. Try solving the issues by yourself, and if you struggle after some time (depends on you), reach for help. Explain what has gone wrong, what you have tried to do before, and what you want to do. Also, it’s fine to consult about your answers with your coworkers and hear their input about it.
Understand your tasks: When getting a new assignment, make sure you understand it, even if it sounds easy. For example: “Just save it on S3 instead of on disc…” and it’s the first time you’ve heard the word “S3”. Of course, you could nod and look about it later, but why not just ask? What is S3? Why it’s better than the disc? , etc. You will get a good (probably also short) and subject-related explanation. If the answer wasn’t enough for you or you want more information, you could always read more about it later.

Let’s talk about CODE.

There are many articles and books about writing better code, but here some quick tips that could help your first upcoming projects. Your first projects\ features won’t be the most interesting coding tasks; they would be small and not too complex. It doesn’t sound too exciting, but it’s an excellent time to learn how to write good code and work in a team. It could be the first time you will use GIT or have your code reviewed for most of you. Until now, you cared most about your code’s functionality and if it does what it should (or if you got an A+ on it). It’s still your concern, but now you’re working in a team with shared projects. Your code should now be straightforward and understandable, even at the price of making the code less “neat” and “elegant.” Writing one line of code that does everything could look “clean” but not readable, and it will waste time for the next one who needs to work with it. Code only you understand now (and probably not even you in the future) is worth nothing.

An excellent, well-written code is like a good book; it doesn’t need many comments or explanations, you understand what every function does, and everything makes sense.

Variables names: Calling a variable ‘i’ or ‘x’ doesn’t make sense, and no one knows what the purpose is.
Functions names: The name of a function should state what it does. Along with the input and the output, anyone could understand the functionality even without its content.

Furthermore, If you split your code into smaller parts with good names, everyone could easily read your code and understand what your code does without getting into the details about how it does it. Such as pseudo-code; it only states what we need to do and not how we should do it.

GIT — how to code in a team

Git is the most popular way to work on shared projects, and sometimes the first use could be intimidating. Git is a version control tool; you can easily track the project’s history and review others’ work. Every change is called commit, and every version of the code is called a branch. The main/master branch is the primary version of the project, and everyone should align with it. In an ideal world, also the version that runs in production. If you need to work on some project, you will create a new side branch, do your changes, and eventually, you will try to merge it to master. To do so, you will need to create a Pull-Request/Merge-Request, and someone will have to review and approve it.

Commit

commit is just a higher scope of your code, and you should act the same. Please give it a meaningful naming along with a proper message.

What and why has it changed? Keep it short and straightforward
Can’t keep it short? maybe it should be serval commits

Code reviews and Pull/Merge requests

Pull request is the most proper way to request a code review. This is the place to challenge each other code and point flaws.
Note: Every company has its own rules to manage code reviews, understand what they are, and follow them.

Don’t afraid of comments- this is a place to learn and understand what you did wrong or could do better.
Question everything- Don’t take any comment for granted. If you think someone is wrong, you can disagree with it. Do it respectfully and back yourself with related facts and info. You shouldn’t be afraid to have an opinion; never do something just cause a “senior” told you so.
Don’t afraid to review other’s code- It won’t be long until you do a code review, and you will be surprised that opinion matters! It’s also a place to learn and challenge other’s people code. Maybe as a junior, you won’t have good alternatives to suggest, but you’re the perfect person to question anything.

Rebase

Rebase is how you put your commits on top of other commits/branches, and every change is also rewriting history. The most common usage is to update your side branch with the main branch. Imagine you’re working on a side branch for a long time, and in the meantime, the main branch keeps progressing. You want your branch to be up to date, so you will rebase your commits on top of the main branch. Some of GIT UI will do it for you, but it also an excellent tool to edit your changes. Rebasing your last commits can give you an option to edit, rename, squash any commit. For me, it was a game-changer, finally a way to edit anything I do quickly. Be cautious; you can’t revert your changes! If you’re going to do a massive rebase, try to push your changes to a remote branch before doing so.

Summery

You will face many challenges in your first job, but they are part of the life of a software developer. And it is a privilege to have them; many people seek a challenging job. It makes the job more exciting and satisfying, and you should have fun while doing so. Getting your first job is a job itself, and sometimes harder; you got this job cause people believe in you. So be optimistic and try to enjoy it!