Skip to content

Career and Context

Becoming a clinician-developer is, mostly, a thing you have to do at the edges of a clinical career. This chapter is about how to do that without burning out, falling out with your employer, or losing your sense of why you started.

Making time to code as a clinician

There is no perfect answer. Everyone I know who has built a real thing as a clinician-developer has done it in a way that wouldn't suit anyone else. A few patterns I've observed:

  • Protected time. Some Trusts and primary care organisations will fund a session or two a week of formal informatics or development time. Ask. The worst answer is no.
  • Research time. A research fellowship or academic post often comes with significant non-clinical time. Software is increasingly research output in its own right.
  • Out of hours. The traditional answer. Sustainable for a project of finite duration; not sustainable as a permanent way of life.
  • Going part-time. Trading clinical sessions for development time. Practical if you can afford the income drop and your speciality allows it.
  • Leaving clinical practice. A small number of clinician-developers eventually move full-time into health technology. This is a real option, with real trade-offs.

Most clinician-developers are doing this in fragments: an hour here, a Sunday morning there, a fortnight of focused effort during annual leave. Be honest with yourself about how much time you actually have. Build for that, not for the time you wish you had.

How to talk to your employer about coding projects

A few practical pointers:

  • Frame in their language. Your employer thinks about patient outcomes, throughput, cost, and risk. Frame your project in those terms. 'A tool that saves clinicians 30 seconds per consultation' lands better with management than 'a thing I built'.
  • Get permission in writing. If you're going to use NHS data, NHS systems, or NHS time, you need explicit permission. Information governance, intellectual property, and clinical safety all come into play. Vague verbal nods are not enough.
  • Be transparent about what you're building and why. Skunkworks projects that get discovered tend to end badly. Projects that have been openly discussed from day one tend to find supporters.
  • Know who owns the IP. If you build something on Trust time, on a Trust laptop, with Trust data, the Trust may have a claim on it. NHS IP policies vary. Read your contract; ask HR for the policy; get clarity before you publish.
  • Open source is your friend. A project that's open source from the start avoids most IP arguments later: nobody is going to fight about who owns code that's already MIT licensed.

Contributing to NHS digital transformation from the inside

If you want your work to influence how the NHS builds and buys software, a few routes:

  • Join the FCI (Faculty of Clinical Informatics). It's the UK's professional body for clinical informaticians, with a membership pathway and increasing recognition.
  • Get involved in standards work. NHS England, HL7 UK, and the openEHR International community all have working groups that need clinician input. The standards we live with are mostly written by the people who turned up.
  • Contribute to NHS open source. A growing amount of NHS-built software is open source. Find a project, fix a bug, send a PR. NHS England maintains an open-source community.
  • Speak at events. Conferences and meetings. The clinician-developer voice is undersupplied.
  • Run for elected roles. Royal College specialty committees, BMA committees, ICB clinical leadership groups. These are the bodies that influence NHS digital decisions; they need members who actually understand the technology.

A theme: the NHS digital landscape is shaped by the people who show up. If you want better software, the most powerful thing you can do is be one of those people.

Finding your people

The community chapter (Community) covers the practical mechanics: where to find the forums, the conferences, the chat platforms.

What that chapter doesn't say is this: the people are the point. The technology will change, the standards will change, the frameworks will be deprecated. The community of clinician-developers you build a friendship with this year will, with luck, be the people you collaborate with for the next decade. Invest in those relationships.

The honest version

This work is harder than it should be. The NHS is not, as an institution, set up to support the clinician who codes. There is no career structure, no formal training pathway (yet), no widely-recognised qualification, no clear progression. You will spend energy explaining yourself to managers who don't quite understand what you're doing.

You will also, with a bit of luck and persistence, build something useful, work with brilliant people, and have more impact on the NHS than you would by doing only clinical work.

It is, on balance, worth it. But go in with your eyes open, and be kind to yourself about the days when nothing seems to work.