Chapter 1: How to Learn to Code

The first chapter of my programming book "Code Blue"

The following excerpt is the first chapter from my book Code Blue: An Introduction to Programming for Doctors and Medical Students. If you're interested, you can find the book here.

Congratulations on deciding to take the plunge into the wide world of computer science.

I guarantee that at the very least, learning to code will provide you with a new perspective on brilliant ways to provide higher levels of care to your patients. To keep them safer. To keep them out of hospital. To serve them faster. To prevent unnecessary readmissions. To educate them, their families and your colleagues. To lower healthcare costs. To provide better healthcare access to the vulnerable and marginalised. To freely and effortlessly share healthcare information and to discover ways to anticipate diseases before they arise.

At the very most, learning to code will give you a means to scale your impact as a clinician to the level of global significance. To redefine entire chapters of what constitutes “good medical practice”. To craft research tools that will cure disease. To add untold volumes of knowledge to the healthcare information ecosystem. To improve the lives of tens of millions of people. To leverage the power of technology to further mankind forever.

By choosing to read this book, it’s clear that you understand that there’s a better way to care for our patients.

If we’re going to push our healthcare services to new heights to serve our ballooning, ageing and ailing global population, we’re going to need to develop new technologies that allow our healthcare services to scale faster than our healthcare needs do.

But how do we dip our toes into this big, wide and frankly overwhelming world of technology and programming for the first time - with little to no IT background, and a whole lot of raw ambition to improve patient care?

This chapter - and in fact, this book - aims to answer these questions. Even if after reading this book you’ve forgotten every single tip and trick about programming, if you said “I now know the principles of how to learn to code”, I would consider this text a success.

To start with, I’d like to set some expectations.

✅ Expect to be challenged

I’ll confess. Learning to code is not easy. Having said that, it’s nowhere near as hard as it seems from the outside. And besides, if you work in health, or have made it through university, there’s no doubt in my mind that you can do this - It’s easier than the citric acid cycle.

✅ Expect to be frustrated

Ask any programmer - long periods of frustration while you’re learning to code or are building something new are entirely normal. This can lead beginners to feel like it’s not for them, or that they can’t do it. I assure you, you absolutely can. Programming is less about being brilliant, and more about being stubborn enough to say “I can definitely do this”. Over the years I’ve found that when I’ve encountered a problem I can’t fix, I take a break and return 15 minutes to 24 hours later. Often, the problem will be fixed within minutes of returning, despite hours of frustration beforehand. It sounds trivial, but this tip alone can save you lots of time and effort.

✅ Expect to be inspired

Once you start to understand what’s possible with programming, you’ll start to see a million new avenues for improvements to patient care. This can be both inspiring and overwhelming at the same time. As it starts to happen, your resolve to improve both your crafts (clinical medicine and software development) will strengthen greatly. Consciously tap into this steady flow of inspiration and channel it towards frustrations that arise as you build your skills.

✅ Expect to need help

If you went to medical school, unbeknownst to you, you likely developed extraordinary self-directed learning skills. You had to memorise enormous amounts of information very quickly, and had to know how to apply it in just the right situation. This has probably given you a deservedly strong sense of independence when it comes to learning new things. However, as a clinician, your time is precious. Therefore, you’re going to hit points where the fastest way for you to proceed is to seek direction from someone else. So, don’t be afraid to ask for help.

❌ Don’t expect to be an expert overnight

Rome wasn’t built in a day. You didn’t become a doctor in a week, and you won’t become a software developer in a week, either. Having said that, ask any senior developer: there will always be conversations that still go over your head. It’s just like medicine - no-one knows everything in the land of programming. So don’t let the absence of expert status stop you from building what you want to build, or solving the problem you want to solve.

✅ Expect to be able to make a difference, even if you’re not an an expert

I’ll often hear clinicians say things like “I don’t have the time to learn programming to the point where it becomes a meaningful skillset”. While this concern does have an element of truth to it, it’s based on an unsound premise. To be clear: you do not need to reach expert status to become “useful” as a clinician/programmer. It’s unrealistic to expect that every clinician who read this book will become an expert, simply from the amount of time investment that’s required. What’s more realistic is that with an intermediate skill level, a clinician will become far more attuned to the opportunities that technology provides. They will also become aware of the risks it poses to good quality patient care. Society needs clinicians who understand technology; both to push for new frontiers of innovation, and also to safeguard their patients and their privacy as new untested technologies emerge.

With that out of the way, I’d like to share some more specific principles about how to approach the monumental task of learning to code.

Firstly, I think you should find one or more mentors. Ideally, they’re someone you trust and aren’t trying to sell you a shoddy “Learn to code” pdf ebook. Finding a mentor is important because while they can’t do all the work for you, they can help you ensure that the effort you’re investing is aligned with your goals. For example, if you want to build slick modern mobile apps, there’s little to no point grinding away on a niche language like R. Unfortunately I see lots of beginners who are hacking away on a list of problem sets from a website with little notion of why they’re learning that skill at that time, and what they’re going to do with it afterwards. This book intends to provide a plan for you long after you’ve finished reading it.

In addition to finding mentors you trust, you should try to mingle with developers who are more experienced than you. Follow them on Twitter or YouTube. Consume their content. Go to meetups and ask them questions. Look at what they’re building, and ask them how they did it. Look at their open source projects on GitHub. By far and away the greatest source of learning I have had in my career as a software developer is from other developers. If you’re looking for some developers to follow related to your niche and interests, send me a message on Twitter and I’ll try to share some of my favourites with you.

Reading this book might give you the impression that I’ve got every little detail of every language we use memorised. That’s far from the truth - this isn’t a medical board exam. In fact, developers often joke about how little development we actually know and remember. Software development is like an open-book exam. You’ve always got the “textbook” or language documentation open while you’re building things. In that sense, it’s far less important to remember every little miniscule detail about how to do x/y/z in a given language, and far more important to remember that it’s possible to do x/y/z. This will enable you to focus on the bigger picture of designing your applications without worrying about the nitty gritty details until it comes time to actually build them.

I’m strongly of the opinion that whichever language or project you choose to start learning to code on, you can end up with the skills to do whatever you want with programming. However, not all of those journeys are of equal length. As a time-poor clinician, it’s important to try and be targeted in what you want to learn. The fastest way to get the skillset you want is to deliberately learn languages and technologies that will get you there, rather than flounder aimlessly. I’m always happy to take a message from you to discuss your individual goals and what I think you should learn to help you get there, however I thought I’d share the headlines here:

A language like Python is great for AI and automation, and can also build powerful websites (YouTube is built on Python!). While less beginner-friendly, a language like Dart (and the Google UI framework Flutter) is one of my absolute favourites and is great for building cross-platform mobile apps. Tools like the C-based languages (C, C#, C++) are extremely powerful, however in my personal opinion, are not suitable for beginners. Java is also powerful but in my opinion, not beginner friendly.

I appreciate however that the vast majority of the readers of this text will not necessarily have a clear idea of what they want to build just yet. This is normal - the world of tech is so overwhelming. You’re spoilt for choice and opportunity.

With this in mind, I believe that everyone should learn the absolute basics of web development to begin with. There are several reasons for this. First and foremost, starting with the “decoration and structure” languages of HTML and CSS immediately grants the programmer the capacity to create something visual, like a user interface, web page or app UI. I consider this an important feedback loop to help you continue to stay motivated to learn. Additionally, knowing some HTML/CSS is essentially the backbone of the internet, and it gives you a lot of flexibility in terms of the projects you might work on. For example, if you’re on a team building a mobile app, you’re still likely to need a landing page, a server to store your users’ data or some other sort of web presence. If you’ve built a consumer AI product, you might need some sort of web page to wrap it in. Not to mention, if you add in a little bit of server-side logic with a language like PHP (as used in this book), the possibilities for the things you can build expand very quickly.

So, if all of this discussion about language specifics is overwhelming you, don’t worry. We’re going to break it down piece by piece in future chapters. For now, just know that in this book we’re going to be building web apps with PHP and HTML/CSS. The reason for this is that it’s a very good general set of skills to develop that will be at least partially beneficial to you regardless of whether you want to go and build mobile apps, make some AI models, harness automation, or get into anything else afterwards. Additionally, I’m going to do my best to generalise the teaching points about programming, rather than focusing on PHP specifics. This will give you the knowledge you need to hit the ground running in any other language, too.

Before we dive into the good stuff, a few final words about learning to code:

Learning to code is just like learning any other skill - practice makes perfect. The more you can code, the better you will become. I encourage you to timetable some time that you set aside for “programming time”. A handy way to do this might be to get up 1 hour earlier one day a week.

Start small. If you’re like me, you might have wild ambitions about a software tool that will be poised to change the world overnight. This is great - I strongly encourage ambition with tech. However, when learning, I found that keeping things smaller and simpler was easier to manage and ultimately led to faster progress.

Keep your eyes open and look at what other people are building. Look at their interface design, their source code and the value they are able to create with their applications. Ask yourself, how can I take the best bits of what they’ve done, and apply it to my own projects? How can I get to that level?

Know that the apps you will build at first will have flaws - and be okay with this. This is normal. Don’t let it stop you from building what you want to build. As you get more and more skilled, you can tear down old parts of your applications and rebuild them. This is a normal part of the development process.

Be patient. You’ll get there. I’ll help you!