I definitely agree with you here: "99% of the time it's you."
Thinking back through years, this rings true. There have been a couple of occasions where there's been a bug in a Ruby gem or even an issue with Rails itself. However, the vast majority of the time it's either misuse of the gem or misunderstanding of a Rails API.
Like you said, searching for blame is a waste of time. It doesn't get you any closer to solving the problem. This is even more important when trying to ship a hot fix. Every minute you spend searching for blame is another minute of production being unstable.
I think it's ok to come back later, after you've fixed an issue, and figure out what went wrong. Maybe there's a process you can improve or some testing you can build. If we keep our focus on learning and getting better, there should be no time for the blame game.
I build things with my hands. The human behind Shift - https://laravelshift.com, master of Git - https://gettinggit.com, and author of "BaseCode" - https://basecodefieldguide.com
For sure. Such things should be mentioned in a retro or standup after the fix. Especially if the fix resulted in any kind of outage or is a chance for the whole team to learn a different practice.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I definitely agree with you here: "99% of the time it's you."
Thinking back through years, this rings true. There have been a couple of occasions where there's been a bug in a Ruby gem or even an issue with Rails itself. However, the vast majority of the time it's either misuse of the gem or misunderstanding of a Rails API.
Like you said, searching for blame is a waste of time. It doesn't get you any closer to solving the problem. This is even more important when trying to ship a hot fix. Every minute you spend searching for blame is another minute of production being unstable.
I think it's ok to come back later, after you've fixed an issue, and figure out what went wrong. Maybe there's a process you can improve or some testing you can build. If we keep our focus on learning and getting better, there should be no time for the blame game.
For sure. Such things should be mentioned in a retro or standup after the fix. Especially if the fix resulted in any kind of outage or is a chance for the whole team to learn a different practice.