What other answers would you put in there, Jeff? Thanks.
Heh... Like what? There's no magic fix, no instant answers to such problems and all of the fixes take time, extreme knowledge, and a whole lot of determination... sometimes, it takes a hell of a lot of risk on your part if you believe in either the company or the people you work for.
Unless you can show management the ROI of doing things more wisely, it will continue to be a problem... the big problem is that management frequently knows the cost of everything and the value of nothing. Sometimes, it simply takes a server meltdown and someone with the nads to step up and say "I know how to fix that" and then do it.
For those who've gotten tired of "the fight", I feel for ya and I've almost (but not quite) been there. Sometimes, management borders on the fringes of absolute ignorance about quality code and it's tempting to just give up. You either have to "re-muster the fight" in you, leave, or be satisfied with being a code drone. I've never
done the 3rd and never will, although I have learned which battles to fight and when to leave. Remember that the managment you may be fighting against also have bosses they
must answer to. Let them do their job and you do yours... help them if you can.
It doesn't have to be a "fight" so much as recognizing or even seeking out an "opportunity"... sometimes you can just educate folks in management by saying/doing something like "We had this one 30 minute run that sometimes fails that I thought could be reworked... I worked on it after hours, got it down to 6 seconds, and I can't make it fail. I think I know a couple of other places where we might make similar improvements." You'll need to demo what you've done and prove that it produces the same correct results reliably... after a couple/three of those small wins, they'll actually start to believe it. Be prepared to demo a big win right after that and be prepared to defend yourself against "nay-sayers" without being arrogant or defensive. Stick to the facts only and make sure the "facts" are right. And never ever bad mouth other folks' code... always make it a "mentoring/helpful/cheerful" experience. "I think there may be other similar opportunities for improvement" usually works a lot better than "This is crap code and it needs to be fixed NOW!"
Here's another huge point... once you've gained some respect as a "goto" person, if you're not willing to coach others and "let
people see it your way", you're doomed to "drone-dum". If you're not willing to stop what you're doing to help someone else, don't expect the same in return from either your peers or managment.
Also, it's ok, maybe even a requirement, to be confident... but the first sign of arrogance on your part will kill managment's opinion of you and, just like the fastest gun in the West, will invite every nay-sayer there is to challenge you. Build your own
authority by being politely correct in everything
you say and do. If you don't know something, say so... and then tell them what you're going to do to change that. That will also earn you a huge amount of respect and surprising numbers of allies that will bust a hump for you.
Above all else, remember that your only
job is to make the people you work for look good (sometimes, despite themselves). Contrary to popular belief, that's all
you were hired for.
That's probably more than you guys wanted to hear, though, huh?
But that's precisely what I've done to be successful. Speaking of success... Napoleon Hill wrote a book called the "Law of Success"... the nineth "lesson" in that book teaches "The Habit of Doing More than Paid For" and it's a darned good habit to get into... I know it works for me 'cause I've noticed that I don't have to
"fight" as much as most.
And for all of those who have grown weary of the "fight"..."If you have tried and met with defeat; if you have planned and watched your plans as they were crushed before your eyes; just remember that the greatest [people] in all history were the products of courage, and courage, you know, is born in the cradle of adversity." --Napoleon Hill
... be great.
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs