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.

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.

C, on the other hand... if uncommented, is a nightmare.

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.

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.

Diogenes: Wow. Author didn't put alot of thought into that list. I wonder if he was playing Halo while writing.

Well, yeah, but he was totally thinking about the article while doing so.

"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 would
a) not change anything towards any future changes
b)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.

My favorite is

"Well it works on my machine"

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.

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.

Beta Tested: "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

Yes they do..

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. 

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.

When I'm playing Halo 4 reading Fark.com I'm thinking about coding, so it's like I'm coding.

/guilty

11. There is probably some interesting reading material on itworld.com

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.

12. I will comment-up the code after I finish the coding part.

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.

FTA: This is a [hardware | database | network] issue, not a code issue - Obviously, it's that recent database patch that's gumming things up, not my hand crafted SQL.

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.

I was a tester before I was a programmer, and one of the things you learn to do is figure out what changed to figure out what the source of a new problem is.

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.

Ok last two for me...

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.

"That chick in accounting totally wants me"

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?

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.

StopLurkListen: "That chick in accounting totally wants me"

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...

yves0010: StopLurkListen: "That chick in accounting totally wants me"

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...

damn it... typed to fast and was not thinking

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).