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 trail 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:
- exercising the knowledge of the algorithm
- obtaining the inputs, and;
- actually executing the work to solve the problem.
A doctor provide a diagnosis, based on his very specialized knowledge base and experience as well as asking the right questions i.e. parameters to their function 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 which you know as your compensation.
Yet, 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 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 also contributes to their probabilistic nature.
It also means the same functions that delivered results in an 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 micro doses of these on twitter @shuuabe