Mission 33 // October 4, 2020

You Need to Learn How to Code

An Australian doctor's motivational case for why every medic should learn to code — and exactly how to start.

JC Josh CaseDoctor & Software Developer, Independent
You Need to Learn How to Code
0:00 // 40 min

About this episode

Dr Josh Case is an Australian doctor practicing in the outback, and he's on a big mission: getting more doctors involved in technology, connecting them with software development skills, and getting them thinking about innovating to improve the efficiency of our health systems. I connected with Josh through Twitter, where he teaches medics how to code — I highly recommend following him at @_JoshCase.

We talk about why you should learn how to code as a medic, which turns into a bit of a motivational talk that'll have you reaching for your nearest computer terminal and a can of Monster Energy. But then I push back and challenge Josh: I ask why you should bother learning to code when (a) no doctor I've spoken to in medtech actually codes much themselves, and (b) today there are so many good no-code solutions out there. Finally, Josh explains how to start coding for two very different kinds of medic. First, the hustlers — the entrepreneurs, the people who don't care much about the tools they use or computers, they just want to build their next startup. Secondly, he explains the path for the academic, who wants to understand the nuts and bolts, build their own models, publish papers, and work with companies like DeepMind and Google Health.

This is a really valuable episode if those topics sound interesting. I hope you enjoy.

In this conversation

  • The core argument: the people who live the problems — medics on the front line — are the ones best poised to solve them, so pairing clinical insight with even intermediate coding skill is "the golden formula" for high-quality innovation.
  • A useful reframe for busy clinicians: you don't need to become a production-grade developer to be valuable to any medtech team — surface-level skills let you spot opportunities, understand APIs, and get an MVP off the ground.
  • A genuinely 2020 time-capsule: Musty pushes back with GPT-3 and no-code, and Josh wrestles live with whether coding is about to become redundant — "even in a world where computers are doing the brunt of our programming, I can still see a role for the human touch."
  • The anti–tutorial-hell method: do just enough tutorials to "find your feet," then ditch them and build — because the real skill is creating what's in your head, not grinding exercises.
  • Two concrete on-ramps: for the hustler, WordPress/Shopify and the insight that 11 of the 12 steps to shipping an app don't need code; for the aspiring AI academic, Google's Teachable Machine and then Python. Josh's book, Code Blue, expands the whole method.

Transcript AI-generated

Musty1:19

Why should medics learn how to code?

Josh

That's a great question, and one I get asked a whole lot. The way I like to think about innovation is that you should start with a problem and then go towards a solution — rather than starting with a solution and then trying to retrofit a problem. With that in mind, the people who are experiencing the problems are actually the ones best poised to solve them. And being on the front lines — particularly in public health services, but in all sorts of public and private health services — you have really good insight into problems. Correct me if I'm wrong, but I think the UK is almost entirely public.

As a medic who sees inefficiencies or opportunities to improve health service delivery, you have access to the problem, and you need access to the skills to solve it. That's where this idea of medics learning to code comes in. Once you have very good insight into the problems a health service or a society is facing, plus a certain level of technical understanding — knowledge of what's possible with currently available technologies, and how easy it is to implement some of them — that is when you have the golden formula for high-quality innovation.

What doesn't work as well is people from outside an industry trying to come in and solve the problems for you. It can work — and of course, if we're trying to solve problems as big as the ones I'm interested in, you need professional software developers to support you — but having a firm understanding of the problem is the most important step in innovation. That's what I believe, anyway. I'm sure critics of me will say otherwise, but that's really what it comes down to: medics should learn to code because they have very good insight into health service delivery problems, and are therefore best poised to solve them. That's the main reason.

There are a whole lot of other reasons too. One is that I'm a maths and science guy — I was terrible at art, I don't knit, I don't do anything artsy or creative at all except programming. Programming is actually an outlet for me to create things: visual things, things that work, things that make my life easier. In that sense it's a fantastic escape from clinical medicine. I'm not saying learning to code will cure your burnout or fix physician mental health issues, but having things happening outside of medicine — hobbies — is a step in the right direction. For me, programming has filled that hobby in a big way and played to my strengths.

