5 Bad Habits I See Developers Make

If you want to become a highly valuable and impactful engineer, don't make these mistakes.

As a Junior developer, you are expected to make mistakes. You'll break production, your first solution will be suboptimal, and you will ship a bug, but if you don't avoid the mistakes I'm going to share below you'll find yourself on the list for layoffs, quick.

• No promotions

• No pay raises

• .. and you'll be undesirable to future employers or clients

Here's the kicker, even experienced developers make these mistakes.

Over the years I've worked with several engineers, some good, and some... well, not so good. The difference between a highly skilled developer that employers are looking for, and the ones that are easily replaced usually doesn't depend on years of experience, but the ability to adapt, overdeliver, and overcome obstacles with grace.

Most developers have massive egos, think their solution is better, and think code is half art & half science, when in reality it's all science.

We are opinionated, and feel the need to be "right". Resulting in slower development times, increased stress, and potentially a toxic work environment.

There are three fundament rules that I want to share with you today, and regardless of your experience, industry, or skillset.. these are non-negotiable.

• Done is better than perfect

• It's okay to be wrong, but not okay to be an ego maniac about it

• It's okay to have strong opinions, as long as they are loosely held.

Bad habits can carry with you for your entire career if you let them, which is keeping you as a low-impact engineer.

1. Not benefiting from pull requests

We've all been there, that first pull request at your new company is nerve racking, stressful, and you can get in your head about it pretty easily.

But at the end of the day these are the only things that matter with new code:

1. Does it satisfy the requirements?

2. Is it tested (properly)?

3. Is it easy to understand?

4. Can it be maintained?

If you're the reviewer, your job is to make sure that the new code aligns with the above criteria.

If you're the author, it's your job to provide support for the above criteria, accept feedback, and understand that not every comment is always correct.

Most of them time when you have a task, you are the most up to speed and knowledgeable about that specific problem or feature. In a perfect world everyone would be on the same page, but more often than not.. that is not the case.

If someone makes a suggestion you don't understand, or feel is incorrect.. ask for more information. Jump on a call with them, walk through it, and come to a mutual understanding.

2. Not communicating

If you get stuck... don't wait until stand up to ask for help. If it's a sure enough blocker (some other stakeholder needs to complete something), then you should at the very least have enough evidence to support that when you have standup.

But if you are fighting a bug, not sure how to get started on something, or just simply don't feel like you know the right direction... talk it out with a team member.

I'm not suggesting that you always rely on someone else to fix your problems, but when you're starting out it can feel awkward to ask for help. I promise it's not a big deal.

If it is, it's probably a sign of a toxic team anyway.

However, when you ask for help make sure you aren't coming across us unknowledgeable, or worse... incapable.

1. What did you try?

2. What specifically are you stuck on?

3. Why is it important?

Like I mentioned above, most of the time you have the most information about the ticket you are working on, and everyone has deadlines. We don't need to waste anyones time so be as brief, but thorough as you possibly can.

Instead of:
"I can't get this to build"

Which then prompts your team to start suggesting things that you may have tried say:

"I'm having trouble building {x} after {doing y}

I've tried:

• Thing 1

• Thing 2

• Thing 3

This is blocking me from completing {your task}, and any help would be greatly appreciated"

More often than not, it's something simple or a missed step that should be better documented, or just a bit of "junior mistakes" that are bound to happen.

But by sharing what you've tried, it doesn't give your team the impression that you aren't capable of trying something for yourself, you made an effort, and are genuinely stuck.

Too often, developers ask for help on things when no effort was made on their part.

3. Not utilizing your team

Imposter syndrome affects all of us, and the only way to get over it is through failure, and consistent improvement.

When you first join a company, you should be learning the processes, codebase, workflows, and dynamics of the team. This isn't typically the time to start making suggestions, or pushing back on things.. especially if you're early in your career.

But, you should feel confident enough to speak up when:

• You don't understand something

• You don't have everything you need to do your job.

• You are over burdened, and need help.

Too often we are focused on the "grind" and making sure we don't look like an idiot, but when you work on a team the only way you can grow in confidence is by fully utilizing your team.

That is what leaders do, it is what separates those that are enjoyable to work with the ones that are not.

The truth is, that no matter how good of an engineer you are, it is your responsibility to utilize your team, assist your team, and grow your team. If you are the weakest link, it's your job to improve.

If you are the strongest member, it's your job to assist your team to improve. Organizations value those that not only deliver, but can elevate their teams processes, behavior, velocity, and impact to the underlying business and it's current goals.

Plus, it makes really for a really strong and enjoyable team dynamic. One that no one will want to leave, and one that you will make friends for life in.

4. Not asking enough questions

Whether it's your first day at the company, or your fifth year, it's your responsibility to do your job. There is in my opinion, no excuse for not asking the right questions.

We are highly paid, intelligent, and have a very specific job to do - solve problems with code.

The majority of time it will be under pressure, with an unrealistic deadline, and it will take more time than you expect. This is an unfortunate reality for working in software, and the only way to fix that is through better processes.

But, as an individual, it is your job to fully understand the requirements and what is expected of you, and most importantly... push back when something doesn't make sense.

At the end of the day, regardless of what the product manager says, or what the CEO says... it is YOUR code to maintain. You and your team need to be able to ship fast, good quality, and testable code. Period.

Anything short of that is a terrible habit that will quickly infect the codebase, and increase the time to ship new features.

If you get a task that you:

• Don't understand

• Don't have enough information for

• Don't have all of the resources you need (designs, endpoints, etc)

• Doesn't align with the UX, or is simply... off from the norm

It is YOUR JOB to gain clarity on these. Ultimately, it is not your decision on what is added to a code base, or what is prioritized... usually. Additionally, you may have a very limited scope of the grand scheme of what things are being prioritized and the direction of the product or company.

By making sure you are aligned, you are showing your employers, team, and self that you want to have a larger responsibility on the code base, and ultimately your impact to the organization.

This can be true whether you are working for a client or for a large organization. Many times the requirements that get distilled down aren't always ready to go, and some things slip through the cracks.

No one likes to be behind, CEOs especially don't like "technical debt" being the reason for a delayed release or feature... but at the end of the day, you can only deliver the best solution with the best information, and it is up to you to make sure you fully understand the requirements before you start writing any code.

5. Staying in your comfort zone

I'm gonna speak about this area a bit differently than most, because this is a pretty "vanilla" topic. I'd like to speak more directly to those that are adjusted and efficient already in an organization.

Sometimes processes are so good, that your team can get in a flow each sprint, knock out work so fast and effectively that it feels like magic. I hope that every organization can get to that point, because it is truly... amazing.

So my question is... are you there? If not... what should change?

There isn't a single engineer on the planet who will argue about improving a process. The problem is, how do you know if something is an improvement vs a waste of time, and ultimately... a good idea.

One way to experiment with this is to to speak with your team lead directly, and you can ask questions like:

• What process do you think needs improved?

• What areas are we falling behind in?

• What's your biggest concern with the codebase right now?

There are several others, but if you have 1-1s with your team lead, and ask questions like these they open up a door of possibilities.

You can take yourself out of your comfort zone of just shipping, finishing JIRA tasks, and reaching your story point goals (story points suck anyway) by asking deeper questions.

You may just be surprised how much impact, and growth will happen from taking chances and initiative in your team.