Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

No respect for developers

Status
Not open for further replies.

mi294r3

MIS
Dec 2, 2002
31
US
I work for a large company. I have been involved in many large projects in my time here. One thing that I have seen happen over and over with these projects is months of analysis followed by a rush to develop. During this analysis, assumptions are made by non-technical people, or at best slightly technical people. When these assumptions prove false developers are asked to “code-around” the design flaws instead of insisting on a design change. Of course this cycle usually ends up with extended project time-lines and bloated budgets. There is little effort from management to allow activities such as prototyping or “proof of concept” to run in parallel with analysis/design. Some of the non-technical management believes that if they assign a task to a plan that development happens “auto-magically” or at least proceed along as if development is just an after thought. To me it comes down to a lack of respect for what developers do. I guess to “bottom-line” it, it does have effect on the bottom-line.

What do you think?
JRjr
[morning]
 
Of course, don't you know as a developer you should be able to read other's thoughts? Also personally I'd be lost without my crystal ball, version 2.3 at the moment, invaluable!

Seriously though, it can take it's toll on you, knowing that time and again, the same thing will happen. What you have to figure out is, are they not learning from their mistakes or are you not learning from their mistakes??

Patrick

"It works in practice, now we have to figure out if it works in theory?
 
I know it is easier said than done, but document, document, document. At the very least keep a hardcopy journal of "who said what", what you did, and what you had to redo with dates and times. Attach pertinent memos & emails. It will become your CYA tool.

If you can find a sympathetic ear in management, present a summarized version that focuses on time/money lost due to "Ready-Fire-Aim" development (pick your time carefully). If not, consider whether you want to continue working for this company since burnout may become inevitable.

It may have more to do with the pressure to produce quickly than an attitude towards developers. We are the casualties of this type of methodology, not the targets.

[sup]Beware of false knowledge; it is more dangerous than ignorance.[/sup][sup] ~George Bernard Shaw[/sup]
Consultant Developer/Analyst Oracle, Forms, Reports & PL/SQL (Windows)
My website: Emu Products Plus
 
I agree with what has been said above but

I have found that even if you keep the documentation that proves that you raised the issues, that you issued the warnings, that you stated the risks, you as a developer will still be deemed to be guilty.

Documenting other people's flaws especially if you they are those of more senior people means that you are not a team player, you are not to be trusted, you are a dangerous subversive.

Forget about being good at the technical stuff - practice your people skills:

toady to your superiors, bully your subordinates and take every opportunity to undermine your peers - then you too shall go to the Ball.
 
SteveGlo,
In no way did I intend the documentation to be a finger-pointing or blame-assigning mechanism, however I agree it could be used that way. I simply like to be able to document the "hows & whens" of a project.

That being said, I think I am glad I do not work with you! [wink]

[sup]Beware of false knowledge; it is more dangerous than ignorance.[/sup][sup] ~George Bernard Shaw[/sup]
Consultant Developer/Analyst Oracle, Forms, Reports & PL/SQL (Windows)
My website: Emu Products Plus
 
BJ

No worries - just my sour old take on things.

I am always going on about the absence of documentation because I was once trained in the Document Inspection method and I am totally convinced of its value as an aid to making life easier in the long run.

Unfortunately everyone I have worked for hates the idea because it makes it too hard to disguise how awfully bad things generally are and undoubtably there are a lot of start up costs of implementing it.

I'm lucky in that I am a more or less tolerated maverick and close enough to retirement not to be threatened but I do sympathise with people who are in not such a pleasant position.

I have noticed that everyone moans about management - even senior managers moan about management!

Steve
 
I've heard 2 conversations in few years that can be applied here even jobs are not similar at all.

One manicurist was complaining about her clients who will not 'let' her take vacation or get sick because they can't BE without manicure for so long. This is why she worked for 10 years without vacation and this was one of many complains she had about how 'they' making her life living h**l and how she would like to have it change but business is good and blah blah blah.

One lady was complaining about her manicurist who will punish her clients for being late by making them take their polish off by themselves (if 10 min late) or wait untill closing (if more then 10 min late), taking long vacations and never letting them know when. Talking about her 'stuff' during 'manicuring' and being oblivious to the client's problems and wanting to talk...

See what I am saying?
ATTITUDE and SELF RESPECT rule the world!

P.S. I was laughing thinking it was the first manicurist who went ballistic after 10 years of slaving without vacation...LOL
 
Forget about being good at the technical stuff - practice your people skills:

Maybe we should place ourselves more often in the "enemy" shoes, and try to figure out what is expected from us.
If you were management, would you hire an employee like yourself?

Making mistakes is part of human nature, blaming others is the rule...

Steven
 
Forget about being good at the technical stuff ???
Not a good advise, not a good one. 'Nice guy' job doesn't pay a squad. I know.
 
If I look back at my own past, I must have been a real pain in the @hum, neck [thumbsup], must have stepped on a lot of sore toes, but I guess somehow they tolerated me.

Steven
 
If you find yourself in the situation where you get the blame for other people's mistakes, the methodology for software development is inherently flawed and any attempts at making this visible or bringing changes about is rebuked, I'd say it's high time to start polishing up that resume. If this is how they prefer to do business, wouldn't it be in your own best interest to find a place that *does* care about getting things right?


"Any fool can defend his or her mistakes; and most fools do." -- Dale Carnegie
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top