There are a couple of other reasons. You can earn extra money with programming. And if you look at AI — I had a quick look at your podcast history and noticed AI has come up a couple of times — there's a huge amount of uncertainty about where the field is going. The only thing that's really certain is that it's going to change. I can't tell you over what time frame, or exactly what the field will look like in 50 or 100 years, but what I can say is that we will absolutely need medics with technical skills to oversee and maintain the implementation of technology services.

Let's pretend for a second that IBM's Watson came in and was going to diagnose everyone in the emergency department. At some point, at some level of quality control, we're going to need medics who understand both the clinical consequences of certain decisions and the technical reasons those decisions are being made. In one sense it's a way to almost future-proof yourself — I don't really like that word, because nothing is truly future-proof, but learning skills in technology and understanding the way computers think and act can only serve to benefit you and make you more employable.

So, in summary: I think all healthcare workers — not just medics — are the people best positioned to solve healthcare service problems. It's a fantastic hobby that serves as a creative outlet, particularly for people who aren't artsy like me. You can earn money, build side businesses, make scalable impact. And it'll — in inverted commas — future-proof you, by allowing you to speak the language of both medicine and technology. Those are the headline reasons. I have essays where I talk about others at length, but that's really the long and short of it.

Musty7:40

One thing I've picked up from speaking to guests who are in medtech or academia is that they don't really code themselves — I think most of them don't actually know how to code at all. What I take away from that is that once you get to a certain stage in your career, you'd never be coding yourself, because there's so much that goes into it. If you're making a healthcare app and you want it to be production-ready, validated, bug-proof — that's a full-time thing. So it seems like: what's the point of learning to code now if you're never going to really use it in the future?

“The average medic does not need to become a developer who can create production-level apps. You can be very useful to any medtech company without being a professional software developer.”

Josh

Josh

Another great question, and one I get fairly frequently. You're absolutely right — if you're going to do the medtech thing properly, if you're going to build a healthcare app that stores patient data and is of clinical-grade quality, security and reliability, it's probably not going to happen with the two hours a month of programming practice you're putting in. It's just not going to work like that.

So the first misconception I'd tackle is this: the average medic does not need to become a developer with the skill set to create production-level apps. You can be very useful to any medtech company, and to the world in general, without being a professional software developer. It would be completely unrealistic of me to parade around saying every doctor should also become an expert web or mobile developer. Some people will do that, but it's not a realistic thing to tell everyone — the world is getting more and more specialised, so it doesn't make sense to try to do everything.

Having a surface-level or intermediate understanding of programming can get you a very long way. If you're trying to start your own medtech company or get an app off the ground, intermediate or even advanced skills — without being an expert — are enough to get your first version, your minimum viable product, off the ground in most situations. I have to be careful here, because I'm not trying to encourage cowboy behaviour where beginners go out and launch hospital medical record systems that just get hacked. That's not what I'm about. But there are a thousand shades of grey in terms of the complexity of projects. You don't need to start at that level.

You can start at the level of an in-your-pocket app, just for your hospital, that has all the hospital guidelines in it. I don't know how you access them at your hospital, Musty, but at mine some of them are taped up on the wall, some are on our dodgy hospital online portal, some of the ones on the wards are out of date — getting access to high-quality information is a little bit alarming at times. And if you're trying to build something that uses AI to look for minute signs of ischaemia on brain MRIs, you're probably not going to be writing the nuts and bolts of the data science algorithm yourself. In fact, you'll likely be using algorithms developed by the top developers in the world who've made some package at Google.

So I hear what you're saying, but to be a meaningful contributor to a team you don't have to write production-level code that's secure and reliable — that's where the whole team comes in. Having intermediate or advanced skills will allow you to identify opportunities, find the right people, and get them in the room to solve those problems. I really believe that.

Musty

What I'm getting is that medium-to-advanced skills kind of give you wings — you can go out and build your minimum viable product.

Josh

And it's not just prototyping your app or tool — you can do that in a team, or without learning to code. It's also identifying opportunities. As a basic example: understanding how an API works, how one software system can talk to another, how you can leverage that to build new technologies. Just knowing that's a thing will help you realise, "I've got this software system at my hospital and this one at another hospital — why can't they talk? Why am I double-handling information?" Just knowing what's possible helps you identify opportunities.

