People make mistakes, even in the real life... Which should we, geeky programmers, avoid?

  • 40
    Never start a land war in Asia. – BlairHippo Sep 9 '10 at 18:00
  • 16
    Only slightly less bad: Never go against a Sicilian when death is on the line – Frank Shearar Sep 16 '10 at 10:55
  • 11
    Don't eat yellow snow. – Matt Ellen Sep 18 '10 at 23:57
  • 2
    Anybody want a peanut? – Steven Evers Sep 19 '10 at 2:40
  • 2
    The mistake of not programming? – Travis Christian Nov 2 '11 at 19:34

17 Answers 17


Learn that what constitutes "An acceptable degree of precision" to you is "Annoying goddamn nitpicking" to most of the world.

  • 4
    That's a work in progress for me, for sure. – Adam Lear Sep 13 '10 at 14:46
  • 2
    Oh yea.. if it wasn't for estimates and deadlines and project managers, I'd still be tweaking my first program. – Preets Sep 14 '10 at 14:33
  • 3
    Mom: "Pass the orange juice." Me: "That's blueberry juice." Mom: "It's the only juice in the house genius. GIVE IT TO ME." – Adel Sep 10 '11 at 19:55
  • 1
    "Acceptable" is going to far. Better to stick to "adequate" or just a bit more than "unobjectionable" Maybe ten point scale could help here. – MatthewMartin Nov 2 '11 at 19:35

Learn how to listen to people (or users of your product).

Too many programmers are fast to jump to "this user is an idiot" instead of listening to what the person or user has to say. There's something to learn from everyone in this world.

  • 1
    Similarly, take time to watch the people using your product - see how they actually do things; make notes as they do, then discuss with them after to prioritise improvements. – Peter Boughton Sep 9 '10 at 18:02
  • 1
    Oh, and make sure they know you're doing it to make the software better; you're not judging them! – Peter Boughton Sep 9 '10 at 18:02
  • The intent was to have a fun question, but it's nice to see some useful answers. – Tamara Wijsman Sep 9 '10 at 18:04
  • 2
    I way too often think a person is an idiot but force myself to listen, only to realise they are talking sense. Then again, there are times wasted on fools. – burnt_hand Sep 10 '10 at 15:28

Biggest non-programming mistake I've ever seen:

Not learning how to communicate effectively, both orally and in writing.

Take two programmers of equal programming skill, one with good communication skills and one without. The former will go farther, faster every. single. time.

  • 1
    Does that include punctuation? – Randall Schulz Sep 19 '10 at 0:36
  • Were you attempting to point out a punctuation mistake in my answer? If so, please be more specific. – user819 Sep 21 '10 at 9:13
  • I think he was joking; but the comment was directed at "every. single. time." Definitely incorrect punctuation. – Michael Brown Jun 24 '12 at 14:46

Spare normal people from any unnecessary technical details. They don't care.

And don't drool on your female coworkers.

  • Females? You have some? – burnt_hand Sep 10 '10 at 15:29
  • @burnt_hand Yes. Not on IT department though. – Carlos Sep 10 '10 at 17:13
  • 1
    Beards are great for hiding drool. Just sayin'... – Shog9 Sep 18 '10 at 23:33
  • 1
    Than these so called normal people should stop asking me questions where the answer has a lot of technical detail! – Matt Ellen Sep 19 '10 at 0:00
  • 3
    If you are female, don't drool on the males. Or If you are Gay... Yaknowwhat, just don't drool on coworkers in general. – Matthew Scouten Dec 2 '10 at 18:38

Ergonomics. Get a real professional to evaluate your workstation and recommend placement of monitor, keyboard, and chair.

Gently stretch out your hands, wrists, and arms before you begin an extensive keyboarding session. Pay attention to your posture too.

I started getting a lot of wrist pain in 1998 and I had to change a bunch of my habits. To this day I wear wrist braces while working at the computer (I use the IMAK SmartGlove).

Don't play too many video games, that just increases the hours you spend torturing your hands and wrists.

Also, drink plenty of water and exercise regularly. Lay off the soft drinks.

  • do you still go for IMAK SmartGlove ? I already have one, and I was thinking for buying another one, but I was wondering if there were other models that would do the job even better. – Stephane Rolland Feb 18 '13 at 12:00
  • @StephaneRolland, yes, I'm wearing the Smartglove right now. – Bill Karwin Feb 18 '13 at 17:56

