The pMD Blog

Welcome to the
pMD Blog...

where we cover interesting and relevant news, insights, events, and more related to the health care industry and pMD. Most importantly, this blog is a fun, engaging way to learn about developments in an ever-changing field that is heavily influenced by technology.

POSTS BY TAG | Developer


With the arrival of opening day for Major League Baseball, my beloved San Francisco Giants begin their journey of defending their World Champion title. They started the season off right with a victory against the Arizona Diamondbacks, but once again they're not the favorites to win it all. Radio talk shows and countless online articles discuss how the Giants just don't stack up against the payrolls of the Dodgers and Red Sox. Year after year, the Giants are the underdogs yet somehow they've won it all in three of the last five years! What is it about this team that brings them so much success while seemingly invisible to the rest of the world? One immeasurable word: chemistry.

Watching the Giants, you get an immediate sense that everyone just has a ton of fun. They joke around in the dugout when the mood is light and collectively focus when the game becomes serious. Everyone genuinely enjoys each other's company and it's not "just a job." Having chemistry is fundamentally important to achieving anything great as a team and it doesn't just stop at sports.

As a core member of the pMD development team, I'm blessed to work with a squad that emanates the same chemistry. Our carpool rides are brief but always with amusing chats - sometimes about our work, sometimes about sheer randomness. Sarcasm is abundant throughout the day, and the laugher is constant. The guys I work with are exceptionally talented, but more importantly, I can enjoy a beer with any and all of them. This is the key to developing truly great medical software for our customers and drives us to do our best work.

The Giants' world class chemistry translates to world class play and world class status. At pMD, we take pride in the same level of chemistry that allows us to lead the way as a world class mobile charge capture, secure text messaging, and patient care solution. Play ball!
As a pMD software developer, I try to get out in the field and work with our customers as often as possible. It’s important for me to see how pMD helps solve our users’ problems, and also to listen to ideas and feedback about new functionality we could add to make pMD even more powerful. Last week, I had the opportunity to travel to Anchorage, AK to meet with a number of practices in the community who use pMD.

Even though I’m from Seattle, I had never been to Alaska before, so I jumped at the chance to visit our 49th state. We landed in Anchorage to sunny and mild weather, which luckily stuck with us for the entire trip. I didn’t build in a ton of time during my stay to venture out into the Alaskan wilderness, but luckily the wildlife came to us! Upon arriving at what we thought was the location of our first meeting, we were greeted by two moose. We spent a few minutes on our phones researching how best to avoid W55.82XA, and then realized our intended destination was actually about two blocks away.


After narrowly avoiding an unwanted moose encounter, we had a series of extremely productive meetings. The medical community in Anchorage is very close-knit, and several of our customers are using pMD’s Care Coordination features to help all of the providers on a patient’s care team stay in sync with one another. We also learned about how some doctors in the area have started using pMD Secure Messaging along with charge capture in order to communicate with their colleagues in remote locations. Those locations often don’t have reliable cell service, which is needed for traditional SMS messages, but they do have WiFi, which allows pMD messages to be delivered.

As a developer, it was inspiring to see the product I work on help facilitate better patient outcomes and improved doctor communication. I always find visiting with customers to be a refreshing change of pace, but this trip in particular left me feeling more motivated than ever to build the next generation of features that pMD has in the pipeline.


I joined pMD when it was a charge capture company based out of New York City. During my interviews, the team revealed that in a few months time, the whole company was relocating to San Francisco. I'm originally from southern California and knew I wanted to move back, so this moved up my time table nicely. At the time, not only was our headquarters and the majority of our customers on the east coast, but our primary data center was nearby as well, in Chicago. The move to San Francisco, other than eliminating my winter wardrobe, sparked some discussions and a desire to geographically distribute our production data center.

Over the last few years, our customer base has grown by a few orders of magnitude and our customers are more uniformly distributed across the country. Network latency due to geography hasn't really been an issue as we've tried to keep our backend code snappy enough to absorb the occasional bottlenecks, in addition to offloading non-sensitive assets to content distribution networks. Having a second live production data center certainly doesn't hurt network latency, but a better argument was needed. For us, it comes down to risk management. We already have several layers of redundancy in hardware and software in addition to off-site data backups, but having redundancy across colocations centers and their respective organizations is a new level of risk diversification that is very attractive. Having two centers serving live requests is something we felt would help us and our customers sleep easier. As a result, early this year we’ve begun the build out of a new San Francisco data center which we hope to complete in the coming weeks.

