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)   9 reasons why programmers' pants are often on fire   (itworld.com) divider line 52
    More: Interesting, Pants On Fire, software engineers  
•       •       •

4706 clicks; posted to Geek » on 13 Mar 2014 at 11:38 AM (24 weeks ago)   |  Favorite    |   share:  Share on Twitter share via Email Share on Facebook   more»



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

First | « | 1 | 2 | » | Last | Show all
 
2014-03-13 10:30:47 AM
#1 Slideshows are cool
 
2014-03-13 10:32:01 AM
Furious masturbation.

You gotta use lube, people!

Once you're done, clean up and GBTW.
 
2014-03-13 10:47:11 AM
My code is compling
 
2014-03-13 11:32:24 AM
That fire is the hottest it ever gets in most programers' pants...

/AMIRITE?
 
2014-03-13 11:40:45 AM
They wear pants?
 
2014-03-13 11:42:20 AM

Devo: They wear pants?


I have to

/Court order
 
2014-03-13 11:43:20 AM
This job fulfilling in creative way.
 
2014-03-13 11:45:00 AM
Programmers do better work when they program naked.
 
2014-03-13 11:46:00 AM

urger: My code is compling


imgs.xkcd.com


Disagree with the "its not a bug" one. In some instances, its an unintended feature. Now, ignoring bugs you can't reproduce but have a clear case of existing is idiotic, but they were a bit vague in my opinion.
 
2014-03-13 11:47:06 AM
I'll fix this later

Programmers are often faced with the tradeoff of doing something fast or doing it "right," whether it's to fix a critical bug or meet a deadline. Coding compromises are often made in the name of saving time with the intention to fix or clean up the not-quite-perfect code later - often with the knowledge that later will never come.


When I used to teach programming classes, I always gave my students my "First Law of Programming":

Bad software lives forever.

There is never (I repeat, never) enough time to go back and do it over to make it "right". Unless it bursts into flame, it's going to stay exactly the way it is. So, do it right the first time, because that's the only chance you're going to get.
 
2014-03-13 11:50:30 AM
Deslided.  At least if I copied and pasted the correct link this time.
 
