Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question

closed as not constructive by Eric Wilson, Thomas Owens, Kate Gregory, Mark Trapp Nov 3 '11 at 6:29

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

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

17 Answers 17

up vote 30 down vote accepted

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

share|improve this answer
3  
That's a work in progress for me, for sure. –  Anna 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
add comment

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.

share|improve this answer
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
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
show 1 more comment

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.

share|improve this answer
1  
Does that include punctuation? –  Randall Schulz Sep 19 '10 at 0:36
show 2 more comments

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

And don't drool on your female coworkers.

share|improve this answer
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
2  
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
1  
+1 for "normal people". –  rightfold Nov 2 '11 at 20:58
show 2 more comments

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.

share|improve this answer
show 2 more comments

Never eat anything larger than your own head

share|improve this answer
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
show 2 more comments

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.

share|improve this answer
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. –  notJim Sep 15 '10 at 8:42
add comment

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

share|improve this answer
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
show 1 more comment

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.

share|improve this answer
add comment

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.

share|improve this answer
show 1 more comment

"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!

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Learn to estimate.

share|improve this answer
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
show 1 more comment

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.

share|improve this answer
add comment

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

-- Under Siege 2: Dark Territory (1995)

share|improve this answer
add comment

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.

share|improve this answer
add comment

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