Why software developers can learn from dentists

Why software developers can learn from dentists

First a little about me: me and

practicing dentist

and

software developer

. From Tuesday to Thursday I write code, and from Friday to Sunday I see patients. Before becoming a dentist, I worked for companies such as Allstate Insurance, Lockheed Martin, and ICS. Having mastered both these professions, I have noticed that software developers can learn a lot from dentists and vice versa. I decided to write down these lessons in the hope that they can help someone. These are just general recommendations – do not expect them to be ideal for any situation.

▍ Dx skills are more important than Tx skills

A surgeon may have the most dexterous hands in the world, but it is worthless if he does not know what he is doing and why he is doing it. In medicine/dental treatment, we value doctors’ ability to diagnose (diagnose, Dx) much more than their ability to simply treat (Tx).

I noticed that this also applies to software development. I got to work on many successful software projects and many more failed ones. I’ve never heard of a project being delayed or canceled just because one of the developers couldn’t come up with an optimized algorithm. Usually the reasons are as follows: we don’t have enough time to write everything before the release date (the most common), a serious bug has appeared and we don’t know how to fix it, a bad management decision. When programmers (myself included) run into problems, it’s rarely because new code needs to be written; Most often, the reason is the need to debug already existing code.

That’s why when I interview a candidate for a developer position, I usually don’t ask him to write new code. It remotely connects to a VM running the full SDK, analyzes code with multiple bugs, and explains why the bugs occur.

Being able to invert a binary tree is one skill, but finding the wrong code to invert a binary tree and explaining why a node is lost at odd N is quite another.

▍ Clients must explicitly consent to very poor decisions

In dental treatment, my patients often insist that I do very bad things; it is mainly due to financial reasons. For example, when a patient wants a composite restoration instead of a crown; It seems like a good idea at first, but after a few years it turns out to be a disaster. Some patients are fine with it. In such cases, I ask you to sign an additional consent form that essentially says “I understand this is a bad idea, but I still want it” (this form is also used with other forms of legal consent).

I believe that such a principle should be applied in software development. Very often, customers come up with very bad ideas, and all engineers understand this. You can have meetings where this topic comes up many times, but the client simply ignores all the evidence to save money. In such a case, I recommend drawing up a very simple form of consent. It does not have to be a legal document or contract, and the form should be particularly long. It should simply say, “I, im, after discussing with the engineers, realize that recording the screen of all users of the application is a very bad idea,” plus perhaps some examples of the consequences of such a decision.

Here’s the point: Most people, especially clients, hate being told “I told you so.” After signing this form, such a need will not arise. The client will know that you were forced to ask them to sign the form; and he will remember it, even if he does not want to admit it. There will be no more “blame the other” games because the customer will already know what they did and you won’t have to remind them of it, even if they won’t admit it out loud.

▍ Replacement of (some) meetings with tests

There are several good reasons for organizing meetings. For example, for a group of people to make a decision on a topic or to spread information. Many people consider the second reason optional, which even spawned the meme “This meeting could have been an email.” But the truth is that most people don’t read emails. And if they read, then only for a moment. Very often, a meeting is organized simply so that everyone is well informed on a certain topic.

There are many continuing education courses in medicine and dentistry that can be taken as needed. Many of them consist of simply reading an article or watching a video. However, there is a short test at the end of the presentation to ensure that the doctor has actually read the article or watched the video carefully.

The same can be done with a good part of meetings. Let’s say you manage twenty-odd developers and you need to create a new rule, for example, “all bug reports with a status of resolved must have the commit id with the patch in the comments.” If you send emails, most people won’t read them and will continue to change the status of bugs without commit ids. If you hold a meeting, it will take not only 30-60 minutes from each employee, but also the time needed to get back on track. If you have a mandatory but short test, not only will the developers be able to pass it between tasks, but they will also be more likely to read the presentation/document instead of floating in the clouds during the entire meeting. The test should be graded, not just a survey. Why? Because if you want feedback on a new policy, I guarantee that people will share their opinion if they are unhappy with the test score.

▍ When you see a strange or absurd decision, first of all assume that the colleague is competent and the circumstances are unusual

Recently, I was analyzing the dental x-rays of one of my patients and noticed that the fillings looked very bad. It was like the doctor didn’t know how to use the composite matrix. However, after examining the patient’s mouth, I understood what was the matter: her teeth were so misaligned that it was very difficult to apply the composite and, given the conditions that the doctor was placing fillings, he did an amazing job. Most doctors do not evaluate the work of their colleagues without getting the full picture. No matter how much we would like to say: “Ha! Terrible doctor! I could have done better!”, we were not there during the procedure and we cannot judge another doctor until we know the whole story. Therefore, when we see the results of treatment, which look strange, the first thing we think is: “Probably something made the doctor do this.”

I think the same principle should be applied when analyzing the code. It’s easy to look at the code and say, Wow! This code is terrible! The developer should have done X instead of Y” without first examining other circumstances. For example, once upon a time I was analyzing Java code that looked terrible. It had a bunch of integer constants, although it would have been smarter to use an enum. First of all, I thought: “What, he doesn’t know about enum?”, and then I asked my colleague what could be the reason. He replied, “Ah, yes, this code was written before Java 5, so it couldn’t use enums.” And then I realized that I shouldn’t judge the developer, because he did the best that was possible in his conditions.

So whenever you see terrible code or terrible decisions in a project, don’t assume the coder was an idiot. It is much more likely that the reason was a bad situation, and the developer tried his best to do his job well, given the existing circumstances. You can condemn the author only in those isolated cases when you have the whole picture, but the code still doesn’t make sense.

▍ It’s better to talk to the people who use the product than the people who created it

Most often, doctors need help in using dental material. We can get basic information about the application of this material from the manufacturer, but the problem is that the manufacturers do not use the materials that we buy in our daily work. Yes, they do the testing, but they have no knowledge of how to use the materials in a clinical setting. Therefore, we usually turn to other doctors for technical advice and tips. Having trouble extracting the Garrison matrix? Use the clamp, grab the ring and turn it over. Is it difficult to make a cast of the palate? Place a ball of alginate mass directly on the vault and then press the plate down. You can only get really useful advice from other doctors and technicians.

The same principle applies to software development. Just because a company develops an SDK/API/toolkit doesn’t mean it’s going to be the best source of information for solving the problem you’re facing. It is best to discuss them with fellow developers who use the software. Sometimes their “best practices” are better than the company that created the product. Some companies have strict policies that prohibit developers from talking about problems with external developers. I think this turns out to be a mistake in the long run, because talking to developers using the SDK can be an invaluable resource, and such strict policies can negate the benefits of stealth. I do not recommend that developers violate their NDA; i just think they should ask management to be more lenient about what they can and can’t post online.

Telegram channel with discounts, prize draws and IT news 💻

Related posts