What is frustrating...
-
I have a list of things: Insane Managers --------------- 1) Unreasonable timelines made worse by an incomplete list of features, and the managers responsible for those timelines that are reluctant to alter the timeline in any way that doesn't include a reduction in the projected time required to finish the project. 2) Not having time to do the job right, settling many times for just "getting it to work" because management is on my ass because "the project is late". 3) Manager's insistance on using Microsoft Project, quite possibly the single worst package for managing a software development timeline. On a related note, there currently is *no* viable project management program that caters to software development. As all of us here know, software isn't developed in a linear fashion. It's developed by jumping around and doing something because "it's time to work on that part now", or because "I've hit a technical/functional stopping point and I'm waiting for an answer, but I don't want to sit here slappin' around ol' Mr. One-Eye in the meantime". Every project I've been on has a start date, with a given number of work hours added on, and an end date. The dates in between don't really matter, but MSP is too stupid to realize it. 4) Managers who insist on using SourceSafe "because it's free". 5) Being told I can do it the way I want it, only to be told later that's not what they wanted. 6) Political correctness - do they want me to run for freakin office, or do they want me to write code? Insane/Moronic Programmers (and/or Team Leads) ---------------------------------------------- 1) Lack of flexibility in class implementations by other programmers - it seems some folks have never heard of function or operator overloading. 2) Illogical refusal to use MFC because it "requires too much overhead" (mostly seen in COM projects), despite the fact that it would save hours and hours of time. 3) Other team members that don't adhere to posted coding standards, or that refuse to use the version control software in a way that prvents loss of code. 4) Team members who change my code without first asking why it exists in its current form. When I want to change someone's code, I usually *overload the function* as a work-around until the other programmer and I can sit down and discuss it. 5) Unreasonable refusal to have *ANY* global functions (every function call has to be in a class) or variables. There are times when a global variable or two are just plain handy to have and it makes sens
Congrats to you on how well you have put it. :) :cool: Farhan
-
the age-old struggle between marketing and programming: marketing sells things that don't exist and expects programming to cover for them. -c ------------------------------ Smaller Animals Software, Inc. http://www.smalleranimals.com
Well we fixed this problem, we built a new version of an application (with WTL) and then showed it to marketing. They liked it and have a copy on their desks to use as a reference for writing up the specs for the "new" system. Steve Maier, MCSD
-
Good Morning, Talked to a guy that said the most frustrating part of his job was the paperwork to do anything. What is your frustration on the job? Better yet, if you could change something about your job, what would it be? Scott! Put the big rocks in the glass jar first!
I once threatened to stick a fork in a co-workers forehead if he ever again changed my code without asking me first. I was the Team Lead and corporate "old guy", and everyone took me at my word. One day, a customer called (I was doubling as tech support and programmer). I answered his question and then told (quite nicely I might add) him that the answer to that question was on page xyz of the manual. He went ballistic and threatened to kick my ass, and invited to Ohio (I was in San Diego at the time) so he could facilitate the threat. After vigorously tossing the phone into the hallway, I went in and asked the guy's sales rep for his mailing address, and left a note on my abused telephone handset that I was on my way to Ohio and that I'd be back in a day or so (in the note, I didn't mention why I was going). Well, I was on my Harley and just pulling out of the parking spot on my way to the airport when the boss came running out the door to stop me. It seems this guy had called my boss and complained about my "attitude" and had admitted that a threat of physical violence had been offered. My boss went to my office to find the note on taped to what was left of my telephone and knew what I had in mind. It took her almost 30 minutes to "talk me down". The guy never called for support again (at least I never heard about it), but he kept using our software. To this day, I'm sure he doesn't know how close to severe injury he truly came. If the boss had been a bit slower on the winding stairwell from the 4th floor to the parking lot, I'm sure I'd be in jail today. :)
-
I once threatened to stick a fork in a co-workers forehead if he ever again changed my code without asking me first. I was the Team Lead and corporate "old guy", and everyone took me at my word. One day, a customer called (I was doubling as tech support and programmer). I answered his question and then told (quite nicely I might add) him that the answer to that question was on page xyz of the manual. He went ballistic and threatened to kick my ass, and invited to Ohio (I was in San Diego at the time) so he could facilitate the threat. After vigorously tossing the phone into the hallway, I went in and asked the guy's sales rep for his mailing address, and left a note on my abused telephone handset that I was on my way to Ohio and that I'd be back in a day or so (in the note, I didn't mention why I was going). Well, I was on my Harley and just pulling out of the parking spot on my way to the airport when the boss came running out the door to stop me. It seems this guy had called my boss and complained about my "attitude" and had admitted that a threat of physical violence had been offered. My boss went to my office to find the note on taped to what was left of my telephone and knew what I had in mind. It took her almost 30 minutes to "talk me down". The guy never called for support again (at least I never heard about it), but he kept using our software. To this day, I'm sure he doesn't know how close to severe injury he truly came. If the boss had been a bit slower on the winding stairwell from the 4th floor to the parking lot, I'm sure I'd be in jail today. :)
-
Oh god - remind me to never call you for Tech Support! That was funny. I've had that desire myself many a time.:-D Phil Boyd MCP "I took the road less traveled..."
I've since mellowed out quite a bit. :) I find that I have barely enough energy for a heart-felt "Bite Me!" before throwing the phone out into the hall. Besides, it's a lot tougher nowadays to get an airline ticket to *anywhere* on a spur of the moment like that. :)
-
Good Morning, Talked to a guy that said the most frustrating part of his job was the paperwork to do anything. What is your frustration on the job? Better yet, if you could change something about your job, what would it be? Scott! Put the big rocks in the glass jar first!
When every time you finish something to spec the specification changes, to the point that you sometimes spend a weekend rewriting the framework to properly support new stuff to be added without it being obviously bolted into a totally different design. Christian The content of this post is not necessarily the opinion of my yadda yadda yadda. To understand recursion, we must first understand recursion.
-
I've since mellowed out quite a bit. :) I find that I have barely enough energy for a heart-felt "Bite Me!" before throwing the phone out into the hall. Besides, it's a lot tougher nowadays to get an airline ticket to *anywhere* on a spur of the moment like that. :)
Gee Glad to hear you "mellowed out quite a bit". Regardz Colin
-
I once threatened to stick a fork in a co-workers forehead if he ever again changed my code without asking me first. I was the Team Lead and corporate "old guy", and everyone took me at my word. One day, a customer called (I was doubling as tech support and programmer). I answered his question and then told (quite nicely I might add) him that the answer to that question was on page xyz of the manual. He went ballistic and threatened to kick my ass, and invited to Ohio (I was in San Diego at the time) so he could facilitate the threat. After vigorously tossing the phone into the hallway, I went in and asked the guy's sales rep for his mailing address, and left a note on my abused telephone handset that I was on my way to Ohio and that I'd be back in a day or so (in the note, I didn't mention why I was going). Well, I was on my Harley and just pulling out of the parking spot on my way to the airport when the boss came running out the door to stop me. It seems this guy had called my boss and complained about my "attitude" and had admitted that a threat of physical violence had been offered. My boss went to my office to find the note on taped to what was left of my telephone and knew what I had in mind. It took her almost 30 minutes to "talk me down". The guy never called for support again (at least I never heard about it), but he kept using our software. To this day, I'm sure he doesn't know how close to severe injury he truly came. If the boss had been a bit slower on the winding stairwell from the 4th floor to the parking lot, I'm sure I'd be in jail today. :)
You are my hero...:rose: Christian The content of this post is not necessarily the opinion of my yadda yadda yadda. To understand recursion, we must first understand recursion.
-
Good Morning, Talked to a guy that said the most frustrating part of his job was the paperwork to do anything. What is your frustration on the job? Better yet, if you could change something about your job, what would it be? Scott! Put the big rocks in the glass jar first!
All those Java programmers (and C++ to Java "converts") who got brainwashed into not needing to care about memory. When later they are required to write some C++ code (example: a bridge to their Java code from a C++ app), they just "new" their way through the code which amounts to like a few KB of memory leaked everytime those code are executed. Now we have to clean all that up...
-
I have a list of things: Insane Managers --------------- 1) Unreasonable timelines made worse by an incomplete list of features, and the managers responsible for those timelines that are reluctant to alter the timeline in any way that doesn't include a reduction in the projected time required to finish the project. 2) Not having time to do the job right, settling many times for just "getting it to work" because management is on my ass because "the project is late". 3) Manager's insistance on using Microsoft Project, quite possibly the single worst package for managing a software development timeline. On a related note, there currently is *no* viable project management program that caters to software development. As all of us here know, software isn't developed in a linear fashion. It's developed by jumping around and doing something because "it's time to work on that part now", or because "I've hit a technical/functional stopping point and I'm waiting for an answer, but I don't want to sit here slappin' around ol' Mr. One-Eye in the meantime". Every project I've been on has a start date, with a given number of work hours added on, and an end date. The dates in between don't really matter, but MSP is too stupid to realize it. 4) Managers who insist on using SourceSafe "because it's free". 5) Being told I can do it the way I want it, only to be told later that's not what they wanted. 6) Political correctness - do they want me to run for freakin office, or do they want me to write code? Insane/Moronic Programmers (and/or Team Leads) ---------------------------------------------- 1) Lack of flexibility in class implementations by other programmers - it seems some folks have never heard of function or operator overloading. 2) Illogical refusal to use MFC because it "requires too much overhead" (mostly seen in COM projects), despite the fact that it would save hours and hours of time. 3) Other team members that don't adhere to posted coding standards, or that refuse to use the version control software in a way that prvents loss of code. 4) Team members who change my code without first asking why it exists in its current form. When I want to change someone's code, I usually *overload the function* as a work-around until the other programmer and I can sit down and discuss it. 5) Unreasonable refusal to have *ANY* global functions (every function call has to be in a class) or variables. There are times when a global variable or two are just plain handy to have and it makes sens
1) Lack of flexibility in class implementations by other programmers - it seems some folks have never heard of function or operator overloading. Also the converse. Sometimes too much overloading is bad news. Sometimes you would be better off with a different more descriptive function/method name rather than an overload implying what you are trying to do. I haven't seen this problem many times, but when you do see it...usually in very deep class hierarchies. Of course everytime I've seen this problem there have been no comments, no documentation etc, so you have to guess why it was done the way it was done... Stephen Kellett
-
All those Java programmers (and C++ to Java "converts") who got brainwashed into not needing to care about memory. When later they are required to write some C++ code (example: a bridge to their Java code from a C++ app), they just "new" their way through the code which amounts to like a few KB of memory leaked everytime those code are executed. Now we have to clean all that up...
