When it comes to the craft of programming, there are a ton of bad habits that prevent ordinary developers from becoming really great at their craft. We were able to think of 35, so we compiled them into a list for you.
It can be intimidating to read through a long list of things that you might be doing poorly, but understand that even senior developers make these types of mistakes. The only way to improve as a developer is to optimize your skills on a routine basis. So hopefully this article will help you identify and drop some bad habits so you can improve your craft.
We think that #15 and #33 are some of the most harmful traps that a lot of beginner developers fall into.
1. You act like you have all the answers
As a developer, things are incredibly complicated. You’ll likely be working with new, evolving technologies and you won’t always have all the answers. Rather than clinging to an insecure feeling that you should know everything, you should treat the world in a different way. You should be open to new, different or changing approaching or opinions.
The best developers feel comfortable saying, “I don’t know”, then working on finding a solution.
2. You act defensively when your code is critiqued.
One of the quickest ways to learn and grow as a software engineer is to receive code reviews from more experienced developers. Writing code often involves making a lot of decisions. Sometimes, your code will work fine. But typically, there are ways that the code could work better.
The best developers are willing to have an open and straightforward conversation about the code that they’ve written and how it can be improved.
3. You attend meetings all day.
In the course of becoming a developer, your day will slowly start to have more and more meetings. If you spend most of your day in meetings, you should consider if you can spend your time more productively.
It might make sense to skip some of the meetings you’re invited to.
4. You give up too soon.
It’s easy to be just so close to the solution to a problem you’re facing. And it’s intimidating to not know if a final fix will take you 2 more minutes, 2 hours, or 2 more days. But the only way you’ll ultimately solve the problem is to continue working on it.
5. You refuse to ask for help.
As a programmer, you might not have all the answers, but that’s ok. The best developers know the right time to ask for help and learn from other members of the team.
A big part of asking for help is learning how to ask for help. You’ll find that skillfully articulating a question with all the relevant details helps people help you sooner. You might even discover that going through this process will help you uncover problems on your own.
The term “rubber duck debugging” refers to this exact idea. Explaining a problem out loud can help you uncover the cause, even if the thing you’re explaining your problem to is a toy rubber duck.
6. You try to pass blame to others
People value developers who take ownership and responsibility for the code they write. If there are problems in the code you wrote, take responsibility, accept why the problem happened, and figure out a way to prevent similar problems in the future.
7. You ignore the opinions of others
One of the best ways to learn and grow as a developer is to pair program with developers who have more experience than you. In the process, you’ll generally find that different developers have different opinions on how the code could be better.
The best developers seek out other people’s opinions on code.
8. You write code that prematurely optimizes other code
In most situations, the performance advantage gained from fully optimizing code to the point that it’s difficult to understand is not worth it.
Writing confusing, but optimized code for things that don’t take a significant time to run will only cause confusion for other developers who use the code later on. Ultimately, this will lead to more problems and bugs in the code that you’re working on.
In most situations, the most straightforward way to code something is the right way to code it.
9. You don’t know how to optimize code.
There are some situations where performance is an issue. In these situations, it’s not uncommon for performance to be a big issue, one that needs to be fixed. There are a variety of places that can cause performance problems in modern applications:
- Algorithmic Complexity
- Inefficient Database Operations
- Third party APIs
- N+1 Queries
And a number of other problems. When performance problems arise, knowing how to analyze, understand what is taking the time and then figuring out how to fix it is an incredibly important skill.
10. You undervalue relationships with other members of your team.
You are hired to write code. But you’ll need to interact with other people on the team, too. This includes people like:
- Other developers on your team.
- Nontechnical people who you will work closely with.
- Team members who you don’t currently work closely with.
Your relationship with the other members of the team can be more important than the lines of code you’ll write. The best developers value the relationships of the other people on the team and will do things that sacrifice short-term code-writing productivity in favor or building or strengthening relationships.
11. You engage in office politics
Having worked at a number of companies as a developer, there are certain scenarios where office politics plays a bigger role in getting things done. This can cause a dev team’s mentality to switch from:
Us at company X, against the World.
To a less productive mode of:
Our dev team, against a different dev team.
Having this mentality only adds fuel to the fire and prevents the company from truly making the correct long-term decisions. Each team will have a collection of biases, a fairly complex history, and potentially unusual organizational structure.
Sometimes, other dev teams will make decisions that you don’t think are the correct. But as long as you can accomplish your team’s objectives, it’s best to simply work around other teams quirks, rather than fighting them too hard.
12. You freeze under pressure.
You’ll likely experience some moments during which you need to be sharp, such as:
- Making a change that inadvertently makes a once-functioning application (that has hundreds or thousands of active users) no longer function.
- Having to migrate a major system to another system, which will incur a certain amount of downtime.
When you operate in a scenario where users cannot use the product, there is a ton of pressure. This can put a lot of developers into a heightened emotional state.
You’ll increase your value as a developer by figuring out how to work under pressure.
13. You’re incapable of writing bad code.
Sometimes, you need be ok with writing bad code. Because in the real world, there are trade-offs and things like:
- Deadlines
- Experiments
- Urgent bugs that need to be fixed immediately
You need to have the mentality that it’s ok to write non-ideal code in order to fulfill the demands at hand.
14. You over-engineer simple problems
Most simple problems have simple solutions. These simple solutions can be over-engineered into advanced, complex and intricate thought experiments.
Occasionally, performing these types of experiments can be fun and uncover new tricks that you can use on a regular basis. But the best developers avoid creating confusing solutions to simple problems.
15. You act like a boss. Not a leader.
You should be a leader, which is the person who other developers turn to for guidance, direction, and opinions. It takes time to get to this point and lots of people can’t handle the role.
16. You use the wrong tool for the job.
The best developers are always open to using different technologies, programming languages, and frameworks. They constantly audit themselves to make sure that they always use the right tool for the job.
You can’t level-up by making decisions based on: “It’s what I know.”
Instead, you need to make decisions based on finding the right tool for the job. Doing so will increase your long-term developer happiness.
17. You refuse to research coding questions.
Google is one of the most powerful tools in a programmer’s tool belt. In most cases, the best reaction to most problems you don’t understand is to articulate a Google search query and try to understand the topic.
18. You don’t have a good grasp on your tools
Since you’ll spend a large number of hours using things like text editors, the command line, and other tools to write code, it’s essential to master them. The best developers are power-users of the tools they use and know various tips and tricks to be more efficient when coding.
19. You avoid error messages.
Code errors happen frequently. They also generally include very valuable information about what went wrong, why it happened, and what lines of triggered the problems. Since error messages (and the related stack trace of the lines of code for the files) give all the details of how to replicate a problem, error messages are one of the most useful tools in a programmer’s toolbelt.
The best programmers seek out error messages, rather than try to avoid looking at them.
20. You count the hours.
The best developers enjoy the time they spend writing code and find themselves getting lost in the in it. It’s not like something will change after you code for 10,000 hours. Programming often requires you to think about coding-related problems when not sitting directly in front of a computer writing software. So measuring the hours is fairly difficult, if not impossible.
21. You refuse to learn from mistakes.
The best developers aren’t nervous about making mistakes. In fact, they make a ton of them. It’s far more reckless to never put yourself in a position to make a mistake then to actually make one.
When mistakes happen, just zoom out and understand these 3 things:
- What was the ultimate cause of the mistake?
- Could processes or behaviors be put in place to prevent this category of mistake from happening in the future?
- Could the mistake be detected sooner and had less of an impact.
Refusing to learn from your mistakes will cause you to repeat them.
22. You’re afraid to throw away code.
Often, the only way to come up with the right solution is to come up with several wrong solutions first. Know that spending three days to write the wrong solution will teach you more falling victim to analysis paralysis.
The best developers use tools, like version control, to make it really easy to revert all the changes.
23. You’re romantic about your toolkit.
Some developers love the text editor known as vim. Others hate it and love the text editor known as emacs. But there will be scenarios where it makes sense to use one over the other.
- If you’re on a server with vim installed but not emacs.
- You’re pair programming with a coworker who is using emacs and you want to make one small change.
The best developers aren’t romantic about using certain tools out of principle. Instead, they adapt to their surroundings and are comfortable working in different environments. Personally, I’m not a huge fan of emacs, but if you are and we were to pair program together on your machine, it would be silly for me to require you to spend hours installing and configuring software on your computer that you don’t even want.
24. You avoid interacting with the programming community.
There are programming communities all over the place. In your local city, you likely have a meetup group for your favorite programming language. With organizations like Railsbridge, Girl Develop It and events like RubyConf, RailsConf and much more, there’s no reason not to recognize that there are other developers who want to share their programming ideas and opinions.
Even if you can’t attend these events in-person, watching presentations online is a practical way to be up to date on the future of the programming language you’re using.
25. You don’t have a Twitter account.
Twitter is a useful tool. The creators of massive open source projects, like ruby, rails, JavaScript, and other tools, are present on the platform. They discuss their viewpoints on trends in the programming world. Following programming leaders like @DHH, @tenderlove, @wycats, or @dan_abramov on Twitter can give you a glimpse into the minds of the people who design the software that you use.
The creators of these projects are also quite active and helpful on Twitter. Seeing them communicate will not only educate you, but can inspire you with how welcoming the community can be.
Having a Twitter account will also make you more reachable. It gives people the opportunity to connect with you. This makes the programming world seem a lot smaller, which is super cool.
26. You don’t give back to the community.
You should embrace the programming community as early as possible. If you do so, you will realize how helpful and friendly it is. It’s really quite amazing. And as you get more and more experience, it’s up to you to continue to give back and shape the community into what you think it should be.
27. You struggle for hours to solve something, and when you do, you don’t document it.
These days, it seems like there is a blog post about how to solve just about every single problem out there.
But every so often, you’ll encounter a strange, really specific problem that someone on the Internet hasn’t solved yet.
After spending hours cracking the code on your own, it’s your duty to write the post so that you can help the next person who encounters the problem.
28. You write too many or not enough comments in code.
Comments in code are notes essential notes to developers. Comments, and being able to leave notes for developers who see the program in the future, is typically helpful. But like anything, they should be done in moderation.
Commenting on every single line of code can start to make the code more confusing.
On the flip side, there are situations where writing comments is actually incredibly helpful.
29. You lazily don’t update issues for product managers.
Product managers generally prioritize work in ticketing systems like Jira, Redmine or other systems. It can be easy to write code, jump onto the next task at hand and not return back to the initial ticket to update it.
It’s important for the product managers to get timely updates and know the status of the product. If you don’t update the issues in these systems in a timely manner, it can cause a lot of headaches.
30. You frequently bundle unrelated features into the same initiative.
As a developer, it can be easy to put yourself in a bad situation by grouping two unrelated things into the same initiative. Sometimes, especially for small things, this habit doesn’t cause too much trouble. But if the two different initiatives are both fairly large in scale, untangling the issues can be complicated.
There’s nothing worse than wanting to ship a feature (that is basically done), but having to complete a massive, totally unrelated thing first because of bad planning up-front.
31. You carefully come up up with a smart plan with other members of the team, only to completely abandon it and change course entirely when one unexpected thing happens.
When writing software, unexpected things will frequently come up. As a developer, you will often be in the driver’s seat when it comes to getting things done. This means you have the ability to control the destiny of how the feature ultimately gets fit. It also means that you can easily behave in ways that are just plain stupid. It’s never good when one of your dumb decisions makes other people have to deal with major consequences.
If you’ve taken the time to come up with a smart plan, don’t ditch it at the last minute. It’s pretty much the worst thing you can do.
32. You stick to a thought-out plan that clearly isn’t working.
The only thing worse than abandoning a plan at the last minute is refusing to stop executing a bad idea. When adding a new feature, fixing a bug, or writing any code, good developers are always auditing themselves and asking if they are on the right track.
Having tunnel vision and executing on a plan that has proven to not work is counterproductive. You should avoid falling into this habit at all cost.
33. You consistently apologize for the bad code you’re writing.
If you’re frequently architecting code in a reckless way that works, there are probably some major underlying problems. In this case, you should make note of these in the comments in your code.
However, if you need to do this all the time, you should evaluate if the deadlines you’re rushing towards are actually important. Perhaps spending one or two additional days to accomplish something the right way is a better idea than implementing something the quick way.
34. You don’t spend the energy you should performing code reviews.
The development team is in it together and it is every member of the development team’s responsibility to make sure the code that other members are contributing is up to the high standards of the team.
Without stringent code reviews, it’s easy for codebases to have multiple “quick fixes” pile up on top of each other. This creates a product that is fragile and difficult to improve upon.
Reviews are worth your time and energy.
35. You don’t spend enough time mentoring junior developers on your team.
Your team should be constantly learning, growing, and becoming better at programming. It’s your job to ensure that this is happening on a routine basis.
So once you level up your own skills, you should spend time pair programming with people who have less experience than you. This is incredibly valuable to them and will help teach them how to approach problems in a vastly different way. It may only be an hour or two of your time, but that time helps shape the growth of the rest of your team.
The only way to get better is to optimize all the time.
I strongly believe that every developer is a work-in-progress. Having self awareness of the bad habits you have and working to fix them is the only way to truly improve and become a better developer in the long-term.
If you found this post insightful, share it using the Facebook and Twitter buttons below.