One of your prior guests, Ali Abdaal, who I actually follow on YouTube — I was very surprised to see he was a guest here, thought it was a terrific coincidence — has a video where he talks about reasons you should learn to code, and one of his main ones is that it helps you understand what's possible and identify opportunities for innovation. As a profession, medicine has, rightly or wrongly, a very traditionalist culture: this is the way our mothers and fathers did it, this is the way our grandparents did it. I don't know what they're teaching at your medical school, Musty, but lots of the examination techniques are dated — if you look them up in peer-reviewed journals, they're neither sensitive nor specific for whatever sign you're trying to elicit.

So much of medical education is focused on the way people who came before us did it. Learning to code is another reason to start thinking about the future in a more flexible way — it makes you more amenable to change. We need doctors who are open to technology and change in our hospitals to facilitate this innovation. Another way you can make a difference with only medium-level skills: having gone through the process of trying to implement and launch your own app of any size, you'll start to understand the challenges in the way when someone else — a big company — tries to implement a technology in your service. You'll understand there'll be teething problems, that it takes time to reach peak efficiency, that things can go wrong. That openness and sympathy to change is what a lot of our hospitals lack, particularly when they're run by consultants of a certain generation. Learning to code is a really good step towards fixing that.

Musty16:51

The second point I want to push back on. I'm very much getting that understanding how to code is beneficial from a problem-solution point of view, and also when things are being implemented around you. But there have been a lot of recent no-code solutions, and it looks like the future of coding might actually be no code. Recently GPT-3 came out from OpenAI, and from my limited understanding, what I've seen people do is literally type in their own words — "can I make a home page with a Google logo on it and a search bar at the bottom" — and it will spit out the code to do that for you. I don't think it's a stretch to say that in five or ten years a lot of people won't be coding, and clinicians will be able to use technologies like these. So my question is: if the future is no code, how important is it really to understand coding and the technology?

Josh

A fantastic question. For anyone listening who doesn't know what Musty's talking about — GPT-3 is the closest thing we have to a generally intelligent software system. It's built by OpenAI, one of Elon Musk's companies, or at least one he's heavily involved in — I don't know if he owns or founded it, but he's involved. You can literally type any instruction into a box. Not just "build me a web page with a watermelon on it," but "read my med school exam, tick all the right answers and write an explanation for each question underneath," and in a matter of seconds it will solve your exam and explain why B is the right answer for question one, why C is right for question two. You can ask it to write poems on any theme — and I'm not talking about randomly generated sentences, I'm talking about deep, funny, insightful, beautifully crafted poems with puns and cultural references. It's really quite frightening. If you haven't seen it — it's only become publicly available within the last six to eight weeks — go on YouTube and have a look at what people are doing with it. It's absolutely wild.

To answer your question directly: I'll be honest, I'm not a computer science expert, I'm not an AI expert. I'm very interested in these technologies, I muck around with them, and I'm an optimist — but I can't say with certainty what the future holds, and I don't think anyone can. I don't think even the people working on GPT-3 can tell you on what time frame their technologies will make programming completely redundant. And if we do hit a point where programming is completely redundant, then honestly, the world is going to look very, very different to how it looks now. If we can just type instructions to a computer and it programs things, I don't have a good answer for you.

But what I don't think is that this possibility — that programming may one day be completely irrelevant — is a satisfactory argument for why you shouldn't learn to code today. Even when those days come, it would be bold to suggest programming skills won't benefit you in any way. I don't have the crystal ball, and I wish I had a ripper argument to pull out here, but the scientist in me is trying to be cautious and say I can't extrapolate and see clearly what's going to happen. Still, I don't accept that alone as a reason to completely neglect programming in August 2020, just because at some point it may be redundant. And even in a world where computers are doing the brunt of our programming, I can still see situations where minute bug fixes, or minor details that need a quote-unquote human touch, mean there's still a role for it — even if there's a terrible amount of uncertainty about what the future looks like.

Musty

