Slashdot Mirror
Ask Slashdot: What Are Some Lies Programmers Tell Themselves?
snydeq writes: "Confidence in our power over machines also makes us guilty of hoping to bend reality to our code," writes Peter Wayner, in a discussion of nine lies programmers tell themselves about their code. "Of course, many problems stem from assumptions we programmers make that simply aren't correct. They're usually sort of true some of the time, but that's not the same as being true all of the time. As Mark Twain supposedly said, 'It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so.'"
The nine lies Wayner mentions in his discussion include: "Questions have one answer," "Null is acceptable," "Human relationships can be codified," "'Unicode' stands for universal communication," "Numbers are accurate," "Human language is consistent," "Time is consistent," "Files are consistent," and "We're in control." Can you think of any other lies programmers tell themselves?
I'll document it tomorrow
or even "My code is correct, so I don't need to test."
"We'll fix it in the next release."
I'm a better than average programmer.
Who ordered that?
"I went to the smart school and do intellectual things. My boss went to the party school and does PHB things. I think it's pretty clear who's winning here."
Nothing posted to
Order of blame;
1.) The error is in the hardware.
2.) The error is in the library routine.
3.) The error is in my code.
Order of probability;
1.) The error is in my code.
2.) The error is in the library routine.
3.) The error is in the hardware.
If the customer asked for it, that must be exactly what they want.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
DevOps will solve our problems.
It's just a quick fix - that'll only take 10 minutes.
Specialist Mac support for creative pros, Melbourne
My job can't be replaced by artificial intelligence.
I've discussed the Linux RAID code with Neil Brown, who wrote most of it. That conversation made me keenly aware that my grasp of Linux storage it is rather pitiful.
I've discussed proposals for new internet protocols with Vint Cerf, known as "the father of the internet". I was reminded I'm the big fish only in a very, very small pond.
A few weeks ago someone at work asked for "a Perl guru". Just that morning I had participated in the Slashdot discussion with Larry Wall - a fresh reminder of who is a Perl guru and who isn't.
My co-worker read something about Linux on Stackoverflow, and he knew as much as other people posting to that question knew - he felt like an expert.
A co-worker once used "telnet 25" to do smtp. Nobody else he knows does that, so he's an expert.
My own experience is that the more I learn, the more I am exposed to actual experts, the more I discover that there are many people much more knowledgeable than I. If I think I'm really good, that actually just means I *might* be better, in some ways, than the people I talk to - thinking I'm good just means I'm failing to learn from people who are better.
I strongly suspect those who are humble are the people who read the work of Knuth, T'so, Engelschall, etc - the really programmers know they aren't the best.
"I'll clean up this code later."
Sleep your way to a whiter smile...date a dentist!
Number one lie:
"Yes, this program/module/milestone will be completed on schedule. "
"Don't worry. This will be used only as a demo/proof of concept and never in production".
Actually that's a lie told to me by the management and I tend to believe it up to the date when the demo happens.
> I am the best developer for my domain.
For an sufficiently narrowly defined domain, so am I. Then again, so is Lennart Poettering.
Eric S. Raymond is a far more accomplished developer than I am. It is good for me to remember there are many, many far more accomplished, and many who are just plain more knowledgeable all around.
I happen to be, or once was, the best in the world at protecting paid web sites from unauthorized access. I was a longtime member of many cracker forums, and got a certain amount of respect because I had been around for many years and knew the ins and outs of the various security systems. Little did they know I was a spy, that the most senior member of their community was there to surveil them and feed them misinformation. So I was the best at my particular speciality, but plenty of people are better than me in much larger, more general domains. Being the best at one very specific thing doesn't make me good, it makes not versatile.
"I'll document this code later."
The main one: 'I'll fix that later'
This is what I was going to say. You see it ALL THE TIME.
Your boss is NOT going to let you go back and clean stuff up later unless there's an imminent business need to do so. Do it right the first time. Don't commit sloppy code.
The only time it's ever acceptable to tell yourself this is on a personal project, and only if you have the discipline to make it be true.
"Everyone uses the American Date format, that is MM/DD/YYYY", 'nuff said
Often found in close proximity: "Hmm, it's not *that* bad".
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Often found in close proximity: "Hmm, it's not *that* bad".
Or "This is how I/we have always done it".
Duplication of the same bad code over and over again is the sign of inept programmers. ... and hundreds of other examples of things programmers do over and over again. It compiles, it runs, so it must be okay? What's my next task?
Passing enormous structures as a stack arguments might work fine the first time or even the fifth. But sooner or later it will blow up.
Empty try/catch blocks might work well when there isn't anything that needs catching, but sooner or later, there will be.
Eschewing "this.", using generic names, and letting the compiler handle it might work well now, until someone else makes a change somewhere else.
Oversizing arrays and always having an off-by-one that ensures overrun if the array ever were to get full will work as long as the array never gets full. But one day it will.
Not providing a default case because you "know" a variable can only be one of N things create code that works. Now, that is.
Writing unittests that rubberstamps the exact code you wrote and not what it's meant to do will give you a pass for code coverage. But it is a waste of time.