As I push forward to graduation, more and more doctors are coming out of the woodwork expressing their interest in coding and implementing tech solutions in healthcare. In-fact, the amount of doctors contacting me became so numerous I decided to start a Meetup group for medics learning and implementing code in order to economize my time. However, some doctors want to implement a tech solution without learning how to code. The grim reality for me is that I know more clinicians than people who can code. Although they want to innovate they seem a little reluctant to take the code development. They ask me, what attributes can they bring to coding? Do they have to start all over again? In some aspects yes, you will have to learn code from the start, and depending on the problems you want to solve you may have to learn some math. However, code is all about getting the computer to do the heavy lifting so you can solve the problem. Below are the 5 clinical learning points I took to code.

teamwork

This is the most obvious so lets start with this. Now other jobs will give you a grounding in teamwork, and I cannot say that a clinical job will give you the best teamwork experience it definitely gives you an intense introduction. On a clinical shift, I lose count how many times I handover or receive a handover about a patient. Due to the specialties, and different job roles deploying patient care you’re trained to spot when something is out of your area, and seek advice and input quickly. This is key in coding. There are loads of different languages, frameworks and solutions to a problem. Identifying when you need input is a key skill in saving time.

hacking

Although hacking is associated with coding and computers it was originally introduced at MIT for producing pranks, such as getting an automobile on the roof of a building. This evolved into the meaning of working around a problem for a solution in a rough quick way. Hence, this is why you see articles with titles like: “Life hacks” which have practical tips to streamline minor problems in life. As a clinician you are a hacker. Again most jobs will give you opportunities to solve problems, and I cannot say that clinical work with give you the best grounding however, it does give you a good foundation. Not only do you have to solve problems with providing medical care you also have to worry about the patient factors such as, will they comply with medical treatment, is their home safe to be discharged to, and can your intervention be done in time in order for the patient to receive treatment from other departments. With code there’s many ways to solve a problem. Whilst math skills will give you an edge in tackling the code logically, speeding up the computational time needed and shortening the code, your clinical hacking skills give you an edge of the bigger picture of the code. This is how your code go will about tackling a clinical problem. The bigger picture solution is defined by you looking at the clinical problem, breaking down how you would solve the problem into steps and then converting theses steps into code. When it comes to this after, a few coding lessons you will be hitting the ground running.

shift work

It’s no secret that clinicians are not super humans, they’re just like everyone else. However, clinical shift work does beat some sort of endurance into you. After a few years of pulling 12 hour shifts, day or night, you do get the ability to push through the tiredness. I have found this extremely useful when learning a new concept or more elegant solution to a problem. After this, I have been able to power through and correct all affected areas in my coding project before going to sleep. This concretes the theory so you don’t have to go back and reread when you attempt to finish refining your code a week later when you have more free time. OK, it’s a minor transferable skill as I’ve met non-clinicians who can stay up all night and power through with a tougher work ethic than me but still, it’s some useful character development you’ve had to endure.

utility

This is a given so there’s not much explanation needed. You’re a clinician so you understand why we need tech/software. You’ve had first hand experience using it in a clinical situation. Those frustrating moments using a useless piece of tech or giving up on software because it actually takes longer and makes the situation more dangerous is not wasted. It’s not hard to work out how this reduces the risk of your innovation being useless whilst speeding up the development process. I know what you’re thinking, you could simply be a consultant for a project. Whilst consultants do have their place and give good insight and value to established companies, your coding skills will give you the ability to knock up and rough prototype and trial multiple approaches to a solution before getting more people involved and turning the innovation into a more professional product. Code can also help in the research stage before conceiving of a solution. Knocking up a few rough programs that mine data and refine it or simply collect data, can help quantify a problem and find trends. It’s depressing to see junior doctors in this day and age still looking through electronic records whilst manually inputting the data into excel files. Not only can this be solved with a couple of short scripts it saves a lot of time and greatly reduces error (exceptions for audits where human interpretation is needed).

exposure to public

Here is another area of frustration that can be a gold mine. This gives you an edge in understanding the uncertainty and outright bizarre consequences that arise in clinical situations. For the sake of this blog I will only refer to a mild case were non-clinicians stared at me in disbelief when I told them that our department got a patient referred by “another clinician” who wrote in the letter that the patient “gets hot when he exercises”. When it comes to service users’ input you’ve seen the good, bad, and the ugly. You’ll be expecting stupid inputs from time to time and you know that if a patient can get round the system they will instead of actually engaging with it the way it was designed. Those confusing conversations, vague histories and breakdowns in communication are all good data points for your machine learning algorithm in your brain.