Maybe I've just said you shouldn't learn how to read because your phone has text-to-speech on it.

“GPT-3 obviously has more scope to be transformative, but right now it's not writing production-level apps. It's making web pages and writing poems.”

Josh

Josh

That's a fantastic analogy. Text-to-speech is a good analogy for where GPT-3 is at the moment — GPT-3 obviously has more scope to be transformative, but right now it's not writing production-level apps. It's making web pages and writing poems. It's proven to me that one day this thing will write whole apps by itself, but not today, not that I've seen.

Musty22:54

Can you talk me through how a medic who's listening, who has no background in code and isn't nerdy, learns to code? Maybe give a high-level approach, a general philosophy — because I think it's slightly different to medicine — and then a few really specific things they can go away and do.

Josh

Over the years I've formulated a bit of a template answer to this. The first thing I'd say is that, like medicine, programming — and technology in general — is a whole big world of a million and one things you can learn, that can take you in all manner of directions. Particularly when you're getting started, that feels so overwhelming. People often send me messages like, "what's the best programming language? How do I start?" And the truth is it depends case by case.

If you have a specific goal in mind — a specific app or website or tool you want to build — then while I still recommend learning to code eventually, those people benefit from teaming up. If you've got a specific app you're trying to build within the next three months, you should team up with someone. If, however, you know you want to be involved in technology and learn to code, and you may or may not have a specific app idea, here's what I think you should do at a high level: find a tutorial, or a series of programming problems that people have made — there are thousands freely available on the internet, and you can also buy excellent paid books or courses. Follow it until a certain point, and that point is finding your feet. If it's an HTML course: can I make a web page with a form, a button, some inputs? If it's Python: do I know how to store things in a variable, make a function, what a list is, what a for-loop is — do I know the basic language structures?

Once you hit that point of finding your feet, I actually think it's time to ditch tutorials and try to build things. It's this transition beginners struggle with the most. Medical students have typically done really well by finishing the chemistry book of questions — if you just finish the book, you'll be a god of chemistry and smash your exam. But the real skills of programming aren't learned by following a tutorial. Given that I've defined programming as a creative pursuit, creating is the real skill — not copying. The real skill you're trying to learn is: how do I get the vision in my head onto the screen? And the way you do that is by trying to build things, failing to build things, and then getting advice from other people.

This is a good time to mention: I really recommend getting a mentor. That can be someone on the internet, a friend who codes, or anyone doing what you want to do. Catch up with them every so often and say, "this is what I'm trying to build, this is what I've done, can you tell me at a high level how to get where I want to go?" That's a far more meaningful way to become a developer who can build things than exhaustively grinding away in tutorials. In the programming world people talk about "tutorial hell," where you're on exercise 78 of some course, going so far down into the nitty-gritty of a language, doing very specific things you're not sure why you're doing. I don't think exhaustively learning a language A to Z is the way. You learn A, B, C and D, and then you learn the next letters when you need them — when they pop up in a project you're building.

So the high-level answer: find a set of tutorials in a technology you want to learn, do enough to find your feet, and do not expect to do 300 exercises on Codecademy and then be an expert. Expect to do 40 exercises on Codecademy, then try to build something and see how you go. That's probably the main recommendation I could make.

Musty29:30

Let me give you two use cases — two types of medic I think would want to learn to code — and you tell me how your advice differs. Person number one is a hustler with an entrepreneurial spirit. They don't really care about programming or computers, they just want to build something — a web app, a mobile app, whatever — an MVP from a business standpoint, and eventually get some investment and a team going. Person number two is more of a standard medic, maybe loves the books, very interested in AI, machine learning and data science from an academic point of view. They see themselves one day working at DeepMind, playing around with machine learning algorithms, riding this wave. How does your advice differ for the two?

“You should sit down with someone who knows what they're talking about and talk about your goals, so they can push you on the right path.”

Josh

Josh

I really like that you've asked this, because — and I don't know if I mentioned this before — you should sit down with someone who knows what they're talking about and talk about your goals, so they can push you on the right path. I've spoken to people who say, "I really want to make phone apps," and they're grinding away on tutorials for a completely different technology. They don't have a curriculum or a trajectory in mind.

