1. Let me know when there is a problem - early on so I can get help and resolve it. If a spec isn’t clear, let me know so I can get an answer.
2. Remember, better is the enemy of good enough - at some point, it’s time to let the working code go and not try to wring even more performance out of it - as long as it does what is needed.
3. Sure, writing documentation and help screens suck - but everyone has to take their turn in the barrel.
4. Don’t keep trying to get your pet hardware/software through based on a project “need” or “solution.” Yea, I know you want a bigger, faster box running Linux, but once it’s clear that it ain’t happening, constantly bringing it up as the “solution” to every problem is counter-productive. ( A real situation I ran into - one of our programers kept pushing a Linux server becasue he needed one for another project (that was on hold but that he wanted to revive))
4. Have a life - if your getting burned out, say so. Everyone needs a break, and let me run interference for you. As a follow-on, when the rules get bent to help the team, don’t brag about it.
Saturday, February 9
AlterSlash ~ the unofficial SlashDot digest
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment