Mid Level Developer Mistakes

Pretending that office politics doesn’t matter.

Junior devs can play dumb. Mid-level and senior devs really can’t get away with that (you probably can’t get away with it if development is your second career). You also can’t assume that your manager or senior developers will cover for you at this point, because that is also a great way to make enemies. You need to be proactively building alliances rather than reactively trying to mitigate your shortcomings.

This also means being aware of other people’s motivations. Not everyone out there wants to be the best developer in the world. Some people want to start businesses, move up into management, or just do well enough to keep their jobs for now. You have to respect those people. Being aware of the motivations of others will make you a better team player, because you more easily appeal to what motivates them instead of what is SUPPOSED to motivate them.

Being arrogant towards other employees

There is a point after you get your feet wet where you get more confident. Some people get a LOT more confident than their skills can really back up. It’s easy for this to become arrogance, or to look like it is. It’s especially important not to be snarky towards your non-coding coworkers. While there is a natural friction between developers and sales/marketing/project management/support, that doesn’t mean you can get away with sneering at them.

Instead, you need to figure out where you fit in the scheme of things with respect to those people, and figure out how you can work more effectively in a way that helps them. Mid level devs often make a mistake in that they want to be highly regarded by their own team while not giving a crap about other people. This is always a mistake.

A mid-level developer acting this way on a team is a problem for management (because management has to mend the relationships) and often a problem for their coworkers because that sort of snark and arrogance become a corrosive habit. It also limits your ability to learn and your coworker’s desire to teach you.

Failing to ask for help.

Another common problem for the mid-level developer is that many of them feel that they are supposed to have all the answers and that they look bad if they ask for help. While you should try to figure things out (it helps you learn), you can’t just sit and spin forever.

Another related problem is that mid-level developers tend to underestimate the complexity of implementing some things. If your implementation plan starts with “we’ll just….”, you probably should step back and re-evaluate. There’s something you’re missing and you need to figure it out.

This can also take the form of not asking for help when you are overloaded. Healthy management does not expect you to work yourself into an early grave as part of your job requirements. You should be talking with management if you are getting overloaded – they can either find help for you or at least tell you what is wrong with your approach that is making you overloaded.

You should also be willing to accept help if it is offered. Sometimes other people will see that you are struggling and will offer to help. Take them up on it if you know they can. It’s only a problem if they are skipping a higher priority task to help you with a lower priority task and the former doesn’t get done.

Failing to find a mentor.

You probably had a mentor, a senior developer, or a team lead who took you under their wing when you were a junior developer. If you don’t still have that as a mid-level developer, you need to find it. This becomes more true the more you disagree with that statement.

While you can read documentation, blogs, and articles about software development, nothing is better than having a mentor who is the sort of developer you want to be in the future. A lot of times, the people writing posts on the internet are mid-level (or worse) developers themselves.

It cannot be emphasized enough, but many of the people giving advice on the internet are not people you would take advice from in a work environment. There is a reason they are trying to get attention for what they are doing, and if they don’t have the work experience to back up what they are saying, that reason is probably not in your best interest.

The ideal mentor is someone you work with who has an interest in you doing well, because it will help them do well. Structured this way, a lot of problems with mentorships go away, because both parties actively benefit and have realistic expectations of the process. That doesn’t mean that you can’t get a mentor who doesn’t work with you, or that such a person isn’t good, it’s just easier if they do work with you.

Job Hopping too frequently.

While changing jobs is probably the best way to get a nice pay raise in this industry, it can easily become a problem if you do it too often. This can make you look flakey and uncommitted. In addition to potentially making it harder to get a new job, it also greatly slows your learning. Junior developers learn from obvious problems, but mid level developers learn more effectively from solving more subtle problems of the sort that take a while to uncover.

Sticking around for a while will also ensure that you get burned by your own mistakes or by the long-term consequences of the mistakes of others you agreed with. It is the fastest way to improve your skill at this point, because it gives you real experience instead of academic knowledge. This doesn’t mean that you can’t or shouldn’t change jobs. It just means that you should be deliberate when doing so. It has to be a big jump in pay and opportunity to be worth it.

Learning things without learning where they don’t apply.

A common problem shared by all mid-level developers is that they tend to learn patterns, techniques, and technologies first, without learning why they would or would not use them. Honestly, this is true of learning anything in a technology space. Oftentimes, the best way to find out where a rule doesn’t apply is to apply it everywhere. The problems become obvious.

However, this can be a bit of a trap for mid-level developers, as they often lack the experience to anticipate where a rule might not apply. They also tend to lack experience with enough other patterns and practices to realize when something else might work. The real issue here is that you need to change your mindset when you learn something new to make sure that you quickly cut through the hype and determine where it isn’t useful.

Not learning business rules.

It’s also critically important as a mid-level developer that you not spend all your time just learning technology. You need to learn why your employer does things the way they do them. Remember that the end product of your work is what your employer is paying for. If you create the wrong thing, or can’t finish the task, then NOBODY cares what technology you used to fail.

Another reason to spend time learning business rules is that you are going to be expected to translate those business rules into code at a level that wasn’t expected of you when you were a junior developer. Understanding WHY certain business rules are in place will make you more efficient in your job. It’s especially useful for figuring out which application requirements management is most likely to prioritize above all the rest (even if you are doing agile, you’ll be surprised how often this doesn’t match what was said in planning).

Accepting promotion into management

While it may seem tempting to accept a management position over other developers when you are a mid-level, it can easily stunt your growth as a developer. While this is probably ok if your goal is to become a development manager, you need to think long and hard about whether this is what you want to do.

If you are a “manager” at this point, more than likely you are leading without authority. However, that lack of authority may not be understood by the people who report to you. And you may find yourself relying on their feedback about the quality of your code. Further, if you aren’t ready to manage other people (especially other developers), either due to a lack of aptitude, lack of experience, or imposter syndrome, this position is potentially very risky. It can blow up in your face in a very public way.

These sort of positions can also be an immense distraction. The thought process and schedule of a manager is very different than that of a developer. While you might be able to handle this sort of personal growth when you are a little more seasoned, it’s very difficult to do when you are also trying to climb the enormous learning curve that is built into a mid-level development position.

Not having measurable learning goals focused towards career objectives.

When you are a junior developer, there are tons of options for learning and most of them are well-suited to your knowledge level. When you are a mid-level developer, a lot of the tutorials are insufficient at best. In particular, many of them use very bad coding practices, as the writers assume you have the sense to spot the problems in the code. That may not be the case.

Just like a junior developer learning how to write Hello World in a dozen programming languages, mid-level developers face the risk of not being focused enough in their learning goals. However, instead of new languages, many will go into random corners of one or two languages, development stacks, or frameworks. If this learning isn’t focused around something you intend to do, you won’t get the results you want to have.

Some exploration is good, especially when you aren’t completely sure whether you want to stick with your current stack. However, trying too many things can be an indicator that you don’t really know where you want to go. Get this figured out and then pursue it relentlessly.

Your goals should also be focused towards your career objectives at this point. While it’s fun to try and build a game, if you don’t want to be a game developer, that might not be the best option. If you focus on things that help your career, this will position you to more quickly gain knowledge. You can then use that knowledge in more fun projects once you get to a more senior level. This also has the advantage of making you learn useful things in a work context where you can get help.

Staying where you aren’t growing.

While job hopping is definitely a problem, it’s also possible to stay somewhere too long. If you are getting too comfortable with your job responsibilities and you aren’t learning, it’s time to change your job. This may not meaning actually leaving. It might simply mean taking on more or different responsibilities instead of changing jobs. However, that may not be possible, depending on how your current job is structured.

Some companies also have really bad management and working practices. You may not have noticed them when you were an enthusiastic junior developer, but many toxic management practices start to become more obvious when you have become a little more seasoned.

Be especially careful during this time to make sure that you don’t stay somewhere that overworks you, underpays you, or keeps you trapped in old technology without much of a future. These things can put you into a headspace that makes it harder to get a new job. Also remember that you have the ultimate control over your own career growth. Unless your job is absolutely working you to death, you almost certainly have the ability to learn useful things in your spare time. DO IT.

Failing to specialize.

The final problem that plagues many mid-level developers is similar to the issue of unfocused learning. While you can learn to work in all areas of your stack, you probably should specialize in one or two at most until you have achieved mastery. This does a few things for you. First, it gives you a smaller set of things to learn, which keeps you from feeling overwhelmed. This makes it easier to keep going.

As you specialize, it also means that other people, including senior developers, may start to come to you when they need help with a particular section of code. This helps you build rapport with the rest of your team. Additionally, a year or two from now, those people will remember that you helped them. They will never remember your job title, but they will remember that they went to you for help. This is the beginning of an effective personal network.