10 Things Doctors can Learn from Programmers

10
6581

Software development is a subject that isn’t really understood by the public. It’s being treated as something obscure, technical and nerdy. That’s bad, because it has implications for us physicians.

We are living in a technological world and are surrounded by products that all once required a piece of code to make it work. From cars to web applications and MRIs. All of these fields require programmers that make use of syntax to tell the products or programs what to do and what to show. The input, a.k.a. the code, is strict and follows a defined set of rules that enable it to work. Programmers (and equivalently engineers from all walks) are often wrongly treated as necessary elements for any product, yet they are hardly being treated as they deserve to be treated – as the people who make things work and who are eventually responsible for a space shuttle bursting or a website being down.

Now I don’t really know how to code, except for some HTML and CSS, but I’ve spent endless hours with both physicians and programmers. What came to my mind recently, is that good physicians run through programms in their head. Apart from being empathic and all other “soft skills” that are vital for any good doctor, they need to know all the paths that lead to diagnosis or treatments. The dead ends, the shortest path, the most efficient path and the u-turns. Having a patient in front of you, is much like a blinking cursor and at the end you except a result (or a product). There are several ways (programming languages/diagnostic techniques) to achieve this goal. The path to result is often stony, because you are mostly distracted by other elements (bugs/ringing phones and buracreucy) and in the end you have to be really sure before you “deliver” (or treat) (quality assurance/lab results).

We’ve identified a bunch of aspects that physicians should keep in mind when helping patients and working in their clinical environment. They do not originate in software development, but they are part of an engineers daily routine – and should be so for doctors as well.

  1. Iterate instead of bulk decisions
  2. Question the path you’ve taken if it’s the best and most efficient
  3. Think long term!
  4. Being able to scale your work is as important as the work itself
  5. Ask professionals or study the literature if you have questions
  6. Document your work and procedures
  7. Identify steps that are reproducable and make them reproducable
  8. Make up a set of rules and stick to them
  9. Work with existing frameworks and best-practice examples
  10. Organize a bi-yearly med-a-thon (reference to “hackathon“)

We are aware that some of these things are naive, but nevertheless you should keep them in mind and we are always happy for feedback.

10 COMMENTS

  1. Good software starts with good requirements and specifications (checklists, visual diagrams, etc.) iterated with all stakeholders. Good customer testing along the way. Modular design. Testable modules. Careful systems integration and regular systems testing. Constant iteration, but with documentation related to original design, not isolated. Constant open reporting and tracking. Multiple checks and balances. Regular feedback from customers. Open monitoring for bugs and viruses, with rapid fixes.

  2. […] the topic of software development, we wanted to pick up a bullet point from our last post – 10 things doctors can learn from programmers, we wanted to focus on a particular bullet point in our last post – medathons.A couple of […]

  3. Hi,

    thanks for the input! We fully agree on the elements you’ve noticed. Especially regular system testing and modular design (bottom up) are crucical for successful medical prodecures!

    best
    lukas (medcrunch)

  4. As a former computer programmer myself I was appalled by the unknowns of my stroke, No damage diagnosis and with that no possibility of comparing initial states and outcomes to each other. Even worse researchers have no common starting point so none of their research is reproducible. In 2400 years from Hipppcrates we haven’t improved at all.

  5. As a former computer programmer myself I was appalled by the unknowns of
    my stroke, No damage diagnosis and with that no possibility of
    comparing initial states and outcomes to each other. Even worse
    researchers have no common starting point so none of their research is
    reproducible. In 2400 years from Hipppcrates we haven’t improved at all.

  6. Hi Dean,

    I believe we do have improved. Science is a very slow, yet constant move forward. There are no wonders and it’s a chain of thought, bright minds and trial and error.

    What do you mean by researchers have no common starting point?

    Best
    Lukas (MedCrunch)

LEAVE A REPLY

Please enter your comment!
Please enter your name here