July 4, 2025 at 12:36 am
Comments posted to this topic are about the item Own Your Mistakes
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 4, 2025 at 8:00 am
Thanks Grant, I agree whole heartedly. I have a similar mantra, own it, deal with it, learn from it, move on! Which is the same as your summary, just paraphrased.
July 4, 2025 at 1:00 pm
I've never done that before, except for that one. And that one. And that other one. And there's another one. ...
ARGH!!
Rod
July 4, 2025 at 1:37 pm
Yeah, ego is the enemy. If it’s your fault, be manly and take it on the chin. And if it’s partly your fault, take your share.
Own up, and you won’t have to climb down later, quite possibly in public.
But if it isn’t your fault, stick to your guns.
MarkD
July 4, 2025 at 6:02 pm
The other fun thing is MOST modern systems have audits of some sort. So even if you try to say it wasn't your fault or you pretend it wasn't or blame someone else, the logs will rat you out. And once people figure out it was you and you tried to hide it, that could be the end of your job or possibly your career. If you own it quickly, it can be corrected faster and be a good learning experience both for you and for whoever is responsible for that system.
In your examples with the book, it's either you or your editor that made the mistake. Not really a lot of people to blame.
In the corporate world, I don't like the methodology of "who broke this?". Blame is not the goal for me. I want to know how and why the user (me or anyone else) did the thing that broke stuff so we can do one of two things (possibly both):
1- fix the system so that problem can't happen again
2- train the user(s) so that it doesn't happen again
AGES back when I was a new DBA, I learned the risk of registered servers. If you clicked on the parent folder for your registered servers then clicked on New Query, it would have that query ready to run against ALL servers in that registered servers list. Thankfully at that time I only had access to the test databases, but the script was to drop a database and restore from backup. Drop succeeded on the one test system I wanted it to go on, but the restore ran across ALL test systems which isn't what I wanted. A small DB (something like 2-5 GB) but restored across 30+ instances adds up with disk use. Immediately informed the senior DBA and we corrected it (dropped the DB where it shouldn't be), then spent a few hours trying to figure out how I even did that before we figured out it was due to registered servers. But that could have been a lot worse had I had access to production. But we couldn't "fix the system" to stop it from happening again, but we did train all the other developers and DBA's on what not to do.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
July 6, 2025 at 4:18 pm
Deeply insightful. Actual = Estimated (in context). Thanks for sharing.
Br. Kenneth Igiri
https://kennethigiri.com
All nations come to my light, all kings to the brightness of my rising
July 7, 2025 at 3:00 pm
Grant, I totally agree. It has served me well in my career to always own up to mistakes. Another developer I worked with always said it happens that sometimes you break things just be prepared to fix them although we would all hop in and assist when something got broke. It is always nice when you notice yourself you broke something and can get it fixed before anyone else notices, I would still let the team know just in case there were repercussions I wasn't aware of.
July 8, 2025 at 1:07 pm
Thanks for all the feedback everyone. For some reason it didn't show up in my email as per usual (I probably broke something).
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 8, 2025 at 1:11 pm
Grant, I totally agree. It has served me well in my career to always own up to mistakes. Another developer I worked with always said it happens that sometimes you break things just be prepared to fix them although we would all hop in and assist when something got broke. It is always nice when you notice yourself you broke something and can get it fixed before anyone else notices, I would still let the team know just in case there were repercussions I wasn't aware of.
True confession time.
I broke something in production. I honestly don't remember what it was. I think it was permissions to a stored proc I was editing by hand instead of automating as we should have done. Anyway, I broke it. I didn't immediately realize it until my phone lit up. Now, I immediately knew what the problem was, and while answering the phone, I was fixing it. I told everyone on the phone "Well huh, that's sure weird. Well, wait a second and try it again." Not fessing up that I had just broken everything. I got it fixed. The phone stopped lighting up. Got away with it entirely.
Except, I went straight in to the boss's office to explain what had happened. Sure, maybe I could have avoided that bit of embarrassment, but if it had come out later, then I'd be truly in trouble for hiding stuff. I did a little public ass covering, but where it counted, I owned my mistake as is appropriate.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 9 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply