Naturalizing programming

05 Feb, 2025

A few years ago I have become disillusioned with my job as web developer working in an enterprise setting. Mainstream practice like OOP, design patterns, SOLID, etc... have always felt wrong wrong to me, but that is all that was, a feeling. I could not explain what was wrong with them. When my daughter was born I left my job and started working at a local company where I could work mainly on my own without all the noise of the industry, to reflect and figure stuff out. This blog is a place where I write about what I have learned through this journey.

I heard the term "naturalizing" from Dave Snowden, who works on naturalizing sense-making.

So Naturalizing Sense-making starts in a field by asking what we know from a natural science perspective, accepts that as an enabling constraint, and then goes on to develop practice accordingly -- Dave Snowden - Naturalising narrated

Programming practice needs to accept natural science as an enabling constraint and develop accordingly ¹. Theories for programming practices are mainly based on experience and opinions, the problem with that is experience is context dependent, what works in a certain context may not work in other so how can we filter out the context independent part that works everywhere and organize the context dependent part to know in which contexts it works in? For example should I factor code into small functions, or inline everything?

• Bob Martin says factor everything into small functions
• John Carmack found that inlining functions brings much better results Now which is it, should you factor everything into small functions, or inline everything into one big function? You might say that John Carmack worked in game dev, and aerospace, while Bob Martin worked in business software, so err on the side of factoring stuff into small functions and classes for business software, and inline more in games, and aerospace software, as the saying goes use the right tool for the right job. I would definitely listen to John Carmack over Bob Martin² but that is one persons experience versus another. In order to know if one is better advice than the other or it depends, I want to introduce some concepts that I think the majority of programmers don't know about, but can help a great deal with programming.

In the beginning was the Word

Watch this video where Russel Ackoff explains Whorfs experiment much better than I do here in writing. The English word perspective has no translation in Japanese. The Japanese word notan has no translation in English. Benjamin Lee Whorf did an experiment where he showed a drawing to Japanese people. And none of them said that it was a cube, they said that it is a flat surface with a line down the middle, and the top and bottom approaching each other. What he did after is that he put on an art exhibit in Japan with western art, and asked people what is their dominant impression in western art. They all said that it was flat. If you are a westerner and look at Japanese silk screen art it looks flat to you, but it does not look flat to the Japanese. From that Whorf drew the following conclusion: you cannot experience something until you have the word for it. I don't think necessarily that you need the word for it, as in one word, instead you need the concept, which does not have to be a word, it can be something you cannot put into words. Nonetheless the important thing is you need the concept before you can experience something. This is important in programming for code readability and understandability. The problem with advice from experienced programmers is that beginners don't have the concepts needed to understand that advice and the experts don't know which concepts they use to understand it, so you get the curse of knowledge.

What concepts do we as programmers need?

The fermionic concepts of objects, components, layers, services that the mainstream uses as basis for building software systems, although very useful in many aspects of life, like manipulating objects in the physical world, have lead to a dead end in software. Instead we need a different kind of thinking, to not miss the forest for the trees and borrow concepts from:

• Cybernetics
• Systems theory
• Complexity science
• W. Edwards Demming system of profound knowledge
  • Appreciating system
  • Statistical process control
  • Theory of knowledge
  • Psychology so that we can improve software development from all angles: modeling, writing code, architecture, system design, quality assurance and management.