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."
"One more compile then I'm going to bed..."
Seven puppies were harmed during the making of this post.
It compiles, so it has to work. Right?
"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
"I am worth what they pay me."
"I am an engineer."
"Users wish they knew who created this wonderful software."
Prove anything by multiplying Huge Number times Tiny Number
"Java is fast"
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
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. "
> 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.
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.
Where do you draw the line on being an engineer? Seems like a good topic for a discussion.
I think of myself as an engineer, but then again I work at a pretty low level (C/assembler, no OS) and do hardware design too (design, schematic capture, PCB layout). I engineer whole systems, engineer firmware from the ground up.
The desktop guys... Well, some of the stuff they do is just plugging modules together. But they also build stuff, like web platforms, and have to know how to assemble the modules and write all the glue code. Maybe it's not so different from when I use chips made by other people, rather than building op-amps and microcontrollers out of transistors.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Often found in close proximity: "Hmm, it's not *that* bad".
Confucius say, "Find worm in apple - bad. Find half a worm - worse."