As clinicians, the tech world can seem like a daunting place. What’s a framework? Which programming language does what? What type of developer should I hire or work with? I want to build an app, what does that involve? Whilst I love the ideas and work ethic that some of the clinicians I speak to have. I cringe at their stories when they work with developers. It’s not all doom and gloom. There have been some great projects that have produced results, however, I have heard my fair share of clinicians who have paid money to a developer, only not to get what they asked, and have in cases been extorted for more money. There are many factors that are involved, but please, if you’re going to hire a developer or work with them, look at their Github.

So what can Github tell you? It can’t enable you to read the developer’s mind, but it can give you an insight into how active and skilled a developer is. This is because Github is a vital tool for coding in a team. When a project is underway, developers pull branches off the master or develop branches (where the main code of the project is stored). They then write and test their code. When they have finished with it, the push to their branch. They then pull their branch into the main branch. A supervisor will then look at the code and approve the merge:

 But it’s more than that. The Github timestamps and classifies what language you coded in every time your code gets merged with the main trunk. In a sense, Github is a CV. You can look at someone’s Github account and get a sense of how much someone codes, and what repositories they are contributing to. This will not tell you everything, but it will tell you a lot. For instance, a lot of none technical people are too impressed with academic achievements when looking for a developer. I’m not completely dismissing academia, I’ve spent 7 years at university myself. However, coding is like medicine. You can get those people who completely ace their exams, do a Ph.D. before graduating med school. But you would not want them running a busy ED department fresh out of med school because they did a Ph.D. over someone who didn’t do the Ph.D., but has an extra 4 years clinical experience in the ED. Managing difficult patients, learning from experience, catching the nuances and acing those practical skills all build towards making a doctor a good clinician.

An experienced clinician is not wowed by the academic titles of a newcomer in terms of clinical competence. However, I’ve heard clinicians get excited because they have found someone who has a Ph.D. in machine learning. Sounds impressive right. Well like the fresh med school grad who has a Ph.D. whilst still at med school, it means he can help you with a specific area of machine learning. However, how is he when it comes to working with a team, solving merge conflicts, or integrating the machine learning into a system? For an example lets look at my own Github:

The darker the dots, the more code was committed. I did a postgrad at UCL, where I worked on 3D mapping in surgical robotics. I got a distinction for the project. I even used some machine learning to filter out some of the noise…. seems pretty fancy, however, look at my Github. I was working on the project between the months of May, June, and July. There was barely any commits. On the other hand, I started coding for a financial tech firm in central London from Oct onwards. The difference between the two was that during the post-grad, I was only writing code to solve the math problems and get a single script to obtain and clean the data from the sensor. In the job at the financial tech firm, I was also working on problems such as machine learning. However, I had to work in a team, plum inputs to a database, and then through the server to the front end. Consider security and logins, backups, different code releases, running the backend and front-end with different task runners. Sometimes different merges from different developers would clash and I would have to solve the issue, and database migrations would not always go smoothly. Uploaded code had to be tested for a range of situations so I became proficient in coding unit tests, which created fake instances in a test database, and ran the functions through a range of different scenarios. Sometimes there would be an error, and the team would be under considerate time pressure to diagnose and solve the problem.

Clearly consider other factors when working with a developer. But just like you wouldn’t want to be operated on by a fresh-faced medical grad with a Ph.D., do not entrust your software product to a new grad because their degree sounds fancy and it’s from a good university.