Risk reduction, however, is only half the story. As developers, the ROI of trips to distant data centers also reduces the frequency of experimenting with newer hardware setups and technologies. Having a nearby site where we can try new things and in essence take greater risks without the fear of negatively affecting our customers is also a huge added bonus for our team culture. In the larger picture, reducing our tolerance for customer facing risk while increasing the internal appetite for risk and innovation is a win-win formula we expect will pay dividends in the years to come.
Software developers at most companies don't have to think about the infrastructure that runs their software. We're cloud-based, which means that our charge capture and secure text messaging customers don't have to install any servers or hardware in order to use pMD. But we also keep tight control over the hardware that powers our cloud. The idea of offloading our processing to Amazon or Google is appealing on the surface; but because of the sensitivity of our customers' data and our own obsessive quest for better performance and reliability, we manage and configure our own servers.

Our system is like a sports car: many separate components all have to work in harmony to create a functioning whole. Except we're a 24/7 service providing software for doctors, so we don't allow our system the luxury of a "pit stop" for scheduled downtime. That requires a lot of thought up front to make sure that each component in the system can be "unplugged" for maintenance without affecting the whole. We've borrowed liberally from the best practices of financial and software companies' datacenters in order to achieve this, with some improvements of our own along the way.

What's been most interesting to me about datacenter work is that there are always tradeoffs. There are better and worse answers, but there is never a perfect answer. For example, when we introduced large file storage into our system so that users can send attachments in their secure text messages, we had to rethink a lot of our assumptions to make sure that those files could be synced in a robust and secure way between our different datacenters. And more recently, we've been looking at ways to use more than one firewall server at a time within a single datacenter, so they can share the work between them. These small innovations keep the system nimble and responsive as our user base and functionality both grow.

We recently crossed the mark of processing more than 1,000,000 HL7 messages per day for our various hospital, Practice Management, and EHR interfaces. It's an exciting milestone, and I enjoy thinking about how our infrastructure will change and evolve to support the next million!
At pMD, we wear many hats. When I describe my job to friends, they often ask "Aren't you a programmer? Why are you doing so many other things?" They, at most, have two major responsibilities at their companies and they assume my other tasks are bothersome. But having those extra responsibilities isn't a burden at all! Instead, I see them as a badge of honor. What I find often overlooked is the fact that hats translate to trust. Being given multiple hats to wear means the company is entrusting you with those responsibilities. They view you as having the ability to own these tasks and to execute them at a high level. Essentially, the company believes in you! And having different responsibilities means no two days are the same, which makes work fun and allows me to avoid the repetitive. Here's a snapshot of one of my developer days at pMD:

In the world of agile software development, when two developers work on a software task together at the same workstation, we refer to it as pair programming. On the surface, it might seem inefficient to have two people taking on the same thing at the same time. However, at pMD we’ve found, along with many other people, that not only is pair programming no less efficient than working solo, it is actually more productive and results in higher quality code.

While counterintuitive at first, consider the following: when working on a programming task, the majority of the developer’s time is often spent understanding the code that needs to be modified, and then thinking about a good way to implement a solution to the problem at hand. This implementation ideally should be easy to understand and it also has to be carefully analyzed to ensure it won’t break any of the existing functionality in the system. Working with another person on these items is often much more effective than working individually. This is especially true if one of the developers is more familiar with the codebase than the other, but just having a second person to bounce ideas off of is extremely helpful.

So, how does one do pair programming? First, identify the task that you want to pair up on and select a colleague on the development team to work with. Then, sit down with your pair partner at a workstation - ideally one with two large monitors! Plug in a second keyboard and mouse, and you’re good to go! Starting from the design and analysis phase, all the way through implementation and testing, pair programming is truly collaborative. When it comes time to actually write the code, each person should take turns implementing pieces of it, explaining what they’re doing as they type. The second developer should follow along, ask questions, and make suggestions.

I’ve mentioned before on this blog that when you’re working at a busy medical software company there’s never a shortage of software development work waiting to be tackled. However, we’re trying to be more diligent about resisting the urge to each go off on our own when we do our programming work. Instead, we want to embrace the mantra that when it comes to software development, two minds are better than one. We know that increasing the amount of pair programming we do will help us write higher quality code and produce even more features that our charge capture and secure messaging customers need.
At pMD, we have a small development team. Although there are a lot of advantages when you work in a small team (efficient communication, no red-tape, speed), one of the disadvantages is that you sometimes feel isolated. One way to feel like part of a larger community is by attending conferences, but finding and going to your favorite tech conference in Fiji is sometimes impractical. In these cases, you can often create your own virtual conference with your dream list of speakers all from the comfort of your own home. Recently, I made my own list. And although they don’t exactly have to do with charge capture or medical software, a lot of the themes are directly translatable to what we try to accomplish every day. I hope these are inspirational, and I would love to visit others' virtual conferences (someone should make an app for this!)

