The Chef & the Cook

Please read him as him/her.

What is that quality or a skill that defines a chef especially when compared to a cook? While the distinction is fairly blurred, few came close to my intuition as I researched in the Internet. One of them went like this – while a cook is more of an ‘executor’, a chef is a ‘conceptor’. Another one said, while a cook can make different kinds of food, a chef could have his own personal recipe. In essence a chef is likely to be far more technically skilled, one who is capable of building his own secret sauce. From a market perspective, I tend to think the skills of a cook can get commoditized over a period of time but not that of a chef’s. Also, I like to see the cook/chef setup as a metaphor to professions in other industries. Any thriving industry would constantly evolve to commoditize the skills of its cooks and at moments also get ambitious to commoditize that of its chefs. No matter how many times the commoditization happens, the same industry is likely to witness the evolution of its chefs in a different form at a later point in time.

In computing industry too, it is not uncommon to find this.  ‘Commoditize’ in this context is when the industry offers to automate a programmer’s task or provide it as a feature part of the technology infrastructure itself. Attempting to ‘commoditize the skill of its chef’ happens when a programmer alone can provide the optimal implementation (in many cases) of the feature being considered. Here I’ll go through 2 instances that I observe, where the industry has offered to commoditize the skills of its software chefs. The first one began 4 decades back and the second one is happening at the moment.

Software programmers don’t do many of the tasks that they used to do long time back. For instance, they no more care about garbage collection; they no more explicitly type cast (in many cases) and so on. While many of these have made the programmer more productive, some are yet to. Codd in his disruptive 1970 paper articulated the role of the Query Optimizer in the paradigm of the Relational Database. The optimizer will arrive at a ‘least cost’ program to retrieve the underlying data to prepare the final result set. In the same paper, Codd did agree that building such an optimizer is a difficult design problem. Although most of the commercial databases have the optimizer built in, I think this task is done best by the programmer alone. Gartner’s 2012 magic quadrant for Data warehouse databases cites performance issues with complex queries as a problem noticed by its clients even with the market leaders and this is 40 years since RDBMS was born. As long as the cardinality and the correlation of the data (of the underlying subject area) continue to evolve, something I believe is inevitable; we will continue to solve this problem.

The second instance is the emergence of the various analytical platforms and their claims to make Analytics easier and accessible. While I’ll not delve deep, this appears to be even more ambitious (compared to the above) especially when analytics is all about imagination and intuition.