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?
"The code is self-documenting!"
Anons need not reply. Questions end with a question mark.
All units pass. Who needs integration tests/functionality tests/load tests?
Are you fucking kidding me? I refactor just to break shit because my code works too well!! Tech debt my ass! If it's working right, it's got hidden bugs I just haven't fixed yet!!
Oh.
I get it.
That means I'm not a programmer.
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
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."