Pharmacology is API to the human body — an its terribly designed

Pharmacology is the API to the human body. Ironically, this API to the human body is terribly designed. APIs are supposed to be designed to serve the end-user, to think about the use cases. However, it seems that the pharmacological APIs are simply designed with a ‘developer-first’ approach, to name drugs to cater to the ease of understanding of the research and the people who discovered and invented the drugs.

This because problem in drug development and to lower the barrier and increase the speed of drug development. Creating siloed and domain specific terminology serves to block out other people from understanding what is going on in the field. For the people within the field, this is good because it blocks out competition. But for the rest of the population, this mean more inefficient drug development process and henceforth higher costs of drug treatment.

Instead, what we want to achieve is an ‘Apple-like’ feel of intuitiveness. Even without formal instruction, end-users should be able to make out the use-case and functionality of the API endpoint. The goal here is the minimise onboarding friction in maximise ease of use. It is interesting how Apple invests heavily on the optimal customer experience, to make the Apple Ecosystem effortless and magical. However, there has been not so much talk about doing the same for API endpoints for developers. After all, developers are the key customers, and we should treat them with the upmost respect and understand that they also desire a service that is completely seamless, intuitive and ‘just work like magic’.

This marks a step upwards in developer experience and developer education. Perhaps it signals that we could borrow some of the concepts from universities and world-class education teaching pedagogies to guide how we can effectively design our APIs. This also means that researchers and discoverers should not lead the way in naming things. Rather, the naming of things should be carefully considered and modified from time to time to make sure it still makes sense. For example, many agree that most of mathematical notation are too confusing. Case in point with Richard Feynman reinventing mathematical notations to make it easier to learn for his students. Perhaps, rather than simply using endless pages of manuscript and docs for APIs, we should have videos, interactive labs (such as LT labs, or articulate rise applications.

One powerful concept to use for building better API endpoints for the human body is utilise existing concepts that are already easily understood by people. For example, the idea of ‘understanding’ a concept and having a ‘eureka’ moment deals with the ability to draw connections with concepts that we are already well familiar with. For example, rather an simply memorising the step for matrix multiplication, we can obtain an intuitive understanding (as described in the linear algebra MIT opencourseware). This is particularly powerful because it draws on our understanding of neuroscience in Long Term Potentiation and Hebbian Plasticity, which explains the concepts that neurons that are connected to the same postsynaptic neuron can cross strengthen each other if they are fired at the same time. This means that parallel neurons that increase the synaptic connections of other parallel neurons, and this is crucial in boost efficiency in learning.

The problem of poor naming practices and its relation to poor API design as already described in mathematics, as shown in this reddit post

Honestly, I feel like notation in math is like tech-debt on another level than anything other fields have to deal with. The trouble is that you get one super smart person trying to convey an abstract idea and only care about conveying that to most likely other super smart people who are capable of adjusting to whatever on-the-fly/arbitrary convention the first super smart person invented on the spot or bent/repurposed whatever and then everyone runs with that forever.

It’s not like in software engineering where there’s code-review and a senior dev can say “nice algorithm, Gary, but for the love of all that is holy let’s worry a smidge more about readability here?”. And then people build on that system and it just gets compounded.

Not to mention that what is convenient in one area of math conflicts with what is convenient in another and then when you’re needing to do the same thing in different types of math, helpful conventions sometimes just go out the door and if you’re new to something you get the sense that people are like “what problem?” Or you’re hitting your head against the door until you finally work out that in the new area some things are just assumed etc.

And then sometimes you manage to (temporarily) transcend into the smart space and you’re thinking “what problem?” yourself, to any new person coming in.

I don’t know what the best solution here is that doesn’t involve some deeply impractical aspects, but I really don’t like things as they stand rn…

The forward vision is henceforth, can we create a human API that requires no ‘domain-knowledge’ to make it intuitive enough such that anyone that stumbles upon this would be able understand it immediately, and such that we can achieve a decentralised reasearch base for collaboration between all field were we do not gatekeep creative people from making contributions to our field by using overly and needlessly complicated terminology.

To this end, I have started a project named Sapiens API for the purpose.