Over the past ten years, Daniel Mullins has worked at four Fortune 500 companies. He’s currently a software engineer at Cardinal Health, where he helps create PathWare, a program that helps doctors determine courses of treatment for cancer and rheumatoid arthritis.
His previous work includes web and intranet development for AutoZone and programming automation software for FedEx.
Cardinal Health is a Fortune 20 company, focusing on medical supplies, medical equipment, and medical software. The product I work on is a decision support tool, mainly for cancer.
Doctors enter a wide range of factors about the patient, like age, height, other diseases they have, the location of their cancer, whether it’s metastasized, etc. Then the program suggests the drug regimen, sets up the infusion, orders the drugs, has them sent to the cancer center, and keeps track of the dosing cycles for the patient.
Then we close the loop on the back end – if the regimen was successful, we can record that. If they ended up needing surgery or radiation, we can record that too.
I’ve got two spheres of technology that I use. In my personal freelance endeavors, I focus mainly on PHP, WordPress development, and Node.js.
My work at Cardinal is different from a lot of work I’ve done in the past, because we’ve completely decoupled the service layer from the web layer. Our set of APIs could be used by any number of applications. If we ever wanted to retrieve drugs from a drug cabinet in a hospital, and have those drugs be ordered and sent to a particular patient record, we could do all that because of the way we’ve written the APIs.
The application is currently written in Backbone.js, which is an unopinionated framework. That means it gives you the tools – the hammer, the nails, the screwdriver -, but not necessarily the instructions.
That’s great because you can put it together in whichever way is best for your team and application, whereas frameworks like Ember.js and Dojo are very opinionated. If you don’t put it together in the recommended way, chances are it’s not going to work.
PERL. It’s the language I got started with for hardcore programming. It’s the first one I got under the hood with. As you learn more and more languages, you’re going to find a lot of the syntax is the same, most of the looping constructs are the same, all of the logic constructs are the same.
I’ve worked for four Fortune 500 companies doing stuff I never earned a degree for. I taught myself everything I know.
I was able to accomplish that because of the openness and the sheer volume of information that exists for people to do what I did. My greatest assets have been web-development sites like Smashing Magazine, A List Apart, Codeacademy, and Treehouse.
I’ve had 10, and all have gone really well.
One of the sessions I did the other day was a college student who needed help with a final project. He had a list of seven things that had to be in the project, things like creating an attachment handler.
At first it felt like a morally gray area – I didn’t want to simply do his his project for him. Instead I explained how to do each one of these things, and he loved it. He told me, “You’ve taught me more in an hour and a half than my professor did all semester.
I said, “That’s scary… but OK!”
Use source control. I wish I could get every developer I work with to use source control… having a source control system has saved me on more than one occasion.
And it’s not as common as you’d think. Every Codementor session I’ve done, and I’ve asked them, “Okay, what source control are you using?” Every single time, the answer is, “What?” That’s when I tell them they need to get set up with Git.
When you weigh spending half an hour doing that, versus 30 days rebuilding everything you’ve lost, it’s a no-brainer.
So I rewound – we talked about HTTP status codes, how XML HTTP requests work, foundational things like that.
If you try and lay bricks over empty air, it’s all going to fall down. You have to build from the ground up so that all the knowledge the person needs to succeed is present.