I had to deal with rewriting this awful unmaintainable program where "correct" behavior was defined as "whatever version XYZ of this program did on some large input." New version never did work "correctly." The closest thing to a spec was an attempt to define the grammar, but not the semantics, of the input language. Other than Halo I could point to most of the things in that article.

I don't know. I've mentally solved some crazy issues with an AI program I wrote in college while playing Tetris. Sometimes letting eyes focus one something other than a block of code helps your brain figure out problems.

minoridiot:I have heard at least 7 of those in various meetings/converstations over the years.

I hear this sh*t just about every time a new version of our software drops. "Oh it's fine, the customer doesn't want to pay for the sh*t they actually said they need, so make them work with this instead."

Um, okay, I guess I have to tell the client (again) that the feature you promised for 2 years, and is finally coming out, doesn't work as advertised.

/Office Space had it right. Engineers are terrible at dealing with people.

Umm...aren't all SQL statements hand crafted? I mean SQL stands for Structured Query Language, implying that somebody is going to write, by hand a statement that retrieves, updates, inserts or deletes data on the database.

I guess you could use an SQL code generator, but really aren't most apps using a persistence framework like Hibernate? Who writes SQL anymore?

The self-documenting one... eh, it's sort of true. More and more languages are being developed as to make them read more like English, and this makes it easier to understand sans-comments. C# is an example.

I think the points that he comes up with are silly and there was no effort to put in to it. However, his initial premise is spot on...programmers spend lots of time staring at code and they construct weird realities that make everyone look at them sideways.

Leeds:I take offense to this one: "I know what the client wants - I know what the client said, but that's not really what they want."

Because knowing how to tease out the real requirements is one of the main keys to success in this business.

My initial training was heavily focused on "Requirements Gathering." And yes, it is a technical skill. Filtering the nonsense out and preserving the required business logic to be implemented is a real skill. And sorely lacking in the industry.

CSB: I had to reengineer a tax compliance system for AT&T. So I interviewed the users. "How do you calculate this tax?" I asked.

"Well, we go into the legacy system, enter this number, and hit this button."

"No, I mean, what is the formula? What are the tax regs? If you had to calculate it with pencil and paper how would you do it?"

"I know what the client wants - I know what the client said, but that's not really what they want."

There is some, SOME, truth to this. Often the client doesn't know exactly what they want, but generally the coders aren't the ones to figure it out, which is why designers/HCI people exist. You conduct all sorts of interviews with people at all levels, you spend days and sometimes weeks watching people work, and you do ridiculous amounts of usability testing. It can be tedious but it pays off in the long run.

Slaves2Darkness:Umm...aren't all SQL statements hand crafted? I mean SQL stands for Structured Query Language, implying that somebody is going to write, by hand a statement that retrieves, updates, inserts or deletes data on the database.

I guess you could use an SQL code generator, but really aren't most apps using a persistence framework like Hibernate? Who writes SQL anymore?

I think it's meant to imply inline SQL. As in some dummy slapped some SQL right in the middle of the code instead of using a function or stored procedure.

But, then, as previously mentioned, lazy article author is lazy, so who knows what was really meant.

For me it's the frustration that comes with the fact that some things need to be done, and if done right, well...they'd be done right, saving a lot of time in the future and would not take much time to implement as there's updates to the files that are already needed.

The replies I always get:

"let's stick with how things are, because they MIGHT change later on", which the changes still woulda) not change anything towards any future changesb)if it would change something, it would be in the right direction.

"we don't have time now, maybe later", with the fact that the updates being done require accessing the same files, taking maybe an extra minute to setup, and would result in the new structure being done and making things easier, faster, better, but somehow, doing the work twice is the way they believe is better.

Then I get the "what can we do to save time and get more done?" question... at which point I repeat the same thing, get the same type of answer... and I simply give up and must stop myself from palming my forehead... I'm paid by the hour regardless.

Sure, the machine where you have all the SKDs installed, full local admin access and not controlled by any policies? You likely stopped the AV, firewall and all centralized management packages from running too. I bet your machine is not even on the domain...

So yeah, I don't give a fark that it works on yours, unless you are going to carry it and your ass up to accounting and do the receivables for the 10 people that now can't work.

Slaves2Darkness:Umm...aren't all SQL statements hand crafted? I mean SQL stands for Structured Query Language, implying that somebody is going to write, by hand a statement that retrieves, updates, inserts or deletes data on the database.

I guess you could use an SQL code generator, but really aren't most apps using a persistence framework like Hibernate? Who writes SQL anymore?