For the hustler — the person trying to make some side income, like many people are — learning to code, especially if they're a medic, is probably not time-efficient. I recommend everyone considers learning to code, but for someone just trying to make money or get an MVP off the ground, I think you should look at modern-day no-code solutions as much as possible. Learning to code would be a poor business decision if money in the next couple of months is your only endpoint. So you should be looking at WordPress, Shopify stores — the Shopify plugin store is so rich in terms of what's already available.

If you're trying to make a bespoke app — something new from scratch that doesn't exist in Shopify or WordPress or any other ecosystem — I have a whole blog post where I go into my methodology. The long and short of it is that, in my opinion, 11 of the 12 steps required to get an app off the ground don't require programming skills. Obviously one of those steps — I think it's step 10, "build the thing" — is fairly big. But there's a whole lot around the app: acquiring your first users, designing it, writing its content, marketing it, branding it.

So to the hustler, I say: get onto those 11 steps and get a long way down the rabbit hole. Design your app — what does it look like? Write its content — what does it actually say on each screen? If it's a trivia app, what are the questions? If it plays music, what music? Then go to your university's entrepreneurship division, go to a hackathon, go to an event, and say, "look how far down the rabbit hole I am, I'm on a trajectory for success — who's coming with me?" and find someone to work with. What a lot of people do is come to you with a blank table and say, "I've got this zillion-dollar idea — you build it, I'll do the marketing, and we'll go halves." As a programmer, that's just not a compelling proposition. What you're trying to do is create the sensation that a train is going somewhere whether you're on board or not, and it's leaving the station now, so you need to get on. That's how you pitch a programmer — you sit them down, pull out your laptop and say, "these are my mock-ups, this is how many people are interested, this is what the content is going to be." That's how you show them you're serious.

I'm conscious of the time, so I'll quickly answer your second question, Musty — the more traditional medic interested in AI and data science. Before I answer: have you by any chance heard of a thing called Teachable Machine?

Musty

No.

Josh

All right. For any AI wannabe — like myself — or medtech wannabe: when you get home, fire up your computer and pull up Teachable Machine. It's an open-source tool made by some very smart AI engineers at Google, and it helps you make surprisingly powerful AI models just using your webcam — or photos you upload, sounds you upload, anything you upload. It'll look at the datasets and do some really cool stuff with them.

Let me give you an example. Open up Teachable Machine and make a fist, like you're playing rock-paper-scissors — a rock. Take about 100 photos of your rock. Then in another dataset, do paper, take 100 photos. Then scissors — you can't see me, but I'm making the scissors gesture like a lunatic. Run the model, and within about 20 seconds this machine in your browser will look at all the photos, identify the common theme between them, then analyse your webcam live and tell you which of those three classes best fits. Make a rock and it'll tell you it's a rock. That is the absolute best way for someone who knows nothing about AI or data science to get a sense of the key principles: labelling data, putting it into classes, and then the algorithm that assigns the best-fit class based on a given input.

So to that person, that's how you start. Go and play around with Teachable Machine, make some cool models that identify your housemates or your pet. You can go File → Export and drop that model into a phone app, a website, even a podcast if you wanted — it exports as a JavaScript file you can drop into any application. It's just unbelievable what you can do with it.

In terms of learning nuts-and-bolts programming beyond that, the road is a little less clear — and again, I'm not an expert in AI or data science. But for that person, Python is absolutely the best place to start. It's one of the world's most common programming languages, and lots of really good data science and AI libraries exist for it. Just learn the basic structure of the language and muck around with it. Because it's so common, there are lots of good free tutorials that vary in quality, like everything on the internet. And then there are some really good Google conferences where you can watch talks from brilliant Google engineers who — as well as being fantastic programmers and scientists — are excellent communicators. You can watch lectures like you would for a university course, pretty much for free. So that's the quick recipe to dip your feet in. But yeah — Teachable Machine, check it out, it's awesome. You won't regret it.

Musty39:37

I hope you enjoyed that episode. You can find Josh on Twitter at @_JoshCase, and if you've been enjoying the podcast, please consider leaving a review on iTunes. Thank you.