If you can read this, either the style sheet didn't load or you have an older browser that doesn't support style sheets. Try clearing your browser cache and refreshing the page.

(IT World)   Seven frustrating things about being a programmer; a few actually don't involve end users   (itworld.com) divider line 226
    More: Interesting, gray hair, software engineers, programming  
•       •       •

7576 clicks; posted to Geek » on 14 Feb 2013 at 12:21 PM (1 year ago)   |  Favorite    |   share:  Share on Twitter share via Email Share on Facebook   more»



226 Comments   (+0 »)
   
View Voting Results: Smartest and Funniest

Archived thread

First | « | 1 | 2 | 3 | 4 | 5 | » | Last | Show all
 
2013-02-15 05:09:46 AM  

lordargent: I have a SQL query which is going to join two tables together (Products and User Data).

A troglodyte programmer would alias those tables as A and B whereas I would alias them as P and U. A and B conveys no meaning, and in larger queries, people will tend to forget what the hell table B was referring to. Was B.UNIQUE_KEY from the user table? The products table? The sales table? The region table? whereas U.UNIQUE_KEY is much easier to grok.


And I'm going to go back and change the aliases to "Products" and "UserData", and curse you for using those stupid one-letter table aliases.  Why would you even do that?  Are you that about the tokenizer using an extra 14 bytes of precious RAM?
 
2013-02-15 06:16:50 AM  
"It wasn't in the requirements so I didn't include it in the code."
-Programmer's response of why site mobile apps land on the homepage rather then the linked article

/inspired by today's XKCD
 
2013-02-15 07:50:48 AM  
1.  developers that still write sql injection.
2.  consultants that get more done than employees
3.  people that still haven't figured out 'SET TAB to [x] spaces' when pressed in their GUI config.
4.  people that don't version control their code
5.  vendors that force you to have a contract before you can join their technical forums
6.  shiatty free coffee
 
2013-02-15 07:57:29 AM  

divx88: Scope creep & project managers that think hacking together something to make the shiny button appear NAOW!! is more important than doing it proper the first time.  Of course said project managers are usually answering to less knowledgeable/informed business pieces that just want a shiny button.

Bad user feedback a programmer issue.  Unless you have a professional QA staff to back you, need to build in mechanisms to catch data when things explode.  Even with a professional QA staff, if you have time to build said nifty tools, it's best you do.  Plus if you have time to do unit testing and other nifty testing related things, it helps even more.

/ fark your shiny button!


This!
 
2013-02-15 08:21:24 AM  

aneki: mccallcl: -dealing with re-invented wheels

1000x this.  I'm doing with with a client, Microsoft stack, that rolled their own identity, security, service client, rules engine, caching layer, etc etc etc.  I've never quit a contract early... but I am sorely sorely tempted.  Their software stack is pure pain to work in.


Worse: Being told to re-invent a wheel when you know the old wheel is going to replace it in 6 months.  Nothing is more demoralizing than realizing that a project of yours is already doomed for failure before it starts.
 
2013-02-15 09:16:05 AM  

Z-clipped: Yeah. Except the other end of that is,

"I need a cappuccino."
"Ok, what's in that?"
"Dude, what's wrong with you? It's espresso and steamed milk."
"Well, you need to tell me exactly how much milk."
"You're the barista. Just make me a goddamn cappuccino."
"Fine, here."
"Um, this is cold."
"You didn't say you wanted it hot."

Etc.

Some programmers really need to get over their butthurt that English isn't a formal language.


That's actually not really true.

Say you walked in and asked for a cappuccino, and I gave you a standard cappuccino, but what you really wanted was a latte or a caffe macchiato.  Those are very similar in ingredients, but distinct products.  Would you complain when you got what you asked for, but not what you wanted?

English can be a very precise tool for describing what you want.  It's intellectual laziness that people don't really think about what they want, even when things have been described to them over and over again.  Very basic logic is simple to grasp, to the point where I once taught my son how to manually implement a bubble sort when he was 4 years old, using LEGOs*.  Most people don't even want to try, however.

*Yes, I know it was child abuse.  I figured it was best he learn the wrong way from me first instead of learning it on the street.
 
2013-02-15 09:43:41 AM  

OgreMagi: As a system administrator, I should mention what annoys me the most about programmers.

Using obsolete packages that are no longer maintained, were last updated three years ago, have known security issues, and aren't supported by more recent versions of our Linux distro so we have to roll a custom version of it which is never easy because of dependency issues.  Let it go, biatches.  It's gone.  Find a new package and adapt your code.  And stop using obscure packages with no user base that is supported by some lone dude living in mom's basement.


