Thinking of Everything as Functions
In retrospect, reading this after 3 months, what am I trying to get across? Read at your own peril.
A developer's job is to figure out the puzzle of creating an output and figuring out the required inputs.
That's right, when you start, you have some idea of the outcome you want, and a vague idea of the inputs you need to get them. Through a trial and error process, you build an algorithm to create an outcome. You also gain clarity on what inputs are essential and which ones are not as relevant.
You can consider producers/developers/builders to be transformation functions.
They provide an end result, a solution.
They create this result by:
- leveraging the knowledge of the algorithm they have built through experience;
- obtaining the inputs, and;
- actually executing the work to solve the problem.
A doctor provides a diagnosis, based on his very specialized knowledge base and experience as well as asking the right questions. These questions are the input parameters to the function they perform (coming up with a diagnosis) and creating the output.
A barber creates the end product (your hairstyle), by taking a look at what you currently have on your head, what you describe you want (if you're lucky), and performing the transformation work to create your desired result.
These functions are very specialized blueprints for solving a very specific problem.
Programmers know there are many ways to arrive at the same result.
Similarly, the transformation functions in real life also have different approaches to obtaining the same result with different underlying characteristics of the function.
When you make these blueprints explicit, they become a sort of a book or instructional manual for other people to be able to achieve the same results via replication. This makes them commodities.
Commodity products fulfill the demand and supply equation to arrive at an average price point. This is the compensation you receive.
Yet, the creation of some blueprints requires very diverse and interesting experiences and may not be easily replicable and/or transferable. These manifest as natural moats, competitive advantages, and 'edge'.
A crucial difference between transformation functions in real life vs. functions in a computer program is that they are rarely deterministic. They are more of the probabilistic variety and hence application of the same function doesn't always yield the same result but something close to what is actually desired.
Unlike the stable environment a software function runs in, real-life transformation functions also operate in a dynamic environment.
This contributes to their probabilistic nature.
It also means the same functions that delivered results in a specific environment may not translate into providing the same outputs as the environment changes.
That is all for this thought storm, I hope it inspires you to think more, particularly as it relates to your own life circumstance.
It is usual for my thought storms to have no specific point or conclusion, and it's typical for them to end abruptly. They are explorations of potential ideas and ways of looking at things that I'm inspired to share. You can gain microdoses of these on Twitter @shuuabe