If you were working on a production system that had a failure, you'd probably want to dig into the why behind the failure and take some steps to keep it from ha

If you were working on a production system that had a failure, you'd probably want to dig into the why behind the failure and take some steps to keep it from happening in the future. Why not apply the same to your own failures and treat them as an opportunity to improve yourself? I like the idea of tracking my own personal performance to help mitigate future problems. There is probably only going to be a retro for the incident if it was something really bad. Even then it's not going to focus on you, it'll be more about cross team efforts and higher level issues. Having a personal tracker may help you understand your own weak spots, common sources of problems, and trends in your work. For each incident look at things like why it happened, what could have been done to avoid it, and the context that the mistake was made in (e.g. we had three issues going at the time and were under a product deadline for X which was due in the next two weeks). To measure performance you could classify the mistake type and plot it over time. It could be something general like the preventable/complex/innovative buckets stated in the article with technical details like: missed the bug during PR review, misunderstood the system architecture, missed handling an edge case, etc. Having the issues clearly stated for yourself should help you not make a similar mistake going forward. If you have a trend in the data you can focus your personal development on areas where you're weak. Keeping a reference of issues that have happened should help with understanding the problem history a year later too. That could be good for planning future work since you'll know where some of the hard spots might be.