Slightly OT here, but I think it should be mentioned. The very first lesson I learned when coding professionally was that hammering code out as fast as possible is the worst approach there is. Often the task ends up taking longer than doing it correctly, and it always ends up as a shabbier product. So now I never take shortcuts, unless so ordered very explicitly by management. I've even risked ignoring those orders from time to time.

Managers who do not understand this concept shouldn't manage, plain and simple. I have been blamed for "over engineering" more than once, but I consistently beat deadlines and customers are happy with my code (I actually have a small 1.0 application that has been deployed to over a thousand users for over six months and no change requests/bug fixes have been made).

I realize this is nothing new to you (clearly you understand it or you wouldn’t be posting), but I figure you should know you're not alone in this battle. I've rarely worked for anyone who I didn't have to fight on this point, and ultimately only repeated success have allowed me the grace get away with my “over engineering” attitude.

About specific goals: overtime and missed dates are often examples of mismanagement. Not saying you should bring this up (you seem to be getting very good advise from Jim in this thread so I'll defer to him), but at least for your own sanity you should realize it. If you can’t meet a deadline with available resources, don’t commit to it and certainly don’t bid your services for it.

edited to tone down a bit of my criticism of managers who have to require overtime. Clearly it can be required even in the best of situations.


Edited by FerretBoy (19/02/2004 15:22)
_________________________
-Jeff
Rome did not create a great empire by having meetings; they did it by killing all those who opposed them.