Virtual Conference Schedule

Keynote:

How to Program Independent Games with Jonathan Blow
Fascinating view on independent game, but more broadly being a moral developer.

Technical:

The Value of Values with Rich Hickey
This is a mind opening view of what data really is, independent of the storage medium.

Closing Remarks:

Inventing on Principle with Bret Victor
An inspiring and often times neglected view on how to make an impact as an engineer.

How can you manage a team of developers and still find time to code?

I felt a sense of urgency around this question last year. Because my team had grown and my responsibilities had increased, it had become almost impossible to protect any focused programming time during the work day. After doing some research, I realized that every successful development manager encounters this problem sooner or later as their scope increases; and most of them eventually give up on the idea of being able to do both things.

But I didn’t want to give up on being an active developer as well as a manager. I enjoy writing code because it exercises a very different part of my mind than my management and customer-facing responsibilities do. It also makes me a better manager because I’m affected by my own decisions and I can better understand the needs of the team. There had to be a way to do both.

It turned out that the other members of my team were also looking for a way to protect solid, uninterrupted blocks of time for deep coding and collaborative work. We put our heads together and came up with the idea of a daily Code Bash. We blocked this time on our calendars, making a mutual commitment that we would dedicate this time to coding and be available to help each other through answering questions, discussing designs, pair programming, and code review.

One of the challenges that we had to navigate was how to make sure that our other obligations to the company as a whole didn’t go unattended, and that a developer would always be available to help with anything time-sensitive that might come up. We didn’t want to reduce our team’s contributions and responsiveness to the rest of the company by blocking this time. So each day, a rotating developer acts as the “superhero,” fielding any support questions, charge capture customer trainings, or data requests that come up during Code Bash.

The team has been a lot more productive since we put this into place, and it’s been truly transformative for me. I now typically get more than 10 hours of dedicated programming time each week, compared to less than 1 hour beforehand - even though my other responsibilities have continued to increase in the meantime. My job is more balanced and more satisfying as a result of this change. It’s a very pMD solution to a problem that felt unsolvable!


My dog, Irwin, and I share many common interests, including playing frisbee, going on trail runs, eating good food, and participating in hardcore coding sessions. OK, maybe that last one is just me, but when I do dive headfirst into a serious software development task, I try to take some inspiration from my canine friend.

When Irwin puts his mind to something, he is focused and persistent. For example, when we play fetch at the park, he makes it his mission to retrieve his favorite ball and return it to me as quickly as possible, and he ignores all of the other dogs around us. Normally, he’d be interested in socializing with his doggy buddies, but fetch time is fetch time, and nothing gets in the way of that.

I try to take a similar approach to my coding sessions. I do everything I can to eliminate outside distractions during these focused times. Working as a developer at a fast-paced charge capture and secure messaging company means that there is always a lot to be done on a number of different fronts. However, to be able to tackle tough software problems, I need my entire brain to be concentrated on the task at hand. Much like Irwin, I ignore for a while all the things around me that I’d normally engage with, and throw all of my energy at my code.

There is a lot of research out there, including a study reported by the BBC, which argues that multitasking of any kind makes us less productive. I personally believe that there are certain times when multitasking is OK and even necessary to get the job done. However, like Irwin, I know that certain tasks are just more productive, more efficient, and more fun when I devote my full attention to them. My coding sessions rank highest on this list, which is why I like to refer to my approach to software as Dog Driven Development.

As developers, we have the unfortunate power to create infinite complexity but a very limited ability to reason about it. Unbounded code complexity can kill software by making it difficult to change and adapt to customer needs. In a talk on simplicity in software, Rich Hickey made the analogy that the difference between how much complexity an average and a great programmer can keep in their head is like the difference between the abilities of jugglers.

A novice can juggle three balls while the current world record holder can juggle at most 13 for a short period. The difference between average and great isn't really that much; no juggler can juggle a couple thousand balls. In software, however, complexity can easily grow by orders of magnitude above anyone’s ability to reason about. This leads to software that can’t adapt to a changing world, stunting innovation and exacerbating inefficiencies - sometimes for decades.

I think business logic is often the most complex and messiest part of most software because it deals directly with people, organizations, and all of their ambiguities. Writing a high frequency trading system that meets some benchmark is arguably simpler than writing and maintaining software that is meaningfully adopted by a jaded industry. In the medical world, huge change is coming not just in terms of charge capture, but more profoundly in the management of patient care within communities. Writing simple yet sophisticated code that can change with the redefinition of the health care industry is more important now than ever. As developers, we are positioned in a unique role in building a new generation of medical software that avoids the paralyzing complexity of the status quo. Think hard, empathize, and keep it simple.