5 Mistakes You Can Make in Development

So you’re either new to development or have been around the block a few times. What are some common mistakes you can make that could be easily avoided with the right approach?

Without further ado, here are 5 Mistakes you can make in development and how to avoid making them yourself:

Mistake #1: Being driven by task completion.

So you wrote some amazing code to satisfy a development task. Your project status meeting is tomorrow morning and you’re going to look like a rockstar when you can tell the team you knocked out three tasks when they estimated you’d only get through one.

It’s way too easy to fall into the trap of measuring the effectiveness of a developer by the number of completed tasks.

But what if the task doesn’t satisfy the success criteria? Or a bug resulting from rushing is missed during testing, makes it to production, and is found by an end user?

Corners can be cut to make a developer look good in the “task completion” game. We’ve all worked with developers who think they are exceeding expectations by crossing things off the team’s to-do list — only to have the task kicked back to them as a defect. This results in wasted energy, added overhead, mud in your face, and reduced confidence.

Consider having a mindset to deliver rather than simply completing tasks. Make sure you are clear on the expectations of your work. Once you have a solid grasp of the assignment, focus on satisfying the requirements by writing quality, tested, functional code. So what if you only get one of the original tasks completed in the same amount of time? Take pride in the fact that it works and won’t come back to you as a bug. Over time you’ll earn respect as someone that can deliver. Who knows? You might end up with a nice little reputation.

Mistake #2: Solving the wrong problem.

You’ve hashed things out on the whiteboard, assembled the right people, nailed down the project scope…things are looking good. The team executes like a well-oiled machine and delivers a quality, elegantly architected solution…

But wait. Oh no. #@$%! You solved the wrong problem, so now our schedule is going to slip, the money went poof, and the team morale is squashed.

If the end result doesn’t solve the problem, you’ve failed. Depending on the project at hand this could be the result of a few things:

• Poor Customer Discovery
• A Requirements Analyst went rogue that is out of touch with true business needs.
• Incorrect assumptions were made.

Save yourself from burning a big pile of cash and make sure the goal is clearly identified before writing a line of code. Depending on the size of the project, you may want to revisit or challenge the original problem being solved and adjust as needed.

Mistake #3: Being a jerk.

In my experience, the biggest challenges in technical endeavors often have little to do with technology. People and communication are typically the things that make or break a project. Unless you are a one-person code-slayer, effective software development efforts require collaboration.

How do we become better at working with our fellow developers? We are commonly smart, opinionated and detail-oriented people who take too much pride in our code and feel strongly that our that ideas are amazing. Given those personality generalizations, here are a few things we can do to not be jerks to each other:

• Check your ego at the door, be humble and understand everyone’s on the same team.
• Bullshitting is an art, but when not executed well you can find yourself kicked off the cool kid's lunch table. Admit when you don’t know something but own it and seek the answer.
• Alphabet soup doesn’t impress. We get it. You know the jargon.
• Recognize that using a stack or framework once does not make you an expert.

Mistake #4: Overindulging in features.

It can be hard to pass up spending a few extra minutes adding a feature that you know the customer or client will love and isn’t expecting. It may seem like a great way to earn some brownie points. You are already in that area of the code, it’s fresh on your mind, so why not stretch a little to add a bit more to the product?

Resist this temptation. We’ve all done this. Why is bad?

• Too often when the client sees the fancy new feature, they will say “that’s great…but…” and then you are on the hook to revisit that code and make changes per the client’s wishes.
• More code brings the potential for more bugs.
• A new test case or set of test cases may be required to cover the new functionality. Now the testing scope has increased.
• Hopefully, your work is appropriately prioritized. Spending time on bells and whistles potentially steals time from higher priority tasks.

A bonus feature can quickly become a burden when you stop and examine the potential impacts. It’s better to stick to the agreed-upon scope for the task or project.

Mistake #5: Surrendering too quickly.

You are swearing under your breath. You will win. You will figure this out. You got this. After researching the nitty gritty details of a third-party component you are blaming for a pesky bug, you have a eureka moment. You are over two hours into this hangup, and you realize you misspelled a stupid variable name and the problem is your code and it’s totally your fault. But it’s working now! Finally!

We’ve all been there more times than any of us are willing to admit. Should I have bothered my teammate for help? When do you dig in and solve a problem yourself versus asking for assistance?

The answer probably varies a bit based on your experience level and the nature of the snag, so what do you do when you are hung up?

• Ask another developer for help. Most times you’ll find when explaining the problem to another developer the solution will reveal itself.
• Give up and do a table-flip. (Kidding, just checking to see if you are still reading)
• Talk to a rubber ducky.
• Put down the keyboard and go for a walk.

For more inexperienced coders, there is a lot to gain by trudging through a problem yourself. A junior developer is still honing their troubleshooting and debugging techniques. You often end up learning about completely unrelated aspects of the framework or language when trying to solve the issue. That said, if after spending a reasonable amount of time you are still stuck, speak up! It is not a sign of weakness.

Okay fine, what is a reasonable amount of time? Fair question. Chasing your tail for several hours is probably not adding value and your client certainly doesn’t want to pay for that, so when you’ve reached the point where you are longer adding value it is probably the time to hit the brakes.

So what about a senior developer? When should you say when? Since an experienced developer presumably has the tools and experience to quickly triage and narrow in on a problem you should try your best to cover the bases before distracting your teammate from their work. Once you feel you can answer the questions that you anticipate the other developer is going to ask, don’t hesitate to leverage their expertise.

It’s important to remember not all coding happens at the keyboard. I don’t know how many times I’ve solved code problems in my head during the car drive home or while in the shower — taking a break from a problem can be the best way to keep you moving forward.

— -

So there you have it, the 5 mistakes you can make in development and how to try and avoid them.

What are some lessons you’ve learned as a developer? Leave a comment below or tweet us @wewritecode.