It depends on your product. If it is extremely data intensive, you can't just bind everything and have nice easy little updates. At best, you can create a data class and bind to that but what loads the class is good ol' SQL (be it ADO or whatever)...and even then, your updates are most likely coded down to the insert/update.

abhorrent1:It's not a bug; the user is doing something wrong - The code is doing what it's supposed to be doing; users are idiots.

This is probably true more often than not.

What is the purpose of the code if not to produce results in the real world? If the code fails due to user activity then it's not well suited to its primary function. The business world doesn't care that your code is 'better' only that it works. If it doesn't work then it's not good code. It really doesn't matter why it isn't working.

bulldg4life:I think the points that he comes up with are silly and there was no effort to put in to it. However, his initial premise is spot on...programmers spend lots of time staring at code and they construct weird realities that make everyone look at them sideways.

ManateeGag:I don't know. I've mentally solved some crazy issues with an AI program I wrote in college while playing Tetris. Sometimes letting eyes focus one something other than a block of code helps your brain figure out problems.

i've been out in the mountains hiking when the solution to a coding problem came to me. just because he (and some other programmers) don't have brains that can do "background thinking" doesn't mean none do.

minoridiot:I have heard at least 7 of those in various meetings/converstations over the years.

This is a [hardware | database | network] issue, not a code issue

This is the one I always hear.

ManateeGag:I don't know. I've mentally solved some crazy issues with an AI program I wrote in college while playing Tetris. Sometimes letting eyes focus one something other than a block of code helps your brain figure out problems.

Yes. This is often very true with any problem you are having trouble with solving.

Marine1:The self-documenting one... eh, it's sort of true. More and more languages are being developed as to make them read more like English, and this makes it easier to understand sans-comments. C# is an example.

He forgot, "The shiat I code is more cool/difficult/complex than 98% of everything out there!!".

I was disappointed to find the technique I was going to use in a 15 year old compiler textbook. I thought I was more clever than that. Then I thought, I don't need to be the first to invent it and it's great that it's so old the patents may have expired. Then I thought, just because it was known in the 1990s doesn't mean somebody won't patent it again today. Finally I decided, it's statistically certain that something we do infringes on a patent and it doesn't matter whether I add another to the pile by accident.

My take as a IT person going through school learning programming and having to write programs for many classes in many languages.

This code is self-documenting - I am guilty of this one. I have written many programs and rarely document them.

This is a [hardware | database | network] issue, not a code issue - I have always assumed it was a code issue first before anything else if I programmed it.

It's not a bug; the user is doing something wrong - This is a tricky one for me cause I have had bugs and I have had the user doing something wrong claiming it was a bug.

When I'm playing Halo 4 I'm thinking about coding, so it's like I'm coding - Not a Halo fan... sorry. But I do enjoy a good round of games as a break to allow myself to get refreshed when needing to write / debug codes.

I'm the only one who knows this code, so they can't lay me off - Never once have I thought that.

I know what the client wants - Once again, never thought that.

QA will find any bugs - Guilty of this one too when I am tired and angry

This fix is so simple that we can put it straight into production - Never encountered this because I only wrote programs for classes right now.

Of course this will scale - Same as above

I could rewrite this pile of spaghetti legacy code and save time in the long run - Same as above.

Vegan Meat Popsicle:I think it's meant to imply inline SQL. As in some dummy slapped some SQL right in the middle of the code instead of using a function or stored procedure.

