Won't RTFM!
-
Don't be dragged down by fixing his mistakes (unless your boss asks you to of course). As long as the boss won't do anything you can't win. Elaine :rose:
Trollslayer wrote:
Don't be dragged down by fixing his mistakes (unless your boss asks you to of course).
Agreed. Once you start covering for someone, they are no longer responsible.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
-
The Solution is: 1. Fix the problems 2. Suggest the solution to your boss "Fire him, because blah, blah, blah" 3. In the meantime "Be happy or cool with him." 4. Say good bay to the problems :-D
IVECINU wrote:
1. Fix the problems 2. Suggest the solution to your boss "Fire him, because blah, blah, blah" 3. In the meantime "Be happy or cool with him." 4. Say good bay to the problems
Ah if only office politics were that easy.... sometimes you have to let a company go out of business because thats what they are determined to do. Next best thing get another job for more money ;)
-
Mate, the amount of damage and havoc this guy could create, he'd need something a little bigger[^] :laugh::rolleyes:
0 bottles of beer on the wall, 0 bottles of beer, you take 1 down, pass it around, 4294967295 bottles of beer on the wall. Awasu 2.2.3 [^]: A free RSS/Atom feed reader with support for Code Project.
lol
Found on Bash.org [erno] hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is.
-
I'm fed up, what do I do? I'm working with a guy who won't RTFM!! I worked with him on another project and he will just start coding with no good knowledge of the device he's trying to write code for. When I ask him what the instrument does he says "I heard it will..." or "I think it will...". Many times I point out it doesn't work like he thinks, so he asks "how does it work?" I tell him to READ THE MANUAL (I leave out the F******). He comes back with he doesn't have time. :mad: In the end, other's (mainly me) has to fix his stuff. I complain to the boss who should be checking up on him and the boss says that we're short on head count so we need him. :mad: :mad: Actually, what's worse is when he doesn't RTFM and then "helps" others by fixing their code to operate the way he thinks it should work, WRONG! :mad: :mad: :mad: (BTW, he doesn't fix my code for me...any more) It takes longer to fix his screw ups than it takes him to screw up. He can screw things up pretty fast. (How many screw ups can a screw up screw up when he's really screwed up? :laugh:) Any Suggestions on what can be done?:confused: Joe Q
Joe Q wrote:
I complain to the boss who should be checking up on him and the boss says that we're short on head count so we need him.
This is a problem. Sounds like this programmer == -1 programmers. If someone has to fix his code continuously, then that means others aren't able to do the work they should be doing. If you take a team of 5 programmers and you add a -1 programmer, you get the output of a team of 4 programmers, which makes the bosses desperate not to let anyone done because you are behind schedule. But if the -1 programmer is released then you are back up to a team of 5 programmers, so you actually have a net gain. However, I never figured out how to explain that well to a manager.... hmmmmm Maybe if every programmer is his own department, five of which are operating a profit (in the black), then you add a new department that always operates at a loss (in the red), then you bring down the net worth of the company.... Whereas if you release the department that operates always in the red, then the company bottom line raises and the networth is actually greater than with the one loosing department....
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Joe Q wrote:
I complain to the boss who should be checking up on him and the boss says that we're short on head count so we need him.
This is a problem. Sounds like this programmer == -1 programmers. If someone has to fix his code continuously, then that means others aren't able to do the work they should be doing. If you take a team of 5 programmers and you add a -1 programmer, you get the output of a team of 4 programmers, which makes the bosses desperate not to let anyone done because you are behind schedule. But if the -1 programmer is released then you are back up to a team of 5 programmers, so you actually have a net gain. However, I never figured out how to explain that well to a manager.... hmmmmm Maybe if every programmer is his own department, five of which are operating a profit (in the black), then you add a new department that always operates at a loss (in the red), then you bring down the net worth of the company.... Whereas if you release the department that operates always in the red, then the company bottom line raises and the networth is actually greater than with the one loosing department....
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Jeffry J. Brickley wrote:
But if the -1 programmer is released then you are back up to a team of 5 programmers, so you actually have a net gain.
-1 on the bosses empire. Plus the guy would be released to another project and the boss would have to report that he released 1 guy, now we need 4 people instead of 3. On the guys resume, he sounds good because you don't put what you did wrong on a resume. It's to much to ask a lazy boss to go through all the justifications that would take.
Jeffry J. Brickley wrote:
However, I never figured out how to explain that well to a manager.... hmmmmm Maybe if every programmer is his own department,
Our company motto "One Company, One Team". We're suppose to be a team but it is more like an army squad dragging around a dead body.
-
The Solution is: 1. Fix the problems 2. Suggest the solution to your boss "Fire him, because blah, blah, blah" 3. In the meantime "Be happy or cool with him." 4. Say good bay to the problems :-D
IVECINU wrote:
The Solution is: 1. Fix the problems 2. Suggest the solution to your boss "Fire him, because blah, blah, blah" 3. In the meantime "Be happy or cool with him." 4. Say good bay to the problems
Except for #3 that's what we're doing. It just gets old.
-
Joe Q wrote:
no violence in the workplace" policy
Tell him you want to show him your new Aston Martin which is parked just of the workplace's property (if he asks why say more people'll see it there).
Ed.Poore wrote:
Tell him you want to show him your new Aston Martin which is parked just of the workplace's property (if he asks why say more people'll see it there).
Or there's invite him to a happy hour in the bad part of town. If he comes out of there, he's tougher than me.
-
Ed.Poore wrote:
Tell him you want to show him your new Aston Martin which is parked just of the workplace's property (if he asks why say more people'll see it there).
Or there's invite him to a happy hour in the bad part of town. If he comes out of there, he's tougher than me.
-
I'm fed up, what do I do? I'm working with a guy who won't RTFM!! I worked with him on another project and he will just start coding with no good knowledge of the device he's trying to write code for. When I ask him what the instrument does he says "I heard it will..." or "I think it will...". Many times I point out it doesn't work like he thinks, so he asks "how does it work?" I tell him to READ THE MANUAL (I leave out the F******). He comes back with he doesn't have time. :mad: In the end, other's (mainly me) has to fix his stuff. I complain to the boss who should be checking up on him and the boss says that we're short on head count so we need him. :mad: :mad: Actually, what's worse is when he doesn't RTFM and then "helps" others by fixing their code to operate the way he thinks it should work, WRONG! :mad: :mad: :mad: (BTW, he doesn't fix my code for me...any more) It takes longer to fix his screw ups than it takes him to screw up. He can screw things up pretty fast. (How many screw ups can a screw up screw up when he's really screwed up? :laugh:) Any Suggestions on what can be done?:confused: Joe Q
The overwhelming majority of programmers have no desire to learn about soft skills, strategy, or coping with office politics. They're only interested in coding, and deem these things to be either boring or beneath them. They'll complain loudly when they get screwed around by others, but ultimately they never bother to improve themselves in this area. Consequently, and perhaps not surprisingly, they continue to be victimized over and over again. But of course, its always someone else's fault when it happens. There are countless "manuals" in your local bookstore for dealing with people and situations like this. So then, suggestions on what can be done? Hmmm. Er, RTFM? :rolleyes:
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
-
I'm fed up, what do I do? I'm working with a guy who won't RTFM!! I worked with him on another project and he will just start coding with no good knowledge of the device he's trying to write code for. When I ask him what the instrument does he says "I heard it will..." or "I think it will...". Many times I point out it doesn't work like he thinks, so he asks "how does it work?" I tell him to READ THE MANUAL (I leave out the F******). He comes back with he doesn't have time. :mad: In the end, other's (mainly me) has to fix his stuff. I complain to the boss who should be checking up on him and the boss says that we're short on head count so we need him. :mad: :mad: Actually, what's worse is when he doesn't RTFM and then "helps" others by fixing their code to operate the way he thinks it should work, WRONG! :mad: :mad: :mad: (BTW, he doesn't fix my code for me...any more) It takes longer to fix his screw ups than it takes him to screw up. He can screw things up pretty fast. (How many screw ups can a screw up screw up when he's really screwed up? :laugh:) Any Suggestions on what can be done?:confused: Joe Q
Quit bailing his sorry ass out! There are plenty of scriptkiddies programmers who would happily take his job and do it better. Maybe you can work something out so they can do it part time, after school. I've written a bunch of instrument drivers in my time, and there is never any excuse for being anything less than an expert on the operation of each one. Perhaps you can recommend some advanced training[^] for him to make him more useful to everyone.
"...a photo album is like Life, but flat and stuck to pages." - Shog9
-
I'm fed up, what do I do? I'm working with a guy who won't RTFM!! I worked with him on another project and he will just start coding with no good knowledge of the device he's trying to write code for. When I ask him what the instrument does he says "I heard it will..." or "I think it will...". Many times I point out it doesn't work like he thinks, so he asks "how does it work?" I tell him to READ THE MANUAL (I leave out the F******). He comes back with he doesn't have time. :mad: In the end, other's (mainly me) has to fix his stuff. I complain to the boss who should be checking up on him and the boss says that we're short on head count so we need him. :mad: :mad: Actually, what's worse is when he doesn't RTFM and then "helps" others by fixing their code to operate the way he thinks it should work, WRONG! :mad: :mad: :mad: (BTW, he doesn't fix my code for me...any more) It takes longer to fix his screw ups than it takes him to screw up. He can screw things up pretty fast. (How many screw ups can a screw up screw up when he's really screwed up? :laugh:) Any Suggestions on what can be done?:confused: Joe Q
Well i've got the link to the full work place "accident" guide: http://theregister.co.uk/odds/bofh and how to cover up with good excuses hehe.
Real programmers don't comment their code. It was hard to write, it should be hard to understand.
-
Well i've got the link to the full work place "accident" guide: http://theregister.co.uk/odds/bofh and how to cover up with good excuses hehe.
Real programmers don't comment their code. It was hard to write, it should be hard to understand.
-
The overwhelming majority of programmers have no desire to learn about soft skills, strategy, or coping with office politics. They're only interested in coding, and deem these things to be either boring or beneath them. They'll complain loudly when they get screwed around by others, but ultimately they never bother to improve themselves in this area. Consequently, and perhaps not surprisingly, they continue to be victimized over and over again. But of course, its always someone else's fault when it happens. There are countless "manuals" in your local bookstore for dealing with people and situations like this. So then, suggestions on what can be done? Hmmm. Er, RTFM? :rolleyes:
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
Advice taken, I'll go RTFM. I'm not always good with wetware. I have heard others around here say all they want to do is code. It seems like they put out some of the worse code around here. If that's all they want to do, they should at least do it right. Thanks
-
Advice taken, I'll go RTFM. I'm not always good with wetware. I have heard others around here say all they want to do is code. It seems like they put out some of the worse code around here. If that's all they want to do, they should at least do it right. Thanks
One of the all time classics on getting the most out of your relationships with people is Dale Carnegie's "How to win friends and influence people." It's very readable, and once you finish it you'll probably be inspired to pick up other titles in the bookstore, according to your needs and personal taste. Unite the Tribes (below) also addresses human nature as well as focusing on strategy in the workplace, but I'd recommend reading Carnegie first. In my opinion, human nature (and therefore people) is one of the most predictable things in the universe. Once you understand how people work, you're in a much better position to control the situation. Best of all, since most programmers don't bother with this sort of thing, you will by definition have a standing tactical advantage in your career. :-D
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
-
One of the all time classics on getting the most out of your relationships with people is Dale Carnegie's "How to win friends and influence people." It's very readable, and once you finish it you'll probably be inspired to pick up other titles in the bookstore, according to your needs and personal taste. Unite the Tribes (below) also addresses human nature as well as focusing on strategy in the workplace, but I'd recommend reading Carnegie first. In my opinion, human nature (and therefore people) is one of the most predictable things in the universe. Once you understand how people work, you're in a much better position to control the situation. Best of all, since most programmers don't bother with this sort of thing, you will by definition have a standing tactical advantage in your career. :-D
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
Christopher Duncan wrote:
In my opinion, human nature (and therefore people) is one of the most predictable things in the universe. Once you understand how people work, you're in a much better position to control the situation.
You haven't met my ex-wife! :laugh:
