What are non-programming mistakes that a programmer should avoid? [closed]

Question

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

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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

And don't drool on your female coworkers.

Answer 5

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.

Answer 6

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

Answer 7

Never eat anything larger than your own head

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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

Answer 12

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.

Answer 13

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.

Answer 14

Learn to estimate.

Answer 15

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.

Answer 16

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

-- Under Siege 2: Dark Territory (1995)

Answer 17

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.