Not learning as much about the business domain, users, content you are writing software for.

  • 1
    +1, assuming you mean Not Learning is the mistake. I think this is one of the thing that sets off the great programmers - the ability to soak up the 'domain knowledge' – AShelly Sep 11 '10 at 19:46
  • Sadly, we tend to soak up domain knowledge better than the workers in that domain... – CaffGeek Nov 2 '11 at 19:35

Never eat anything larger than your own head

  • What if it were shaped in such a form that does allow one to easily eat parts of it? – Tamara Wijsman Sep 9 '10 at 18:02
  • 4
    I think its still considered bad practice – Ryan Roberts Sep 9 '10 at 18:15
  • 1
    Also - there are wonderful brand new inventions - fork & knive - they seem to help a lot, or so I heard ;) – Maciej Piechotka Sep 9 '10 at 21:10
  • Fantastic advice. If only I'd heard this years before... – Shog9 Sep 18 '10 at 23:32

Geeky programmers and developers should avoid saying what they really think about project managers, QA testers, DBAs, and other non-programmers to their face.

In essence, be nice.

  • 2
    Or learn to appreciate their not as technical view – Brian R. Bondy Sep 10 '10 at 15:51
  • 1
    I love the way you phrased the first sentence. – davidtbernal Sep 15 '10 at 8:42

Treating everyone else you meet like a programmer. You have to understand that not everyone around you cares about computers as much as you do. It's a hard pill to swallow, but unfortunately, a very real one.


Realize that if you are in a waterfall development environment, requirement documents, BRDs, etc. are, in general, fairy tales. Requirements and software projects as a whole are in a constant state of flux and it is extremely rare to have a set of requirements that don't change throughout the lifecycle of the project. Business people are finicky and like to change their minds a lot. This being said, most software shops still operate with a waterfall mindset. There is a growing movement that supports Agile methodologies (change is inevitable and should be embraced), but I, personally, have never seen or heard of a modern, enterprise development project that had concrete requirements, practices, etc. for its entire lifetime. The key take-away is that things pretty much always change. In my experience, the likely degree to which things change is directly proportional to the length of the project... which is also in a constant state of flux.


"It works on my machine!" is an excuse that can only go so far. Make sure you consider multiple unbiased environments. Your development machine, unfortunately, is well-built to run whatever you program on it!


Learn to admit what you don't know. If you don't know the answer, say so. Don't try to make something up just so you can give an answer. That will get you in trouble in the long run.


Thinking you will be fairly rewarded for your efforts. In other words, you might think that you will be rewarded for working hard and making good code and that you will be punished for spending all day on stackexchange.

But this is not the case. In many cases, you will work with/for clueless people who will just guess how much you work, what your value is, and condescend you.


Learn to estimate.

  • I propose this be changed to: Try to estimate. – spong Sep 9 '10 at 18:08
  • 1
    Or learn to accept estimating will never be perfected and never to charge for a project based on an estimation – Brian R. Bondy Sep 10 '10 at 15:53

A 'non-programming mistake' I see people make (especially the guy in the mirror) is 'stubbing your toe'.

By this, I mean, getting overly excited over a little mistake, like stubbing your toe. Then taking an excessive negative reaction. The frustration ultimately snowballs and a bunch of little problems end up causing massive heart ache and sorrow. When something goes wrong, take a quick break, breath then reengage.

  • Get stuck on a bug, take a break.
  • App works on 3 servers, but not the 4th, take a 5-15 minute break.
  • IDE crashes randomly, take a break.
  • Kids won't stop bouncing off the walls,take a break. (maybe reduce dietary sugar as well)

In the first decade or so of my career, this happened to me all the time. I was my own worst enemy more often than not. I still fall prey to this trap, but far less frequently.


"Assumption is the mother of all f**kups."

-- Under Siege 2: Dark Territory (1995)


Avoid being overly dramatic when mistakes do happen. A typo isn't the end of the world. Just because a task took a little longer than initially estimated isn't the worst thing possible. The tale of the Norden Bombsight would be an example where while someone had a good idea and good intentions in making a new device, there can be various other things that happen to reduce the effectiveness of the new thing created. Definitely a cautionary tale as he hopes to get the spaghetti sauce talk behind him from Feb. 2004.

Not the answer you're looking for? Browse other questions tagged or ask your own question.