What Makes a Mid-Level Developer?

I was recently asked by more than one junior developer about how to progress to a mid-level developer. As a junior developer looking to move towards a mid role myself, I wanted to collect a few of my thoughts in a blog post. This isn't a checklist of skills that a workplace might typically give you. Instead, it's a collection advice from my own, lived experiences!

I've worked for nearly two years as a front end web developer in a multidisciplinary team. Currently, I work on a product that requires me to handle API data, authentication, localisation etc. This isn't the case for every front end developer. No one developer has the same experience as another.

So, please see this post as a list of suggestions and not as a complete to-do list on how to progress in your career :)

I've organised my thoughts into three categories:

1. Non-technical skills
2. Current skills
3. Skill focus

As a junior it should be expected that you get better at writing code, and spend most of your time writing it. You should also get feedback on your learning and performance and be helped to get better. Becoming a mid-level developer involves spending more time on things that don't involve writing code. You should spend more time looking at the bigger picture of a project. In other words, it will become more important to look at how all parts of a project (that are worked on by every member of the team) fit together, rather than focusing solely on your own, separate coding tasks.

Writing well-structured code

Writing code is one thing, but paying attention to how well it is structured is another. It's worth taking time to write code that is as clear to others as it is to you three months after you wrote it. Practice this by breaking down the logic in the code you (and others) write. Try seeing where a feature originates, how and where data flows into it along the way, and what the end result is. Note the architecture down in a notepad, or explain to another developer (or rubber duck). This will show how well you understand what the code does and where improvements can be made.

The advantage of well-structured code is that it creates a codebase that is easier to traverse and understand. This helps you make better and more confident decisions about a project, reducing stress and confusion for yourself and your team. It also limits mistakes and technical debt - meaning there is less need for refactoring or necessary re-writing of code that was poorly written.

Encouraging better communication

Paying attention to your team's communication patterns means you notice unhelpful patterns when they appear. A retrospective is a good place to suggest ways to improve. My team at work noticed that there were pockets of smaller conversations happening between some team members. This resulted in information getting lost and not everyone being informed. So, we began documenting the results of meetings, no matter who they include, both in our team’s main communication tool, and on our story tickets.

Spending time thinking about and implementing ways to improve communication has helped everyone in my team to understand project requirements quicker and easier. Another thing that was noticed is that we rely a lot on other teams for some features, whether design, marketing, product or back-end related. Our features can be slow to progress when we do not make an effort to talk with other teams about deadlines and requirements.

No team can have perfect communication, but we continue striving to become even better at documenting information and informing everyone involved in a feature of necessary info.

Taking ownership of work

Taking ownership of your work brings a lot of benefits, and it should happen right from the beginning of a project. Be as involved as you can in decision making during planning meetings. This limits the work others have to do and reduces the chance of decisions being made that will slow the whole project down. It encourages you to do more than the minimum required to finish a feature.

Both when planning and implementing tasks, try taking some time to find out how similar features have been implemented. Think about how your tasks fit into those of other people, and whether you need to collaborate on something. Remember that taking this time is expected of you as a more experienced developer. Spending less of your time coding than you used to doesn't mean you're failing.

Spending less time coding and more time thinking about how best to approach a feature actually saves time in the long run. Creating features that are robust and well-thought-through helps you and your team feel much more in control and able to move onto new features faster.

This list covers both technical and non-technical skills that I've already begun using as a junior. If I'd gone into depth on them it would have made this post five times longer. Still, I think it's fairly easy to grasp their importance. I find it really valuable to remind myself of them:

• Writing tests to make both refactoring and finding bugs much, much easier.
• Paying attention to error logs, learning to read them, and using them to find the origin of bugs.
• Asking questions about WHY things are implemented the way they are and not another way.
• Asking questions about anything that is not clear.
• Looking closely at code that has already been written, by you or others, and suggesting refactoring changes (if needed) to make it clearer and less prone to breaking in the future.
• Reading your project's code styleguide/docs and making sure the codebase adheres to the rules stated there.
• Suggesting/implementing updates to current documentation (especially since docs can get out of date relatively quickly).
• Taking time to review other peoples' code.
• Trying several methods of approaching a problem, discussing the pros and cons, and choosing the method that makes most sense at the time.
• Making sure to spend plenty of time not coding, so that you get a rest, and have more fun when actually coding.

Finding what to focus on

When it comes to skills, maybe you've had similar thoughts to me - now I am good at quite a few things. I am feeling quite proud of myself, even. What a nice feeling! Now, how can I get really good at something? Can I dig down into something and become a bit of an expert in it? Is there a point in that? Yes! I've been told by more than one person that this is a good idea. Why? Mainly because web development is a huge field, so it is not possible for someone to be good at, or enjoy, everything.

Maybe you have a good idea of what you are particularly good at as a developer. Maybe you have an almost intuitive feeling on what you're most interested in. Could be accessibility, performance, security, whatever. Whether you know what you are most interested in or not, I am guessing you may feel like you don't have much time to really focus on coding that much outside of work.

It's a good idea to let your colleagues at work know where you'd like to focus. Your workplace should take an interest in helping and supporting you in getting better at the things you like most. That's not to say you should drop your efforts to learn things outside of your fave topics. It's about finding some extra time to focus more deeply on such topics. At my work one developer interested in accessibility has set up weekly mentoring meetings around it, and recently begun holding a series of presentations on it.

This sounds like a lot of pressure, but don't worry. The things we are most interested in might totally change from one month to the next, and that's fine. Life is short and coding should be something you enjoy, especially if its your job. So take deeper dives into things you enjoy and feel you can handle. You might end up diving into some things more than others. Even if your learning was unplanned, it's all good.

Finding your developing style

Aside from specific topics, take a look at your strong points as a developer that involve your approach to development as a whole. Some people's style might be that they are good at coding many things in a short space of time and taking a trial-and-error approach. Others may prefer to study a concept for a few hours and take a more measured approach. Some leave the coding to others but tend to be very good problem solvers. A few may be particularly good at explaining coding concepts.

Most developers are a mix of a number of the things mentioned above. The web team at my work contains people who fit into the points I made above and this is a good thing. It's an advantage to have a web team containing people with different strengths, because these strengths can complement each other.

No one developer can know everything, and no one developer can be good at everything. My advice is to find the things you like doing most, find how you like doing them most, and still challenge yourself to learn new things some of the time ;)

In conclusion to this post, I want to remind you (and myself) that everyone started at the beginning. We all still feel imposter syndrome and shame when things go wrong. We are all learning all the time, which can be exhausting, so don't beat yourself up for not knowing something. We all need to hear stories from and support each other so please share your experiences with people too. No developer has to be alone!