I do think that sometimes it's ok to not come back to understand the root cause, and be satisfied with the lucky fix. I had such a case just today, where we touched an area of another team, and we had a bug, and suddenly it dissappeared - I think because of a cron job that runs every hour and does something, but I'm not sure.
I can go deeper here, but I think my time is better invested in other things.
Sure thing! I've had countless similar anomalies, too, but if they disappear without touching the codebase, I consider that's a different story. Something I would never do in your case (as Measure twice, cut once suggests) is adding code that _I guess_ would fix the thing because, in that case:
- It wasn't my addition that fixed it. In reality, it just disappeared
- I introduced more liability to the codebase that may not do any good
I loved your latest article – my application for a higher role is still pending, and I'm trying to devour all engineering management and leadership advice I can 😃
Thanks for the mention, Akos. I'm glad I could encourage you in some way. I also felt the same with other people in the community when I started. And I think that's the beauty of what we are doing here :)
About the post, you just triggered a memory of the template I have for these situations. It's called "🧪Labnotes debugging". When I need it, I go completely into an experimentation mode, getting rid of my biased understanding of the problem and approaching it with fresh eyes. The name and emoji help me get into this "scientist persona".
As you mentioned, we identify and understand with experiments and finding reproducible behaviors. Taking notes of these brings a better understanding. Only then we have the knowledge to go for a solution.
Fran, I'm happy we connect here and find value in each other's writings!
It's good to know AWS takes advantage of a scientist's mindset and methodologies. It saved me and my team lots of hours many times. Also, you have a good point about the bias. That's our gut feeling that sometimes takes us down a path where we're trying to fix the wrong thing because we made assumptions. That's where tests help because they're unbiased.
When I use telco, insurance, or bank websites, I always think everything is on fire elsewhere in the system. That's why they don't have the time to fix their broken UIs.
Thanks for the shoutout Akos!
I do think that sometimes it's ok to not come back to understand the root cause, and be satisfied with the lucky fix. I had such a case just today, where we touched an area of another team, and we had a bug, and suddenly it dissappeared - I think because of a cron job that runs every hour and does something, but I'm not sure.
I can go deeper here, but I think my time is better invested in other things.
Sure thing! I've had countless similar anomalies, too, but if they disappear without touching the codebase, I consider that's a different story. Something I would never do in your case (as Measure twice, cut once suggests) is adding code that _I guess_ would fix the thing because, in that case:
- It wasn't my addition that fixed it. In reality, it just disappeared
- I introduced more liability to the codebase that may not do any good
I loved your latest article – my application for a higher role is still pending, and I'm trying to devour all engineering management and leadership advice I can 😃
Good luck in the application! :)
I hope it'll work out
Thanks!! 🤞
Thanks for the mention, Akos. I'm glad I could encourage you in some way. I also felt the same with other people in the community when I started. And I think that's the beauty of what we are doing here :)
About the post, you just triggered a memory of the template I have for these situations. It's called "🧪Labnotes debugging". When I need it, I go completely into an experimentation mode, getting rid of my biased understanding of the problem and approaching it with fresh eyes. The name and emoji help me get into this "scientist persona".
As you mentioned, we identify and understand with experiments and finding reproducible behaviors. Taking notes of these brings a better understanding. Only then we have the knowledge to go for a solution.
Fran, I'm happy we connect here and find value in each other's writings!
It's good to know AWS takes advantage of a scientist's mindset and methodologies. It saved me and my team lots of hours many times. Also, you have a good point about the bias. That's our gut feeling that sometimes takes us down a path where we're trying to fix the wrong thing because we made assumptions. That's where tests help because they're unbiased.
"Measure twice, cut once."
Spot on Akos! That's how bugs should be solved.
Sadly, most of the time, only bugs that block the business come into the queue and it's a mad scramble to get things working...
I somehow don't doubt that. 😃
When I use telco, insurance, or bank websites, I always think everything is on fire elsewhere in the system. That's why they don't have the time to fix their broken UIs.
I'm glad you enjoyed the article, Saurabh!