In my last post, I explained why good code matters. However, if you don’t have any background in coding, you have no idea what makes code good or bad. In this article I’m going to explain—in layman’s terms—why we developers sometimes feel like barfing when we look at another coder’s work.

No, not that…

First of all, let’s get some misconceptions out of the way. Coders often argue over coding conventions. A classic example of one of these arguments concerns opening curly braces. Here are two ways of writing your curly braces:

This is not good or bad code, merely coder’s preference. Generally, if your coder is following any convention at all, he’s a decent coder.

Two types of bad programmers

We’ll call the first type of bad programmer the coding MacGyver. The MacGyver uses unconventional tools to solve his problems. Don’t get me wrong, when you’re in an emergency, you may need to duct tape things together. However, when you’re building something complicated like a web application, you really don’t want to be using makeshift building materials. A MacGyver approach is great for fixing short-term problems, but you don’t want him building anything large for you.

The second type of bad programmer is the guy who doesn’t listen or think before acting. Or neither [grimace]. We’ll call him Leeroy Jenkins. Whenever a programmer writes code, he is really just using tools to build, improve, or fix stuff. A good programmer carefully plans his project, visualizing how each piece will fit together. The Leeroy Jenkins coder will generally skip the planning step, rush into the project, and make poor decisions that cost you time and quality later in the project.

The results of bad programming

Imagine that your friend asks you to edit his stream-of-consciousness poem. In order to do so, you have to recreate the author’s original thought process, right? The problem is that your friend has ADHD, multiple personalities, and took 3 years to write the poem. You are never going to be able to understand his work mess. This is exactly the problem with some poorly written code. Three different interns have maintained the code over the last 3 years. When we see code like this, we always try to persuade the client to start from scratch. Sometimes there are things that are not worth saving.

What to look for

We’ve looked at qualities we don’t want in our coders. On the flip side, what sorts of attributes do we want our coders to have? Here are a few:

• Experience – You want coders (and tech companies) who work with a wide variety of projects. We know more systems, and can make more informed decisions.
• Flexible – If your developer only uses one system, that’s a red flag. The one software to rule them all does not exist.
• Analytical – You want your developers to understand your needs and to find the best solutions.
• Careful – A good developer is careful to make promises, and careful when making changes.

Recap

Hiring a bad programmer or tech company will end up costing you money and time. To avoid this keep your feelers up, and stay tuned to what your developer is saying. If you start see red flags or feel like you can’t trust your developer, come talk to us.

Photo credit: slworking2 via Compfight