Things That Scare the Bejeezus Out of Programmers 641
itwbennett writes "Software developers are, by and large, a cool and analytical bunch, but there are a handful of things that strike terror in their hearts. Phil Johnson scoured developer forums looking for an answer to the question: What's your biggest fear as a programmer? The answers clustered into 5 broad groups ranging from being forced to learn or use a specific technology to working for and with incompetents. What's your biggest fear?"
Comment removed (Score:5, Interesting)
My Biggest Fear (Score:5, Interesting)
Inheriting another project written by an idiot... (Score:5, Interesting)
Being stuck (Score:5, Interesting)
Being stuck at a job, because you drifted away from your main skills, and now have difficulty to catch up. Or more specific: being stuck at a job where you don't want to spend another year or even longer. In the company I'm working I stand alone, being the only programmer, so no support from other programmers. I find it hell to get my skills up to date while doing my job properly.
Bureaucracy + Stupidity (Score:5, Interesting)
Whenever I hear a congresscritter make noise about restricting research, or instituting programming certifications to get a job, or my (now ex-)company requiring a training session on how to walk because someone tripped in the hall, I get scared for the country as a whole because we've cultivated this environment.
That, and the aformentioned velociraptors.
Pilots and Astronauts have the same fear (Score:5, Interesting)
their #1 fear isn't the rocket blowing up and getting killed, it's not fear of blacking out from G-forces, it's not fear of getting shot down, it's the fear of screwing up.
Same as the #1 fear from TFA. (fear of writing buggy code / messing up)
The official Pilot's Prayer (as handed to us by Alan Shepard) is "Lord, please don't let me fuck up".
Not "Lord, please don't let me blow up" or "Please keep me safe"
One class, 16000 lines, (Score:2, Interesting)
450 variables. And I've got to fly halfway around the world to fix it (among other things) in 5 days.
Re:Average programmers writing parallel code (Score:5, Interesting)
Average programmers being forced to write parallel code scares me more than anything else. "The multicore dilemma is actually a substantially worse problem than generally understood: we are headed not just for an era of proportionately slower software, but significantly buggier software, as the human inability to write good parallel code is combined with the widespread need to use available CPU resources and the substantial increase in the number of scientists with no CS background having to write code to get their job done." --The multicore dilemma (in the big data era) is worse than you think [flowlang.net]
This is probably the most true thing I've seen in this list, and the fact that you're the only person who posted it is a sign of just how bad of a problem it is.
Rounded to the nearest whole number, I think its absolutely safe to say 0% of programmers understand how to write multithreaded code properly.
A faulty test suite (Score:5, Interesting)
Remember when the Hubble telescope first went up, and could not focus? It had all been tested on the ground on an artificial star target. Unfortunately, the test rig had a plate that was about half-an-inch thick that should have been subtracted from the optical path. So they had a mirror that was accurate to about 1/100th of a wave but half an inch in the wrong place.
There was a rocket where the guidance for the two stages had been coded separately. One stage used a value of -9.8 m/s2 for 'g' because it measured heights upwards and the acceleration was downwards, while the other used a value of +9.8 m/s2 and flipped the sign in the equations. When the rocket took off, the first stage was fine but the second stage suddenly flipped over.
That's what I dread: thinking I have checked everything, and thought of everything, and then finding out publicly and expensively that my regression tests were worthless all along.
Re:True story (Score:3, Interesting)
Mandatory fields in addresses are a truly insidious form of evil. They screw everything up, because not all addresses have the same structure. I've seen address forms that have mandatory house number/name and street name fields (sure, I can fill those in for my parents' address, but you'll get them the wrong way round when you print them out and the delivery might never arrive). Here in the UK, one thing that really annoys me is mandatory county fields, which you see sometimes. Yes, we have counties, but they have officially not been part of our addresses for 15 years [wikipedia.org] now. So why are you insisting I make my address incorrect so I can fill in your form? (For reference, I've lived in one of those locations where my actual county is different to the county my post town's delivery office is in, so putting the county I actually live in in my address was even more incorrect than not including a county at all. I don't think this situation is at all uncommon.)
Re:Doesn't anyone remember FDR? (Score:4, Interesting)
Economy: We need small businesses who can innovate (and much more than silly mobile apps). [...] Or get some lawsuit for stepping on some bogus patent or make a product that someone misused and hurt themselves.
And this is, I'm afraid, a pretty valid reason not to bother starting up a technologically innovative business in the US. As soon as you gain any traction you will be swamped with patent claims from many different patent trolls.
Re:A faulty test suite (Score:4, Interesting)
That's what I dread: thinking I have checked everything, and thought of everything, and then finding out publicly and expensively that my regression tests were worthless all along.
I believe that an analysis of the Apollo Project and other similar engineering projects has shown that integration malfunctions are the most egregious kind of errors, both in terms of their proportional presence among all failures and in terms of their eventual costs. For example, the infamous "1201 alarm" (that fortunately didn't cause a loss of the vehicle and the crew) in the final phase of Apollo 11's landing was found to be caused by insufficient integration testing (and I also believe that there was a tiny discrepancy in the testing environment that prevented the engineers from finding out about the problem in advance).
Re: No backups (Score:5, Interesting)
Been there, done that.
The programmers insisted that the production database not have any passwords, for their convenience. The DBA protested mightily, but was overruled. Then it happened. We were in the middle of something else when the company's website stopped responding. It was a mad scramble to find out what the hell had happened. I remember very well the sick look on the DBA's face when he went to check the database and announced in shock and dismayed surprise "it's gone!" First thought was that somehow we had been hacked. The DBA quickly found what was responsible: SQL commands to drop all the tables. The network admin went hopping about like a rabid frog making sure he could still log in everywhere and trying to run down the IP address that had originated that command. A few minutes investigation didn't turn up any supporting evidence for the hacked hypothesis. Had to be an inside job. We had just reached this conclusion when a programmer fessed up. He meant to wipe out and reload a demonstration database, but accidentally targeted the wrong machines and destroyed production. The idea of setting up a slave database didn't protect from this. Then it was discovered another programmer had turned off the daily backup a week before, to free up some CPU cycles. The DBA managed to recover, because he had also had all the transactions logged, but it took a full day to restore the database to a usable point, and then a further 3 weeks to clean up.
Re:My Biggest Fear (Score:3, Interesting)
I wish I could find that comic. Something like:
Just out of university: "I'm going to change the world!"
After one year at first job in your field: "I'm going to change this company!"
After ten years: "I'm going to change the coffee!"
Stupid bosses, office politics (Score:5, Interesting)
Office politics. Just lovely when the management fucks up through sheer stupidity, but still has the cunning to find some way to blame you for it and make it stick.
I'll whip out a car analogy. The bosses direct the driver down the wrong road. The driver questions this, but is told to shut up and drive, he doesn't know what he's talking about. 100 miles later, they realize they're not on the right road, and the screaming starts. They blame the driver for taking the wrong road, and fire him. They hire a map reader. They turn to the mechanic and demand he get 200 mph out of the engine, no excuses will be accepted and if he can't do it, he will be fired and they'll get someone who can. Never mind that the car is a cheap econobox that can't even do 100 mph. The mechanic manages a miracle and coaxes 120 mph out of the engine, and is promptly fired because that's not good enough. Over the protests of the map reader, they elect to take a desperate shortcut on a dirt road, to try to get back on track, and end up stuck in the mud. They fire the map reader, but are still stuck in the mud. With no one left to get them out, and no one left to blame, they finally lose their grip. Customers and supporters abandon them.
Re:Biggest Fear? (Score:5, Interesting)
The stablest C code I've ever worked on used GOTO for error correction. It was WAY stabler than the C++ code that replaced it using try-catch blocks.
My biggest fear for a long time was templates. The reason I feared them is because I used them to re-write a C graphics engine I got a source copy of into C++. I used a lot of novel approaches that should have sped up the whole thing, including a blitter (that should date me...) that was 4x faster because I used the floating point unit's much wider data path for block memory moves than the C code did, and wrote it in assembly (in fact, that exact same technique was published in a book called The Black Art of Game Design, albeit with slower code than mine, partially because it was not in assembly). When I got it done and compiled it, I was dismayed because my code was slightly slower, and after a few more optimizations, about the same speed. Baffled by this, I profiled the code, and the entire slowdown was template calls at the lowest level that triggered a lookup table that was abysmally slow (templates were REALLY bad in the compiler I was using, which I think was Borland). Unfortunately, it broke the entire codebase and I essentially had to throw away the entire engine and redo it from scratch. On the plus side, the rewritten engine was not based on the existing one and landed me a job writing games, albeit briefly (working 16-18/7 for months during crunch, sleeping at work, etc - very rapid burnout).