The pMD Blog
POSTS BY TAG | Responsibility


As a developer for a mobile charge capture company, I am blessed with some unique access to the medical industry. I get to have one-on-one conversations with doctors, practice administrators, and even those who've been on Capitol Hill to discuss and lobby for better health care reform! Those special experiences aside, at the end of the day, I’m a developer at a software company. And like all developers at software companies, I am subject to similar frustrations and roadblocks that can prevent me from being the best programmer I can be.

In my career I have spent an unknown number of hours on a bug that I just couldn't figure out, or a new feature that just wouldn't work right. Often, I get that "Eureka! moment," not from staring at the screen for the umpteenth hour, but driving home or walking the dog. But why couldn't I see the answer when I was dead focused on it, and instead more successful when I was, say, doing the dishes? Aren't developers supposed to disappear into a dark coding cave for long periods of time and mystically emerge with some cool new feature? To answer that question, we must admit that developers are not machines. We are humans and we need breaks. It may sound backward, but we need to stop working so much in order to get more done.

As developers, we have a responsibility to create great code that should do more good than harm. When we work and push ourselves for long periods of time, we set ourselves up for failure. When the mind fatigues, the risk of introducing software bugs goes up. The more bugs introduced, the more time needed to fix them later. This downward spiral is expensive - in both time and money. With our ever growing technologically dependant society, these bugs can cost billions of dollars, physical harm, and in the worst of cases, fatalities. A particularly expensive example occurred in 2012 to Knight Capital Group. What was supposed to be a simple set of trades over the course of a few days, was executed in a matter of moments, and reportedly cost the company $440 million. Yikes!

But what can we do? Implement new or better agile practices? Add seemingly infinite unit tests? Re-train personnel to re-emphasize the importance of testing? Or all of the above? No matter what the attempted solution, nothing will help without a clear, focused mind to execute these solutions. So instead of working long hours in a row, we should think about how to work more efficiently and effectively. Rather than powering through daily code-a-thons, try working in smaller blocks of time (90-120 minutes). Afterwhich, get away from your desk and take an effective break.

The goal of an effective break is to let your brain recharge from all the concentrating. Tap into the other lobes of your brain for a few minutes; those synapses need exercise too! Go for a walk, grab a snack, or chat with coworkers - just get away from your desk. By switching gears, we let our minds take a rest from the tunnel vision of focusing and can just relax. The mind constantly works even when we’re not aware of it, and it continues to process information even when we’re doing something entirely unrelated. And no, as much as we’d like to tell ourselves, checking and responding to emails is NOT an effective break!

Here at pMD, we pride ourselves in providing our customers the confidence to desire and expect constant quality of our software. We strive to go above and beyond these expectations, and to do so, we strive to strike that proper work/life balance. We achieve this by promoting the work hard AND work smart mentality. So get up and get some grub. Go take a jog during lunch. Me? I’m taking the long way back from the coffee shop.

"After I was overruled, I wrote a letter of resignation. In my letter I explained the risks and said I would rather resign than allow dangerous hardware onto the Shuttle. And I pressed my letter into more hands than absolutely necessary. The embarrassment level got pretty high and the managers backed down — I was allowed to make the necessary changes.

Does this make me a hotshot, a moral person? Not really. I wasn’t married, no children to support, I could afford to lose my job for a principle. Besides, I was able to imagine what would happen to me if I caused a Shuttle failure — kids on the street saying ‘There’s the guy who killed all those astronauts and the schoolteacher.’

I didn’t become an engineer just to design things. I wanted to design them right. I was a bit too idealistic for engineering profession, who’s motto is “Ship it.” So I changed careers — I got into computer science.”

- Paul Lutus, Confessions of a Long-Distance Sailor

This was written more than twenty years ago, and it’s funny that the term “ship it” was as connotative and full of meaning back then as it is today in the midst of the lean startup movement. When I read this in Paul Lutus’ very engaging sailing travelogue, it made me think that software engineering has always had a bad reputation when it comes to quality and reliability.

It seems like not a week goes by without millions of emails and accounts being hacked or a software bug halting a stock exchange or delaying an airline. Software’s increasing potential for good is only matched by its equal potential for harm. Testing methodologies and its culture have advanced a great deal in the last decade, but most would agree that it’s no panacea. Instead some argue that the deeper solution is in the languages and idioms we use that make writing code safer. Yet this too can never protect us if the person who writes the code doesn’t see the potential for harm in their work and second, does not feel the moral responsibility of saying no to “ship it.”

In an industrial society, the makers of things are usually far removed from the end usage and impact of their product. Developers are no different, and that’s why when I joined pMD, I was so surprised by the heavy exposure of the developers with the customers. We routinely visit customers on site and build first-name relationships with them. I remember the first time I sat down with the billers in a practice in Colorado and discussed their workflow, their pain points, and generally how overworked they were. When I returned back to the office, I felt a renewed sense of empathy and purpose to how a seemingly small feature I would write could impact someone’s daily job across the country. This impact could go well beyond the ROI of our software, and affect someone’s happiness and sense of effectiveness in their profession.

Even though developers sometimes love to put on their headphones and crank out some piece of software wizardry, it’s important to occasionally step out of the office and engage with your customers. Regularly seeing the daily work-life of your users first-hand helps establish that sense of responsibility to the end-user, and it makes the software better for it.

I’ll leave with an excerpt of an interview with a famed Japanese woodworker, Toshio Odate:

"Toshio added something very important: there is something else that is not always being grasped by many woodworkers in the craft: the social responsibility of the craftsperson, be they woodworkers, musicians, photographers, doctors, or writers. Each of these persons practices a craft and in that craft they are expected to produce a result that carries with it a social responsibility. And that responsibility is where the person’s skill and even artistry must be used to serve others. For example, if a joint is used to show off a person’s ability to create a showy piece, but fails when it comes to joining two pieces of wood securely and efficiently, that person has failed at their responsibility to society—even if the joint “looks beautiful.” But the craftsperson who makes a solid joint, that looks “good enough,” does its job and holds for decades or centuries to come—that person has fulfilled the responsibility society asks of them. Even if that joint is hidden, it has the spirit of being a good joint…

…once you commit to making a piece for a client, or a family member, that responsibility is there, to those people. It’s your job to make sure your design and your workmanship serve the needs and desires of your clients, and that the techniques and materials you use serve those ends. Anything else is superfluous, and runs the risk of being dangerous, or at best, ugly.”

Source Fine Woodworking.