From Junior to Mid - Tips to Become a Better Software Developer

Did you get your first developer job some time ago and struggle with moving forward in your career? Or maybe, you are an experienced software developer but feel your growth is slowing down?

The feeling of being stuck can be highly frustrating, especially if you are hungry for new challenges. I still remember my first job as a junior front-end developer and my itch to take the next step in my career. I wanted to become more independent in programming, eliminate bugs, and have a real impact on product development rather than just handle routine tasks.

So -

I took matters into my own hands and created a plan that helped me improve my skills, gain more confidence, and finally, get promoted.

In this article, you will find all I've learned and put into practice till the day now. I divided the article into three parts: code, skills, and mindset, as these areas were crucial for my tech and soft skills development.

Let's start!

Mid-level vs. junior level - what is the difference?

Some may say that it's all about the time we've spent working in a particular position. However, it's not all that simple. Years of experience don't equal knowledge and skills, especially in such a dynamic environment as IT.

What does it mean to you?

You can't just wait and assume that your promotion will happen without your active participation.

First, most companies have their own definition of career levels - the things you should know and do as a junior/regular/senior. Look at the job description and discuss it with your manager/ team leader to identify the areas you could improve.

But don't stop here!

Do your research on the market and follow experts in your field. It will help you base your judgment on more reliable - external - sources, not only on information provided by the company you work for now.

Part 1: CODE

Write good code

OK, I know what you're thinking:

What the heck does "good" code mean...

To put it simply - your code must work properly. As Marcin Brumer, Senior Frontend Developer, says: "Write the code and check if everything works. Test it manually. Not only a happy path, but go further - think how you can break it. Open a console and check if there are any warnings."

The golden rule is to try to find apparent mistakes instead of relying on others to find them.

Good code equals tested code. If your company doesn't require testing, write tests anyway (and convince others to do that). Why? Tests prevent you from accidentally causing regression or unwanted changes in the behavior of already written code.

Good code is also easy to understand - for others and your future self ;) You (probably) know that situation: you read a file in a codebase, don’t understand what the author was thinking, and finally use the command "git blame" to know who is guilty of this mumbling and... surprise! Your name pops out.

I've experienced it a few times. Since then, every time I’m doing my tasks, I spend a few extra minutes thinking about my code's readability and doing a "refactor" of my own code. At first, code can be ugly, but it has to work. And then, I polish it by changing the names to be clear and precise and rewriting it to be shorter and look better.

Work with legacy code

Surprised?

Many developers want to write only new functionalities and avoid working with old projects - it's understandable. But working with legacy code can be a game changer in your learning process!

It will teach you to analyze the codebase and debug in a challenging environment. It is essential for juniors, who used to deal with relatively small projects, and now can operate in big ones.
It shows you how decisions made at the beginning can influence the project and which patterns or solutions you should avoid because they are hard to scale.
Working with a big not-tested, or not documented well codebase teaches you how to make small changes, extract some parts to the refactor, and improve the code without breaking the app on production.

And bonus point - there are not many volunteers to look at ugly old code. If you push yourself to do that, your efforts won't go unnoticed, and you will get a desirable and, at the same, quite unique skill.

Take part in the discussion

You are probably familiar with rubber duck debugging (or rubberducking ;)) when programmers explain yellow rubber duck their coding problems and, thanks to it - figure out solutions.

Why not do the same with your coworkers?

Discussion about code is crucial, and there is no better occasion to do it than Code Review. Code Review is much more than checking someone's mistakes. It's a chance to learn from others. But before you start, remember - you are not your code!

"Don't take it personally when someone has commented on your code," - says Marcin Brumer. Someone suggests changes or points out your mistakes? Great, lessons learned. You can write it better next time.

On the other hand, when your colleague asks you for feedback, don't think you can't do it because you are "only" a junior. It surprised me when I found a bug in someone's code for the first time. Even the most experienced developers make mistakes and will appreciate your help.

Additionally, Code Review is a great chance to learn more: asking why someone chose this method instead of a different one or what is the purpose of the code that you couldn't understand by yourself.

Be up to date

Look -

You work in the most dynamic industry, and you will always have to learn new things. Being up-to-date with changes in the language, framework, or library you use is crucial for your career development.

You can sign up for newsletters, follow Twitter accounts, read tech news regularly, or subscribe to YouTube channels. Make sure you don't stop learning after getting the first job.

