It's even worse than it appears..
It seems Marco Rubio is beatable. Wouldn't it be something if the listenters to Keith Olbermann's fantastic podcast could make it happen? I think it's possible. #
But what do I know. Heh. Every poll has Rubio far ahead of Demings. #
I usually exercise in the afternoon, but it's been so hot, so I did my Peloton ride first thing this morning. Then swimming, a nice breakfast with a tall glass of delicious ice coffee. The sense of well-being is overwhelming. I used to have this feeling all the time after working out when I was younger. Now it's harder to get there. It's nice to see if I do everything well, I can still do it.#
  • We should write a book on bug reports. There's so much to say. A case study. #
  • A user is testing a fresh new feature. Released seconds before. He tries it out on his iPad and gets a blank screen. Tries it on his desktop machine, it works. He concludes there's an incompatibility with iPads and reports it as such, in great detail with screen shots. He follows the 1. 2. 3. format. #
  • But as the developer reads the report, right from the start, he's pretty sure that the user's theory is incorrect, that it has nothing to do with an incompatibility with iPads. He has strong reasons to believe this, because: #
    • The new feature reuses already tested display code, there was nothing new there in this release. Almost all browser incompatibilities are display problems. #
    • He had just seen the same behavior on his own machine, and the problem was that he hadn't done a hard reload, so some code files updated, others didn't. #
  • The developer would like to know if there are any error messagess in the JavaScript console, being 99 percent sure there are. The user's report didn't include any info on this. They error messages are in the software for a reason, to help figure out what went wrong, to take the load off the user and the developer. To make these puzzles resolve faster.#
  • They're not in a good place, because the developer is going to have to first convince the user to look elsewhere first, and users like everyone else, don't like to be told they're wrong. That's why we have to slow down. Don't rush to write a bug report. At least try it again, to be sure it reproduces. Think about what else can go wrong.Like it or not, the user has to participate in the debugging process, if they want the problem resolved reasonably efficiently in time, for everyone.#
  • The best bug reports are short. A bug report and lab notes are different things. By digesting your report into simple statements of fact, you get to challenge your own assumptions and might cause you to change your thinking. #
  • You have to think about it as likely your problem, not the software's because in my experience that's what's usually going on. In almost 50 years of being a programmer only once did I find a bug in a compiler, yet in my early years, I often stopped looking because I thought I had, only to find the bug later, in my own code. #

Last update: Sunday August 7, 2022; 12:57 PM EDT.

You know those obnoxious sites that pop up dialogs when they think you're about to leave, asking you to subscribe to their email newsletter? Well that won't do for Scripting News readers who are a discerning lot, very loyal, but that wouldn't last long if I did rude stuff like that. So here I am at the bottom of the page quietly encouraging you to sign up for the nightly email. It's got everything from the previous day on Scripting, plus the contents of the linkblog and who knows what else we'll get in there. People really love it. I wish I had done it sooner. And every email has an unsub link so if you want to get out, you can, easily -- no questions asked, and no follow-ups. Go ahead and do it, you won't be sorry! :-)