| > Ability to write source code that adheres to specifications This article reads like a series of bad advice from 1990s. - No, engineers shouldn't be writing code that "adheres" to specifications. They should study, understand, question and contribute to problem statement and approach at all times (also called "requirements" in pre-2000s). - Manager shouldn't be at center of evalauting performance but rather establishing process, standards and collecting feedback and metrics. - Bonuses are inherently evil and would always motivate individuals to exploit short term gains at the expense of long term sustainibility. Any performance evaluation strategy must keep this issue front and center at all times. - Large part of performance feedback shouldn't come from managers but peers - Performance reviews should never be entirely metrics-driven. No finite set of metrics tell the full story and all metrics are susceptible at gaming. - Don't treat new comers as incapable of fixing bugs or do X but not Y. Don't create class system of seniors vs juniors. Titles cause more troubles then they are worth. |