What are some bad programming practices every programmer do ? and how to avoid ?

The following are most of the programmers are do

•     Assuming you know how to actually write a working program, as opposed to a buggy piece of <bleep>
•     Thinking you have completely mastered or understand programming, computer science or software engineering
•     Listening to gurus, white knights and sages over your best own judgement
•     Using tool X because all the other lemmings are doing it
•     Not thinking carefully about *every* line of code that you write
•     Losing track of the forest when making a tree.
•     Forgetting that paradoxes are the state of being in software engineering
•     Assuming that picking the magic algorithm, design pattern or magic potion will solve all your problems
•     Forgetting that theoretical CS and hardware impose hard limits
•     Forgetting that theory is useless at the end of the day
•     Reading someone else's list about bad programming practices and assuming that you know the end all and be all
•     Using the wrong definition of algorithm, i.e. anything other than algorithms are not any of the following: non-ambiguous, finite, time-and-resource processes, communicated in a formal language
•    Being sloppy in your code and thinking

Some programming practices that grow tech debt, increase the cost of maintainability and cause unexpected behavior or frustrate your colleagues:

1. Naming functions, variables, files and classes poorly.
2. Switching or selecting a new framework, library because it's cool, not because it solves a real problem. 
3. Upgrading to the latest version of something because it's been released, not because it solves a problem.
4. Experimenting (dabbling) with a bunch of different technologies in a production system that you expect to live a long time. Solving the same problem a bunch of different ways in one system.
5. Allowing unused code to remain in a system.
6. Catching errors/exceptions and silently allowing failures to go unknown.
7. Carelessly creating objects that implement the same interface without knowing how the performance characteristics differ. (Pick ArrayList/LinkedList thoughtfully).
8. Not taking the time to learn how things really work to expand your intuition.
9. Let unexplained errors continue without investigation.
10. Taking the time to whiteboard up a design and show it to someone else before taking on a medium or big change
11. Not googling your question before bothering the engineer next to you
12. Not asking for help when you're stuck and slipping the release date
13. Not adopting the existing coding standards when you're joining an existing project.
14. Breaking the build or checking in a big change and leaving
15. Making the build process more complicated, brittle and slow
16. Putting in stupid (offensive, verbose, useless, performance killing) log statements
17. Speed kills.  Write your code carefully, debug it, integrate it, refactor, optimize and repeat.  The challenge is quality not quantity.  Software engineering requires skilled craftsmanship.  There is too much crappy code being written daily in the world.
18. The lack of self criticism.  Being satisfied and contented with one's code is a dangerous habit.  Take a major piece of code you wrote a few years back and if you cannot see how to improve it, you are not progressing forward technically.  Be willing to learn from others.   Learn to recognize, acknowledge and learn from your mistakes. 
19. Complacency.  Getting code to work is the lowest acceptable outcome.  One should always strive for clarity, simplicity, extensibility, modularity, predictable runtime behavior and scalability.   Code that has these highly desirable attributes is more stable, testable and maintainable.  If you're any good, some future engineer will have the task of reusing your code.  Make sure this engineer has kind thoughts for you.
20. Using the first proposed design.  There are many possible designs for software modules.  Solve the task at hand N different ways conceptually on the whiteboard.  Then critique each design in terms of pros and cons.  Then choose the optimal design with the best trade offs.  If you can only come up with one design you are not thinking hard enough.  Implement the chosen design.  Do not be lazy.
21. Cut & pasting code.  This is very dangerous habit.  Crappy code propagates  with slight modifications like a horrible virus with deadly mutations.   When code has to forklifted to retrofit the latest API some poor sap has to fruitlessly track down N random obscure hidden inline locations as opposed to one clean API interface (use an interface, function or class please).  IDE code refactoring tools should be used instead.  Less is more.  Create less code by refactoring, not more code. Adding more code by cut & pasting code is very evil creating an unmaintainable codebase.
22. Lack of attention to detail.  Although coding requires high level design and conceptualization, skills, it also requires extreme attention to detail as it is unforgiving.   Code that is 99% correct is as nonfunctional as code that is 50% functional.  Code either works or it does not, approximate incomplete  solutions have no value.
23. Lack of ownership.  Coding is a refined craft which requires pride of ownership.  If one is the original author of a software module, one should always being willing to improve it, maintain it and support it indefinitely.  Disowning code breaks the positive feedback loop for improving your skills using the complete software lifecycle.  Your code should have an infinite lifetime warranty honored by your sincere personal commitment.  Great code does not have an expiration or or a use by date.