Developers have a challenging enough job without bad habits getting in the way, but everyone winds up falling victim to a few. That's why it's valuable to take a step back every so often, examine your work patterns, and remedy the faults and blind spots you're bound to find. Here are some of the biggest pet peeves our programming team identified.
1. Wearing rose-colored blinders
Any system is susceptible to a wide range of internal and external errors. Yet many developers tend to write code that's structured to handle only successful scenarios gracefully. They fail to test for those times when user or system errors occur. When unsuccessful cases inevitably arise, large code revisions may be required to accommodate them.
2. Adhering dogmatically to patterns/conventions
Code conventions and styles are great guidelines for ensuring your code is readable and consistent across a codebase. But as with any other system, following them inflexibly can restrict your productivity. Falling too deeply into habits can lead developers to shoehorn certain patterns or conventions into situations where they don't belong. Remember, guidelines aren't ironclad rules—you need to apply your best judgment, too.
3. Missing the big picture
No system is an island—a code change in one portion can impact related components in ways you don't expect. The best way to stay on top of these ripple effects is to write solid unit tests.
Managing interdependencies can be accomplished through a technique called "separation of concerns," in which methods and classes are focused toward the concrete task at hand instead of trying to accomplish a wide range of business functions. Separating concerns allows for easier testing, and gives developers confidence that their changes won't trigger adverse side effects.
4. Over-engineering
Eager developers often try to solve problems that don't exist, or build systems to handle situations far outside the scope. While the impulse to solve a core problem in an elegant way is a good one, it needs to be tempered with a realistic grasp of further development opportunities and current resources. Limitations on a project's scope and responsibilities exist for a reason.
5. Under-documenting
Everyone here is guilty of this at some point, so it bears repeating: Including good comments in your code makes life easier all around. Clarity is the key here. For instance, a comment such as, "this will loop over person objects and call remove on each" is terribly unhelpful, because that's clear from looking at the code. Instead, write something additive like "we need to remove this person object because the user no longer belongs to X group when Y circumstance is met."
This doesn't just apply to team projects, either—if you're working solo, You Five Months From Now will appreciate the effort Present You puts in.
6. Developing extraneous features
Don't simply put your head down and charge into the programming. Establish the technical design first—without understanding the problem at hand, you'll never solve it.
7. Over-optimizing
Everyone wants to write performant code that's efficient and simple. Often they'll spend much of their initial development pass trying to optimize this function to within an inch of its life, or devising neat tricks to cut out cycles. But with modern hardware—both processors and memory—excessive optimization isn't worth the effort.
For instance, take a developer who's determined to move a code segment from taking 0.7 seconds to taking 0.5 seconds. If that effort eats up two days worth of working hours, the code segment would need to be run roughly 300,000 times to pay back the time investment. Furthermore, those extra 0.2 seconds are only worthwhile if 1) the segment is the biggest speed issue in your system, and 2) it's noticeable to the user—neither of which you'll know until deployment.
8. Resting on your laurels
They say the half-life of any developer's skill set is two years—which means every other year, half of what you know becomes obsolete. Devote a portion of your working hours to brushing up on the latest technologies, frameworks, approaches, etc. Read blog posts and trade publications, apply new concepts in your work, swap ideas with your peers, and embrace the fact that a developer's training is never complete.
9. Getting a bit too clever
Sometimes there's a fine line between "creative problem-solving" and "coming up with a crazy hack that nobody else understands." If your clever solution can never be replicated, improved, or repaired, was it really all that clever?
10. Reinventing the wheel
Sure, putting your own spin on simple processes can be fun. But it's awfully easy to get carried away without adding any real value. How many more approaches to "namespace patterns" in JavaScript does the world need?
What do you think?
Which bad habits should developers try to minimize? Which good ones should they adopt? Let us know in the comments.
0 comments