It's a backup...



  • So I recently started a new role at a small start-up (.Net shop). During a conversation with my new boss, he mentions to me that, when publishing code to production, we need to include all the files. Not just source files, but also project and solution files...

    OK...

    Not awful, but I know it's fairly common to push code which isn't pre-compiled. Fine... He then goes on to tell me why. "Because it serves as a backup. And because some developers don't 'Get Latest' before working on code. So before you publish, you diff all the files to make sure you don't overwrite the other developers work"

    Let's try to spot the WTF's here:

    1. He's OK with developers not getting latest, and publishing potentially non-compiling code straight into production
    2. He's also OK with these same developers never checking their changes back into source control
    3. You have raw code, along with debugging information, in production (think performance and security issues)
    4. The onus is on YOU to diff all the files so as to not overwrite the developers' "work", because, ya know, they couldn't be arsed to USE THE FUCKING SOURCE CONTROL!
    5. So, not only is code in source control different than what should be in production, but each developer has their own flavour of the code-base

    I would keep adding to the list, but I'm starting to weep uncontrollably... I'll leave the floor open to anybody who wants to add to this already sad list.



  • @C-Octothorpe said:

    3) You have raw code, along with debugging information, in production

    With .Net, all the information is in the assemblies anyway.  The only thing in the .pdbs is line numbers and stuff like that.

    Other than that... *shakes head*



  • @Sutherlands said:

    @C-Octothorpe said:

    3) You have raw code, along with debugging information, in production

    With .Net, all the information is in the assemblies anyway.  The only thing in the .pdbs is line numbers and stuff like that.

    Other than that... *shakes head*

    The thing is that, because they're just pushing the .cs files, technically, there is no way to know if it compiles until it runs for the first time. Either way, I never said that it's the only WTF, just a minor one. I'd prefer to precompile as release and push that, but it's not necessary. The fact that the code in production is newer than what's in source control is a HUGE WTF.

    EDIT: a lot of the developers here spend a lot of their time putting out fires, daily. Surprise, surprise...



  • Sadly, things like those only strengthen the C#-code-monkey stereotype.



  •  Is this .net shop very near Los Angeles, California?



  • @C-Octothorpe said:

    Either way, I never said that it's the only WTF

    That's why, for everything else, i shook my head...



  • Hey, this sounds familiar! To mitigate the situation, I suggest using a distributed source control system, and have a repository in production; it really helps merging the code when deploying your changes. And never help a co-worker who can't tell with which revision of the software they has a problem :-)



  •  I've had to work with clueless people in the past, but thankfully I was the senior dev and put my foot down. Anyone so much as sneezed in production without going through source control first, he was a dead man. And of course there were the constant code reviews where I beat them into shape until they could be trusted to be left to their own devices.

    I shudder to think that one day I might be in your shoes...



  •  Just a couple of observations:

    1. Walltext is hard to read. Aligned numerical lists are easier to read.
    2. If it "servers as a backup", have you asked him what his recovery procedures are, and if the inclusion of extraneous files assists or hinders that process?
    3. If developers don't always "get latest", have you asked $boss why isn't there some automated/technical solution if it's considered a problem?
    4. What procedure has $boss laid down when diffs are discovered? (yes, we're starting to see the benefits of checkout/commit)
    5. How often are reports run against source control to track developer effort, or aren't they monitored?
    6. What kind of testing is run?
    7. Did you get any indication of this level of cluelessness during the interview?
    8. Have you asked how effective the process has been up until now, and has he spotted any potential for improvements?
    9. You seem to have plenty of upcoming WTF fodder - will you post them here?



  • @DOA said:

     I've had to work with clueless people in the past...  ...I beat them into shape until they could be trusted to be left to their own devices.

    That.

    I think people's attitude to cluelessness says a lot about how they view the situation.

    These people are clueless now. Do they:

    • want to remain clueless, resisting any attempt at absorbing clue, making a concerted effort to avoid the Big Box of Clue that someone's labelled "CLUE" standing in their path?
    • detest being clueless, want to learn, to explore strange new worlds, to seek out new facts and new experience, to boldly go where no fuckwit fears to tread?

    I initially give clueless people the benefit of the doubt, on the basis that everyone is born without clue and some may have valid reasons to their ignorance about a particular subject. Unfortunately, IME the majority of clueless people are that way due to their own behaviour  - and will sadly remain that way until they themselves change their own mentality.

    My years of experience means I'm now able to detect that mentality quite early on, luckily, keeping wasted effort to a minimum.



  • @m said:

    Hey, this sounds familiar! To mitigate the situation, I suggest using a distributed source control system, and have a repository in production; it really helps merging the code when deploying your changes. And never help a co-worker who can't tell with which revision of the software they has a problem :-)

    DCVS isn't going to fix anything. I like DCVS but it doesn't stop people from doing retarded stuff like not testing before deploying. Also, even with DCVS nobody should be able to push directly from their repo into the production repo...



  • @morbiuswilters said:

    @m said:

    Hey, this sounds familiar! To mitigate the situation, I suggest using a distributed source control system, and have a repository in production; it really helps merging the code when deploying your changes. And never help a co-worker who can't tell with which revision of the software they has a problem :-)

    DCVS isn't going to fix anything. I like DCVS but it doesn't stop people from doing retarded stuff like not testing before deploying. Also, even with DCVS nobody should be able to push directly from their repo into the production repo...

     

    It doesn't fix the WTFish environment, but it is a handy tool for working in it.

    I don’t expect C# as new employee to have the possibility to enforce proper testing and deploying procedures (mind they don't have time for such fancy stuff, they're putting out fires), but he has the possibility to automate merging changes from developement to production, and, …, back.

     




  • Holy fuck. So, the deployment process is to push code from developer's machines to production? How do you all connect to the production machine? Is this a "local" (i.e., your servers or the clients') server?

    And yes, it sounds like we've hit a great new seam of WTFs with your new job. Please keep us posted.



  • Simple solution (when you have the authority to create it)...make it so the ONLY way a "production ready" package can be created is by one of the automated build machines that push to a staging area. Do not ever give the developers direct access to some of the "critical items" (given them "mocks" to use).

    Now if a developer wants to do a direct push, they do not have sufficient information... even if the big boss is standing directly over them ordering them to do it.



  • @TheCPUWizard said:

    Simple solution (when you have the authority to create it)...make it so the ONLY way a "production ready" package can be created is by one of the automated build machines that push to a staging area. Do not ever give the developers direct access to some of the "critical items" (given them "mocks" to use).

    Now if a developer wants to do a direct push, they do not have sufficient information... even if the big boss is standing directly over them ordering them to do it.

    Exactly; 99% of developers should not have access to production.



  • @morbiuswilters said:

    Exactly; 99% of developers should not have access to production.
    I'll raise that to 100%. It is not the task of a developer to push anything to production. There should be unit testing / integration testing / acceptance testing / management decision / operations personnel (you know the whole story). Otherwise, chaos ensues. Well, maybe for very small shops with less than a dozen employees.

     



  • Reminds me of this conversation I had a few years ago. Standard count-the-WTFs territory:



    Boss: What are you up to?

    Me: Just fixing the deb packages we use to install our software. They had no dependencies defined, despite having many actual dependencies. So I'm putting them in.

    Boss: No! No! Don't do that! Never do that!

    Me: Why not?

    Boss: Because I had a terrible experience with that, once. Customer had a problem, so I logged on and did a few things to try and fix it, including uninstalling package X that our package depended on. So I did and Boom! Out went ours with it.

    Me: Erm ... it must have warned you ...?

    Boss: Do you think we have time to READ what spews out of the terminal? Sheesh! Job to do, anyone?

    Me: OK, well, it can't have been the end of the world. So you just reinstalled it, right?

    Boss: Reinst- ... what? No, I couldn't just "re-install" it. I'd lost all the code I'd written on there - all the edits I'd made, over the years, to the files contained in the package.

    Me: Oh.



  • @Cassidy said:

    1. What kind of testing is run?

     

    ROFL. Please tell me you don't seriously expect a shop incapable of using source control system to on the other handever use tests?

     



  • @token_woman said:

    Reminds me of this conversation I had a few years ago. Standard count-the-WTFs territory:



    Boss: What are you up to?

    Me: Just fixing the deb packages we use to install our software. They had no dependencies defined, despite having many actual dependencies. So I'm putting them in.

    Boss: No! No! Don't do that! Never do that!

    Me: Why not?

    Boss: Because I had a terrible experience with that, once. Customer had a problem, so I logged on and did a few things to try and fix it, including uninstalling package X that our package depended on. So I did and Boom! Out went ours with it.

    Me: Erm ... it must have warned you ...?

    Boss: Do you think we have time to READ what spews out of the terminal? Sheesh! Job to do, anyone?

    Me: OK, well, it can't have been the end of the world. So you just reinstalled it, right?

    Boss: Reinst- ... what? No, I couldn't just "re-install" it. I'd lost all the code I'd written on there - all the edits I'd made, over the years, to the files contained in the package.

    Me: Oh.
    Wow! I'm in awe!

    Although I've been there before. But it was my home server only, and it concerned some open source LCD display driver software package. And I didn't know my ass from my elbow at the time. The experience helped to distinguish, though.



  • @token_woman said:

    Reminds me of this conversation I had a few years ago. Standard count-the-WTFs territory:

    Boss: What are you up to?
    Me: Just fixing the deb packages we use to install our software. They had no dependencies defined, despite having many actual dependencies. So I'm putting them in.
    Boss: No! No! Don't do that! Never do that!
    Me: Why not?
    Boss: Because I had a terrible experience with that, once. Customer had a problem, so I logged on and did a few things to try and fix it, including uninstalling package X that our package depended on. So I did and Boom! Out went ours with it.
    Me: Erm ... it must have warned you ...?
    Boss: Do you think we have time to READ what spews out of the terminal? Sheesh! Job to do, anyone?
    Me: OK, well, it can't have been the end of the world. So you just reinstalled it, right?
    Boss: Reinst- ... what? No, I couldn't just "re-install" it. I'd lost all the code I'd written on there - all the edits I'd made, over the years, to the files contained in the package.
    Me: Oh.
    I encountered a fun dependency issue once when I tried to do a rebuild all on a coworker's solution and it did not work.  Upon investigation I found project A depedent on project B, project B dependent on project C, and project C dependent on the debug built dll of project A.  Rebuild all wiped out debug built dll of project A and thus caused a chain reaction of dependency failures.  When I tried to explain to him the issue, it took far too long for him to understand why it was wrong.



  • @Anketam said:

    I encountered a fun dependency issue once when I tried to do a rebuild all on a coworker's solution and it did not work.  Upon investigation I found project A depedent on project B, project B dependent on project C, and project C dependent on the debug built dll of project A.  Rebuild all wiped out debug built dll of project A and thus caused a chain reaction of dependency failures.  When I tried to explain to him the issue, it took far too long for him to understand why it was wrong.

    Why, just restore the deleted debug built dll of project A from backup and you're back in business. We'll take care of the circular reference problem later, once we have time for such nice-to-have improvements.

     



  • @TheRider said:

    @Anketam said:
    I encountered a fun dependency issue once when I tried to do a rebuild all on a coworker's solution and it did not work.  Upon investigation I found project A depedent on project B, project B dependent on project C, and project C dependent on the debug built dll of project A.  Rebuild all wiped out debug built dll of project A and thus caused a chain reaction of dependency failures.  When I tried to explain to him the issue, it took far too long for him to understand why it was wrong.

    Why, just restore the deleted debug built dll of project A from backup and you're back in business. We'll take care of the circular reference problem later, once we have time for such nice-to-have improvements.
    Dont worry the dll in question was also checked into source control along with all other compiled files so nothing was lost (Mean while someone somewher just twiched at that).



  • @DOA said:

     I've had to work with clueless people in the past, but thankfully I was the senior dev and put my foot down. Anyone so much as sneezed in production without going through source control first, he was a dead man. And of course there were the constant code reviews where I beat them into shape until they could be trusted to be left to their own devices.
    I wish. I'm not important enough nor do I carry enough clout to be able to push anything... That being said, I do have a lot of experience, and I think (hope) my boss is open to some discussion. I mean really, it's not like it's hours of extra work, and it's a perfectly logical thing to do.@DOA said:
    I shudder to think that one day I might be in your shoes...
    You haven't lived until you've worked in a place so upside down that you start exhibiting signs of PTSD just three weeks in...



  • @Cassidy said:

    Walltext is hard to read. Aligned numerical lists are easier to read.
    Point taken. Will do for future posts...@Cassidy said:
    If it "servers as a backup", have you asked him what his recovery procedures are, and if the inclusion of extraneous files assists or hinders that process?
    HAHAHAHAH!!... Oh wait, you're serious.@Cassidy said:
    What procedure has $boss laid down when diffs are discovered? (yes, we're starting to see the benefits of checkout/commit)
    When diffs are discovered, the (his) procedure is: check out the entire solution, copy everything from prod to local, and check it all in.@Cassidy said:
    How often are reports run against source control to track developer effort, or aren't they monitored?
    None.@Cassidy said:
    What kind of testing is run?
    Whatever testing the developer feels is sufficient. And judging by the fact that some of the devs here don't really know how to use source control (or understand the drawbacks of not using one), then you can imaging the type of testing that happens here.@Cassidy said:
    Did you get any indication of this level of cluelessness during the interview?
    Not really. I mean, they seemed pretty technical, but it's hard to weed out WTFs like this in a one-hour interview, especially when it's something you could never imagine being done in the first place.@Cassidy said:
    Have you asked how effective the process has been up until now, and has he spotted any potential for improvements?
    Planning on doing this soon. Just working out an approach (I'm not very good with these scenarios as I am not the most patient person).@Cassidy said:
    You seem to have plenty of upcoming WTF fodder - will you post them here?
    Yes I do, and yes I will.



  • @boomzilla said:


    Holy fuck. So, the deployment process is to push code from developer's machines to production? How do you all connect to the production machine? Is this a "local" (i.e., your servers or the clients') server?

    No, these are dedicated servers running mission-critical apps that have many dependencies. If one service goes tits-up, the entire house of cards comes tumbling down.


  • @morbiuswilters said:

    @TheCPUWizard said:

    Simple solution (when you have the authority to create it)...make it so the ONLY way a "production ready" package can be created is by one of the automated build machines that push to a staging area. Do not ever give the developers direct access to some of the "critical items" (given them "mocks" to use).

    Now if a developer wants to do a direct push, they do not have sufficient information... even if the big boss is standing directly over them ordering them to do it.

    Exactly; 99% of developers should not have access to production.

    Ideally, yes. In smaller shops, developers need to push their own stuff. However, in situations like these there should be a pinch-point where only one or two developers have production access and are tasked with running the build script and pushing the package(s).



  • @C-Octothorpe said:

    @boomzilla said:
    Holy fuck. So, the deployment process is to push code from developer's machines to production? How do you all connect to the production machine? Is this a "local" (i.e., your servers or the clients') server?

    No, these are legit servers running mission-critical apps that have many dependencies.

    I guess I wasn't clear. Where are these servers, physically? At the clients'? At your facility? Hosted somewhere in a data center?



  • @C-Octothorpe said:

    @morbiuswilters said:
    @TheCPUWizard said:

    Simple solution (when you have the authority to create it)...make it so the ONLY way a "production ready" package can be created is by one of the automated build machines that push to a staging area. Do not ever give the developers direct access to some of the "critical items" (given them "mocks" to use).

    Now if a developer wants to do a direct push, they do not have sufficient information... even if the big boss is standing directly over them ordering them to do it.

    Exactly; 99% of developers should not have access to production.

    Ideally, yes. In smaller shops, developers need to push their own stuff. However, in situations like these there should be a pinch-point where only one or two developers have production access and are tasked with running the build script and pushing the package(s).

    Sometimes MPD is an advantage. Even though a small shop may have one human who has to fill multiple roles, there can be advantages to having distinct identities for these roles. For example, using my "normal developer" login, I do not have access to any of my in-house production (or even QA) environments. To access those, I must make a deliberate decision to put myself in that role, and sign into the appropriate environment with the appropriate identity. Once I am in a "production" login, I no longer have access to development capabilities.

     If this overkill? Perhaps. But it has saved me from countless stupid WTF's over the years (thereby freeing up time for completely diferent types of WTF's <grin>)



  • @TheCPUWizard said:

    @C-Octothorpe said:
    @morbiuswilters said:
    @TheCPUWizard said:

    Simple solution (when you have the authority to create it)...make it so the ONLY way a "production ready" package can be created is by one of the automated build machines that push to a staging area. Do not ever give the developers direct access to some of the "critical items" (given them "mocks" to use).

    Now if a developer wants to do a direct push, they do not have sufficient information... even if the big boss is standing directly over them ordering them to do it.

    Exactly; 99% of developers should not have access to production.

    Ideally, yes. In smaller shops, developers need to push their own stuff. However, in situations like these there should be a pinch-point where only one or two developers have production access and are tasked with running the build script and pushing the package(s).

    Sometimes MPD is an advantage. Even though a small shop may have one human who has to fill multiple roles, there can be advantages to having distinct identities for these roles. For example, using my "normal developer" login, I do not have access to any of my in-house production (or even QA) environments. To access those, I must make a deliberate decision to put myself in that role, and sign into the appropriate environment with the appropriate identity. Once I am in a "production" login, I no longer have access to development capabilities.

     If this overkill? Perhaps. But it has saved me from countless stupid WTF's over the years (thereby freeing up time for completely diferent types of WTF's <grin>)

    Not overkill, but this would be step 462... Currently, everyone shares a single login account for production. And all service accounts (web sites, services, etc.) all use a single database login with DBO access.

    Is it a bad that things like this no longer bother me?



  • @boomzilla said:

    @C-Octothorpe said:
    @boomzilla said:
    Holy fuck. So, the deployment process is to push code from developer's machines to production? How do you all connect to the production machine? Is this a "local" (i.e., your servers or the clients') server?

    No, these are legit servers running mission-critical apps that have many dependencies.

    I guess I wasn't clear. Where are these servers, physically? At the clients'? At your facility? Hosted somewhere in a data center?

    My mistake. Some are hosted in-house and others are located off-site. All the in-house server instances are virtualized (I think).



  • @Renan said:

    Sadly, things like those only strengthen the C#-code-monkey stereotype.

    Well, as politically uncorrect as it is to point this out, stereotypes do exist for a reason...



  • @C-Octothorpe said:

    @Cassidy said:
    Did you get any indication of this level of cluelessness during the interview?
    Not really. I mean, they seemed pretty technical, but it's hard to weed out WTFs like this in a one-hour interview, especially when it's something you could never imagine being done in the first place.

    The Joel Test is handy for interview situations like this. They don't need to score perfect, IMO, but they at least need to have heard of every item in the list. It's simple enough to get through in an interview.



  • @C-Octothorpe said:

    @Cassidy said:
    Did you get any indication of this level of cluelessness during the interview?
    Not really. I mean, they seemed pretty technical, but it's hard to weed out WTFs like this in a one-hour interview, especially when it's something you could never imagine being done in the first place.

    I'll second this. I've been hornswoggled in an interview before. When talking to the CEO (who had written most of the original codebase) he was eloquent and explained a well-designed system. He told me he was hiring a developer because he didn't feel confident in his programming abilities and wanted a professional. Once I started I discovered that this was a lie and that he frequently inserted himself into the codebase, usually creating havoc which brought down the entire service for hours on end. When we had talked about development process in the interview, he made copious reference to unit testing and source control.

    When I started I discovered that his preferred method of development was to fire up vim on the production servers and tweak until he got something working, then scp it to all the other servers. The code directories were littered with filenames like "file.2.php" and "file.test.GOOD.php". The other developer and I tried to use SVN but the CEO flat-out refused. He ended up developing his own source-control system for some of his projects which stored entire source files in a database TEXT field and kept a version ID column. The software "auto-updated" by connecting to the DB, querying for the source file, writing it to a temp file and then mv'ing it into place..

    The nadir was when he asked me to remove all JOINs from my queries because he didn't understand how they worked. I also had to spend an hour explaining to him why a variable declared in a function was not accessible after the function had returned. He told everyone in the office I was a genius when I sped up part of the system several-hundred-thousand-fold by converting a 100M row table to use ints, booleans and enums instead of text for every column, including the booleans (which could be "True", "T", "true", "TRUE" or "t" for true and "False", "F", "false", "FALSE", "f", "" or NULL for false) and the numbers (which had all kinds of casts to get SUM() to work..)



  • @token_woman said:

    Reminds me of this conversation I had a few years ago. Standard count-the-WTFs territory:



    Boss: What are you up to?

    Me: Just fixing the deb packages we use to install our software. They had no dependencies defined, despite having many actual dependencies. So I'm putting them in.

    Boss: No! No! Don't do that! Never do that!

    Me: Why not?

    Boss: Because I fucked up terribly, then didn't read the output, had no backups to perform a re-install... hang on, this is totally unrelated to your package dependencies!

    FantasiedTFY.

    @Shinhan7 said:

    ROFL. Please tell me you don't seriously expect a
    shop incapable of using source control system to on the other handever
    use tests?

    I expect any competant SDLC process to include testing phases. Whether or not they use source control shouldn't affect what testing they do.

    @C-Octothorpe said:

    HAHAHAHAH!!... Oh wait, you're serious.

    Only to the point that I don't honestly expect a serious answer from $boss. I do, however, expect him to squirm uncomfortably when questions expose potential vectors for large business losses, and know that if the situation actually arose then I couldn't be accused of being a plant.

    @C-Octothorpe said:

    However, in situations like these there
    should be a pinch-point where only one or two developers have production
    access and are tasked with running the build script and pushing the
    package(s).

    Then in that situation, they're not developers

    • they're build & release managers. They may be called
      "developers", but they're taking the role of managing deployment.

     



  • @blakeyrat said:

    The Joel Test is handy for interview situations like this.

    I'm now thinking that "What do you think of Joel Spotsky?" is a good question to ask at an interview.



  • @havokk said:

    @blakeyrat said:
    The Joel Test is handy for interview situations like this.

    I'm now thinking that "What do you think of Joel Spotsky?" is a good question to ask at an interview.

    Might be. "Heard of him" = good. (Even if they hate him and disagree with everything he does.) "Haven't heard of him" = bad. Similarly, you could ask about The Mythical Man-Month with the same grading scale.


  • Discourse touched me in a no-no place

    @Cassidy said:

    I expect any [b]competant[/b] SDLC process to include testing phases.
    What's that got to do with anything?



  • @morbiuswilters said:

    I discovered that his preferred method of development was to fire up vim on the production servers and tweak until he got something working, then scp it to all the other servers.
    And why, may I ask, haven't you posted all this already? Do you expect Snoofle to do all the work around here?



  • @DOA said:

    @morbiuswilters said:

    I discovered that his preferred method of development was to fire up vim on the production servers and tweak until he got something working, then scp it to all the other servers.
    And why, may I ask, haven't you posted all this already? Do you expect Snoofle to do all the work around here?

    This was many years ago, but I've mentioned it from time-to-time.



  • @blakeyrat said:

    @havokk said:
    @blakeyrat said:
    The Joel Test is handy for interview situations like this.

    I'm now thinking that "What do you think of Joel Spotsky?" is a good question to ask at an interview.

    Might be. "Heard of him" = good. (Even if they hate him and disagree with everything he does.) "Haven't heard of him" = bad. Similarly, you could ask about The Mythical Man-Month with the same grading scale.

    Except if they disagree with the Mythical Man-Month, you definitely should only hire them if you're actively looking for WTFs.



  • @morbiuswilters said:

    When I started I discovered that his preferred method of development was to fire up vim on the production servers and tweak until he got something working, then scp it to all the other servers.

    $Boss from my previous post had a better method, which took him less time and therefore was obviously preferable:


    Fire up vim on customer's server and tweak until he got something working.


    That's it.



    We had 150 customers running our software (I shudder to think what they all must have done in previous lives) which meant, by this method, we had 150 versions of the code.


    I think the idea was, when one person has complained of a bug, why spend time fixing it for the other 149 who haven't noticed?


    @morbiuswilters said:

    The nadir was when he asked me to remove all JOINs from my queries because he didn't understand how they worked.

    But you had foreign keys, right?



  • @blakeyrat said:

    @havokk said:
    @blakeyrat said:
    The Joel Test is handy for interview situations like this.

    I'm now thinking that "What do you think of Joel Spotsky?" is a good question to ask at an interview.

    Might be. "Heard of him" = good. (Even if they hate him and disagree with everything he does.) "Haven't heard of him" = bad. Similarly, you could ask about The Mythical Man-Month with the same grading scale.

    True. Personally, I think he's an opinionated blow-hard who, when he's right he's very right but when he's wrong, my god, it's like watching a car accident in slow motion.

    A few years back, I had an interview at a large bank. Once I got there, I was introduced to my interviewer, the "Senior Developer", who was a very quiet, socially inept and overweight man in his early thirties. "Aw fuck, Rain Man is interviewing me. This should be fun...", I thought to myself.

    This guy asked me some very pedestrian type questions about variable declaration and types (this was for a senior position). About ten minutes into the interview, I joked with him and asked if he was going to ask me the standard .Net question about the difference between the objects and structs. He looked at me like I had just used my Jedi powers to lift the boardroom table, starting nervously flipping through his stack of ".Net Interview Questions" and said something like "you're way more senior than me. I can't even interview you properly." I got a call five minutes later with a job offer, which I promptly turned down...



  • @boomzilla said:

    @blakeyrat said:
    @havokk said:
    @blakeyrat said:
    The Joel Test is handy for interview situations like this.

    I'm now thinking that "What do you think of Joel Spotsky?" is a good question to ask at an interview.

    Might be. "Heard of him" = good. (Even if they hate him and disagree with everything he does.) "Haven't heard of him" = bad. Similarly, you could ask about The Mythical Man-Month with the same grading scale.

    Except if they disagree with the Mythical Man-Month, you definitely should only hire them if you're actively looking for WTFs.

    I have never seen proof that the Mythical Man-Moth exists..



  • @token_woman said:

    $Boss from my previous post had a better method, which took him less time and therefore was obviously preferable:


    Fire up vim on customer's server and tweak until he got something working.


    That's it.



    We had 150 customers running our software (I shudder to think what they all must have done in previous lives) which meant, by this method, we had 150 versions of the code.


    I think the idea was, when one person has complained of a bug, why spend time fixing it for the other 149 who haven't noticed?

    Yeah, that's what my employer prior to the one I mentioned did.

    @token_woman said:

    But you had foreign keys, right?

    Ha ha ha, you're adorable..



  • @morbiuswilters said:

    I have never seen proof that the Mythical Man-Moth exists...

    ^- Proof



  • @blakeyrat said:

    @morbiuswilters said:
    I have never seen proof that the Mythical Man-Moth exists...

    ^- Proof

    Now I'll ace those interviews!

    Look out, World: you're about to get a new Junior ColdFusion Developer!


  • Discourse touched me in a no-no place

    @C-Octothorpe said:

    @blakeyrat said:
    @havokk said:
    I'm now thinking that "What do you think of Joel Spotsky?" is a good question to ask at an interview.

    Might be. "Heard of him" = good. (Even if they hate him and disagree with everything he does.) "Haven't heard of him" = bad. Similarly, you could ask about The Mythical Man-Month with the same grading scale.

    True. Personally, I think he's an opinionated blow-hard who, when he's right he's very right but when he's wrong, my god, it's like watching a car accident in slow motion.
    What's worse is that when he comes this close to being right (make wrong code look wrong), but for some reason fails to take the next logical step (make wrong code not compile), his not-quite-there attempt still gets parroted perpetually on programmers.stackexchange.



  • @PedanticCurmudgeon said:

    Filed under: smart and gets things done
    ... and gosh darn it, people like you.


  • Discourse touched me in a no-no place

    @C-Octothorpe said:

    @PedanticCurmudgeon said:
    Filed under: smart and gets things done
    ... and gosh darn it, people like you.
    And one day, if I study and work hard, I may be done and gets things smart.



  • @PedanticCurmudgeon said:

    @C-Octothorpe said:
    @PedanticCurmudgeon said:
    Filed under: smart and gets things done
    ... and gosh darn it, people like you.
    And one day, if I study and work hard, I may be done and gets things smart.

    That's a really great article. It accurately reflects what I've seen and experienced. I think it illustrates why I don't like Joel: he thinks he knows more than everyone else even though he's hardly a "done and gets things smart" kinda guy. He has a tendency to state the bleeding obvious "Use source control" and then act like he's God's gift to software engineering.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.