What are some bad programming practices every programmer needs to be aware of in order to avoid them? originally appeared on Quora: the knowledge sharing network where compelling questions are answered by people with unique insights.
1. Acting like you have all the answers.
Don’t cling onto the insecure feeling that you have to know everything. You don’t. And that’s ok.
2. Attending meetings all day.
If you spend most of your day in meetings, you should consider spending your time more productively.
3. Acting defensively when someone critiques your code.
The best developers are willing to have an open and straightforward conversation about the code they’ve written and how it can be improved.source
4. Giving up too soon.
Too many programmers get so close to a solution, only to give up right before they’re about to solve the problem.
5. Refusing to ask for help.
By going through the process of articulating your problem to someone else, you’ll often discover the solution. This is what is known at “rubber duck debugging.”source
6. Passing blame to others.
The most valuable developer is the one who takes ownership and responsibility for the code they write.
7. Writing 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.
8. Ignoring the opinions of other developers.
One of the best ways to learn and grow as a developer is to pair program with developers who have more experience than you. Go seek out other people’s opinions.source
9. Not knowing how to optimize code.
There are some situations where performance is a big issue, such as problems with:
- Algorithmic Complexity
- Inefficient Database.
- OperationsThird party APIs
- N+1 QueriesWhen performance issues arise, you need to know how to analyze them, understand what is taking the time, and how to fix the problems.
10. Undervaluing relationships with other members of the team.
You are hired to write code. But you need to be able to interact with other members of the team, too.
11. Engaging in office politics.
Sometimes, other development teams will make decisions that you think are incorrect. 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.source
12. Freezing under pressure.
When you operate in a scenario where users cannot use the product, there is a ton of pressure. You need to develop the ability to stay calm and get the job done.
13. Being incapable of writing bad code.
In the real world, there are trade-offs based on things like:
- Deadlines
- Experiments
- Urgent bugs that need to be fixed immediately
- You need to have the mentality that it’s ok to write bad code to fulfill the demands at hand.
14. Over-engineering simple problems.
Don’t create confusing solutions to easy issues.
15. Acting like a boss. Not a leader.
Too many developers don’t know how to manage other people. You should be the person who other devs turn to for guidance and direction- not just step-by-step instructions.source
16. Using the wrong tool for the job.
Stop making decisions based on “it’s what I know.” You need to be open to using different technologies, languages, and frameworks.
17. Refusing to research coding questions.
Google is one of the most powerful tools in a programmer’s toolbelt.
18. Not maintaining 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. Take the time to learn the tips and tricks that make you more efficient.
19. Avoiding 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. You should seek out error messages, rather than try to avoid them.
20. Counting 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.
21. Refusing to learn from mistakes.
This is counterproductive. When mistakes happen, just zoom out and understand these three 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. Being afraid of throwing away code.
Know that spending three days to write the wrong solution will teach you more falling victim to analysis paralysis.
23. Romanticizing your developer 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
24. Separating yourself from the developer community.
There are programming communities all over the place. With organizations like Railsbridge, Girl Develop Itand events like RubyConf, RailsConf and much more, there’s so much to discover.
25. Not having a Twitter account.
The creators of massive open source projects, like ruby, rails, JavaScript, and other tools, are present on Twitter. Spending time here can give you a glimpse into the minds of the people who design the software that you use.source