As a programmer, I should mention what annoys me the most about system administrators.

They will request "small" changes to code when they have no farking clue what kind of a mess they are asking us to make. They also completely ignore the time and effort required for testing and validation of any changes in the code. And they are doing all of this because they are just too lazy to do their jobs.
 
2013-02-15 10:02:20 AM  

dittybopper: Z-clipped: Yeah. Except the other end of that is,

"I need a cappuccino."
"Ok, what's in that?"
"Dude, what's wrong with you? It's espresso and steamed milk."
"Well, you need to tell me exactly how much milk."
"You're the barista. Just make me a goddamn cappuccino."
"Fine, here."
"Um, this is cold."
"You didn't say you wanted it hot."

Etc.

Some programmers really need to get over their butthurt that English isn't a formal language.

That's actually not really true.

Say you walked in and asked for a cappuccino, and I gave you a standard cappuccino, but what you really wanted was a latte or a caffe macchiato.  Those are very similar in ingredients, but distinct products.  Would you complain when you got what you asked for, but not what you wanted?

English can be a very precise tool for describing what you want.  It's intellectual laziness that people don't really think about what they want, even when things have been described to them over and over again.  Very basic logic is simple to grasp, to the point where I once taught my son how to manually implement a bubble sort when he was 4 years old, using LEGOs*.  Most people don't even want to try, however.

*Yes, I know it was child abuse.  I figured it was best he learn the wrong way from me first instead of learning it on the street.


I was about to type out a reasoned and nuanced argument illustrating the intellectual divide between formal and non-formal language, and how expectations of the former are occasionally misapplied to human interactions with eye-stabbingly annoying results...

But then I started cracking up, because teaching sorting algorithms to my kid is exactly the kind of thing I would do. My first child isn't even born yet and I'm already devising similar forms of abuse. Having a physics teacher for a dad is going to make my kid wish she never asked questions like "why is the sky blue?"

In summation good sir, please accept this laurel, and hearty handshake.
 
2013-02-15 11:12:16 AM  

Z-clipped: But then I started cracking up, because teaching sorting algorithms to my kid is exactly the kind of thing I would do. My first child isn't even born yet and I'm already devising similar forms of abuse. Having a physics teacher for a dad is going to make my kid wish she never asked questions like "why is the sky blue?"


When he was a bit older, we built a basic Pascaline together, using LEGOs.

The littlebopper is actually an interesting datapoint in the Nature vs. Nurture argument:  He's adopted, but like me, he ended up in the "gifted" program at school.   We've had him since he was a few days old, and the distaffbopper and I always took great pains to make as many mundane moments teaching moments as possible.

/distaffbopper is "average" IQ wise.
//We complement each other.
///We also compliment each other.
 
2013-02-15 11:51:29 AM  

EngineerAU: 7. "We're now doing all low level programming in Javascript" (Seriously, this fad needs to die)


I know you're talking about Javascript and not Java, but this quote came to mind...

Saying that Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders
 
2013-02-15 11:56:44 AM  

umad: They will request "small" changes to code when they have no farking clue what kind of a mess they are asking us to make.


I'm not 100% sure, but I think that some requesters conflate "ease of expressing in words" and "ease of solution".  For example:

Statement:  "I just learned that I have pancreatic cancer and will die in 2 weeks."
Solution:  "Why don't you just cure cancer?"

Easy to say, yet tantalizingly difficult to complete...
 
2013-02-15 12:25:17 PM  

MrEricSir: amundb: Things that drive me nuts are crappy, wrong, or completely missing requirements. Or even requirements that are written so no one can understand them but the author.

Or requirements that change constantly. One recent project I worked on had requirements that changed every week. The people making them didn't seem to know what they were doing (we later found out they were actually graphic designers, surprise surprise.)

The project took about a year but if they'd waited to hire us until they'd finished the design, we could have done it in about three months. And frankly, it would have worked better.

The moral is this: If you're still deciding on features a week before the deadline, you're not qualified to be directing a project.


But But But.... Agile!

I know what your saying, changing requirements can be annoying. My favorite is when the customer wants to change requirements at the last possible, most in-opportune moment, screaming at the top of their lungs AGILE AGILE AGILE AGILE. Then we go back and tell them fine, we will have to push X amount of story points to the next sprint to handle this sudden change of requirements. Then they come back at us saying that is unacceptable, they need everything right now, and WATERFALL WATERFALL WATERFALL!
 
2013-02-15 12:29:14 PM  
Looks like I'll be spending the afternoon commiserating with the rest of you in this thread.

