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.
I'm a better than average programmer.
Who ordered that?
It compiles, so it has to work. Right?
"The code is self-documenting!"
Anons need not reply. Questions end with a question mark.
You meant, of course, discrimination FOR women:
http://www.news.cornell.edu/stories/2015/04/women-preferred-21-over-men-stem-faculty-positions
All units pass. Who needs integration tests/functionality tests/load tests?
"That error condition will never happen because I trap for it."
"No one will ever put that kind of stuff into this form field."
"No customer will ever need more than X number of records for $DATA_ITEM." (kids names, addresses, cars, phone numbers, etc etc etc)"
"TLD extensions will never be longer than X number of characters."
"I can positively validate an email address with my home-grown code."
"No one has a one-letter name." ...and on and on and on....
Just cruising through this digital world at 33 1/3 rpm...
"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"
I understand the task
I have thought of all the possible test scenarios
I have coded for all possible test scenarios
The scope will not change
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
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.
These should be required reading for programmers AND designers. I'm looking at you Mr. shitty designer/programmer that only lets me put 13 characters in for my (first) name.
* Falsehoods about Names
* Falsehoods about Time
* Falsehoods about Computers, aka, Murphy's Computers Laws
* 97 Things Every Programmer should know
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
All throughout school, everyone told me there are jobs for programmers. Everyone lied. I have multiple advanced degrees in computer science. I have started open source projects. I have contributed to open source projects. I debug software for fun. I live and breathe code. And yet, I have no job, and I have no prospects. I apply for jobs, and nothing happens. In my experience, all job listings are lies, and there aren't any jobs out there. There's absolutely nothing at all.
DevOps will solve our problems.
It's just a quick fix - that'll only take 10 minutes.
Specialist Mac support for creative pros, Melbourne
"If something seems stupid to me, it is, because I am definitely smart."
Example:
"Smart pointers are stupid. I know how to manage memory, and anyone who can't have zero memory leaks directly using malloc and free shouldn't be coding anyway."
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'
"I'll have sex later."
CLI paste? paste.pr0.tips!
Oh.
I get it.
That means I'm not a programmer.
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
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."
In the US, if you want to be a mechanical, or civil, or electrical, or plumbing engineer, these are the rules you generally have to follow.
- you go to school and eventually graduate
- you may have to serve as an apprentice (in my state, electricians serve a 5 year apprenticeship)
- you take an exam that's created and run by the state government in which you want to practice (not by a vendor)
- if you pass the exam, then you ask the state, not the vendor, for a license (probably some money involved here too)
- once you're licensed, then you're an engineer, unless
- the state finds out that you aren't following the state's (electrical / civil etc.) code regulations and pulls your license. Then you're no longer an engineer. And by the way, good luck finding your next job.
So whether you're an engineer or not depends on the state government, not a vendor or a school. This also provides more global skills. For example, a plumbing engineer can spec out either a Moen or a Delta faucet for a design. Could a Cisco engineer spec out a Juniper switch? Maybe...or maybe not.
When I was getting my degree (90's) the ACM wrote about the issue of whether software could truly be called "engineering" or not. Two things that they pointed out were that (1) in a couple of US states, it was illegal to call yourself a software engineer because you weren't licensed by the state, and (2) a lot of mechanical etc. engineers are pretty PO'd at the software industry because any fool can call himself / herself a software engineer without having skills, practices or state certs to back it up. Both point to a level of respect and trust in the skills of the person who puts "engineer" in their title. Would you go to a doctor who didn't have a state license? Or use a lawyer who wasn't a member of the state's bar? Probably not, because you don't know if you can trust their skills. A state's "engineer" stamp is a similar scenario: "this person is trustworthy in their trade and their opinions deserve respect."
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.