Take the 2-minute tour ×

Just curious, what kinds of temptations in programming turned out to be really harmful in your projects?

Like when you really feel the urge to do something and you believe it's going to benefit the project or else you just trick yourself into believing it is, and after a week you realize you haven't solved any real problems but instead created new ones or, in the best case, pleased your inner beast with no visible impact.

Personally, I find it very hard to not refactor bad code. I work with a lot of bad legacy code, and it takes some deep breaths to not touch it when I have no tests to prove my refactoring doesn't break anything.

Another demon for me in user interface, I can literally spend hours changing UI layout just because I enjoy doing it. Sometimes I tell myself I'm working on usability, but the truth is just I love moving buttons around.

What are your programming demons, and how do you avoid them?


locked by World Engineer Jun 15 '13 at 21:05


I find it humorous that nobody has been able to answer the second part of your question - "[and] how do you avoid them?". –  Craige Feb 24 '11 at 16:30
Has anyone noticed that this has been the top question on SE all day. –  msarchet Feb 24 '11 at 20:26

53 Answers 53

To answer the question about avoiding them: Familiarise yourself with Anti-Patterns so you can call them out when you recognise them.


My brain's worn out from this project. I'll just take a quick break on this short side project to rejuvenate it.

I do this all the time... should probably stop. –  Ben Feb 25 '11 at 14:07

Writing new code after code-freeze date.

Code freeze date must be set in stone. Any new code written after it must be moved to the future release, as it may require all kinds of regression testing.


Cleverness. Of course, not always. Some cleverness and conciseness will make your code look very nice and maintainable. But just because you can do


instead of a couple of lines of if statements, doesn't mean you should.

Btw, yes I know there is a bit of redundancy in my example... If you even caught it yourself :)


"There must be a better solution to this."

And you end up thinking and thinking, and letting your mind drift off to a far away land until you realized you were gone for too long. It should be fine, but not when you have a deadline.


All of the others plus feature creep: "It would be really cool if it did this, and I know the customer will love it and would have put it in the spec if they'd thought of it". I try to avoid this by asking where in the real spec the requirement exists for this real cool feature.

Then again, I don't often get written specs.


"I have been assigned a feature that interfaces with [software/eg: sharepoint]. I should probably know everything there is to know about that software."

Then you spend weeks researching that product, when the feature could have been written and tested in a day or two. The hunger for knowledge has a dark underbelly. rawr

Yup, but for me SharePoint is not the case here. On the opposite, I want to spend as little as possible of my time reading or learning about it. –  Dan Feb 24 '11 at 20:05

"it's only the pilot, so there's no need to make it easy to maintain or expand".

In my experience it's more common to see the pilot enter production and the product it's supposed to be a pilot for to be scrapped than for the pilot to be scrapped and the actual product developed to production ready status.


Spending too long tweaking the editor. Trying to find the best font and colorscheme for programming.


"I'll comment/document this later"

it never happens, the author moves on, and then you find out that they don't comment their code when the job has been assigned to you.


What are your programming demons,

Everything that's already been mentioned, particularly the urge to refactor like mad.

and how do you avoid them?

Before starting any nontrivial edit, take my hands off the keyboard for 5 seconds and quickly weigh possible outcomes of changing vs. leaving it. Then again before committing, weigh the same consequences for about a minute.


To start attacking a new project, without understanding it, and I usually avoid this by researching a little about the project domain before I actually begin to work with it, just to have a good starting point, and to prove the project is more complex than I initially through it was.

I also have the problem that I like to move around with buttons, they are so cool!! But maybe that's because I'm doing multimedia systems and user interface design... So for me the solution to this problem, was to actually include that in my curriculum and study something about it, so that I have a valid excuse if anyone sees me playing with the UI a lot. (And that includes putting the background green, the text orange, and the icons with a lot of yellow.)


Very complete list: anti-patterns.


I think I have it in my head that enums are a lot more useful than they really are in Java. I tend to try and do too much with them, and then get bogged down because they don't really support polymorphism.


over committing yourself to avoid in-house development, 90% of a wheel is not better than inventing one.


Someone said premature generalization, but premature specialization can be just as bad. With premature generalization, you can get a software that works for 50% of the cases, but premature specialization can work for 5%, or none. In the end, management would rather have 50% than 5%.


Doing countless hours of extra work for the company in my off time only to find out "that wasn't the direction they were looking for."


To find a comfortable sofa to work or work lying in bed.


Using a framework while not fully understanding it. But then again. a framework is only fully understood by it's creators (most of teh cases). I don't have a real solution for that item but trying to understand as much as possible from a framework.

* Calculates the return value for humptyDumpty
* return int modifiedHumptyDumpty
function awesomeWayToCalculateSomething(int humptyDumpty) {

TODO: I need to document this properly.

Will _never_ happen


Using a language feature, an idiom, or a design pattern not because it is the best solution to the problem, but purely for the sake of using it.


Fixing a bug that's been bothering you because it is "so simple", but never telling QC and/or the customer.

These fixes always crash production.


Being "Perfect"

While avoiding getting it right the first time is a problem, it's not near as bad as an undying focus on perfection. Just get it done, there is no such thing as perfect, and if there is, it's purely temporal, or already been done and not worth the time to do again.

