The community of doctors and nurses who code continues to grow. This is exciting! Not only is there 90+ members in my coding meetup group, multiple doctors are contacting me and others with business ideas which utilise the boom in big data and coding languages. However, this field is still new which means that there are plenty of snake oil salesmen going around town. Not only is this annoying it stifles innovation, holds back people who want to create solutions, and potentially put them off completely. I’ve had doctors contact me telling me stories where they were strung along. If you’re pulling clinical shifts and prepping for exams your time is precious. Not only this, but the time window can also be a deal breaker. After being messed around you may have to abandon your hard work as you rotated to another hospital with a different system. Here are 5 signs you should keep an eye out for when seeking a partner to work with or get advice from.

Being negative about all tech

This is something that should raise alarm bells instantly. Now some criticism is needed. Do not walk out instantly as soon as they say something negative about a system. However, keep an eye on the amount of criticism they dish out. Count how many suggestions and solutions they offer. In tech, you can appear like you know your stuff by trash talking every system and piece of hardware under the sun. This seems to fly in the clinical world simply because most clinicians don’t know much about computers. You tell them that there are using a inferior product and then quickly conclude that the NHS will not spend any decent amount of money of a “proper” system. This means you don’t have to come up with a solution to get peoples’ attention about your opinion on technology. Sadly, it’s easier to point out the flaws in a system than come up with solutions. The average user can complain about the bugs in Facebook messenger, very few users could provide coding solutions to the bugs. Again, this doesn’t mean you should walk out the door as soon as they talk negatively about a product. But remember, you’re looking to them to solve problems. Ask them how the fault could be improved. If they only come up with vague statements be careful. Just because some junior points out that all the consultant surgeons do not have 100% success rate, that doesn’t mean that you want him leading his own operations tomorrow.

Vague statements

A good friend told me a golden rule. If someone says something, say the exact opposite in your head. If it sounds completely mental they haven’t said anything. One example that sticks in my head was from a politician on drone strikes. She answered a question by saying that we must ensure that the people who carry out these strikes are doing is proper job. On the flip side, we do not have politicians arguing that people should have a go at a half-baked drone strikes. She was saying nothing. Vague statements sound good when you’re half asleep but they are not a sign that the person knows what they’re talking about. I’ve seen doctors who are “tech leaders” who say stuff like “doctors should take charge of technology”. When pressed on the issue they just come up with equally vague statements. Every clinician who is coding and engaging with the clinical community will have this ethos. They wouldn’t be doing what they are doing if they didn’t believe this. The proof is in the details when pressed. Let’s apply this starting point for me. You ask how. I reply with clinicians should learn a high-level programming language which is easy and quick to develop. It should also have a wide range of utility. With this they can collect data, generate crude scripts, come up with prototypes, and quickly test them. They are not computer science grads so they will not be doing anything cutting edge but they clinical exposure will speed up the testing and altering of the approach to solving the clinical problem. As a result, the feedback loop is short. When they have a working prototype, and separated the failed ideas from the ones that have traction they can seek tech help from professional coders who can translate it to a more robust framework, and worry about processes like speed, memory management and security. If ask me which language I will tell you python and I can give you multiple reasons why. If you want to build a communication tool or web app I’ll recommend Flask for light quick development and Django for more robust admin functions. I can also provide code examples if needed. If they cannot give you a detailed plan when to their nebulous statement stay clear. The nebulous statement is a title, not an argument.

Fanatical about one language

Everyone has their own pet language that they prefer for most tasks. For beginners in healthcare I recommend python. I will also tell people that they are learning the wrong language if I can come up with distinct reasons why and I can offer a better alternative. However, there are different tools for different jobs. A sign that the person is inexperienced is that they say that their language is the best and they berate others for not learning it. For instance, if I want to develop a web app I will use Python. Recently, I developed a mathematical model for different wavelengths of light penetrating skin. I wanted to compute multiple outcomes so I did it in Matlab. When I coded an iphone app for the app store I used objective-C and Swift. Languages come and go. They are also different. A good coder is someone who can breakdown the problem and solve it in the most logical and efficient way. I am not above using an easy language if it provides a quicker, simpler solution. However, I have heard stories where a clinical “tech leader” has told them that their choice “isn’t a proper coding language”. When it comes to this you must ask yourself. Why are they seeking pride in the type of language they are using as opposed to pride in the solutions and products they have developed?

Nothing to show

There is no excuse for this. No regulation about coding means that anyone who can code can produce a product or sample program. The only thing stopping them is their work ethic and ability to code. This point is short and simple. If they do not have something they can point to and say, I coded that, do not dance to their tune. Find someone who has developed something. If I am going to a meeting with someone I usually have at the very least some scripts that have no graphical interface that produce demos in the field that they are talking to me about. Both of us have taken time out of our schedule to meet up. At the very least they should get some sort of insight on how something is done even if we agree not to work together. The person you’re talking to should want you to succeed if they are truly passionate about the field. Providing insight and pointing you in the right direction is a minimum.

Claiming you don’t have to learn code

With some of the high languages floating about today you can produce scripts that will help even with modeling and prototyping without knowing any math or anything about computers. There is zero excuse for this. I know doctors who have taken further study in branding and focus on the branding and interface areas of tech. They still take steps to learn an easy lightweight language so they can dabble and tinker with projects. I know of a nurse who took no further study but made a working prototype using Microsoft Access and reading what he needed out of a visual basic book. When it got tough he copied and pasted lines of code off the internet and tinkered till it worked. He’s now expanding its use and I am talking to him about coding it into a proper web app with an SQL database. If a clinician doesn’t express any interest in coding even for a hobby, be careful. You should really question their interest in tech. There are plenty of people who want to ride the med tech wave for free. This doesn’t mean that if a clinician doesn’t code they are a waste of time. Many doctors have ideas but cannot code. They are passionate about their idea, not med tech in general. However, the horror story begins if they run into the arms of another clinician who will “help them” with their project but has zero interest in learning how to code, even as a hobby. Clinicians who are “passionate” about med tech but have zero interest in learning even a little bit of code have to be treated with caution. They also lack crucial insight into how a software solution is developed.