And categorizing it as "community outreach regarding best practices" on my timesheet.
 
2013-02-15 12:57:45 PM  

dittybopper: Z-clipped: But then I started cracking up, because teaching sorting algorithms to my kid is exactly the kind of thing I would do. My first child isn't even born yet and I'm already devising similar forms of abuse. Having a physics teacher for a dad is going to make my kid wish she never asked questions like "why is the sky blue?"

When he was a bit older, we built a basic Pascaline together, using LEGOs.

The littlebopper is actually an interesting datapoint in the Nature vs. Nurture argument:  He's adopted, but like me, he ended up in the "gifted" program at school.   We've had him since he was a few days old, and the distaffbopper and I always took great pains to make as many mundane moments teaching moments as possible.

/distaffbopper is "average" IQ wise.
//We complement each other.
///We also compliment each other.


Mine was the only kid in her first grade who would correct her peers, "1 plus 1 is not eleven.  That's concatenation."
 
2013-02-15 01:45:27 PM  
When end users don't provide enough information about bugs, it's because they don't want to do the work of documenting their process step-by-step any more than you as a programmer want to do it for them.  Sometimes this can be solved with technology: have the software provide a stack trace and an action history whenever it sends home a bug report, and then nobody has to work too hard.

Scrum came into existence as a backlash against the kind of inflexible, overly-rigid project methodologies that came before it.  A Scrum Master who insists that there's a process that must be followed to the letter doesn't understand the basic concept of agility, and doesn't deserve the title.  Every aspect of Scrum is negotiable based on the unique needs of the team at hand.

It's a fact that people ignore documentation.  Instead of wasting time writing it and complaining that no one looks at it, IT professionals should be applying human factors knowledge (usually called "UX" these days) to the design of their products, so that additional documentation isn't needed in the first place
 
2013-02-15 01:48:28 PM  

enigmaticsource: "s/[ ]{2}/\t//" for various values of two is about the first thing I run when I have to look at code.


Hey, what happened to all the carefully constructed string literals in the project?!?
 
2013-02-15 02:02:41 PM  

theresnothinglft: The head of the QA department assumes control of the software development department and has an ego so big that he can't realize this is a conflict of interest.


It's only a conflict if he constantly sides with one department over the other, which I'm guessing from your complaint that he does.

A smarter manager would let the Dev and QA teams do their respective things and butt their heads with each other when needed, and only step in to impartially adjudicate when they can't resolve an issue between themselves.
 
2013-02-15 02:05:30 PM  

umad: OgreMagi: As a system administrator, I should mention what annoys me the most about programmers.

Using obsolete packages that are no longer maintained, were last updated three years ago, have known security issues, and aren't supported by more recent versions of our Linux distro so we have to roll a custom version of it which is never easy because of dependency issues.  Let it go, biatches.  It's gone.  Find a new package and adapt your code.  And stop using obscure packages with no user base that is supported by some lone dude living in mom's basement.

As a programmer, I should mention what annoys me the most about system administrators.

They will request "small" changes to code when they have no farking clue what kind of a mess they are asking us to make. They also completely ignore the time and effort required for testing and validation of any changes in the code. And they are doing all of this because they are just too lazy to do their jobs.


Did I say anything about "small changes"?  No.  I realize that dropping an obsolete package can sometimes be a major coding change, but it still needs to be done.  Stop biatching and do your job.
 
2013-02-15 02:14:01 PM  

OgreMagi: Did I say anything about "small changes"?  No.  I realize that dropping an obsolete package can sometimes be a major coding change, but it still needs to be done.  Stop biatching and do your job.


Big changes like that are above my pay grade. I do what I'm told when my boss tells me to do something, not IT.
 
2013-02-15 02:15:41 PM  

Rent Party: I want more comment than code, because I don't want to read your crappy assed code.  I want to read about what it is supposed to be doing when it ceases to do what it is supposed to do.


Appropriate commenting practice really depends on the nature of the language.

Ruby, for example is so easy to read code intent from that _why had to write a deliberately unreadable book about it just to bring back balance.  Comments that reiterate the behavior of the code, rather than the rationale behind it, are superfluous.

C code, on the other hand, is hard to read.  Pointer indirection and abbreviated function and variable names are not only common but idiomatic.If you're writing code in C and you implement something like Duff's device, you need to:
a) include copious comments describing what the code is doing;
b) delete it and do something sensible instead.
 
2013-02-15 02:18:20 PM  

treesloth: EngineerAU: 7. "We're now doing all low level programming in Javascript" (Seriously, this fad needs to die)

