• David (unregistered)

    cool .. a politician at work

  • n/a (unregistered)

    This reads like the Sartre play No Exit.

  • (cs)

    There's more wrong here than Dave. The VP and the CTO are personally involved in showing Carlos where he made programming errors? Uh... wouldn't that be Dave's job? Must be a very small company. Either that, or very tightly micro-managed.

  • blah (unregistered)

    Have you read the latest comments yet?

  • Gorfblot (unregistered)
    "OK, I'll rework what I have," Carlos said. Turning to Dave, he asked "Dave, how did we miss that when we were going over this earlier?"
  • Real Old Fart (unregistered) in reply to Gorfblot
    Gorfblot:
    "OK, I'll rework what I have," Carlos said. Turning to Dave, he asked "Dave, how did we miss that when we were going over this earlier?"

    Actually what Carlos said was.........

    OK, I'll rework what I have," Carlos said. Turning to Dave, he said, "Dave, looks like you really didn't know what you were talking about there. Next time, I'll just implement my design, if you don't mind."

    It's called playing hardball. Dave needs to learn the rules.

  • (cs)

    And this, dear friends, is why you get directions/instructions in writing - so you don't have to take the fall for your superiors' incompetence!

  • Bobble (unregistered) in reply to Real Old Fart
    Real Old Fart:
    Gorfblot:
    "OK, I'll rework what I have," Carlos said. Turning to Dave, he asked "Dave, how did we miss that when we were going over this earlier?"

    Actually what Carlos said was.........

    OK, I'll rework what I have," Carlos said. Turning to Dave, he said, "Dave, looks like you really didn't know what you were talking about there. Next time, I'll just implement my design, if you don't mind."

    It's called playing hardball. Dave needs to learn the rules.

    It's Carlos' job to code. Not to teach his boss a lesson. Gorfblot has it right. It draws attention to his manager's involvement in the problem. Then Dave's bosses can do their jobs.

  • Rocketboy (unregistered) in reply to blah

    Well, I wasn't done typ

  • (cs) in reply to snoofle
    snoofle:
    And this, dear friends, is why you get directions/instructions in writing - so you don't have to take the fall for your superiors' incompetence!

    I've learned to always do this when someone tells me about how to do something or answers a question I have. Otherwise Joe will tell me to do X, and a month later call me to his desk and say "Hey, why is it doing X? I want it to do Y." It's nice to be able to diplomatically say "Well, last time we discussed it, you wanted X, as per this email exchange. But if you think Y makes more sense, we can change it..." whereupon he'll usually say "Oh, right, I guess I did ask for X. Well, that's fine then."

    Even if it's an informal discussion in the cube or hallway, I will always send a message saying "As per our discussion in the hallway, I will be implementing X."

  • Pat (unregistered) in reply to snoofle
    snoofle:
    And this, dear friends, is why you get directions/instructions in writing - so you don't have to take the fall for your superiors' incompetence!

    Exactly. Document everything or else it all trickles down to the guy at the bottom.

    It also helps during quality control so you don't have to piece together what you were doing weeks ago.

  • (cs) in reply to blah
    blah:
    Have you read the latest comments yet?
    Still working on it. Some of them just won't parse.
  • sir_flexalot (unregistered) in reply to snoofle

    and of course, if you are denied the instructions in writing, make them yourself and CC everyone so that you have deniability. There is no excuse for word-of-mouth only and then being blamed if/when it turns out to be wrong.

  • Stu (unregistered)

    I wonder if all of these people are really passive-aggressive, or if they just end up that way in the rewrites. It seems like 2/3 of the WTFs involve someone who knows there's a problem but fails to adequately communicate the problem.

  • Zap Brannigan (unregistered) in reply to snoofle
    snoofle:
    And this, dear friends, is why you get directions/instructions in writing - so you don't have to take the fall for your superiors' incompetence!
    That's culturally insensitive. Our company has a rich tradition of oral communication. Historically, our managements doesn't even have a written language.
  • fungible (unregistered) in reply to snoofle

    I had a manager who wouldn't put anything in writing specifically so we couldn't prove that our work was per his instructions. So we just started writing everything down with the date and time, or we would always have a second person around when he wanted to "chat."

  • Ben4jammin (unregistered) in reply to snoofle
    snoofle:
    And this, dear friends, is why you get directions/instructions in writing - so you don't have to take the fall for your superiors' incompetence!

    Exactly. Yes, you can make snide remarks in front of your manager's boss but keep in mind that long before you walked in, your manager had a chance to lay the ground work for the blame to go to you. It wouldn't be that difficult for your manager to tell his boss, "yea and he'll probably act like he thought that is what I told him to do" or whatever. Then when you say it, you just reaffirmed everything your boss told him and you look even worse. Paper trails can be your best friend

  • Asiago Chow (unregistered)

    On the flip side, it has been long standing advice to executives to give all orders verbally to avoid providing material for "Pearl Harbor Files".

    I can't comment on the manager's background but there are very different ways of using source control repositories. I've worked in shops that did the "long checkout" cycle... programmers had files out for days or weeks at a time. They often turned off locking or did concurrent checkouts and spent additional time merging changes caused by constant branching. They lost time and released regression-laden code too, all because they didn't check their changes in very often.

    I've also worked at places where the checkout/change/checkin operation was typically far smaller. If you had to change a file you would do your test spikes offline to prove that your approach would work, then you checked out the file you needed, integrated the change, built, and checked it back in. If the change was a one liner the whole process might take literally 20 seconds. Of course there were lots of little checkouts but it also promoted fast code sharing and minimized merges. That worked really well when the source repository was integrated into the IDE so that an attempt to change a file triggered an automatic checkout.

    Having used both methods, I think the short cycle approach was far superior. Yeah, you wound up with buggy code in your repository, but you always have that. You also wound up with a very tight log of what actually changed, with good sharing (so that work groups could collaborate more closely), and by using tools of the environment (marked builds, autobuilder systems, and so on) we picked up a lot of benefits. The general rule was that remote employees checked in changes at least once a day and preferrably didn't keep a file checked out for more than a few minutes unless they were making major changes (e.g. writing a whole bunch of code in an unfinished project).

    Is that the story here? Could be. Sounds like Carlos really wasn't fitting in to the point that Dave was actively trying to torpedo him. What caused that? Nobody is blameless in this world.

  • Brandon (unregistered)

    I hate where the story ends and Carlos doesn't call him out or punch him in the face or something. Even if it wasn't true, I still would have liked some ass kicking

  • (cs)

    Did this guy previously work at Open[elided] and have a habit of forging subordinates names on documents he gave to the Board?

  • (cs)
  • effi (unregistered)

    Well, that didn't read very well... Or maybe I'm just tired...

  • no way (unregistered)

    The TRWTF is that the word "people" is always spelled as singular if definite article was not mentioned.

  • Walleye (unregistered) in reply to Zap Brannigan
    Zap Brannigan:
    snoofle:
    And this, dear friends, is why you get directions/instructions in writing - so you don't have to take the fall for your superiors' incompetence!
    That's culturally insensitive. Our company has a rich tradition of oral communication. Historically, our managements doesn't even have a written language.

    Ha! Ours can barely walk upright.

  • jp (unregistered) in reply to Asiago Chow
    Asiago Chow:
    If you had to change a file you would do your test spikes offline to prove that your approach would work, then you checked out the file you needed, integrated the change, built, and checked it back in. If the change was a one liner the whole process might take literally 20 seconds. Of course there were lots of little checkouts but it also promoted fast code sharing and minimized merges. That worked really well when the source repository was integrated into the IDE so that an attempt to change a file triggered an automatic checkout.

    The real WTF is that people still use locking version control systems and think that is good way to work.

    Seriously. Put down that Perforce crap (or $deity forbid, Visual Source Hell) and join the 90s, where we have this wonderful magical pixie dust called "a text merging algorithm".

  • configurator (unregistered)

    The word peoples' is spelled correctly, because it is not a plural but a possessive, meaning the s should in fact be there.

  • Tyrr (unregistered) in reply to snoofle

    And carlos Replied, Full of Angsty Wraith.

    "DO YOU HAVE ANY IDEA, ANY CONCEPTION! ANY IOTA OF A THOUGHT OF HOW MANY VIRGINS I MUST SACRIFICE TO THE DARK LORD CLUTHULU IN ORDER TO PERFORM THESE DARK ARTS? SIXTY THREE, Precisely SIXTY THREE virgins! EACH TIME I Feel Guilty, MORE Dirty! Last night it was an orphanage, a week ago I hit a jackpot and just freaked out on a bunch of Nuns, and half of them weren't even virgins! Good God Man, doesn't your bloody thrust for more code end somewhere? At some point? Isn't there a LINE somewhere that we can draw?"

    Dave: With a smile on his face, the rest of the programmers in hysterical laughter.

    "NOT TO MENTION, what happens if I Divide by Zero. Each time that happens I open up a portal TO THE NETHERVERSAL ZOMBIE PLANE and I have to pull precious out of her safe and save the world."

    Dave: opens his mouth

    "DO NOT move that tongue, Do Not even ask. Don't even say it. Do not utter the words or may the dark lord strike you down where you stand! For my sanity is ever THINNER, Even more BARE, and one day, I might just snap! And we wouldn't want that, now would we?"

    Dave: Is it

    "AUGHGHGHGHGHGHGH!!!!!!!"

    Pulls out nerf gun, start shooting Dave.

    "Ok, now I've satiated my trigger finger's urge and had my oral cleansing. No, dave, it isn't done, and it's going to take awhile. So how bout you check in twice a day with me, instead of 16 billion times, and go do something useful for a change? Like get me some coffie? Double black, sugar?"

    Because in the kingdom of trolls, laughter is king.

  • (cs)

    I swear if I had someone coming into my cubicle every 30 minutes to ask if I had checked in my code they would be quite firmly told to "get the fsck out of here and let me work'. Then every minute I spent having to deal with the idiot would show up on my time reporting.

    Of course, I would follow up with an e-mail to my boss explaining in more corporately acceptable terms that I was being harassed by this idiot.

    Having that in writing would pave the way for all kinds of future fun.

    But I also agree that anything that comes through for me is in writing. I keep records of everything in our tracking system so that it's much harder to come back and bite me later. Painful experience taught me that one.

    Sounds like Tenacious Dave needs to meet up with Alice from Dilbert. Problem solved.

  • Franz Kafka (unregistered) in reply to jp
    jp:
    Asiago Chow:
    If you had to change a file you would do your test spikes offline to prove that your approach would work, then you checked out the file you needed, integrated the change, built, and checked it back in. If the change was a one liner the whole process might take literally 20 seconds. Of course there were lots of little checkouts but it also promoted fast code sharing and minimized merges. That worked really well when the source repository was integrated into the IDE so that an attempt to change a file triggered an automatic checkout.

    The real WTF is that people still use locking version control systems and think that is good way to work.

    Seriously. Put down that Perforce crap (or $deity forbid, Visual Source Hell) and join the 90s, where we have this wonderful magical pixie dust called "a text merging algorithm".

    Yeah, hi, guess you didn't hear - perforce can do non-locking checkouts and does a dandy job of merging. It also does branches pretty well too.

  • (cs) in reply to snoofle
    snoofle:
    And this, dear friends, is why you get directions/instructions in writing - so you don't have to take the fall for your superiors' incompetence!

    My personal opinion is: if you have to CYA this carefully, the company doesn't deserve your services or you deserve what you get. Accepting behavior like this allows it to continue.

    That's not to say "don't keep a trail", but something this blatant can't just be swallowed day in and day out.

  • Evo (unregistered) in reply to effi
    effi:
    Well, that didn't read very well... Or maybe I'm just tired...

    I must be tired as hell then... Anyways, I think it's just because it's hard to make a long story we're supposed to cry 'WTF' at out of nothing. Because lets get real... Person 1 gives advice, Person B follows this, Person III blames Person B and Person 1 does nothing. Is that something new? Or Person 1 taking the credit for something Person B does. I've seen both happen loads of times. Maybe that's just me.

  • Glow-in-the-dark (unregistered) in reply to snoofle
    snoofle:
    And this, dear friends, is why you get directions/instructions in writing - so you don't have to take the fall for your superiors' incompetence!

    This is why you get ALL your instructions in writing, especially the dodgy ones appear to suddenly become less important when someone has to confirm this in writing like "book that time to client x" when you have just told them you weren't on that project during that time. Pointing out that that is fraud doesn't work, asking for just a quick confirmation email is much more effective..

  • (cs)

    I worked in an environment where the developers were protected from everything. Someone wrote requirements and gave them to you. You programmed them. If anything was missing or not specific enough, you ask the person who wrote the requirements to fix their document. When you're done programming, the testers test your code. How can you be responsible for anything if you programmed what someone else requested, and someone else tested/verified it works as intended.

  • (cs) in reply to pglewis
    pglewis:
    My personal opinion is: if you have to CYA this carefully, the company doesn't deserve your services or you deserve what you get. Accepting behavior like this allows it to continue.

    That's not to say "don't keep a trail", but something this blatant can't just be swallowed day in and day out.

    Ex-actly. If you need to deliberately fix requirements and work instructions in emails or meeting minutes, that means either (or both) of these things:

    A) the project is organized badly and does not have proper (or any) requirements/workflow management - this can be fixed, but if management resists that, the project is probably going to do very badly overall unless it's small

    B) communication and/or management is dysfunctional and people are working against rather than with each other - get out of there ASAP

  • Asiago Chow (unregistered) in reply to Franz Kafka
    Franz Kafka:
    jp:
    Asiago Chow:
    If you had to change a file you would do your test spikes offline to prove that your approach would work, then you checked out the file you needed, integrated the change, built, and checked it back in.

    The real WTF is that people still use locking version control systems and think that is good way to work.

    Seriously. Put down that Perforce crap (or $deity forbid, Visual Source Hell) and join the 90s, where we have this wonderful magical pixie dust called "a text merging algorithm".

    Yeah, hi, guess you didn't hear - perforce can do non-locking checkouts and does a dandy job of merging. It also does branches pretty well too.

    Shrug. Maybe it's the tools I've used or the people I've worked with but the benefits of non-locking checkouts have never materialized for me in smaller projects. Yeah, necessary for large projects with lots of developers, but if there are so few developers that Dave can go bug Carlos every half hour that's a small project.

    For smaller projects the results have always been increased regressions (due to screwed up merges) and developer tension (because different people make changes to the same area of code and nobody wants to back down) without any of the supposed benefits. That's especially true if you've got Refactorers as coworkers... you know, the programmers who can't see a program without changing something to suit their esthetic sensabilities and management won't reign in. They go to add a simple conditional and next thing you know they have touched six files and made changes right in the middle of what four other people are working on and it has a real tendency to screw up autmated merges from what I've seen. Locking checkouts get rid of that problem with no real downside (again, for smaller projects).

    Maybe if we all switch to Git life will be better...

  • Carlos's Coworker (unregistered)

    I work there, and this story was confusing even for me.

    The basic problem was that Dave would constantly ask for check-ins, and would constantly be told that the check-ins weren't ready, and would constantly say he didn't care and just wanted to take a peek at where we were.

    Code would get checked in. A build would run. Stuff wouldn't work. And Dave would wave his arms showing everyone how broken everything is and file bugs against it.

    Developers had to spend half their time explaining to dave's and carlos's boss why the builds weren't working right.

  • (cs) in reply to akatherder
    akatherder:
    I worked in an environment where the developers were protected from everything. Someone wrote requirements and gave them to you. You programmed them. If anything was missing or not specific enough, you ask the person who wrote the requirements to fix their document. When you're done programming, the testers test your code. How can you be responsible for anything if you programmed what someone else requested, and someone else tested/verified it works as intended.
    "Who's responsible?" is the wrong question. The right one is "How can we fix it and prevent it from happening again?". Any environment where assigning blame is considered important (beyond making sure the person responsible understands the error and will not repeat it) is not productive. Is the customer going to be any less annoyed about a delay or a bug in production just because you know whom to blame?
  • (cs) in reply to snoofle
    snoofle:
    And this, dear friends, is why you get directions/instructions in writing - so you don't have to take the fall for your superiors' incompetence!
    Exactly. This is what ticketing systems are for. Have a suggestion? I won't act on it unless it is in the ticket.
  • Franz Kafka (unregistered) in reply to Asiago Chow
    Asiago Chow:
    On the flip side, it has been long standing advice to executives to give all orders verbally to avoid providing material for "Pearl Harbor Files".

    If you have someone playing stupid games, then it's your job to create a pearl harbor file.

    Asiago Chow:
    I can't comment on the manager's background but there are very different ways of using source control repositories. I've worked in shops that did the "long checkout" cycle... programmers had files out for days or weeks at a time. They often turned off locking or did concurrent checkouts and spent additional time merging changes caused by constant branching. They lost time and released regression-laden code too, all because they didn't check their changes in very often.

    If you have decent organization, the devs won't be partying on the same files at the same time, so this isn't an issue. SOA helps here, as it breaks the overall system into chunks.

    Asiago Chow:
    Is that the story here? Could be. Sounds like Carlos really wasn't fitting in to the point that Dave was actively trying to torpedo him. What caused that? Nobody is blameless in this world.

    Dave may be trying to torpedo him so he looks good or to hide his own incompetence.

  • SoonerMatt (unregistered) in reply to Ben4jammin
    Ben4jammin:
    Exactly. Yes, you can make snide remarks in front of your manager's boss but keep in mind that long before you walked in, your manager had a chance to lay the ground work for the blame to go to you. It wouldn't be that difficult for your manager to tell his boss, "yea and he'll probably act like he thought that is what I told him to do" or whatever. Then when you say it, you just reaffirmed everything your boss told him and you look even worse. Paper trails can be your best friend

    Don't ever delete emails, turn IM loggin on, etc....

    CAPTION: nulla (feminine tense for nothing?)

  • (cs) in reply to pglewis
    pglewis:
    snoofle:
    And this, dear friends, is why you get directions/instructions in writing - so you don't have to take the fall for your superiors' incompetence!

    My personal opinion is: if you have to CYA this carefully, the company doesn't deserve your services or you deserve what you get. Accepting behavior like this allows it to continue.

    That's not to say "don't keep a trail", but something this blatant can't just be swallowed day in and day out.

    I agree. If someone micromanages me (I had a boss who did something similar once), I let it go no more than twice. The third time, I drag them into a closed office for a "conversation", and if it persists, I go directly to their boss. If that fails, I leave - quickly.

  • Staz (unregistered) in reply to jp
    jp:
    Asiago Chow:
    If you had to change a file you would do your test spikes offline to prove that your approach would work, then you checked out the file you needed, integrated the change, built, and checked it back in. If the change was a one liner the whole process might take literally 20 seconds. Of course there were lots of little checkouts but it also promoted fast code sharing and minimized merges. That worked really well when the source repository was integrated into the IDE so that an attempt to change a file triggered an automatic checkout.

    The real WTF is that people still use locking version control systems and think that is good way to work.

    Seriously. Put down that Perforce crap (or $deity forbid, Visual Source Hell) and join the 90s, where we have this wonderful magical pixie dust called "a text merging algorithm".

    Join the 21th century, we have Distributed Versions Control System

    and cookies.

  • (cs) in reply to Asiago Chow
    Asiago Chow:
    Shrug. Maybe it's the tools I've used or the people I've worked with but the benefits of non-locking checkouts have never materialized for me in smaller projects. Yeah, necessary for large projects with lots of developers, but if there are so few developers that Dave can go bug Carlos every half hour that's a small project.

    For smaller projects the results have always been increased regressions (due to screwed up merges) and developer tension (because different people make changes to the same area of code and nobody wants to back down) without any of the supposed benefits.

    Sounds like your problem is not with the tools or the people, but with the code design and the modus operandi. Well-designed code is split up into relatively small files that each have a narrow responsibility. Then, if people are organized properly so that they work on separate features, they shouldn't usually have to touch the same file at the same time, and almost never the same part of a file. If they check in frequently, conflicts will be rare and nearly always easily resolvable.

    That's especially true if you've got Refactorers as coworkers... you know, the programmers who can't see a program without changing something to suit their esthetic sensabilities and management won't reign in. They go to add a simple conditional and next thing you know they have touched six files and made changes right in the middle of what four other people are working on and it has a real tendency to screw up autmated merges from what I've seen. Locking checkouts get rid of that problem with no real downside (again, for smaller projects).
    Except for the code quality growing steadily worse. Refactoring is a thing to be encouraged, not "reined in". Of course, you still have to apply some common sense and not do a global change unannounced.
  • (cs) in reply to snoofle
    snoofle:
    I agree. If someone micromanages me (I had a boss who did something similar once), I let it go no more than twice. The third time, I drag them into a closed office for a "conversation", and if it persists, I go directly to their boss. If that fails, I leave - quickly.

    It's a shame most people won't take the same stance. We both know there's no shortage of incompetents, paranoids, and game-players out there who will fill the position.

    As we can see from the "protagonist" of the story, some people actually seem to enjoy this sort of thing. I can appreciate sarcasm as much as any other born smartass, but using it in a work related conflict like this is trwtf. Sounds like Carlos and Dave are made for one another.

  • (cs) in reply to brazzy
    brazzy:
    "Who's responsible?" is the wrong question. The right one is "How can we fix it and prevent it from happening again?". Any environment where assigning blame is considered important (beyond making sure the person responsible understands the error and will not repeat it) is not productive. Is the customer going to be any less annoyed about a delay or a bug in production just because you know whom to blame?

    Bravo.

  • (cs) in reply to Pat
    Pat:
    snoofle:
    And this, dear friends, is why you get directions/instructions in writing - so you don't have to take the fall for your superiors' incompetence!

    Exactly. Document everything or else it all trickles down to the guy at the bottom.

    It also helps during quality control so you don't have to piece together what you were doing weeks ago.

    Maybe; but I prefer Drugs and Violence. They seem to work for me. YMMV.

  • (cs) in reply to Asiago Chow
    Asiago Chow:
    Maybe if we all switch to Git life will be better...
    Nope; I sill prefer Drugs and Violence.

    I was having a conversation with an ex cow-orker the other day. He's in a new job. It's a Web Development job. They were using CVS.

    "It's all going to be better from now on," he enthused, "because the head office in Australia has mandated that they move to GIT!"

    "Read that back to yourself," I replied. "In any other field, saying that the solution is GIT would get you nothing but derision."

    "But GIT is good!" he burbled.

    "Why, precisely?" I asked. "Because Torvalds wrote it?"

    "Well, that, and the fact that it's the latest thing!. No more problems with CVS!"

    I forebore to mention that the problems weren't with CVS but with the sorry collection of Ocker half-wits using it. "Have they considered using Subversion?" I asked.

    "Oh no, that would take too long," he answered.

    "What, four minutes for the basic set-up, plus a guaranteed path to migrate your current repositories?" I asked.

    "But it's not GIT, is it?" By this time the phone was practically dripping with enthusiasm.

    ... six weeks later ... and my friend has faithfully written a shed-load of tests based on the shiny new GIT repository.

    "Ah no, mate," said the technical guy sent over to oversee the transition into production, "all that's about as much use as a pelican fart in a hurricane. All the code's in the CVS repository."

    Like I say: Drugs and Violence. Every time.

  • (cs) in reply to Stu
    Stu:
    I wonder if all of these people are really passive-aggressive, or if they just end up that way in the rewrites. It seems like 2/3 of the WTFs involve someone who knows there's a problem but fails to adequately communicate the problem.
    Exactly.

    No wooden table anywhere to be seen.

    It amazes me that, in this day and age, our proud academic institutions (and DeVry) are still churning out software engineers with such pitifully inadequate communication skills.

  • graygoat (unregistered) in reply to real_aardvark

    [quote user="real_aardvark"][quote user="Asiago Chow"] "Ah no, mate," said the technical guy sent over to oversee the transition into production, "all that's about as much use as a pelican fart in a hurricane. All the code's in the CVS repository." quote]

    If a butterfly flapping its wings caused the hurricane, I can imagine that a pelican fart could have serious consequences...

  • (cs) in reply to brazzy

    You forgot:

    C) There's a communication issue, but by documenting everything you make sure all the stakeholders are aware of what's going on. Process improves, everyone is happy.

    It happens, you know. Sometimes a phone conversation gets forgotten, or someone wasn't kept in the loop. By having an email list or something similar, there's a place to go to keep tabs on the change. Plus, you can always go back and find places for improvement later on (great for bonus or performance objectives).

    Carlos -should- document what Dave is requesting and make sure everyone on the project knows what's going on. That way when stuff breaks, the source is immediately identifiable. No snide comments during meetings required, and anyone's attempt to shift blame can be easily debunked.

    That said, there's only so much you can do to fix things and CYA. If management is unwilling to improve an obviously broken process, you might want to start shopping around. However, you have to make an attempt to fix it or it will never get better.

Leave a comment on “Tenacious Dave”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article