same experience level, similar formula. Take your gut estimate, double it, double that new value, then add another "increment".
e.g. say you think it will take a day, so 2 days, 4 days, add another day, likely estimate is 5 days.
My pet theory is that when we estimate, we typically think of how long it will take to figure out a working solution to the problem, but forget about how long it takes to debug it, add tests, rework for changed requirements and unexpected nuances, and then roll it out and do any training, etc.
The part you didn't mention is that for most businesses it's better to be over than under in the estimation. I also explain this thought process to the various stake holders. We can certainly try to tighten up an estimate, but that runs a higher risk of being under which is usually a worse outcome (promised launch dates are missed, marketing is missed/happening, customers are told, etc...).
That's a recursive definition (estimate * 3) = ((estimate * 3) * 3) = (((estimate * 3) * 3) * 3)... But if you do that for a few years, "your honest and concise estimation" starts to grow because you've seen how it usually takes longer than expected, and your coefficient can approach 1.
yes, going from identification of the bug/idea to the solution in end users hands is a lot different than just the coding estimate. On teams with multiple levels of management both engineering side and customer side the actual code required to fix/implement the solution is such a small part of the overall effort you could, ironically, consider it immaterial.
There are just to many unknowns you cannot foresee. Software development is complex.