A little bit of background information about myself: I am both a practicing dentist and a software engineer. I write code Tuesday through Thursday and and see patients Friday through Sunday. Before I was a dentist, I used to work at companies like Allstate Insurance, Lockheed Martin and ICS. With both skills under my tool-belt, I noticed there are a number of things that software engineers can learn from dentistry and vice versa. I decided to write a few of them up in case they can help anyone. This is all free advice so don’t assume this will be perfect for each situation.
A surgeon could have the best hand skills in the world, but it means nothing if they don’t know what they are doing or why they are doing it. In medicine / dentistry, we value the doctors ability to diagnose (Dx) more than their ability to simply treat (Tx).
I have noticed the same should be applied to software development. I have worked in a number of successful software projects. I have worked on many more failed projects. I have never heard, either first hand or second hand, of a project getting delayed or canceled simply because one of the engineers couldn’t figure out the correct optimized algorithm. It is normally, “we don’t have enough time to write everything for release date” (most common), “there is a show-stopper bug, we don’t know how to fix it”, or insert bad management decision here. When I see engineers (including myself) struggle, it is rarely when I need to write new code; it is often when I need to debug existing code.
As such, whenever I interview any software engineer, I actually don’t ask them to write new code. I have them remote in to a VM that is running a full SDK, review code that has a few bugs in them, and ask them to explain why the bug is happening.
It is one skill to know how to invert a binary tree, but it is another skill to see flawed code that inverts a binary tree and know why a node gets lost when N is odd.
Very often in dentistry, patients insist I do some really bad ideas; mostly for financial reasons. Like, instead of a crown, the patient wants a MODBL posterior composite; which sounds good at first, but will be a huge disaster after a couple years. Some patients are OK with that. For such bad ideas, I do an additional consent form that simply says “I understand this is a bad idea, but I am going ahead with it anyway” (this is on top of the normal legal consent forms that I use).
I actually think that this idea should be applied in software development. A lot of times, customers have a really bad idea and all the engineers know it. There could be meetings where it was brought up multiple times but the customer simply ignored it to save money. For this, I actually recommend a very simple consent form. It doesn’t have to be a legal document, it doesn’t have to be a contract, and it doesn’t have to be that long. It simply says something like “I, Joe Customer, understand that after talking to the engineers, that screen recording everybody who uses the app is a bad idea” and maybe outline a few bad consequences of that decision.
Here’s the thing: most people, especially customers, really hate it when they are told “I told you so!”. With this consent form, there is actually no need. They know you went out of your way to have them sign it; and they will remember it even if they don't want to admit it. There is no longer a blame game because they already know what they did and there is no need for you to remind them; even if they don’t admit that out loud.
There are a few valid reasons to have a meeting. One is to have a group of people make a decision on a subject, other is to disseminate information. In the latter case, many people have found it unnecessary, creating the whole “This meeting could have been an e-mail” meme. But here is the truth: most people don’t read their email. Even if they do, they will skim it very quickly. A lot of times, the meeting is scheduled simply because they want to make sure everybody to be on the same page about a specific subject.
In medicine and dentistry, we actually have a lot of online Continuing Education (CE) courses that can be done on-demand. A lot of them are simply reading an article or watching a video. However, at the end of the presentation, there is a short quiz to ensure the doctor actually read the article or paid attention to the video.
Same can be done for a good number of meetings. Let say you are in charge of 25+ developers and you need to make a new rule like “all bug reports set to resolved must have the patch commit id in the comments”. If you send out an email, most people won’t read it and still resolve bugs without a commit id. If you do a meeting, you not only took up 30-60 minutes of everyone’s time, but it takes a while for the developers to get back to their “zone”. With a mandatory but short quiz, you not only have developers take it when they are between tasks, but you are more likely to ensure they actually read the presentation / document rather than just zoned out during the whole meeting. Make sure the quiz is actually scored rather than just a "poll". Why? Because if you are looking for feedback about a new policy, I can promise you that people will give you their piece of mind if they disagree with the score they got on the quiz.
Not that long ago, I was reviewing one my patient’s bitewing radiographs (x-rays) and noticed the fillings on her teeth looked very bad. It was almost like the doctor didn’t know how to use a matrix to place the composite. However, after looking at the patient’s mouth, I realized what actually was going on: her teeth were tilted in such a way that it was very difficult to place any composite and the doctor that did the fillings did an awesome job given the circumstance. Most doctors don’t make any judgment about their colleague until they get the full picture. As much as we would like to think “Ha! That doctor sucks! I can do a much better job!”, we weren’t there when the procedure was done and we can’t make any real judgment on the other doctor until we know the whole story. As such, when we see some treatment that looks odd, our first thought is “OK, something must have caused the doctor to do things that way”.
I think the same should be applied when reviewing code. It is easy to look at code and say “Wow! This code is terrible! They should have done it X instead of Y” when it is isolated from the rest of the environment. For example, a long time ago, I was reviewing some Java code that looked terrible. There were a bunch of constant integers when an enum would have made more sense. My first thought was “doesn’t this guy know about enums?” and then I asked my co-worker what was going on. He said “oh yeah, that code was written before Java 5 so he couldn’t use enums back then”. I then realized I shouldn't have judged the developer when he was just doing the best he could.
So whenever you look at terrible code or terrible decisions in a project, don’t make the first assumption that the coder was an idiot. More likely than not, it was because of a bad situation and the developer was trying their best to make things work in that environment. In the off chance you do get the full picture and it still doesn't make sense, then you are welcome to make your judgements ;-).
Often times, doctors need help in using a dental product. We can get the basic information on how to use said product from the manufacturers but the problem is that the manufacturers don’t actually use whatever material we buy on a daily basis. Sure, they do some testing but they don’t internally have the knowledge of how to use certain materials in a clinical situation. For that, we normally talk to other doctors for tips and techniques. Having trouble getting the Garrison matrix out? Use the patient forceps, grab the band and spin it around. Having trouble impressing the palatal vault? Place a ball of alginate directly in the vault and then place the tray. The true pro-tips are from other dental and medical providers.
As such with software development. Just because a company makes an SDK / API / Toolkit, that doesn’t mean they will be the best source of how to fix whatever problem you are encountering. The best people to talk to are fellow developers who are using said software. Sometimes, they have better “best practices” compared to the actual company that made it. Some companies have strict policies in that developers are not allowed to talk to other outside developers about their issues. I think this is a mistake in the long-term because speaking to other developers who use the SDK can be invaluable and such a strict policy can undo whatever benefits the secrecy may provide. I’m not recommending developers break their NDA; I just think they need to start asking the higher ups to be more lenient about what they can and can’t post online.
So, that’s about it for now. If anybody is interested, I can also make something for the opposite (“Five things doctors can learn from software engineers”). As mentioned before, they are not perfect for each situation but hopefully it will help somebody.