10 Things Doctors can Learn from Programmers

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.