4 ms·

The way I saw is it like doing a commit bisect. While there were other problems before, this particular problem started after the pacemaker operation, the other

The way I saw is it like doing a commit bisect. While there were other problems before, this particular problem started after the pacemaker operation, the other problems had stopped. It is like a one bug is fixed and another was created. Either the operation or the device itself was the most likely cause of the change in such a short time frame? In software dev a bug being created as side effect solving another usually means QC missed it, perhaps here too? I don't know if surgeons do checklists or some else normally verifies post op on the procedure( peer review?), and are there ways to verify the device before and after insertion , if it was software dev that's what I would recommend . While surgeries and medical practice has lot of regulations and it cannot be changed easily, the principles are sound, and other fields like airline pilots do similar things.

JshWright 6y ago
I totally get where you're coming from. I'm a full time developer, and part-time paramedic. There are definitely a lot of similarities between debugging a program and debugging a person. The doctor in the post was also working off the base assumption that this was a bug that got shipped in the last release (surgical complication leading to interval bleeding, leading to hypotension; surgical complication leading to cardiac tamponade; etc). My original point was just that the answer that was obvious to the commenter was actually pretty low on the probability list, and it only seemed obvious because they had an incomplete mental model of the system as a whole (something that happens in software debugging as well). As it turns out, it was the correct answer, but the correct approach (on average) would still put "failure of the pacing leads" pretty low on the list of likely causes. There are a lot of checklists used in surgery. For instance, immediately before any procedure, there is a "time out" to make sure everyone is on the same page with the right patient, right procedure, and right location. I'm not aware of any checklists specific to pacer leads, but I don't spend much time in the OR these days.

JshWright 6y ago

I totally get where you're coming from. I'm a full time developer, and part-time paramedic. There are definitely a lot of similarities between debugging a program and debugging a person. The doctor in the post was also working off the base assumption that this was a bug that got shipped in the last release (surgical complication leading to interval bleeding, leading to hypotension; surgical complication leading to cardiac tamponade; etc). My original point was just that the answer that was obvious to the commenter was actually pretty low on the probability list, and it only seemed obvious because they had an incomplete mental model of the system as a whole (something that happens in software debugging as well). As it turns out, it was the correct answer, but the correct approach (on average) would still put "failure of the pacing leads" pretty low on the list of likely causes. There are a lot of checklists used in surgery. For instance, immediately before any procedure, there is a "time out" to make sure everyone is on the same page with the right patient, right procedure, and right location. I'm not aware of any checklists specific to pacer leads, but I don't spend much time in the OR these days.