People make mistakes, even in the real life... Which should we, geeky programmers, avoid?
-
40Never start a land war in Asia.– BlairHippoSep 9, 2010 at 18:00
-
16Only slightly less bad: Never go against a Sicilian when death is on the line– Frank SheararSep 16, 2010 at 10:55
-
11Don't eat yellow snow.– Matt EllenSep 18, 2010 at 23:57
-
2Anybody want a peanut?– Steven EversSep 19, 2010 at 2:40
-
2The mistake of not programming?– Travis ChristianNov 2, 2011 at 19:34
|
Show 2 more comments
17 Answers
Learn that what constitutes "An acceptable degree of precision" to you is "Annoying goddamn nitpicking" to most of the world.
-
4
-
2Oh yea.. if it wasn't for estimates and deadlines and project managers, I'd still be tweaking my first program.– PreetsSep 14, 2010 at 14:33
-
3Mom: "Pass the orange juice." Me: "That's blueberry juice." Mom: "It's the only juice in the house genius. GIVE IT TO ME." Sep 10, 2011 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. Nov 2, 2011 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.
-
1Similarly, 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. Sep 9, 2010 at 18:02
-
1Oh, and make sure they know you're doing it to make the software better; you're not judging them! Sep 9, 2010 at 18:02
-
The intent was to have a fun question, but it's nice to see some useful answers. Sep 9, 2010 at 18:04
-
2I 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.– DanSep 10, 2010 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
-
Were you attempting to point out a punctuation mistake in my answer? If so, please be more specific.– user819Sep 21, 2010 at 9:13
-
I think he was joking; but the comment was directed at "every. single. time." Definitely incorrect punctuation. Jun 24, 2012 at 14:46
Spare normal people from any unnecessary technical details. They don't care.
And don't drool on your female coworkers.
-
-
-
1
-
1Than these so called normal people should stop asking me questions where the answer has a lot of technical detail! Sep 19, 2010 at 0:00
-
3If you are female, don't drool on the males. Or If you are Gay... Yaknowwhat, just don't drool on coworkers in general. Dec 2, 2010 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. Feb 18, 2013 at 12:00
-
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'– AShellySep 11, 2010 at 19:46
-
Sadly, we tend to soak up domain knowledge better than the workers in that domain...– CaffGeekNov 2, 2011 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? Sep 9, 2010 at 18:02
-
4
-
1Also - there are wonderful brand new inventions - fork & knive - they seem to help a lot, or so I heard ;) Sep 9, 2010 at 21:10
-
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
-
1
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.
-
-
1Or learn to accept estimating will never be perfected and never to charge for a project based on an estimation Sep 10, 2010 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.