351–356 of 356 posts
Earlier quoted context omitted.
It's the right lesson because the difficulty of the bug often depends on the dev. For example it might take one dev weeks to figure out that a hang due to a sleep(.001) call within asyncio whereas another can identify it with a glance at the code.
Which is why they get payed different rates.
Earlier quoted context omitted.
I had a job that required estimation on bug tickets. It's honestly amazing how they didn't realize that I'd take my actual estimate, then multiply it by 4, then use the extra time to work on my other bug tickets that the 4x multiplier wasn't good enough for.
Are you sure they didn't realize it...? Virtually everywhere I've ever worked has had an unwritten but widely understood informal policy of placing a multiple on predicted effort for both new code/features and bug fixing to account for Hofstadter's law.
Earlier quoted context omitted.
Yeah, Joel Spolsky is adamant about this with the "Bugs First" approach and he claims most of the delays and garbage that Microsoft released during the early years of his career were centered on that one rule being violated.
The problem is even if you make a note to fix it later, one you never get back to it and two this drives decisions for things around it, until it breaks...
Earlier quoted context omitted.
"Please don't post shallow dismissals" Same source. Don't trivialize my useful feedback. If a person tries to communicate, but his stylistic choice of laziness (his own admission!) gets in the way of delivering his message, it is very tangibly useful information to tell, so that the writing effort could be better optimized for effect. I wasn't even demanding/telling him what to do. I simply shared my observation, but…
> appearing or claiming to be one thing when it is really something else https://dictionary.cambridge.org/dictionary/english/ostensib... ostensible laziness => not actually laziness. although yes it is a stylistic choice (which i wont be changing as the result of our interaction).
I love the idea, but this line: > 1) no bug should take over 2 days Is odd. It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done. That said, unless fixing a bug requires a significant refactor/rewrite, I can’t imagine spending more than a day on one. Also, I tend to attack bugs by priority/severity, as opposed to difficulty. Some of the most serious bugs are often qui…
I think what they mean is that after 2 days of working on bug you stop it regardless the result, leaving paper trail behind for the next person.