It can be useful sometimes. SQR(eporting), for example, requires you to process your query results row by row. If there's a write involved, that also means writing row by row, incurring network overhead for each and every row. And that can get rather horrific if what you're doing is ugly enough to require subqueries. (Peoplesoft's all-in-one database, for example, forces you into this almost as a matter of routine.)

Submitting it as an inline query means the server can deal with it on its own without you being underfoot, turning a 5 hour ordeal into an operation lasting less than a second, including network. It can be very worthwhile to use temporary tables for the worst of it.

Beta Tested:There is some, SOME, truth to this. Often the client doesn't know exactly what they want, but generally the coders aren't the ones to figure it out, which is why designers/HCI people exist.

Unfortunately, when the 'client/boss' decides he/she can forgo progs in the design phase, then overthinks the requirements and decides something is too complicated (to describe) and so goes with something simpler (on paper), or worse, holds back information (a required feature they think is best to tackle later), it can totally fark things up.

Sure, the machine where you have all the SKDs installed, full local admin access and not controlled by any policies? You likely stopped the AV, firewall and all centralized management packages from running too. I bet your machine is not even on the domain...

So yeah, I don't give a fark that it works on yours, unless you are going to carry it and your ass up to accounting and do the receivables for the 10 people that now can't work.

The only time I ever say this to a client is when they do something like this:

Client: "I ran the program, and pulled up the personnel list. When I clicked on a person, I got errors. But the person seemed to load. I then tried to give the person a schedule record and got errors when I tried to save. Could you fix this?"

Me: "You need to send me a screen shot of your errors and/or the text of the errors. I cannot replicate this here at my office and my attempts to do what you are doing work perfectly. I will look at the code but it would be a huge help to have the actual errors descriptions."--------------------

Most programmers aren't that stupid. We know you are running in a different environment (sometimes radically). If you can't do something, you need to either provide the error you are getting or give the sequence that led to the error or both.

It's not a bug; the user is doing something wrong - The code is doing what it's supposed to be doing; users are idiots.

Usually this is just "It's working exactly like the spec you gave me dictated." A lot of times people get so bogged down trying to dictate how a program should function, when what they should be doing is figuring out (and clearly explaining) what the ultimate goal is. Leave the how to the person whose builds these things for a living. If they have any use-cases they need clarification on they'll ask you.

burndtdan:If you have code (any language) that has been working just fine for years then one morning, with no one making any changes to anything... yeah, it probably is a hardware or network issue.

My rule of thumb: if one person's reporting it, investigate pilot error first. If a few people are reporting the problem, investigate their procedure first. If several people are reporting it, it's the code.

/ The solution to all three may involve reinforcing the code, or fixing the code, but odds are, the rule of thumb leads to the greatest understanding of the problem.

MooseUpNorth:Beta Tested: There is some, SOME, truth to this. Often the client doesn't know exactly what they want, but generally the coders aren't the ones to figure it out, which is why designers/HCI people exist.

Unfortunately, when the 'client/boss' decides he/she can forgo progs in the design phase, then overthinks the requirements and decides something is too complicated (to describe) and so goes with something simpler (on paper), or worse, holds back information (a required feature they think is best to tackle later), it can totally fark things up.

Yeah, I have done that to myself when going projects for my classes. Forgot to take all aspects in or I was not team leader and our leader broke the project up and gave us assignments to write only part and hoped the parts worked together.

I could rewrite this pile of spaghetti legacy code and save time in the long run - If only I wasn't so busy right now playing Halo 4 - I mean thinking through complex programming problems.

I've done this a lot of times in my current job (we had some really shiatty programmers here before the current team), with programs that needed constant manual intervention, and now they have all been running for years with little to no problem. You can rewrite the pile of spaghetti legacy code and save time in the long run.

I'm the only one who knows this code, so they can't lay me off - They're lucky I don't demand a raise.

We had one guy that knew the legacy system for years. The guy fell asleep at his desk almost every day, the CIO hated him, and he had no other particularly useful skills except knowing the legacy system (he wasn't touching anything new). The same month we finally turned the legacy system off, he retired. This happens.

MooseUpNorth:burndtdan: If you have code (any language) that has been working just fine for years then one morning, with no one making any changes to anything... yeah, it probably is a hardware or network issue.

My rule of thumb: if one person's reporting it, investigate pilot error first. If a few people are reporting the problem, investigate their procedure first. If several people are reporting it, it's the code.

/ The solution to all three may involve reinforcing the code, or fixing the code, but odds are, the rule of thumb leads to the greatest understanding of the problem.

If no one reported it for years, then one morning the entire company reports it, it's the network (or a server).

burndtdan:I'm the only one who knows this code, so they can't lay me off - They're lucky I don't demand a raise.

We had one guy that knew the legacy system for years. The guy fell asleep at his desk almost every day, the CIO hated him, and he had no other particularly useful skills except knowing the legacy system (he wasn't touching anything new). The same month we finally turned the legacy system off, he retired. This happens.

For some reason, I am reminded of Wally from Dilbert. The only reason Wally is there is because he knows how to fix Big Bertha when Y2K was about to strike.

Diogenes:Leeds: I take offense to this one: "I know what the client wants - I know what the client said, but that's not really what they want."

Because knowing how to tease out the real requirements is one of the main keys to success in this business.

My initial training was heavily focused on "Requirements Gathering." And yes, it is a technical skill. Filtering the nonsense out and preserving the required business logic to be implemented is a real skill. And sorely lacking in the industry.

CSB: I had to reengineer a tax compliance system for AT&T. So I interviewed the users. "How do you calculate this tax?" I asked.

"Well, we go into the legacy system, enter this number, and hit this button."

"No, I mean, what is the formula? What are the tax regs? If you had to calculate it with pencil and paper how would you do it?"

"Can you make the new screen light blue?"

[head banging on desk]

What a bunch of idiots, am I right? They should have totally asked for a mauve or chartreuse screen. Dumbasses.

Welcome to the modern world of 1950's. The assumption: the programmer is a male; there are no women programmers; and if there are women in the company, they're in some non-technical field like accounting.

UberDave:Most programmers aren't that stupid. We know you are running in a different environment (sometimes radically). If you can't do something, you need to either provide the error you are getting or give the sequence that led to the error or both.

I agree, most are not this bad. I just happen to work with a few that are and it is frustrating to no end to troubleshoot something for a few hours that they won't admit to farking up. Thankfully I personally am not in desktop support anymore, but I still deal with those yahoos from time to time. Usually goes like this:

Programmers: OMG. Critical, urgent, right now, mail is not going out of Oracle. Your Exchange servers MUST BE DOWN!@!@

Me: Well, seeing as you just emailed me this, and I'm responding to email, and your service account is on the same server, no Exchange is likely fine. For fun, I just dropped whatever I was doing and looked at the queues, logs and services and everything looks fine.

Programmers: OMG, you need to fix Exchange now.

Me: I see nothing wrong, and the 8,000 other users on that server are not complaining. What *exact* error are you seeing. What do your logs say?

Programmers: OMG, we need a conference call to discuss what is wrong with Exchange.

Me: Gah, just send your flipping errors and let me know what servers you are trying to connect to.

..... 2 hours of silence go by....

Me: Guys, are you still having issues? I looked and see mail being processed for your Oracle accounts.

.... 4 hours later

Programmers; Oh yeah, we found it. We changed a module last night and fixed it.

Me: Fuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu

So right, not all are that stupid. Even not all the ones in my company are. But it only takes a small sample to ruin your day.

Welcome to the modern world of 1950's. The assumption: the programmer is a male; there are no women programmers; and if there are women in the company, they're in some non-technical field like accounting.

"#1reasonWhy" was just yesterday, wasn't it?

Or maybe subby is a guy who is a programmer who has a think for this chick in accounting...

Welcome to the modern world of 1950's. The assumption: the programmer is a male; there are no women programmers; and if there are women in the company, they're in some non-technical field like accounting.

"#1reasonWhy" was just yesterday, wasn't it?

Or maybe subby is a guy who is a programmer who has a think thing for this chick in accounting...

UberDave:Most programmers aren't that stupid. We know you are running in a different environment (sometimes radically). If you can't do something, you need to either provide the error you are getting or give the sequence that led to the error or both.

That's better than what I get most of the time. Usually I have to troubleshoot "This no workey!" "Well, what's not working?" "it doesn't work!" "Ok, but what about it doesn't work?" "Everything. It's just all not working!"

So I go out to the floor and cannot identify any problems. I go back to my office and I never hear another peep.

FuryOfFirestorm:What a bunch of idiots, am I right? They should have totally asked for a mauve or chartreuse screen. Dumbasses.

burndtdan:If no one reported it for years, then one morning the entire company reports it, it's the network (or a server).

Often, but now always. We've had cases of poorly written applications (both internal and OTS) that broke when a new desktop update was applied. Granted that is not usually the case and if you have decent software developers and vendors, it should not be. But sometimes you have deploy some shiatty software against your all your caution.

Celerian:UberDave: Most programmers aren't that stupid. We know you are running in a different environment (sometimes radically). If you can't do something, you need to either provide the error you are getting or give the sequence that led to the error or both.

That's better than what I get most of the time. Usually I have to troubleshoot "This no workey!" "Well, what's not working?" "it doesn't work!" "Ok, but what about it doesn't work?" "Everything. It's just all not working!"

I got that from my Girlfriend's mother when I was over visiting her. And it pissed me off cause I was fixing her computer, turns out if was just a driver issue, and the next day when I asked her about it. She told me she just reset her computer to factory settings and it solved the problem. I usually get very pissed off at that point.

Celerian:UberDave: Most programmers aren't that stupid. We know you are running in a different environment (sometimes radically). If you can't do something, you need to either provide the error you are getting or give the sequence that led to the error or both.

That's better than what I get most of the time. Usually I have to troubleshoot "This no workey!" "Well, what's not working?" "it doesn't work!" "Ok, but what about it doesn't work?" "Everything. It's just all not working!"

My favorite is, "I tried to do X and I got an error."

"What did the error say?"

"I don't know, I just closed it."

A significant percentage of the time, it's not actually an error (all dialog boxes = errors, apparently).