2014-03-13 11:53:58 AM
Code doesn't need commenting. Any programmer who has more than a year or 2 working on the same code knows this is not true.  You might have thought that at the time, but if you're staring at it 12 months later, you might find yourself asking WTF you were trying to do (especially if there's a bug).

This shouldn't take long.  Take your estimate, double it, then increase to the next highest unit of time.  If you think it will take 2 weeks, allow 4 months.

That's not a bug. No, that's what managers sometimes tell customers.  I got into an argument once.  The manager wanted to tell the customer "it's working as designed." when he and I both knew that was bullshiat.  Oh well, I think the customer paid for a customization to our code.  Cha-ching.
 
2014-03-13 12:02:25 PM
"9 things younger coders will eventually learn The Hard Way"
 
2014-03-13 12:03:41 PM
Oh, and #10: NEVER schedule a release for a Friday or the day before vacation.
 
2014-03-13 12:03:55 PM
This code doesn't need commenting

Well duh.  If you needed comments, you're clearly unworthy of editing my code.
 
2014-03-13 12:04:26 PM
#6 No such thing as a small change.

I was in a review meeting and the lawyers wanted to change the wording to the disclaimer on the splash screen.  The disclaimer was read from a text file and displayed it with an 'OK' button for the user to click after he ignored the disclaimer.  The programmers treated is as a major change.  "You don't know how it will effect the rest of the program"  blah.. blah... blah...   The text change was forced through the same revision control process as it were feature change with regression testing and all.  IT WAS A SMALL CHANGE!!  It was a text change!
 
2014-03-13 12:04:30 PM

gfid: Code doesn't need commenting. Any programmer who has more than a year or 2 working on the same code knows this is not true. You might have thought that at the time, but if you're staring at it 12 months later, you might find yourself asking WTF you were trying to do (especially if there's a bug).


There's a spreadsheet I input data into.  It contains some macros to speed up some tasks that the user might have to do.  I didn't set up the macros, but on the few times I have time, I try to look at the code, and the guy who wrote them neglected to comment anything, and it drives me crazy and he no longer works for the company.  I'm actually taking a programming class, and try to make sure I make plenty of comments.


gfid: This shouldn't take long. Take your estimate, double it, then increase to the next highest unit of time. If you think it will take 2 weeks, allow 4 months.


Ah a modified Scotty method.
 
2014-03-13 12:18:37 PM

Dr Dreidel: Oh, and #10: NEVER schedule a release for a Friday or the day before vacation.


Actually did that a couple years ago, before going on a cruise no less. That is to say no phone or internet access for 10 days.

Technically though, all my stuff worked fine. My division had been purchased, so some customers were supposed to move into our former company's system but they couldn't get it working and no one but me knew how to reactivate those parts of our system. So the real lesson there is: Don't let only one programmer know how to manage the system!
 
2014-03-13 12:20:11 PM

Dr Dreidel: Oh, and #10: NEVER schedule a release for a Friday or the day before vacation.


You get to schedule your releases? That must be nice.
 
2014-03-13 12:22:55 PM

Dr Dreidel: Oh, and #10: NEVER schedule a release for a Friday or the day before vacation.


This.  If it has to go on Friday, then take Wednesday and Thursday off because you're definitely going to be working on Saturday and Sunday.

Tuesdays are a good release day.  You have the entire weekend to obsess over details and one more GO/NO-GO meeting if needed..
 
2014-03-13 12:31:26 PM

Telos: Dr Dreidel: Oh, and #10: NEVER schedule a release for a Friday or the day before vacation.

Actually did that a couple years ago, before going on a cruise no less. That is to say no phone or internet access for 10 days.

Technically though, all my stuff worked fine. My division had been purchased, so some customers were supposed to move into our former company's system but they couldn't get it working and no one but me knew how to reactivate those parts of our system. So the real lesson there is: Don't let only one programmer know how to manage the system!


Ah, the "hit-by-a-bus" problem. If we were staring a list of things IT managers should avoid, that'd be #1.

SeaMan Stainz: You get to schedule your releases? That must be nice.


As opposed to...deploying the code package(s) at random times? Or is the problem that someone else schedules them for you? If that's the case, I'd fight to have someone from your team in those meetings (someone who is actually going to lose a weekend when the initial 16 deployments fail).
 
2014-03-13 12:33:42 PM

Dr Dreidel: Oh, and #10: NEVER schedule a release for a Friday or the day before vacation.


Actually, I usually schedule releases for Friday night so I have all weekend to fix it if something goes wrong. Nothing gets published within 3 weeks of a vacation. That's just idiotic.

Also, I can not think of any instance where comments in code have substantially helped me work on old code. Good code is self documenting and there is no help for bad code. The only use I've ever got from comments is knowing who to blame for a piece of bad code.
 
2014-03-13 12:34:06 PM

Mentat: #1 Slideshows are cool


GET OUT OF MY HEAD!!!!   :-)
 
2014-03-13 12:40:00 PM
As the author of TFA pointed out, programmers mostly work alone.
They have to lie to themselves - they have no one else to lie to, and the innate human compulsion to lie has to find some outlet.
 
2014-03-13 12:53:21 PM

NewWorldDan: Also, I can not think of any instance where comments in code have substantially helped me work on old code. Good code is self documenting and there is no help for bad code. The only use I've ever got from comments is knowing who to blame for a piece of bad code.


Where I work, code gets re-used; often for not quite the same purpose as the original. Comments are essential.

Paraphrasing examples of comments that have helped me:

"Per Dr. W, values of serum X higher than Y.Z are incompatible with human life, and so have been recoded as missing." = I could figure out why there was a number "Y.Z" written into the code, and who to ask about whether it should be changed when I applied that code to a slightly different patient population.

"Using the formula from ZZ et al. 1996 p. X" = I can verify that the statistical formula was written and used correctly.

"The following chunk of code is to test for error X . . ." = I could stop worrying about the fact that the variable created wasn't used anywhere else in the program. I was thinking at first that the code had been brought into a larger program incorrectly.

"The question on which this variable is based was changed on the input form in 2003, but the {outside} group maintaining the data put the new value into the same field." = Letting me know why the hell a variable was treated differently depending on what year it was created.
 
2014-03-13 12:56:51 PM
And it's stuff like this that makes you regret Tim Berners-Lee wasn't busier 25 years ago.
 
2014-03-13 01:11:05 PM
I once had a job working with about 50,000 lines of C code that had almost NO comments. Seriously, it was like they had threatened to dock his paycheck for every comment he added to the source code.

Plus, the code was written by a guy who was long gone, and whose thinking and approach to solving the problem at hand was utterly different than anything that I would have come up with.

That was not fun.
 
2014-03-13 01:23:53 PM

Cybernetic: I once had a job working with about 50,000 lines of C code that had almost NO comments. Seriously, it was like they had threatened to dock his paycheck for every comment he added to the source code.

Plus, the code was written by a guy who was long gone, and whose thinking and approach to solving the problem at hand was utterly different than anything that I would have come up with.

That was not fun.


Ahh yes. He built a mountain so they wouldn't fire him and he still left. Those people piss me off to no end. Share knowledge and become Yoda don't squirrel it all away you Hutt.
 
2014-03-13 01:25:34 PM
Dr Dreidel:

SeaMan Stainz: You get to schedule your releases? That must be nice.

As opposed to...deploying the code package(s) at random times? Or is the problem that someone else schedules them for you? If that's the case, I'd fight to have someone from your team in those meetings (someone who is actually going to lose a weekend when the initial 16 deployments fail).


Trust me, we've tried. When the people writing 10 figure checks want Friday deployments, they get Friday deployments. And yes, we get to spend all weekend fixing the farkups too.
 
2014-03-13 01:27:13 PM

NewWorldDan: The only use I've ever got from comments is knowing who to blame for a piece of bad code.


No such thing as bad code. (Just the occasional sloppy coder.
 
2014-03-13 01:31:28 PM
 
2014-03-13 01:56:12 PM

SeaMan Stainz: Dr Dreidel:

SeaMan Stainz: You get to schedule your releases? That must be nice.

As opposed to...deploying the code package(s) at random times? Or is the problem that someone else schedules them for you? If that's the case, I'd fight to have someone from your team in those meetings (someone who is actually going to lose a weekend when the initial 16 deployments fail).

Trust me, we've tried. When the people writing 10 figure checks want Friday deployments, they get Friday deployments. And yes, we get to spend all weekend fixing the farkups too.


That sucks. Have you tried making them pay you for time spent over the weekend (assuming you're salary) or getting flex time in exchange? Have you tried turning it off and on again?

Lawyers - would there be a legit labor complaint there? If the company, knowing Friday deployments often (if not always) led to weekend work that didn't pay overtime, could someone file to have (some of) that time paid or flexed? (Clearly, no court would tell them to release on Thursday instead.)

This is why I like small companies - IT at that point is usually able to cajole what they need from management (who more often that not says "IT? ...Uh, sure. Whatever you need. 'Reframbulate the scranary flange'? How does $10k sound?).

// right up until they become Big Companies that suck the life out of everything
 
2014-03-13 02:11:18 PM

47 is the new 42: Deslided. At least if I copied and pasted the correct link this time.


i.imgur.com

#0: Slideshows and forced pagination in order to maximize banner ad impressions and reader engagement are the hallmarks of good (... on to page 2 ...)

(... after the jump ...)

(... back to page 1...) web design.
 
2014-03-13 02:29:49 PM

Cybernetic: I'll fix this later

Programmers are often faced with the tradeoff of doing something fast or doing it "right," whether it's to fix a critical bug or meet a deadline. Coding compromises are often made in the name of saving time with the intention to fix or clean up the not-quite-perfect code later - often with the knowledge that later will never come.

When I used to teach programming classes, I always gave my students my "First Law of Programming":

Bad software lives forever.

There is never (I repeat, never) enough time to go back and do it over to make it "right". Unless it bursts into flame, it's going to stay exactly the way it is. So, do it right the first time, because that's the only chance you're going to get.


I worked at a company where a senior programmer we hired (when I was a junior programmer) argued with me to just slap something in production and we would "fix it later".  He brushed me off when I complained that later never comes and we're always dealing with other priorities.

He shot down a proposal I had to restructure the nightly batch stream so that in the event the system had shutdown errors, all of the users reports could be generated from the day's files, rather than the entire process being held up.  He was quite miffed when I made the request to our supervisor.  She told me I could proceed so long as my efforts did not interfere with my daily tasks.  After two weeks of testing, I implemented the changes to the production jobstream.  That was about four months before I left the company, and after I did, one of the other programmers met up with me later to say that my idea saved them a lot of headaches.
 
2014-03-13 02:43:36 PM

Dr Dreidel: Telos: Dr Dreidel: Oh, and #10: NEVER schedule a release for a Friday or the day before vacation.

Actually did that a couple years ago, before going on a cruise no less. That is to say no phone or internet access for 10 days.

Technically though, all my stuff worked fine. My division had been purchased, so some customers were supposed to move into our former company's system but they couldn't get it working and no one but me knew how to reactivate those parts of our system. So the real lesson there is: Don't let only one programmer know how to manage the system!

Ah, the "hit-by-a-bus" problem. If we were staring a list of things IT managers should avoid, that'd be #1.



Our plan is actually called "ampoliros gets hit-by-a-bus". There's a magic folder with descriptions, layouts, passwords, theory of operation (because we're not totally sure how it works), etc. It's kept in a lockbox a few minutes from the office. There's also a number to call of a third party who has been briefed and trained on operation (but not given access).

/can't believe they let me name it that
 
2014-03-13 03:39:53 PM
It's not my fault I'm a liar. My clients and coworkers keep asking me how long things will take to do before I do them. What am I, a farking psychic? And of course whatever number I pull out of my ass, it actually takes twice as long. So just double my estimates, right? Hahahaha. Then it takes twice as long as THAT.
 
2014-03-13 04:22:26 PM
I started root causing in QA just to shut the developers up because every bug I found was, "Not a bug, can't reproduce!"  Of COURSE you can't!  Everything's on your machine.  My QA environment is a CLIENT-EMULATED environment.  Sheesh.

Eventually they started writing less sloppy code but, man, you're not gods.  I used to be a programmer, too, when QBasic and Btrieve were all the rage, but still!
 
2014-03-13 04:42:37 PM

WhoGAS: I started root causing in QA just to shut the developers up because every bug I found was, "Not a bug, can't reproduce!"  Of COURSE you can't!  Everything's on your machine.  My QA environment is a CLIENT-EMULATED environment.  Sheesh.



Good old MSVCRT90.dll
 
2014-03-13 04:53:05 PM
I yell at my own code, then yell at myself for writing bad code. Then I yell at the code for being bad.

/all I write is pulp...
 
2014-03-13 05:24:44 PM

Smidge204: How to write unmaintainable code

=Smidge=


Wonderful, truly wonder stuff in there.  Woohoo career writing java code for lieeefe!

/I realized a while back I just can't code drunk, inevitably its down to just me and god who know what it does
//and once I'm sober, only god.
 
2014-03-13 05:47:46 PM

JNowe: This job fulfilling in creative way.


I'll write the goddamn login page myself.
 
2014-03-13 06:37:45 PM
Attempted advert in the middle == close tab now
 
2014-03-13 09:59:24 PM

WhoGAS: you're not gods.


And this is why we know not to listen to QA people. :P
 
2014-03-13 11:07:20 PM
There are two types of code comments. Some people fill code with useless comments like this

//if isNewUser is True, run newUser method
if (isNewUser)
{ newUser(); }

comments like that are completely useless, and make code more difficult to read, not easier

If you document the method, function, sub, well, you usually don't need tons of comments for each line, because at that point you have to assume that other coders can figure out what you are doing.
 
2014-03-13 11:35:57 PM

ampoliros: Our plan is actually called "ampoliros gets hit-by-a-bus". There's a magic folder with descriptions, layouts, passwords, theory of operation (because we're not totally sure how it works), etc. It's kept in a lockbox a few minutes from the office. There's also a number to call of a third party who has been briefed and trained on operation (but not given access).

/can't believe they let me name it that


I've always encouraged my teams to say "won the lottery", not "got hit by a bus (and is now a red smear on the road)".  Somehow the former inspires more positive thinking.
 
2014-03-14 12:11:49 AM

Telos: WhoGAS: you're not gods.

And this is why we know not to listen to QA people. :P


Touche.

lol.

(oh, wait, now we're supposed to flame each other or whatever these kids do these days...bah...I'm too tired. Want a beer?)
 
2014-03-14 12:48:08 AM

JNowe: This job fulfilling in creative way.


Such a load of crap.
 
2014-03-14 02:30:16 AM
I still resist version control.
And I still rarely refactor. Usually, though, I plan meticulously enough that I don't need to. Waterfall design isn't so hip anymore, though, I guess I'm just a dinosaur.
 
2014-03-14 06:32:55 AM

starsrift: I still resist version control.
And I still rarely refactor. Usually, though, I plan meticulously enough that I don't need to. Waterfall design isn't so hip anymore, though, I guess I'm just a dinosaur.


If you're in a position to get people to finish telling you what's required before they start asking you if it's done...  more power to ya.

The only thing "dinosaur" about that kind of gig these days is the way it tends to end with a sudden asteroid strike.
 
2014-03-14 07:25:08 AM
When I saw that some programmers like to "role their own" I stopped reading. This guy's not a programmer.
 
Displayed 50 of 52 comments

First | « | 1 | 2 | » | Last | Show all

View Voting Results: Smartest and Funniest


This thread is closed to new comments.

Continue Farking
Submit a Link »






Report