EMS & Coding - Shared Skills
![](https://res.cloudinary.com/strozstuff/image/fetch/https://idmqjyw9i2ib.objectstorage.us-ashburn-1.oci.customer-oci.com/n/idmqjyw9i2ib/b/blog/o/2022/ems.jpg)
Many people close to me (and quite a few who are not that close) know that before I started my career as a developer I worked as a paramedic for almost 15 years. When my family and I left New Jersey in 2004, it was the first time in almost 20 years (dating back to when I was 16) that I did not have a job in the medical profession. I often get asked how I made the switch from being a paramedic to being a developer (a story I will share here at some time) as they seem to be drastically different careers. However, over the years, I have discovered that a lot of the skills I used as a paramedic I still use almost every day.
Differential Diagnosis
For those not familiar with 'differential diagnosis, it is a medical term for coming up with a list of possible causes of symptoms a patient is experiencing and then systematically eliminating items from that list as you gain more information. Sound familiar? In the development world, we call it ‘troubleshooting’. Just like medical personnel assess a patient to gather information about them, we start gathering information about the issue that was reported. We need to know what is happening and how is it different than what is expected. We also need to know how to consistently reproduce the issue so we can verify our fix addresses the issue. As we gather this information we mentally start building a list of what could be causing the problem. We also start building a list of things we can do to fix it.
Hunting Zebras?
Once we have narrowed down the list of possible causes, we need to start implementing our ideas on how to address the issue. We would do the same thing with a patient. Once we had a good idea of what was causing the symptoms, we can start treating them.
There is a saying in medicine similar to this:
When you hear hoofbeats, don’t go looking for Zebras
What this means is that you should look for the more common causes of an issue before you look for the rare causes. So, once we have our list of possible causes, we should look at the ones that are more likely and address them. If a patient is having chest pain, it is more likely the result of an issue with their heart than some exotic disease. When we try to fix the more common issues but the problem persists, we start to move to the rarer causes.
Thinking Outside the Box
To continue our analogy from above, if you have determined the hoofbeats are not from a horse you need to be able to figure out what animal we are dealing with. Now, we probably still don’t want to jump right to zebras, but we need to start thinking maybe it is a donkey or goat. This is where thinking outside the box comes in handy. We need to be able to look at the information we have at hand, including what treatment has not yet worked, and come up with less than common causes or treatments for an issue. I cannot begin to count the number of times I have looked at a problem with some code and thought, “There is no way it can be x
could it?” and sure enough it was x
.
Trust Your Gut
This is something you can only do when you have gained enough experience, but, it is a valuable part of troubleshooting. There were numerous times in my career in EMS where my gut told me it was one thing even if the patient did not present a ‘textbook’ way where my instinct was correct. This is not something a new developer (or medical professional) is going to have as they start their career, but they quickly learn to use their experience to guide them in the future.
Staying Calm Under Pressure
Some of the most chaotic calls I have had as a paramedic were at big family functions - such as weddings - where there are a lot of people who know and care about the patient. They are all upset, and they all want to offer some help. One thing I learned was, in those cases, I would ask everyone to keep quiet and ask for the person who knows more about the patient than any other, and then I would talk only to them. This mitigated a lot of information being hurled at us so we could assess the situation more easily. It also often helped calm the crowd as it gives an impression you are in charge and can handle the situation. Walking into scenes of sheer chaos, people often looked to us to be the beacon of hope. If we showed our stress it only served to make the situation worse.
No matter how bad things are when you have a show-stopping bug in production, it really can’t match the pressure of having to make life or death decisions for a patient. But, that does not mean it’s stressful. In some cases, incredible amounts of money can be lost with every minute that a bug in production is not addressed. You can have people looming over you as you try to work. It can be incredibly stressful. When the stress is amped up, it is important to remain calm. Remaining calm not only helps you think more clearly but can also have a calming effect on those around you. The calmer everyone is, the easier it is to do your job.
Continuing Education
As a paramedic and a developer, I have worked with people who thought they did not need to improve their skills or knowledge. People who thought they didn’t need to learn anything new because they have been around long enough and have seen it all. These are people, who ask “we have been doing it this way for years, why do we need to change?” I loathe working with these types of people. I crave knowledge. I always want to learn new/better ways of doing things. The best developers and paramedics I worked with were the ones who not only wanted to learn as much as they can but those who enjoyed sharing that knowledge.
If you are a developer or medical worker who thinks “I don’t need to learn anything else, I know enough”, your career has already passed you by.
Wrap-up
I am certain other skills carried over from my old career and helped me be successful as a developer, but those above are the ones that have become most obvious to me (While it may be a neat party trick, I’m not sure being able to scarf down an entire meal in 90 seconds helps me be a better developer). A lot of these skills are ones that need to be honed over time. They also need to be used or they become dull and ineffective.
While people’s lives are no longer in my hands on a daily basis, a lot of the skills that made me a good paramedic helped me have a lot of success as a developer. I imagine a lot of these skills would bleed over (pun intended) into other careers, as well.