You can also invite your teammates to share and discuss the news and how these changes will influence your work.

Part 2: SKILLS

Communication matters

Great communication is a fundamental part of team cooperation. However, building effective communication requires extra effort and attention - where to start?

Make your communication simple and use terms that everyone understands.
Learn how to present your ideas clearly. If you can say something shorter, do it.
Learn how to communicate well in writing. At Tidio, we work asynchronously, and having a good description of the story, bug, or test cases is crucial to make our work smooth.
Adjust communication with the person you're talking to. Style, type, and frequency of communication each of us likes vary depending on our personality types.

Focus on smaller pieces

One of my biggest challenges during the first months of my work was that I often felt stuck with bigger tasks connected with things I hadn't done before.

How did I deal with it?

I divided the task into smaller pieces. I estimated what I already knew, what I needed to learn, and where I could start. As I got to the point of "this is new," I looked for the answer in the documentation. And if I wanted to ask someone for help, I had a clear question, e.g., "what is the format of data from API" rather than: "I don't know how to do that task."

It helped me to implement good practices in every task and avoid repeating the same mistakes.

Part 3: MINDSET

It's ok not to know something

There is a sentence by Henryk Kukla that I heard from one of my colleagues:

"If you have a problem and have to ask someone, you feel ashamed only once. If you don't ask, you will feel ashamed many times."

It's absolutely normal to ask questions. Damian Marczak, Engineering Manager, points out: "You should not spend your time reinventing the wheel. Sometimes juniors try to prove that they can do something by themselves, but it is not effective. You should ask for a clue instead of being blocked for hours, pretending you do not need help."

Asking questions is not the end; what you will do next is important. Remember the answer, use it, and don't ask again and again about the same things. Moreover, ask not only when you have a problem but also to broaden your knowledge.

Take ownership

Ok -

You know your tasks and do your best to fulfill your responsibilities.

What if I say you should go even further?

Think not only about the work you do but also about the outcomes. At first, it can be a bit scary, but with time and practice, it will give you a lot of satisfaction! Here are two small steps you can follow to gain more confidence:

Have you noticed a bug in production? Don't wait for someone else to report it or assume that it is not your problem. Prepare the fix or consult it with the right person.
Your team promised to deliver a solution within one sprint, but in the middle of it, you see that it's doubtful that you will do it. Don't wait till the last day. Start the discussion about the goal and what you can do to deliver it despite the obstacles.

You may think that accountability is something only for leaders or managers. But even they don't learn accountability overnight - it takes time, and the earlier you understand how important it is, the faster you grow.

Expand your business knowledge

Grzegorz Kazimierski, the Frontend Developer, says - "Development is about solving problems. Writing code in only one way of doing that."

Let’s dig a little deeper -

Yes, you are paid for creating tools that solve problems. Yes, you are paid for building apps that do tasks. But coding is only one way of doing it. And you can do more!

Learn about the business aspects of your work. Figure out how to achieve the goal, not only code the solution invented by someone else. Get to know at least the basics about the backend of the app. Try to understand the main pain points for your customers or what is crucial for your client. Of course, you don't have to be an expert in these topics, but your knowledge should constantly grow outside your coding area.

Use your talents and do what you like

There is no one right path for everyone.

The key is finding the environment where we can develop the way we want.

One of the tools that can help us discover our unique predispositions and preferences is CliftonStrenghts. It identifies our natural talents so we can perform better in our job, build stronger relationships and achieve personal growth. I'm a massive fan of this tool and recommend it to everyone.

What do I learn about myself?

I like to fix things, iterate on something that was already done, and learn the past context of decisions. Thanks to all of that - I find it truly inspirational to work in a product company that has some history but also creates new things and constantly challenges them.

I know that working on different projects every couple of months or not having a space to experiment is not for me. But, at the same time, it can be perfect for you! Discover what suits you best and find a job that uses your talent, enables you to do what you like, and honors your values. It will be a win-win situation for you and your company.

Final words

At this stage, you already understand that instead of thinking about how to jump into a mid-developer position, you should think about becoming a better developer. Treat development as a part of your job, not something that will end when you achieve some magical point. The rest will come. I hope this article will help you create your own path to becoming a better developer and gain confidence in programming.

Special thanks to Grzegorz, Marcin, Damian, and Anonymus Dev (not junior anymore) for their contribution to this article. And to all the great developers I met who helped me grow 🚀