What is the worst programmer habit? [closed]

Question

Many people get into programming because programming is fun. At least in the beginning. After some time doing it professionally, programming is no longer fun, often just hard work. Sometimes we develop bad habits along the way to make it fun again. Some bad habits of programmers are well known, for example the "I fix that in a second" habit, the "reinvent the wheel" practice or the "all code except mine is crap" attitude (which often leads to "I will re-write the entire program from scratch" syndrome). There are things which a programmer should never do. What is the worst programmer habit?

Answer 1

Having contempt for the end-user is the worst of the worst in programmer habits.

Answer 2

For me the most common one is: "I will fix that small bug later....", where later=never

Another one: Commenting out a piece of code 'just in case', instead of making use of SVN/GIT"

Answer 3

Failure to simplify and refactor

This is IMO by far the most detrimental of all programmer habits. Many programmers are quite smart so when they write an application they can keep all the "complexity" in their head while they're writing it. The problem is when that code needs to be revisited by them or someone else. Wrapping your head around a complex solution that was incrementally built but never simplified can be incredibly hard.

Good code is a simple as it can be, but not simpler. Good programmers refactor their code continously to keep the conceptual integrity of the solution intact.

Answer 4

Just a few:

• Ignoring wisdom accummulated over the last few decades, and thinking that only the latest cool technology is what matters.
• Blindly jumping into every bandwagon that is thrown at him/her by industry fashionistas, be it agile methods, SOA or anything else.
• Failing to gain contextual insight about what they do, by learning about fields other than programming, such as management science, management theory, psychology, etc. (see here).

Answer 5

Lack of humility.

In my experience those considering themselves much better than their peers usually aren't. Knowing that makes you humble.

Answer 6

Just a simple fix. No need to test.

Answer 7

Assuming things.

"Assumption is the mother of all f*** ups!"

Do not assume. Test/assert/prove your assumptions.

i.e. Ignorance and false sense of "knowing it". Lack of humility and not understanding that it is what you do not know, think or plan for that bites you.

Answer 8

My worst habit is underestimating effort required. "Oh I think I can have that implemented by the morning..."

Answer 9

-"I am not a tester"

And then those guys tend to write buggy code that is not testable.

Answer 10

Copy-pasta. Badly designed code can be understood and refactored. Copy-pasted badly designed code has to be diffed and the differences understood before it can be refactored.

Answer 11

Assuming that one is smarter than ones peers.

Answer 12

Code First, Think Later....

then code and think again

Answer 13

Not caring enough to notice or fix by oneself when things go wrong.

Answer 14

• Assuming other people have knowledge that they couldn't possible have by giving answers to questions using advanced terminology - rather than attempting to explain things in the simplest possible terms. If they understood the terminology, they would probably know the answer.
• Explaining solutions in these abstract terms, without giving an example of how to implement.
• Having no patience with those who are trying to learn.
• Looking for the answer that utilises their coding ability, rather than the simplest answer - or a solution which is already available.
• Looking down on programming languages which aren't their own language of choice.
• Not annotiating code for future users.

Answer 15

Over-engineering, because "we'll need that in the future".

Answer 16

"Damn I'm not catching that case, better write another if-test..." Instead of well thought algorithms.

Answer 17

• Over-genericising and -abstracting things that don't benefit from it. Often done in the name of "avoiding hard-coding". E.g. having a DB table complete with access layer to hold the structure of the application's navigation menu. If the menu changes, it's pretty much guaranteed to be because of new features for which you'll have to touch the code anyway. And if new pages can be added without touching the code, you're developing a CMS - why aren't you using/extending an existing one?

• Related: Building the system architecture around what's technically interesting rather than what the requirements call for. Extreme example: programming a "rules engine" that ostensibly "executes" the business requirements as supplied by the users (except it turns out to be inflexible and unusable by non-programmers).