• (cs) in reply to Staz

    Source control, no matter what you use, is just a tool. It's only as good as the people who are using it.

    When people check in broken code (either by choice or coercion), it creates problems. Worse yet is when people don't check in code changes and someone else comes along and starts working from the "latest version" in the repository.

    Of course, the source control isn't the WTF here. It's the fact that Dave is screwing Carlos over. The forced code checkins are just a means to an end. As I said previously, it's time for Carlos to "fix the process" (read as set Dave up for a fall) by documenting what and when Dave suggests something and whether it's implemented or not. Either management will figure out Dave's a crock of alligator dung, or Carlos will realize that the whole company's a mess and have just cause to get out.

  • EatenByAGrue (unregistered) in reply to pglewis
    pglewis:
    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.

    The problem is that the answer to "how can we prevent it from happening again?" sometimes is "fire the person responsible". Even if that isn't the solution, you can bet that someone who is getting blamed for fiascos is not going to be the person who does well when it's time to decide who's getting a promotion, bonus, or raise. So it is advantageous for any individual who can assign blame elsewhere to do so, even though it's a disadvantage for the organization.

  • Zap Brannigan (unregistered) in reply to m_talon

    I'll try not to be so pithy with this comment. If you find yourself in a work situation where you have play CYA a signification percent of the time, leave. Life's too short.

  • Asiago Chow (unregistered) in reply to brazzy
    brazzy:
    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.

    We agree on what constitutes well designed code and you'll have to take my word for it when I say that you've made an unsupported leap in blaming the code. As for the modus operandi, to me that's closely tied to people. I'm pretty sure I was advocating frequent check-ins for the same reason you just did: because they reduce conflicts. So we're on the same page there. I just see a value in locking for small teams.

    What I have seen, and you can blame what you like but I have seen it in multiple shops with multiple code bases in multiple languages, is that non-locking revision control allows sloppy practices that result in merge problems more often than not. Those merge problems don't go away in larger projects (or with larger teams) but they are less avoidable. When you have three or four coders working on a moderate project (which means it has 30-300 files depending) you can get away with serialized access that would be unsustainable when you have 100 coders working on a code base with 3000+ files.

    I get to see it constantly with another division of my employer. I write code that interfaces to theirs so I get to watch their efforts without being an insider. They have dug themselves into a pit where they have a deployed version they are supporting, two subsequent releases going through QA concurently, plus a third future version in development, which means they are constantly propegating changes up and down four $&#*ing versions.

    And they use non-locking source control.

    And for a while it was literally every couple of weeks that someone would pull all the latest files and start changing one to update a feature while her coworker pulls all the latest files and starts changing the same file to shift a bug, err, bug fix, around... and by the time they are done both are marked done in the project management suite and only one of them is actually present in the code base. Then QA would find it in their testing again and it would become a big issue again.

    Yeah, there are a lot of problems there... but I can't control whether someone gets so far ahead, or behind, themselves that they are shuffling code across four releases constantly. Maybe it could happen to you or I too. I can observe that a great deal of trouble would've been saved by using a locking repository and frequent "micro" checkins.

    brazzy:
    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.

    Humm.... well, that's a perspective. Have you worked with many Refactorers? I'm not talking about programmers who refactor code...hopefully we all do that...I'm talking about big-R Refactorers. I have. If you don't rein them in you will definitely see the quality of your code grow steadily worse. Especially if you have dueling refactorers... two people with different esthetic standards and the total belief that their way is the best.

    It is part of the nature of Refactorers to make changes unannounced. Maybe it's their version of being nice... Why would you embarrass people by announcing that you had to change their code again? Or maybe they are tired of getting pummeled in the halls because they went and rewrote some perfectly good code yet again because they didn't like the variable names or they thought using a different approach might be more efficient.

  • Franz Kafka (unregistered) in reply to Asiago Chow
    Asiago Chow:
    And for a while it was literally every couple of weeks that someone would pull all the latest files and start changing one to update a feature while her coworker pulls all the latest files and starts changing the same file to shift a bug, err, bug fix, around... and by the time they are done both are marked done in the project management suite and only one of them is actually present in the code base. Then QA would find it in their testing again and it would become a big issue again.

    Sounds like you have some cow not resolving their changes before checking in and stomping over the other guy. This isn't a problem with the VCS, it's a problem with asshole coworkers

  • (cs) in reply to m_talon
    m_talon:
    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.

    That's actually case A), i.e. a piss-poor excuse for proper requirements/workflow management. Sure, requirements, change requests and the like start out as something someone said in a meeting or wrote in an email. But if it is important enough to require coordination (i.e. is not something you can just trust the other guy to do right away), then it should go into a ticket system or a proper requirements document.

  • Group29 (unregistered)

    This story has the most uncomfortable payoff of any WTFs I have read in the last year. Developer gets shaft and management goes on lying. I suppose even the Washington Generals get to win once in a while. There has to be a Tenacious Dave part II.

  • (cs) in reply to Asiago Chow
    Asiago Chow:
    brazzy:
    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.

    We agree on what constitutes well designed code and you'll have to take my word for it when I say that you've made an unsupported leap in blaming the code.

    I'd hope that this LCD isn't your only perspective on what constitutes well designed code.

    As for unsupported leaps (and, code not being represented here, it's difficult to envisage any other kind of leap), may I quote:

    Asiago Chow:
    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.

    Indeed.

    We are all at fault, but society^Wprocess is to blame.

  • katastrofa (unregistered)

    Carlos was a wimp. Why didn't he point his finger at Dave?

  • (cs) in reply to real_aardvark
    real_aardvark:
    our proud academic institutions (and DeVry)
    I lolled.

    Then I gagged.

    When I was finished lollygagging, I got back to work.

  • (cs) in reply to real_aardvark
    real_aardvark:
    "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."

    For full comedic effect, sound this out in a very thick Australian accent.

    As for Carlos and Dave: thank you, gentlemen, for making me appreciate my job all that much more. The worst I've really had is the occasional design change at a code review.

    How do these companies function with this kind of stuff going on?

  • An Old Hacker (unregistered) in reply to Asiago Chow
    Asiago Chow:

    ...

    Lots of stuff about the joys of file locking

    ...

    Yep, and then someone goes on vacation without doing "ci". Now what? No, I did not bug the sysadmins. I executed cp, rn, chmod. You are presuming a management failure at a very basic level, and prescribing a solution that involves attempting to force the responsibility on the poor vcs.

    If you have two different developers working on the same bits of code at the same time without coordinating, your problem is NOT in your vcs.

  • (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!

    Get everything in writing, period. You also don't get blamed for the helpdesk guy's incompetence, the client's incompetence (so what if we coded what you asked, not what you wanted, pay up) and you don't have to spend days arguing about who said what. You just provide the email log.

    It's so easy to say "Sounds great, could you email me that? I'm a bit busy right now." If countered with a "Uh, I don't have time to write that down", just "in your own time" and "Are you sure you talked to me about that? I can't remember... did you email me?" later.

  • Mathew (unregistered) in reply to Ren
    Ren:
    It's so easy to say "Sounds great, could you email me that? I'm a bit busy right now." If countered with a "Uh, I don't have time to write that down", just "in your own time" and "Are you sure you talked to me about that? I can't remember... did you email me?" later.
    One could also record their phone calls and even conversations. At least where I live it's legal even without permission from other party (although not necessarily polite). Then it's just matter of archiving the audio file in the self created ticket :D
  • Jiffy Whipper (unregistered)

    LOL, Dude Dave just like totally ROCKS. I love Dave.

    Jiffer www.anonymize.us.tc

  • Jeltz (unregistered) in reply to no way
    no way:
    The TRWTF is that the word "people" is always spelled as singular if definite article was not mentioned.

    Um, that rule about "the" is incorrect.

    The "people" that we can give a plural s means a body of humans sharing a common culture.

    People that can beFor example "Many different peoples have lived in Palestine." and "In the post-colonial period, the concept of specific indigenous peoples within the African continent has gained wider acceptance, although not without controversy." are correct uses of the word in its plural form.

    I have probably made a bunch of grammatical errors of my own in this post, but I don't claim they follow any specific rule -- just me not being a native English speaker.

  • Jorgey Porgey (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!

    very true. if any time you disagree, just jot it down what they said and tell them that you disagree, and why, and you have the paper to show later that it wasn't your idea

  • Dan (unregistered)

    The RWTF is that Dave couldn't check source control to see if Carlos had checked anything in. It would have been easy for Carlos to say yes and that he's moved on to the next thing. Repeating this process Dave would probably report that the twenty month project was done, in a bout a week. When someone else comes to ask Carlos, they get the truth about where he's at, and that he had told Dave the same thing. Carlos doesn't understand why Dave would say something else.

  • Asiago Chow (unregistered) in reply to real_aardvark
    real_aardvark:
    Asiago Chow:
    brazzy:
    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.

    We agree on what constitutes well designed code and you'll have to take my word for it when I say that you've made an unsupported leap in blaming the code.

    I'd hope that this LCD isn't your only perspective on what constitutes well designed code.

    Yawn.

    Is it yours?

    real_aardvark:
    As for unsupported leaps (and, code not being represented here, it's difficult to envisage any other kind of leap), may I quote:
    Asiago Chow:
    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.

    Indeed.

    We are all at fault, but society^Wprocess is to blame.

    Hum.... OK, let's try this again.

    Carlos pissed Dave off. Dave was trying to spike Carlos. Carlos (or his proxy) wrote up a one-sided story about how Dave was making absurd demands (like frequent check-ins, though that isn't necessarily absurd so he lost some credibility points there) and changing requirements/presenting Carlos's work and statements in a way that made Carlos look bad.

    Sounds like Dave is a bad person...but nobody is blameless in this world and it is very likely that Carlos contributed to the problem. Without more information it is impossible to rule out the possibility that Carlos caused the whole thing by ignoring some common convention of that workplace. Even if he didn't cause the whole thing you've got to ask how Carlos could have avoided the really nasty bad blood that seems to have developed between him and the Dave character.

    Was that direct enough for you?

    And yeah, asshole cows sums up a lot of what I deal with. :)

  • soru (unregistered) in reply to An Old Hacker
    If you have two different developers working on the same bits of code at the same time without coordinating, your problem is NOT in your vcs.

    A lock is an automated way of sending the message 'we need to talk if you want to change this file right now'.

    You could handle that manually instead, but if you can spare intelligent management attention to make up for the shortcomings of your tools, you must have a pretty unusual surplus of that generally rare quantity.

    A good vcs system should support both branching and locking, and the interactions between them. You need to lock within a branch, and you need to be able to retroactively move that lock to an ad-hoc sub-branch to manage the cleanup work when someone leaves something half-done and locked locked and goes to Denmark.

  • Asiago Chow (unregistered) in reply to An Old Hacker
    An Old Hacker:
    Asiago Chow:
    Lots of stuff about the joys of file locking

    Yep, and then someone goes on vacation without doing "ci". Now what?

    You work around the lock (e.g. by using concurrent checkouts or telling the version control system to undo the checkout) and bitch slap the guy into next Wednesday when he gets back from vacation.

    This ain't rocket science, people...mistakes don't blow up Scotty's ashes.

  • JimBob (unregistered) in reply to configurator
    configurator:
    The word peoples' is spelled correctly, because it is not a plural but a possessive, meaning the s should in act be there.
    You're looking for "people's" there, configurator.
  • (cs) in reply to Group29
    Group29:
    There has to be a Tenacious Dave part II.
    There is; this is it. Note the haiku-like ditty that started this whole sordid affair:

    When we last met Dave He was all about keeping Things on the fast track.

  • (cs) in reply to Code Dependent
    due to screwed up merges

    That only happens when whomever does the merge doesn't run the tests after merging, before committing. If someone does that more than once, you have a people problem, not a tool problem.

  • Dracolith (unregistered) in reply to Zap Brannigan

    Then the organization will have to adapt to your rich personal tradition of having a clear record of every important communication.

    Communicating something orally doesn't mean you get to not put a note about it in writing.

    Unless it is so absolutely trivial as to be obvious that such communication would have occured.

    (No need to document hello/goodbyte/brief personal chatter unrelated to the business that doesn't involve either party being responsible for doing something)

  • (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. ...
    And I typically work with just one other person these days, but I still find it handy to have non-locking checkouts and merges - especially on stuff like CSS files, website-wide menu files, and HTML-heavy pages.

    Horses for courses, as long as what you're doing works and everyone plays along.

  • (cs) in reply to Carlos's Coworker
    Carlos's Coworker:
    ...

    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. ...

    That's a build management problem, not a check-in problem. If you have an environment like that, with constant check-ins, you need builds based on checkpoints (like, say, a specific SVN revision, or a tag reflecting build status). This requires tighter focus on what revisions will build, and a better manager than Dave sounds like.

    Alternatively, if you have an environment where the checked-in code must build, then check-ins should be delayed until it compiles. This requires that Dave stays the fsck away from developers until they can show that their code builds. It also can lead to lost code, because check-ins can be too far apart to allow developers to check-in partly completed changes that allows them to undo their next edits if they need to.

    Either way, Dave is a hindrance to the process!

  • RogerRamjet (unregistered) in reply to WhiskeyJack

    Exactly...

    Plus it gives them a chance to catch the situations early when you've misunderstood Y as doing X, or they've explained X when really meaning Y...

  • eric76 (unregistered) in reply to pglewis
    pglewis:
    As we can see from the "protagonist" of the story, some people actually seem to enjoy this sort of thing.
    I occasionally take perverse enjoyment in pushing someone's button. That can apply outside of work as well as inside work.

    For an outside of work example, I used to play volleyball on Sunday afternoons for fun. There were a few ultracompetitive types that played with us on occasion, but for the most part, it was just a friendly game.

    One Sunday, one of the most competitive players was right behind me in the rotation. I was never very good at digging a hard hit ball (actually, pretty pathetic), especially if it was to the side. So he told me that anything that was to my right in the back row was his.

    I ignored him a few times and went for it anyway and he just got madder and told me it was his. I finally agreed to let him have anything to my right.

    Sure enough, the next ball over the net came just barely to my right so I stood there and watched it go by and then said "I thought you were going to get that."

    A couple of serves later, and one came right at me. I did the most logical thing -- I stepped to my left and said "Yours".

    I never saw that player again.

  • Levi (unregistered)

    As far as I'm concerned, no change occurs without an email.

  • Tom (unregistered) in reply to snoofle

    Or clients for that matter.

    This is exactly why we have switched to an issue management system that tracks email communication AND we only accept tasks or changes that were communicated through email.

  • Matt (unregistered) in reply to configurator
    configurator:
    The word peoples' is spelled correctly, because it is not a plural but a possessive, meaning the s should in fact be there.

    Or more accurately, it's a plural possessive, but we all knew what you meant :P.

  • itsmo (unregistered) in reply to brazzy
    brazzy:
    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?

    If only it were ever so - anytime I start at a new place if they tell me that they have a 'no blame' culture, I always think - 'well whose fault is that?'

  • Coder (unregistered)

    Reminds me of working at the Conan project.

  • YAGrammarNazi (unregistered) in reply to configurator
    configurator:
    The word peoples' is spelled correctly, because it is not a plural but a possessive, meaning the s should in fact be there.

    Yes, it's a possessive, and yes, the "s" should be there, but the apostrophe is misplaced - the sentence could be written "...at the desks of people...", so it should be "...people's desks...".

  • m0ffx (unregistered)

    So did you check in your comment for this article yet?

  • Anon (unregistered) in reply to Franz Kafka

    But heaven help you if you want to move a file that someone else is editing. Without silently getting two copies of it, that is...

  • Gorfblot (unregistered) in reply to Asiago Chow

    [quote user="Asiago Chow"]

    Sounds like Dave is a bad person...but nobody is blameless in this world and it is very likely that Carlos contributed to the problem. Without more information it is impossible to rule out the possibility that Carlos caused the whole thing by ignoring some common convention of that workplace. Even if he didn't cause the whole thing you've got to ask how Carlos could have avoided the really nasty bad blood that seems to have developed between him and the Dave character.[quote]

    In my opinion, correct. Based on the data only contained in this story- Dave doesn't share the credit for the work when he thinks it is correct. If Carlos helped, then before Dave is told the solution is wrong, sharing the credit would be expected.

    Why does Dave expect Carlos to take the blame once the solution is revealed as incorrect, when Dave wasn't willing to share the credit?

    Starting the explanation of the solution with "Dave noticed that some of the older systems seem to differ in their message handling, so I'm proposing this..." would give credit where credit is do if the solution is correct, and allow blame to fall where it is due if not.

    Knowing niether party, and only having access to this story, that's where I suspect the bad blood came from.

  • BTM (unregistered) in reply to snoofle

    Hear, hear!

  • ThisIsMe (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!

    Uh, can you send me an e-mail for that, please?

    Thanks! :)

    PS Captcha: transverbero ... what the h*** does that mean? some type of verb in transition to ... something more overbearing? ;)

  • Sijin (unregistered)

    I might be minority opinion here but who's the really incompetent guy here? Dave seems to be an expert at people manipulation which serves his interest the best! The programmer who doesn't know basic strategies for dealing with this kind of a boss is the real wtf! A newbie maybe.

  • phoet (unregistered)

    i cant believe that such things happen in real life. stories are getting boring recently.

  • (cs) in reply to Walleye
    Walleye:
    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.

    Well My boss is a Raptor and his boss is a primitive fish with legs! and his boss's boss is a single celled organism!

  • Cybercat (unregistered)

    I think I may have lost my cool in that meeting, gotten my bike lock, and smashed Mr. Dave in the face until his teeth were mostly in the form of ground powder. Then I would have demanded a raise for eliminating 90% of the non-productivity in the office and freeing up what was probably about $100,000 in salary.

    CAPTCHA: vindico! (like vindication? IRONIC!)

  • Global Warmer (unregistered) in reply to brazzy
    brazzy:
    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

    Well I hate to tell both of you rookies, but you need to get out in the real world and work with real people. Most projects are not as perfect as the ones you guys have apparently worked on. And all coworkers are not as honest and straight forward as your coworkers.

  • John (unregistered) in reply to snoofle

    This is why you go back to HR, or the VP and CEO and explain to them that they have a management problem. Any company worth working in will be thankful to hear what you have to say.

  • Dave (unregistered)

    Ahh, I'm going to need you to go ahead and check in the code for that change. So if you could go ahead and check in your code, that would be terrific, mmmK?

  • Fall Guy (unregistered) in reply to snoofle

    I wish. The managers that are incompetent make sure NEVER to give anything in writing so they have plausible deniability. If you have some magical trick to get all requests in writing, I'd love to hear it.

  • Rob (unregistered)

    Cool - just shoot me an email to that affect. Thaaanks.

  • Snow_Cat (unregistered) in reply to snoofle

    This is why I used to carry a cassette recorder;

    At my first job I had many bosses with conflicting instructions, and extremely poor comprehension skills; each with the same authority to completely override my decisions and 'fine' my pay for offenses (insubordination was a favourite). And each demanded written hourly reports from me, but never provided written instructions.

    On more than one occasion each made an undocumented change or physically destroyed months of work in my domain of responsibility or scapegoated me for their boneheaded mistakes in other areas.

    Eventually I started recording any time they approached, and eventually I ran out of recorders for them to break when they reproached.

    The benefits pacakge was awesome though; I recieved full-dental, medical, perscription, glasses, phone-allowancee, tranport, housing, etc... until three years ago, or nine years after I escaped.

Leave a comment on “Tenacious Dave”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article