I know you're talking about Javascript and not Java, but this quote came to mind...

Saying that Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders


I'm stealing that.
 
2013-02-15 03:50:23 PM  
dilbert.com
 
2013-02-15 04:07:50 PM  

meddleRPI: [dilbert.com image 640x199]


A pointy haired boss type would probably look at Agile and decide that removing the chairs is all that it takes, completely ignoring EVERYTHING about Agile and Scrum that actually matters.
 
2013-02-15 06:52:21 PM  

lordargent: WTF is the concatenation operator in this language?


I think there is a limit to the amount of almost-exactly-the-same shiat you can learn.

MrCrazyInsane: "Environment changes breaking working code" is the biggest pantload of horse shiat. Do you program around NT 4 over token ring?


No, but the thing I program on is controlled by a maniacal dictatorship that changes the aspect ratio or pixel density of the screen without notice. That thing connects to a series of web services running on computers that move physical location and subnets without notice (and are either accessed by IP, or the server naming convention uses the location in the host name). Sometimes a manager forgets to pay a bill for a web service or hosting provider. Sometimes a domain name expires and the expiry email went unnoticed or to an inactive email address. Sometimes Amazon Web Services goes down.

All of these things have happened to me in the last sixteen months. A list of environment changes that have broken my working code or degraded its performance to unacceptable would fill an entire thread.

/nice token ring reference
 
2013-02-15 07:53:30 PM  
1.  People that assume all programming jobs are the same.

Yes, I work with C# code every day.  I may write tests that deal with network functionality, but that doesn't mean I'm hooking up Channel Factories every day.

2.  Code that was committed without vetting for functionality or efficiency and left for months before being implemented by the rest of the project.

Hooray, that large chunk of framework was outsourced to India 6 months ago so we didn't have to do it.  Yesterday, we turned on the interface between the two and nothing's working.  In the meantime, ownership of that area changed hands twice and all Unit testing wasn't being monitored the whole time.  You're the new guy, fix it by Friday.

3.  Being handed higher position responsibilities in the long term without boosting the position.

If my contract says I'm an E1 and the workload I've been handed is E3, I have just as much right to complain about this breach as it does about any of the things in the useless Employee Handbook.

 4.  The Employee Handbook.

Signing a form that says I've read a document that can change any moment without notice won't make me concerned about the contents of it.

5.  A lack of standards within code (between project groups).

Nothing's more frustrating than having parts of a large project formatted differently so that there are line conflicts because someone from another group pushes a change.

Sometimes, I just hope all this is unique to my job.  I doubt it...
 
2013-02-17 04:32:04 PM  

Electromax: China White Tea: I'm not a professional codemonkey, but I do a little bit of programming and the most frustrating thing, for me, is that I pretty constantly get stuck in a perpetual cycle of, "This code is okay and it does what I need it to do, but there is probably a better, more "correct" way of doing this - to Stack Overflow!"  And then I read for a bit, rewrite the function in a better-er, correcter-er way, and then repeat the process until I finally decide that I'll never reach the "correct-est" way of doing it, scrub the project entirely, and go watch Netflix instead.

I do coding professional and as a hobby, and my general philosophy unless some client is going to be reading the code (ie never) or there's noticeable performance problems is that, if it is okay and it does what you need it to, that's the correct-est way.

The more anal programmers will always have "suggestions" for how THEY would do it to optimize this or that or use fewer lines of code, but in my experience this is often just them trying to flex in front of you or feel superior or it has no noticeable effect on the end user/output and thus is pointless. Like when someone at my old shop spent 2 days learning how to implement lambda functions and then broke the code trying to implement it because he wanted to impress people.

At some point you realize life is short and everything doesn't have to be optimal. Also programmers/nerds thrive on one-upsmanship and its better for your mental health to jump outside that rat race and work to improve your own happiness/enjoyment.

This is not to say advice is bad, but unless there's a known issue, why go looking for ways to refactor the code? It's just a pointless exercise. It's like the person who spends 2 hours perfecting the layout of a powerpoint slide then it's on the projector for 8 seconds in the meeting. Nice time investment.

/You should instead spend 2 minutes on the slide and 118 minutes reading news article comments
//Maybe they were already d ...


I agree with everything you just said unless you plan to sell, patent, or distribute your code, which I think applies to almost any professional situation...
 
Displayed 26 of 226 comments

First | « | 1 | 2 | 3 | 4 | 5 | » | Last | Show all

View Voting Results: Smartest and Funniest


This thread is archived, and closed to new comments.

Continue Farking
Submit a Link »






Report