One piece of advice I continue to want people to hear is: Keep trying to achieve _goals_ instead of the metrics you put in place to reach those goals.
A good example from development is DRY. The goal is not to never repeat yourself. The goal is write good abstractions. DRY can go way too far and then stops being useful.
It's difficult though. Much easier to know when your code is perfectly DRY than when you've written "good" abstractions.
This is all pretty well summed by Goodhart's law, btw:
@edwardloveall You're saying "when a metric becomes a target, it ceases to be a good metric." I strongly agree with you about focusing on goals. But here's what I'm wondering. If I focus on the goals I'm trying to achieve, how do I keep those goals from becoming target metrics? This is where it's more an art than a science.
@mildbeard Great question. I think some argue that it's impossible. One thing I've been thinking about is keeping multiple, competing goals in balance, and continually evaluating their efficacy as a whole. e.g. "DRY + easy for new comers + easy to change" instead of only "DRY".
Attempting to measure more artful metrics can be useful too. How fast can a new hire get up-to-speed? How quickly can we fix prod issues? How confident are we that we can deploy with no issues every time?
