Pathology is defined as “the precise study and diagnosis of disease.” The subject’s name is derived from the Greek word pathos, which means “experience” or “suffering.” Medical students typically take up this course on illness in their first year of medical school. They study the varying afflictions that grieve the human body, and are trained to identify and differentiate what these sufferings might be.
In fact, most of what an early medical student is taught (anatomy, histology, biochemistry) is not the medicine that they will eventually prescribe, but the nature and dynamism of the patient they will encounter. Only after understanding the human body and its intricacies at a detailed level should she conclude a diagnosis and prepare a suitable treatment.
If I can draw a parallel from medical literacy to the technology sector today, my sense is that technologists are delivered a highly reversed set of instruction. If programming holds the potential “tech medicine,” then our community rushes to equip itself before first clarifying what it will be used to address. So its not the subject of computer science itself that I contend with, but more the sequence and relative weight of its given importance.
The value of the discipline is quite clear. The rationale is that to solve problems one needs to have command of the range of potential (technological) solutions or an awareness for how to access them. To go out and actually effect change you need a grasp of the complexity of tools needed. Another equally important reason: you need to speak the language of those on your team who are building as well. I’ve learned the hard way on that one.
Part of the importance of programming literacy is the problem-solving mentality it induces, but more importantly, the ability to build and/or understand systems that automate work or make work efficient is increasingly valuable in today’s business climate, where tech touches everything. -Shane Snow, Why You Need To Know Code
Wholeheartedly agree. But since I’ve grown in the venture and technology space, I’ve heard with increasing intensity, perhaps now at a reckless level, the need to develop a computer science proficiency (“Everyone should learn to code. Especially “business people” should learn to code”).
Yet the underlying and glaring assumption in almost all these calls to action is that you’ve sufficiently diagnosed the problem you’re solving. We tend to assume the entrepreneur has surfaced a resonance within a market around whom she plans to build. But this is not frequently the case.
So might the order of operations here be a bit off? Is it possible that we should be attempting to first learn and understand the techniques to surface such human / user / customer resonance, and then assemble the tools with which to build? The order as it is currently stands may significantly underestimate the subtleties required to create truly innovative products. We see time and time again when a product, not attacking a new problem by any means, breaks into mainstream consumption because of a narrow set of features that users “just get”. The Mailbox app comes first to mind. I’ve come to believe that the founders who go on to grow successful businesses are either innately attune to these needs, arrive at them through a slower, iterative learning process, or in other cases get lucky.
And to be sure, some of this empathic thinking has emerged. As entrepreneurship has flourished, there’s more written for technologists to get out and talk to users. But its still in many cases an afterthought and still not spoken at a volume that many founders hear or in the sequence that may be appropriate. The Google Ventures design team, who borrow some of IDEO’s philosophies for their approach, have one of the best resources on how to do this in a more methodical way.
Software is indeed the backbone of innovation in the digital era. Teams that can harness computer science in powerful ways will continue to transform the world. But please, bring the sociologists and ethnographers into the conversation. Let’s get better trained in diagnostics to better interpret user needs and then develop the technical skills, by learning or through partnership, to put the desirous solution together. Bring on the pathology.
