I was a bit confounded when you said you were going to make this comparison. Having read it now, I agree with the majority of your points, and think this is an apt comparison. The one major difference is urgency; medicine often has incredible urgency where programming can take a step back and think when needed.
To provide a concrete example towards something you said. We definitely don't know what we're getting ourselves into most of the time, and being flexible and reactive is a huge part of it. Even without medical knowledge, I'm sure the first thing you'd think for a patient coming into the ER with his "arm torn off" is a tourniquet. You'd be correct. So, I had everything ready ahead of time expecting that, with no complications, since that's very urgent. EMS neglected to mention this was a farming accident and the man didn't just have his arm torn off. He also had cow manure everywhere, including in the wound. The entire "playbook" went out the window, because now we have to carefully balance cleaning out the wound so he doesn't get sepsis, with stopping the bleeding so he doesn't bleed out. Curveballs, not necessarily this severe, are the norm, and it's expected any medical worker can think on their feet in response to new data. The "spec" is always the same, but what we think the "spec" is constantly changes.
A more technical example, is I applied this kind of thinking to some software I develop, since, it's what I know. I had some rough design requirements; a problem I was trying to solve. But that was it. How long would it take? Idk. How would it be implemented? Idk. It wasn't TDD because I didn't have a concrete spec; I couldn't. I just dove in, keeping the hard requirements in mind. What started as an uninspiring and "misguided" project many tried to talk me out of, turned into a major contender among parsing frameworks. I made constant little UX and perf tests, and refined everything until I eventually had a spec; the spec, or "diagnosis" was a late product. The design I have barely resembles what I thought it would be. No amount of design docs or meetings could have gotten me there. But I wound up with what seems to be the worlds first allocationless parsing framework, reliably in the top 3, and usually 1st for every performance benchmark I've seen (near 100 cases now), and with far less required knowledge than parser combinators need for anything non-trivial.
Looking at it both ways, I completely agree. I liken what's being done now, to the philosophers of old thinking if they thought long and well enough, they could know, upfront, how many teeth were in a sheeps mouth. You can't. And that you can't spawned sciences hypothesis-test-infer approach. This is Computer Science not Computer Philosophy right?
Absolutely. My original programming language was Ada, so you can guess the kind of stuff I was doing. When there's a physical product that's being controlled by the software, the whole process is drastically different. You know exactly what you need to do.
Excellent points! And I love that you bring up the term Computer Science. I always thought that term was a bit "lofty" for what we do (unless you're, like, developing the next generation of quantum computers). But now I think I should embrace it more. Because science isn't about having all the answers. It's about following a rigorous process in an attempt to find those answers.
Exactly. I had a hypothesis on how I could design a good parsing framework that solved the problems I laid out. I set up falsifiable and reproducible experiments (both benchmarks and UX tests) with a null hypothesis. The times I was right, I went forward with that approach. The times I was wrong, I rewrote that component with a new hypothesis.
Ironically, science tends to be more about finding all the wrong answers. We know a lot more about how things don't work than do. Less glamorous way to put it though.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I was a bit confounded when you said you were going to make this comparison. Having read it now, I agree with the majority of your points, and think this is an apt comparison. The one major difference is urgency; medicine often has incredible urgency where programming can take a step back and think when needed.
To provide a concrete example towards something you said. We definitely don't know what we're getting ourselves into most of the time, and being flexible and reactive is a huge part of it. Even without medical knowledge, I'm sure the first thing you'd think for a patient coming into the ER with his "arm torn off" is a tourniquet. You'd be correct. So, I had everything ready ahead of time expecting that, with no complications, since that's very urgent. EMS neglected to mention this was a farming accident and the man didn't just have his arm torn off. He also had cow manure everywhere, including in the wound. The entire "playbook" went out the window, because now we have to carefully balance cleaning out the wound so he doesn't get sepsis, with stopping the bleeding so he doesn't bleed out. Curveballs, not necessarily this severe, are the norm, and it's expected any medical worker can think on their feet in response to new data. The "spec" is always the same, but what we think the "spec" is constantly changes.
A more technical example, is I applied this kind of thinking to some software I develop, since, it's what I know. I had some rough design requirements; a problem I was trying to solve. But that was it. How long would it take? Idk. How would it be implemented? Idk. It wasn't TDD because I didn't have a concrete spec; I couldn't. I just dove in, keeping the hard requirements in mind. What started as an uninspiring and "misguided" project many tried to talk me out of, turned into a major contender among parsing frameworks. I made constant little UX and perf tests, and refined everything until I eventually had a spec; the spec, or "diagnosis" was a late product. The design I have barely resembles what I thought it would be. No amount of design docs or meetings could have gotten me there. But I wound up with what seems to be the worlds first allocationless parsing framework, reliably in the top 3, and usually 1st for every performance benchmark I've seen (near 100 cases now), and with far less required knowledge than parser combinators need for anything non-trivial.
Looking at it both ways, I completely agree. I liken what's being done now, to the philosophers of old thinking if they thought long and well enough, they could know, upfront, how many teeth were in a sheeps mouth. You can't. And that you can't spawned sciences hypothesis-test-infer approach. This is Computer Science not Computer Philosophy right?
The obvious caveat here, is anyone reading this that writes software for life support machines, or anyone on the Boeing team.
For those people, software bugs are somewhat more important than the rest of us.
Absolutely. My original programming language was Ada, so you can guess the kind of stuff I was doing. When there's a physical product that's being controlled by the software, the whole process is drastically different. You know exactly what you need to do.
Excellent points! And I love that you bring up the term Computer Science. I always thought that term was a bit "lofty" for what we do (unless you're, like, developing the next generation of quantum computers). But now I think I should embrace it more. Because science isn't about having all the answers. It's about following a rigorous process in an attempt to find those answers.
Exactly. I had a hypothesis on how I could design a good parsing framework that solved the problems I laid out. I set up falsifiable and reproducible experiments (both benchmarks and UX tests) with a null hypothesis. The times I was right, I went forward with that approach. The times I was wrong, I rewrote that component with a new hypothesis.
Ironically, science tends to be more about finding all the wrong answers. We know a lot more about how things don't work than do. Less glamorous way to put it though.