• woopass (unregistered) in reply to Lone Marauder
    Lone Marauder:
    Julia:
    ...which is a sure-fire way to plenty of timewasting interviews where every answer meets the riposte "but your resume says you're an expert with (insert WTFware here)".

    And it's not just technical stuff they fake. I had the joys of meeting such an agency once. Told them that as a relatively new mother I wasn't going to relocate or stay away from home. They doctored the resume to tell the victim company I was fine for a contract that involved alternating 3-month periods between UK and Saudi Arabia...

    I usually cut off stuff like this by handing them my resume. Had more than one interviewer find it interesting that what I gave the recruiting company is different than what I gave them.

    It honestly makes me wonder how people like that stay in business. Honestly, if I found out that a recruiter was falsifying applicant data just to put people in front of me, I would no longer use the lying sack of crap.

    Recruiters are like estate agents: they ALL lie.

  • YeOldeOperator (unregistered) in reply to Fred

    Back when I was a computer operator, events like that would eventually annoy us so we'd let the job run until it hit its maximum print lines (which most people would leave at the JCL default of "more than you could possibly ever need"). We'd then get the handcart and place the printout on the person's desk. On their entire desk, each stack all the way to the ceiling.

    Later in the day we'd have their manager trying to convince us to take back the blank paper. Sadly, we could not take it back without someone (perhaps the very programmer who wasn't doing any work because of their "desk access issues") inspecting every page to assure us that there was no confidential information printed in the middle of the job :-)

    Some managers would be clever, and offer to walk us through the code that produced the job (deletion on MVS being even less effective than deletion on MS-DOS). After a few minutes of "we operator, too dumb to read code", we'd suddenly "get it" and ask what else the code did besides eject pages. Leaving the manager mumbling and leaving to "chat" with his programmer.

    Later, we got an upgraded job accounting system. Which was nice because the default job print limit matched the default weekly print limit. So one infinite loop and no more output for the rest of the week. So programmers would need to confess to the systems team as well as to the operators. Which would naturally do nothing but increase Systems' contempt for Applications.

  • alister (unregistered) in reply to Julia
    Julia:
    He also said that he'd taken the liberty of rewriting my resume to include a couple of things about my experience troubleshooting IIS...

    ...which is a sure-fire way to plenty of timewasting interviews where every answer meets the riposte "but your resume says you're an expert with (insert WTFware here)".

    And it's not just technical stuff they fake. I had the joys of meeting such an agency once. Told them that as a relatively new mother I wasn't going to relocate or stay away from home. They doctored the resume to tell the victim company I was fine for a contract that involved alternating 3-month periods between UK and Saudi Arabia...

    Or in my case turned netware admin + Unix familiarity into 3 years of UNIX Admin - lets just say I told them NOT to submit my CV.

    The issue is that not only does it annoy the hiring company and potentially waste both hirer's and seeker's time at interview, it can screw you up if you are going for a job with the company later, as one CV says X but new one says Y, which is correct? It is easier for the company just to reject you.

  • IsRetro (unregistered) in reply to boog
    boog:
    Code is not art. It's not something that you pour your soul into. It's just code. As long as it gets the job done and other programmers can maintain it, it doesn't matter who "likes" it.

    I beg to differ. Code is art - art that you should pour your soul into. You have to love it, and you shouldn't consider a particular code snippet done until it has matured into a state where you can love it with all of your heart.

    Mind you, I'm not saying you should act like these dicks/divas when someone explains what's wrong, and what's WRONG, and what's so wrong it's not even WRONG, with your code.

    I'm just saying that you can only create elegant, sleek, sexy code if you put your heart and soul in it. Note: That's a necessary condition, not a sufficient one. Heart and soul are not a suitable replacement for skills.

  • IsRetro (unregistered) in reply to Fred
    Fred:
    NutDriverLefty:
    No, but I have written a print job that made the line printer do Beethoven's Fifth. :-)
    Back when there were "computer operators" one good way to see if they were awake was to schedule a tight loop of page feeds to the high speed printer at 2:00 AM. You could usually shoot clean through a box of paper before they could run to hit the "online" button.
    So you're the bastard that made the original UNIX coders add the lp0 on fire error code.

    Lads, we found him! Bring on the torches and pitchforks! Empty the chad boxes over him and set him on fire!

  • fish2kill (unregistered) in reply to Nexzus

    He didn't burn any bridges - the bridge was already in the water. If you insist on using trite metaphors, what he really did was catapult a load of crap back onto their side of the river. Reminds me of my father-in-law's explanation of the dynamics of a lawsuit: It's just a formalized pissing contest. The unwritten rule of the game is that if they piss you off, they win; if you piss them off, YOU win. (He was a senior patent counsel for an aerospace giant). It's clear that the candidate won this contest.

    Similarly, once when I worked as a contract engineer for a small tech firm in RT128/Boston area, I returned from lunch and parked my car nose-in against the narrow landscaped area by the front door, in an open, unmarked, and unreserved space. Four hours later, I went to leave and found my car blocked from behind by another car that was also blocking the traffic lane of the industrial park. I found the receptionist and told her that some clown had parked me in. She looked out the window and then informed me that it was the CEO's car, I had inadvertently taken his space, and that he was in a meeting and couldn't be interrupted. I responded by saying that was OK, my big old American car was perfectly capable of moving that little Porsche, no need to bother the boss. About a minute later, the big man came out, fired me, and moved his car.

    Guess I really burned my bridges when I went out and had a sign made, and planted it in the lawn in front of his parking space about a week later: "RESERVED FOR CLOWN".

  • yername (unregistered) in reply to gravis
    gravis:
    sholdowa:
    Grog = drink, not understand

    go for some grog and Heineken, you'll like it.

    FTFY
    FTFY

  • Welsh (unregistered) in reply to Fred
    Fred:
    Any code that doesn't look like line noise is for mental weaklings that don't deserve to be writing code in the first place. Give them a GUI and let them drag and drop buttons until they die.

    Anyone who doesn't know what line noise looks like is too young to work in this profession.

    You're not cool unless you've whistled into a modem and had it respond.

    Let me guess, you no longer hear the modem, All you see now is blonde, brunette, redhead.

  • Jon H (unregistered)

    The TDWTF Interview (from Christian Riesen) ... In addition, everyone used whatever the hell they wanted to code on whatever operating system they wanted: Windows, Linux, Mac OSX and one even swore on FreeBSD.

    You consider this as bad? This is of course a good thing for several reasons, like (1) It enhances robustness and (2) it makes the programmers more productive.

    /Jon

  • Anonymous (unregistered) in reply to Jon H
    Jon H:
    > The TDWTF Interview (from Christian Riesen) ... > In addition, everyone used whatever the hell they wanted to > code on whatever operating system they wanted: Windows, > Linux, Mac OSX and one even swore on FreeBSD.

    You consider this as bad? This is of course a good thing for several reasons, like (1) It enhances robustness and (2) it makes the programmers more productive. /Jon

    Yeah, right - having a completely inconsistent IT architecture makes people WAY more productive. When you live in Opposite World.

  • Erm (unregistered) in reply to Dreadwolf's Jockstrap
    Dreadwolf's Jockstrap:
    Every one of us, to a man, will or will have looked back on code we wrote fresh out of university and be overwhelmed with shame. To. A. Man. (Even the women)

    Not I. Sure, I churned out awful, rancid, amateurish code back then. Sure, I look back and laugh at it now. I'm just not ashamed of it. I'd be ashamed to churn it out now, but I wouldn't, so what's to be ashamed of?

  • Pretentious? Moi? (unregistered) in reply to IsRetro
    IsRetro:
    boog:
    Code is not art. It's not something that you pour your soul into. It's just code. As long as it gets the job done and other programmers can maintain it, it doesn't matter who "likes" it.

    I beg to differ. Code is art - art that you should pour your soul into. You have to love it, and you shouldn't consider a particular code snippet done until it has matured into a state where you can love it with all of your heart.

    Mind you, I'm not saying you should act like these dicks/divas when someone explains what's wrong, and what's WRONG, and what's so wrong it's not even WRONG, with your code.

    I'm just saying that you can only create elegant, sleek, sexy code if you put your heart and soul in it. Note: That's a necessary condition, not a sufficient one. Heart and soul are not a suitable replacement for skills.

    You represent almost everything that's wrong with software development. It's not art, at all. I pity you.

  • Jon H (unregistered) in reply to Anonymous
    Anonymous:
    Yeah, right - having a completely inconsistent IT architecture makes people WAY more productive. When you live in Opposite World.

    We are talking about development, not production environment. Do you and your fellow developers wear the same clothes, drive the same car model and so on?

    If your choice of language and architecture framework are so fragile that you need to use the same tools all over, I consider the risk is your choice of framework.

  • Anonymous (unregistered) in reply to Jon H
    Jon H:
    Anonymous:
    Yeah, right - having a completely inconsistent IT architecture makes people WAY more productive. When you live in Opposite World.

    We are talking about development, not production environment. Do you and your fellow developers wear the same clothes, drive the same car model and so on?

    Clothes and cars have nothing to do with software development so your analogy is non-sensical in the extreme. We don't drive the same cars but you know what - we DO use the same development tools running on the same O/S running on the same hardware as each other. Because, unlike cars, those things are actually relevant to software development.

    Trying to rebut a valid comment with a totally unrelated analogy is the sort of thing they'd try to pull in Opposite World. But you've already made it perfectly clear that's your permanent place of residence.

  • Jon H (unregistered) in reply to Anonymous
    Anonymous:
    Jon H:
    Anonymous:
    Yeah, right - having a completely inconsistent IT architecture makes people WAY more productive. When you live in Opposite World.

    We are talking about development, not production environment. Do you and your fellow developers wear the same clothes, drive the same car model and so on?

    Clothes and cars have nothing to do with software development so your analogy is non-sensical in the extreme. We don't drive the same cars but you know what - we DO use the same development tools running on the same O/S running on the same hardware as each other. Because, unlike cars, those things are actually relevant to software development.

    Trying to rebut a valid comment with a totally unrelated analogy is the sort of thing they'd try to pull in Opposite World. But you've already made it perfectly clear that's your permanent place of residence.

    I give up. You only ridiculed my metaphore, not my point. WTF

  • Erm (unregistered) in reply to Anonymous
    Anonymous:
    Jon H:
    > The TDWTF Interview (from Christian Riesen) ... > In addition, everyone used whatever the hell they wanted to > code on whatever operating system they wanted: Windows, > Linux, Mac OSX and one even swore on FreeBSD.

    You consider this as bad? This is of course a good thing for several reasons, like (1) It enhances robustness and (2) it makes the programmers more productive. /Jon

    Yeah, right - having a completely inconsistent IT architecture makes people WAY more productive. When you live in Opposite World.

    It can do. In what way does, for example, forcing me to develop on Windows when I am much more productive with a bunch of Bash sessions on the go, help? Inb4 "use Cygwin" it's a poor substitute, and I still have to pick up a mouse to open another session.

  • Anonymous (unregistered) in reply to Jon H
    Jon H:
    Anonymous:
    Jon H:
    Anonymous:
    Yeah, right - having a completely inconsistent IT architecture makes people WAY more productive. When you live in Opposite World.

    We are talking about development, not production environment. Do you and your fellow developers wear the same clothes, drive the same car model and so on?

    Clothes and cars have nothing to do with software development so your analogy is non-sensical in the extreme. We don't drive the same cars but you know what - we DO use the same development tools running on the same O/S running on the same hardware as each other. Because, unlike cars, those things are actually relevant to software development.

    Trying to rebut a valid comment with a totally unrelated analogy is the sort of thing they'd try to pull in Opposite World. But you've already made it perfectly clear that's your permanent place of residence.

    I give up.

    Giving up is merely carrying on when you live in Opposite World.

  • itsmo (unregistered) in reply to Paul
    Paul:
    On the storm out, I can honestly say I feel that tech recruiters are nothing but spineless leeches . GET A REAL FUCKING JOB!
    FTFY (no other changes required however)
  • boog (unregistered) in reply to IsRetro
    IsRetro:
    I beg to differ. Code *is* art - art that you *should* pour your soul into. You have to love it, and you shouldn't consider a particular code snippet done until it has matured into a state where you can love it with all of your heart.

    Mind you, I'm not saying you should act like these dicks/divas when someone explains what's wrong, and what's WRONG, and what's so wrong it's not even WRONG, with your code.

    I'm just saying that you can only create elegant, sleek, sexy code if you put your heart and soul in it. Note: That's a necessary condition, not a sufficient one. Heart and soul are not a suitable replacement for skills.

    I'll buy that it's important to love what you do, that you can only really do something well when you love doing it, and I'll even accept that people can love the code they write. That doesn't make it art.

    If I asked two separate artists to each paint an apple sitting on a wooden table, I would end up with two paintings of an apple, but they would be two very different paintings using different techniques, colors, styles, etc. The artists express themselves through their paintings, and there are many "right" ways to do it.

    However, if I asked two quality programmers to each write code that implements a given algorithm with given requirements, given parameters, in a given language, their code is probably going to look a lot alike. It's harder for programmers to really express themselves through their code and, as a customer, I would rather they didn't, lest I end up with code that does not integrate into my design/application. There are very few "right" ways to do it.

  • Jay (unregistered) in reply to boog
    boog:
    IsRetro:
    I beg to differ. Code *is* art - art that you *should* pour your soul into. You have to love it, and you shouldn't consider a particular code snippet done until it has matured into a state where you can love it with all of your heart.

    Mind you, I'm not saying you should act like these dicks/divas when someone explains what's wrong, and what's WRONG, and what's so wrong it's not even WRONG, with your code.

    I'm just saying that you can only create elegant, sleek, sexy code if you put your heart and soul in it. Note: That's a necessary condition, not a sufficient one. Heart and soul are not a suitable replacement for skills.

    I'll buy that it's important to love what you do, that you can only really do something well when you love doing it, and I'll even accept that people can love the code they write. That doesn't make it art.

    If I asked two separate artists to each paint an apple sitting on a wooden table, I would end up with two paintings of an apple, but they would be two very different paintings using different techniques, colors, styles, etc. The artists express themselves through their paintings, and there are many "right" ways to do it.

    However, if I asked two quality programmers to each write code that implements a given algorithm with given requirements, given parameters, in a given language, their code is probably going to look a lot alike. It's harder for programmers to really express themselves through their code and, as a customer, I would rather they didn't, lest I end up with code that does not integrate into my design/application. There are very few "right" ways to do it.

    Hmm. If I asked two artists to paint a realistic picture of an apple sitting on a wooden table (presumably in preparation for being photographed with a digital camera and then scanned in, but that's another story ...) I would expect the results to show significant differences in style, but also to show obvious similarities, like both would show a roundish-looking fruit with a stem, probably red or green, and there would be wood grain visible beneath, etc.

    If I asked two programmers to write code to implement, say, updating a customer name-and-address database, I would expect the results to show significant differences in style, but also to show similarities, like both would include data entry fields for "name" and "address", etc, some sort of "save" button, etc.

    If I gave the programmers more detailed specs, I'd expect the code to be more similar. If I gave the artists more detailed specs -- like if we are talking about commercial art for an advertising campaign and not just "be creative" -- I'd expect their results to be more similar.

    Sounds to me like the two cases are very much alike. Code is a lot like art.

    We could, I suppose debate the definition of "art". I think of programming more as a "craft" than an "art form". That is, I think a programmer is like a carpenter who makes custom furniture or an engineer who designs machines to fulfill a specific purpose.

  • Jay (unregistered)

    It's amusing that this compilation of stories includes at least three examples of "what do you expect to accomplish by doing that?"

    1. Sending a "you could have had the best" email. As someone earlier noted, do you expect the person who made the hiring decision to read that and say, "Zounds, he's right! Cancel the offer to the second guy and let's do whatever it takes to hire this guy!" Surely that's just not going to happen. It's difficult to imagine anything positive good coming out of such an email. And there's an obvious negative: You make yourself look like a childish, spoiled brat. Perhaps next year the company would be looking to fill another position and they would have remembered you and given you a call. Perhaps one of the people involved in interviewing you will move to another company that is looking to hire someone and will remember you. Etc. I've had a number of times in this business where someone I worked with at one company turned up again at another company I worked for later. I once had a case where I was working for company A, left there to work for company B, and then some time later company B bought out company A. If I had left A with all sorts of nasty comments about how stupid they all were, it could have been very embarrassing. Especially if someone from company A whom I had insulted had ended up as a coworker on a project ... or as my boss.

    2. "Review this code." So they give the guy an example of production code that they think is very good and that they're very proud of and ask him to review it. If he makes any criticism, their feelings are hurt and they get defensive. If he makes no criticism but declares it to be great code, then they've learned nothing about his abilities. What a pointless exercise. If I was going to conduct such an interview exercise, I'd give the person a sample of code that included some deliberate bugs and bad practices of varying degrees of subtlety, and see how many he finds.

    3. Storming out of the interview. Pretty much the same story as #1. Maybe it makes you feel good, but you gain nothing. Who cares if the recruiter is an idiot. You're not hiring the recruiter or even considering going to work for the recruiter, you're trying to use him to find a job elsewhere. If I'm on my way to a job interview and a traffic light along the way malfunctions, I don't turn down the job because there was a bad traffic light on the road to the company's headquarters. I probably just put up with it and work around it.

  • Franz Kafka (unregistered) in reply to Jon H
    Jon H:
    Anonymous:
    Jon H:
    Anonymous:
    Yeah, right - having a completely inconsistent IT architecture makes people WAY more productive. When you live in Opposite World.

    We are talking about development, not production environment. Do you and your fellow developers wear the same clothes, drive the same car model and so on?

    Clothes and cars have nothing to do with software development so your analogy is non-sensical in the extreme. We don't drive the same cars but you know what - we DO use the same development tools running on the same O/S running on the same hardware as each other. Because, unlike cars, those things are actually relevant to software development.

    Trying to rebut a valid comment with a totally unrelated analogy is the sort of thing they'd try to pull in Opposite World. But you've already made it perfectly clear that's your permanent place of residence.

    I give up. You only ridiculed my metaphore, not my point. WTF

    Fine, I'll call you out: you're an idiot. If we all have different development environments, then how am I going to confirm a bug is in the code and not some difference to do with the environment? How do I know when it's fixed? How much time do I spend debugging the environments vs. actual work? When it comes time to make a new one, how much time will it take?

    Jay:
    3. Storming out of the interview. Pretty much the same story as #1. Maybe it makes you feel good, but you gain nothing. Who cares if the recruiter is an idiot. You're not hiring the recruiter or even considering going to work for the recruiter, you're trying to use him to find a job elsewhere. If I'm on my way to a job interview and a traffic light along the way malfunctions, I don't turn down the job because there was a bad traffic light on the road to the company's headquarters. I probably just put up with it and work around it.

    I agree with the guy in #3, although I would be very specific about him not submitting me anywhere - this recruiter is a walking disaster and I don't want any on me.

  • Lego (unregistered) in reply to Jay
    Jay:
    boog:
    IsRetro:
    I beg to differ. Code *is* art - art that you *should* pour your soul into. You have to love it, and you shouldn't consider a particular code snippet done until it has matured into a state where you can love it with all of your heart.

    Mind you, I'm not saying you should act like these dicks/divas when someone explains what's wrong, and what's WRONG, and what's so wrong it's not even WRONG, with your code.

    I'm just saying that you can only create elegant, sleek, sexy code if you put your heart and soul in it. Note: That's a necessary condition, not a sufficient one. Heart and soul are not a suitable replacement for skills.

    I'll buy that it's important to love what you do, that you can only really do something well when you love doing it, and I'll even accept that people can love the code they write. That doesn't make it art.

    If I asked two separate artists to each paint an apple sitting on a wooden table, I would end up with two paintings of an apple, but they would be two very different paintings using different techniques, colors, styles, etc. The artists express themselves through their paintings, and there are many "right" ways to do it.

    However, if I asked two quality programmers to each write code that implements a given algorithm with given requirements, given parameters, in a given language, their code is probably going to look a lot alike. It's harder for programmers to really express themselves through their code and, as a customer, I would rather they didn't, lest I end up with code that does not integrate into my design/application. There are very few "right" ways to do it.

    Hmm. If I asked two artists to paint a realistic picture of an apple sitting on a wooden table (presumably in preparation for being photographed with a digital camera and then scanned in, but that's another story ...) I would expect the results to show significant differences in style, but also to show obvious similarities, like both would show a roundish-looking fruit with a stem, probably red or green, and there would be wood grain visible beneath, etc.

    If I asked two programmers to write code to implement, say, updating a customer name-and-address database, I would expect the results to show significant differences in style, but also to show similarities, like both would include data entry fields for "name" and "address", etc, some sort of "save" button, etc.

    If I gave the programmers more detailed specs, I'd expect the code to be more similar. If I gave the artists more detailed specs -- like if we are talking about commercial art for an advertising campaign and not just "be creative" -- I'd expect their results to be more similar.

    Sounds to me like the two cases are very much alike. Code is a lot like art.

    We could, I suppose debate the definition of "art". I think of programming more as a "craft" than an "art form". That is, I think a programmer is like a carpenter who makes custom furniture or an engineer who designs machines to fulfill a specific purpose.

    The difference here is repeatability. Writing code should be a science. Identical inputs should produce identical results, uniformly and consistently. This is a deterministic process.

    Art, on the other hand, at it's highest form produces unique masterpieces. These are works of absolute brilliance never to be repeated or duplicated. This is not what I am looking for in a programmer.

    --Lego

  • boog (unregistered) in reply to Jay
    Jay:
    If I asked two programmers to write code to implement, say, updating a customer name-and-address database, I would expect the results to show significant differences in style, but also to show similarities, like both would include data entry fields for "name" and "address", etc, some sort of "save" button, etc.
    Exactly what significant differences in style would you expect? Naming conventions? Formatting/indentation? What do you classify as "style" when it comes to coding? Maybe you mean design? So, logic flow? Simplicity vs. complexity? Choice of sorting algorithm? Do these things express the emotions and experiences of the programmer? Will we feature these code snippets in museums? Will we all look at them, and interpret them in different ways? Seriously, how do you apply artistic principles to a set of instructions that the computer will use to perform a task?

    Regardless of the differences, if both programmers are experienced, they will probably arrive at mostly the same solution. If not, based on customer requirements, performance, etc., one solution will probably be better than the other, and the lesser will be thrown in the trash where it belongs.

    Jay:
    If I gave the programmers more detailed specs, I'd expect the code to be more similar. If I gave the artists more detailed specs -- like if we are talking about commercial art for an advertising campaign and not just "be creative" -- I'd expect their results to be more similar.
    While your point is valid, I think you underestimate the effect that artistic styles and techniques have on a work of art; even with very detailed specs, a single artist could come up with many different results. Concept artists generally arrive at many possible solutions (and iterations of solutions) which the customer reviews, choosing their favorites based on personal preferences and test audiences. I don't expect that this happens too terribly often with code.
    Jay:
    We could, I suppose debate the definition of "art". I think of programming more as a "craft" than an "art form". That is, I think a programmer is like a carpenter who makes custom furniture or an engineer who designs machines to fulfill a specific purpose.
    We could also debate the definition of "programming"; some consider it to be writing code only, while others include software design in their definition. While I personally am reluctant to classify the former alone as a "craft", I could easily agree with you that the latter is akin to a "craft".
  • pingmaster (unregistered) in reply to danixdefcon5
    danixdefcon5:
    TFA:
    His closing words were: "you could have had the best, now you'll just have the rest!"
    Am I the only one surprised that a 50-something would actually quote Hackers in a didn't-get-the-job rant?
    Hackers was made in 1995. So he'd have been a 30-something (maybe early 40's, for very large values of '50-something'), which would have been within the target demographic for that movie.
  • Jay (unregistered) in reply to Lego
    Lego:
    The difference here is repeatability. Writing code should be a science. Identical inputs should produce identical results, uniformly and consistently. This is a deterministic process.

    Art, on the other hand, at it's highest form produces unique masterpieces. These are works of absolute brilliance never to be repeated or duplicated. This is not what I am looking for in a programmer.

    You're telling me that if you asked two programmers to write a program meeting the same specs, that you would expect the resulting code to be identical or nearly so? Like, wow. I don't mean to be insulting, but I don't know how to respond except to say that that is absurd. You would naturally expect that two programmers would logically and inevitably choose the exact same field and function names? Okay, maybe you wouldn't go that far. But if your statement means anything at all, you must mean that you would assume that they would both decompose the problem into the exact same set of functions. For example, it would be unimaginable for one programmer to break the "calculate customer balance" operation into a separate function for enhanced readability while another puts it inline to a bigger function because it's only done once? There is no way that one programmer could store data in a linked list while another chooses a dynamic array? When writing queries, you can't imagine one programmer using a subquery while another uses a join?

    If I took a problem that I coded six months ago and sat down to write it again today, assuming I didn't remember how I'd done it the first time, I would be quite surprised if the resulting programs were the same.

    Of course I don't expect every program to be "brilliant" (or even "brillant"), any more than I expect every painting produced by everyone who aspires to be an artist to be brilliant. The average high school student just learning Java is not likely to produce masterpieces, just like the average high school student taking Art 101 is not likely to produce masterpieces.

  • Jay (unregistered) in reply to boog
    boog:
    Jay:
    If I asked two programmers to write code to implement, say, updating a customer name-and-address database, I would expect the results to show significant differences in style, but also to show similarities, like both would include data entry fields for "name" and "address", etc, some sort of "save" button, etc.
    Exactly what significant differences in style would you expect? Naming conventions? Formatting/indentation? What do you classify as "style" when it comes to coding? Maybe you mean design? So, logic flow? Simplicity vs. complexity? Choice of sorting algorithm?
    Yes, exactly those sort of things. From naming conventions to choice of data structures and specific algorithms and functional decomposition and all the other thousands of decisions that go into writing a program.
    Do these things express the emotions and experiences of the programmer? Will we feature these code snippets in museums? Will we all look at them, and interpret them in different ways? Seriously, how do you apply artistic principles to a set of instructions that the computer will use to perform a task?
    Are you trolling or is this a serious comment? Of course I don't think of programming as an "art" in the sense that I expect to arouse an emotional response from the audience. At least, other than "hey, that's pretty clever". Actually, I don't see why particularly clever code snippets might not end up in a "museum of programming" some day. There are plenty of museums dedicated to old cars and farm machinery and other mechanical devices. Why shouldn't there be a museum of software? Aside from the fact that the audience that could appreciate it would be small. But really now, when people say that programming is an "art", I presume they mean it in the same sense that one describes architecture or carpenty as an "art". That's why I said "craft" might be a better term.
    Regardless of the differences, if both programmers are experienced, they will probably arrive at mostly the same solution. If not, based on customer requirements, performance, etc., one solution will probably be better than the other, and the lesser will be thrown in the trash where it belongs.

    This is simply absurd. See my previous post. There are many many ways in which two programs could both solve the same problem and yet be vastly different, and different in ways where it would be very difficult to say which is better. For example, one programmer might break the task into more functions than another. In some cases breaking something out into a separate function makes the code more readable by simplifying the top-level function. In other cases it makes it less readable by obscuring what is really happening. Which is better is a judgement call.

    Jay:
    If I gave the programmers more detailed specs, I'd expect the code to be more similar. If I gave the artists more detailed specs -- like if we are talking about commercial art for an advertising campaign and not just "be creative" -- I'd expect their results to be more similar.
    While your point is valid, I think you underestimate the effect that artistic styles and techniques have on a work of art; even with very detailed specs, a single artist could come up with many different results. Concept artists generally arrive at many possible solutions (and iterations of solutions) which the customer reviews, choosing their favorites based on personal preferences and test audiences. I don't expect that this happens too terribly often with code.
    So you've never attended a code walkthru then, eh?

    It is true that details of artistic style tend to be visible in the final result and thus important to the customer, while differences in coding style are often invisible to the user and thus not important to the customer. If the question is, "Is there any difference at all between painting and programming?" of course the answer is yes. But I didn't think that was the question.

  • Lego (unregistered) in reply to Jay
    Jay:
    Lego:
    The difference here is repeatability. Writing code should be a science. Identical inputs should produce identical results, uniformly and consistently. This is a deterministic process.

    Art, on the other hand, at it's highest form produces unique masterpieces. These are works of absolute brilliance never to be repeated or duplicated. This is not what I am looking for in a programmer.

    You're telling me that if you asked two programmers to write a program meeting the same specs, that you would expect the resulting code to be identical or nearly so? Like, wow. I don't mean to be insulting, but I don't know how to respond except to say that that is absurd. You would naturally expect that two programmers would logically and inevitably choose the exact same field and function names? Okay, maybe you wouldn't go that far. But if your statement means anything at all, you must mean that you would assume that they would both decompose the problem into the exact same set of functions. For example, it would be unimaginable for one programmer to break the "calculate customer balance" operation into a separate function for enhanced readability while another puts it inline to a bigger function because it's only done once? There is no way that one programmer could store data in a linked list while another chooses a dynamic array? When writing queries, you can't imagine one programmer using a subquery while another uses a join?

    If I took a problem that I coded six months ago and sat down to write it again today, assuming I didn't remember how I'd done it the first time, I would be quite surprised if the resulting programs were the same.

    Of course I don't expect every program to be "brilliant" (or even "brillant"), any more than I expect every painting produced by everyone who aspires to be an artist to be brilliant. The average high school student just learning Java is not likely to produce masterpieces, just like the average high school student taking Art 101 is not likely to produce masterpieces.

    My assertion here is that requirements, schedule, budget, environment, standards and best practices will tend to suggest an optimal solution to the skilled and experienced software engineer. While two such people may not produce results that are byte for byte identical, the basic structure, naming, internal documentation, etc. would be visibly similar.

    This type of discipline is what sets professional engineers apart from programmers. It is what is necessary for software engineering to receive the same credibility as the traditional professional engineering fields.

    You may not like my point of view, but the folks we work for want engineers, not brillant artists.

    --Lego

  • boog (unregistered) in reply to Jay
    Jay:
    Are you trolling or is this a serious comment? Of course I don't think of programming as an "art" in the sense that I expect to arouse an emotional response from the audience. At least, other than "hey, that's pretty clever".
    Definitely not trolling. Your post seemed to imply a correlation between stylistic differences in code and those of actual art forms. I wanted you to clarify and you did that (thank you). I took it a bit far with the questions (mainly to drive the point home), but I was dead serious about the last question: how do you (or anyone) apply artistic principles to a set of instructions intended for a computer to perform a task?
    Jay:
    But really now, when people say that programming is an "art", I presume they mean it in the same sense that one describes architecture or carpenty as an "art". That's why I said "craft" might be a better term.
    I presume they mean it in the same sense as well; artistic principles can be applied to architecture, and probably carpentry, so calling either "art" would probably be appropriate, but I get your point.

    As I said in my last post, I would agree with your term of "craft" over "art", assuming you include design aspects in your definition of "programming" (which it sounds like you are). Still, others continue to call it "art"; my beef is with their term, not yours.

    Jay:
    This is simply absurd. See my previous post. There are many many ways in which two programs could both solve the same problem and yet be vastly different, and different in ways where it would be very difficult to say which is better. For example, one programmer might break the task into more functions than another. In some cases breaking something out into a separate function makes the code more readable by simplifying the top-level function. In other cases it makes it less readable by obscuring what is really happening. Which is better is a judgement call.
    Absurd? No. TFA mentioned two half-sheet examples of code, so I assumed we were talking on that scale (my mistake). In a half-sheet of code there may be a few differences, hence the qualifier "mostly". And obviously as the scope expands, so will the potential differences.

    I guess to get back to the original point, do any of these differences imply that the coder is an "artist"?

    Jay:
    boog:
    While your point is valid, I think you underestimate the effect that artistic styles and techniques have on a work of art; even with very detailed specs, a single artist could come up with many different results. Concept artists generally arrive at many possible solutions (and iterations of solutions) which the customer reviews, choosing their favorites based on personal preferences and test audiences. I don't expect that this happens too terribly often with code.
    So you've never attended a code walkthru then, eh?
    I've never been to a walkthru where a programmer provided a few dozen versions of code that all perform the same task, and everyone glanced them over and chose one purely for subjective reasons. Maybe that's because I've never worked for a company that will waste that much time (money) writing code that they expect to throw away.
    Jay:
    It is true that details of artistic style tend to be visible in the final result and thus important to the customer, while differences in coding style are often invisible to the user and thus not important to the customer. If the question is, "Is there any difference at all between painting and programming?" of course the answer is yes. But I didn't think that was the question.
    It wasn't the question. In fact, I don't think there was a question. I simply mentioned that "code is not art" in my original post, and it seems to have sparked some interesting discussion. <soapbox> Personally, I get tired of people elevating coding to the status of an art-form, or magic, or state-of-mind. The geek culture is fun and all, but I'll be honest: writing code is the easiest part of my job. So much in IT is more challenging and more meaningful to the success of a project than writing good code.

    Good software design is more of a challenge than writing good code. Extensive and effective testing is more of a challenge than writing code. Requirements-gathering, troubleshooting, root-cause analysis, working with users/customers, attending meetings, documentation, deciding what to have for lunch, and getting out of bed in the morning are all more challenging than code.

    So if it's so easy, why do so many people act like it's some higher form of art? Furthermore, why aren't these other things I mentioned treated with the same respect? </soapbox>

  • Neuro (unregistered)

    "what's the difference between layer 7 routing and layer 4 routing?"

    I am am a bit rusty not even sure that there is such a thing as layer 4 and layer 7 routing - I supose they also thought that MIDI is in presentation layer :-)

    BTW I used to be the main tester and a suport person for x.400 and x.500 of rthe bigest ADMD in the UK

  • Christian (unregistered)

    About that TDWTF Interview, the code was horrid. One part looked copy pasted from the php manual, and then even from the wrong section. Imagine a function that declares a variable at the top (not taking any parameters), runs on for almost half a page, then returns said variable from the top, unchanged, not even doing anything external, like a database lookup or anything. If you want to one line it, it would be something like this: function wtf() { return 'somevalue'; }

    And that was half a page of code of their production code.

    The other one had a couple WTF's in them too, but it wasn't as bad. Still, how can anyone who has coded for more than a couple of days, think that first example is not some sort of test if you over think the solution, a ruse to weed out those guys who like to make a diagram before adding that missing semicolon at the end of some statement?

    And yes, some people take their code too serious. I look back at code I made with a framework I had no prior experience with a year back and I sometimes shake my head at the WTF's I built into that thing. But we all learn and get better at it, if there is someone to point out the errors or we learn more and find them ourselves.

  • Mike (unregistered) in reply to Anonymous

    Your comments are an excellent argument in favor of forbidding anonymous posting... At least have the balls to put your name on your bold statements. :)

    And insulting people by saying they 'live in opposite world' is the last resort of those with no logical argument.

    Perhaps you could discourse on WHY it is so heinous to allow creative people to use tools that they are comfortable with, as long as the end-result is compatible across-the-board with other developers that may need to work with it.

  • (cs) in reply to Mike
    Mike:
    Your comments are an excellent argument in favor of forbidding anonymous posting... At least have the balls to put your name on your bold statements. :)

    And insulting people by saying they 'live in opposite world' is the last resort of those with no logical argument.

    Perhaps you could discourse on WHY it is so heinous to allow creative people to use tools that they are comfortable with, as long as the end-result is compatible across-the-board with other developers that may need to work with it.

    This was me. I registered! Cool perks from registering, btw!

  • Grig (unregistered)

    I never stormed out of an interview, but those recruiters are terrible:

    One sent me to a site where it became apparent I was not applying for a system administrator job, but for some kind of application programmer with a PMP. Both of us were very confused until she realized that the job description I had (I showed her a copy of the recruiter e-mail on my iPhone) was NOT what they asked for at all. What a waste of time!

    "You have Linux experience. That's an OS. Windows is an OS, so you are a Windows administrator?"

    "No, I'm sorry, the correct answer is Java is written in JavaScript."

    And I can't count the number of times I have been told the job was local when instead it was for some Podunk town halfway across the country. Many don't even know where I am: "So, Raleigh is close to Washington DC, right?" I guess compared to Ganymede, yes, but not exactly a daily commute I am willing to take a 6 month contract for.

  • jim dorey (unregistered)

    should have gone to the second interview, with a copy of the e-mail, and your original resume... 'i can't work for a company that would use such an incompetent boob as a recruiter' then walked out. there's also the option of naming names online... then sending them a link to it.

  • Prism (unregistered) in reply to boog
    boog:
    IsRetro:
    I beg to differ. Code *is* art - art that you *should* pour your soul into. You have to love it, and you shouldn't consider a particular code snippet done until it has matured into a state where you can love it with all of your heart.

    Mind you, I'm not saying you should act like these dicks/divas when someone explains what's wrong, and what's WRONG, and what's so wrong it's not even WRONG, with your code.

    I'm just saying that you can only create elegant, sleek, sexy code if you put your heart and soul in it. Note: That's a necessary condition, not a sufficient one. Heart and soul are not a suitable replacement for skills.

    I'll buy that it's important to love what you do, that you can only really do something well when you love doing it, and I'll even accept that people can love the code they write. That doesn't make it art.

    If I asked two separate artists to each paint an apple sitting on a wooden table, I would end up with two paintings of an apple, but they would be two very different paintings using different techniques, colors, styles, etc. The artists express themselves through their paintings, and there are many "right" ways to do it.

    However, if I asked two quality programmers to each write code that implements a given algorithm with given requirements, given parameters, in a given language, their code is probably going to look a lot alike. It's harder for programmers to really express themselves through their code and, as a customer, I would rather they didn't, lest I end up with code that does not integrate into my design/application. There are very few "right" ways to do it.

    I need to strongly object here. I suppose in the strictest sense of the word, 'code' is not art. Although parts of my balk at even that idea. Code is a map, and all maps are pretty.

    But-- coding, is a discipline, and all human disciplines are an art.

    Examples. Look at the space program. No frills here, pure technological endeavor. Is it a beautiful thing? Then it is art.

    We may be reinventing the wheel, or wiring up components - and it may be very mundane comparatively...

    Compare this to a gymnast. Basically he/she has his routine, nothing really groundbreaking or unique, its all been done before. yet-

    it is the sheer discipline behind a human endeavor that grabs our attention and our awe.

    This and the act of creation itself, what someone has once called the 'war against nothingness', the fight against the empty canvas. Therein lies the human drama.

    If I am Conan and I ask two blacksmiths to forge me a sword, they will create very similar objects according to my physique. It may be a 'plain Jane' sword, but I doubt that anyone could claim it is a thing without beauty, even down to its humble and sparse details.

    And isn't THAT what art really is -- the thing that happens between the viewer and the object?

  • Prism (unregistered) in reply to Lego

    Pounding nails is pounding nails. You want a nail pounder.

    Plenty of them out there. A very left brain occupation, this programming stuff.

    Do the words 'creative' and 'programmer' ever belong together?

    I think half the battle in creating a 'unique masterpiece', or in the software world, the 'killer app' -- is knowing what is possible.

    There are also plenty of right brain creative types out there too, but (typically) they don't swim in the world of possibilities and potentials that programmers do.

    Therefore, they don't have the palette to draw upon to create or imagine in this world.

    Maybe you are correct and the 'creative programmers' out there tend to be bad apples in a pragmatic sense. We've got all these nails to pound, right? No time to be mucking around.

    Question is, where do you think the next killer, or semi-killer app is most likely to come from, and do you care?

    I mean, its ok if you don't. Seriously, you got 'your thing', and it suffices.

    But it is wrong to discount something based on a 'too risky for me, not my bag' type of evaluation?

    The majority of 'artists/creators' in this world 'fail' and fail badly. They don't produce your masterpieces. And IMHO they don't produce much noteworthy, with some exceptions of course.

    Should they also drop their brushes alongside the forsaken keyboards of the 'creative programmers'?

    Is that whats best for the world and all concerned?

    Granted, I am putting some words in your mouth, based on your inferences.

    And I guess you're right in a way, if your the owner of a sweatshop churning out t-shirts, you really don't have much use for a limp-wristed Madison avenue designer full of crazy ideas. Why would you?

    Harsh analogy, I know. But maybe the shoe fits, and the reason it would is because you discounted those people you personally have no use for.

    Objection complete.

Leave a comment on “The Best, The TDWTF Interview, and The Storm-out”

Log In or post as a guest

Replying to comment #322476:

« Return to Article