Or why learning to program without ever touching pointers, recursion, syntax trees or delving deep into OS internals among others, leads to lethargic software teams in the long run, those constantly growing organisms clumsily developing their own peculiar ways of solving problems with the help of legions of tools and processes.

Now, all human activities on this planet eventually develop their own theories and best practices, both of which take time to understand and master. Hell, for introverts like me it is painfully evident that even talking or dressing appropriately at parties is a mine field. Fail to get a daily exposure to these prerequisites, patterns and mindsets from a young age, chances are one will never be able to catch up and be anything more than an deceiver.

Let's take a few steps back into the wilderness, though, where legitimate engineers still roam unsupervised, and see how these wanderers of the spirit explore their surroundings. In short, with a cold brew of languages among which mathematics plays a leading role. This is quite distinct from natural languages like English, with its endless interpretations based on who-knows-what. With the allegorical pen and paper in hand, these free roamers move at ease in their peculiar environment, cojuring up sentences, inventing new words and playing with concepts. What comes out is sometimes garbage, to be sure, but at least it has these advantages over the feel-good elixirs: it is consistent, it can be tested for correctness, it can be handed down from person to person, or even from generation to generation, without altering its meaning, it can describe both the problem and the solution, it can be used as an exploration tool for new questions, questions so special they could not even be addressed outside of these special languages.

For example, a classical archaeological problem asks to show that if one drills a hole through the Earth and then falls in, they will execute simple harmonic motion about the Earth's center and that the time it takes to return to their point of departure is also the time needed for a satellite to circle the Earth in low orbit. An archaeological quiz solved single-handedly with an engineer's pen. How would one solve it without recourse to mathematics or physics, though? Outlining the problem would be a problem in itself, let alone finding a solution and, even more importantly, playing with different scenarios around the idea of falling into such a death trap. One might be able to do it but with an army of people, tools, time and money. That's what happens in observer teams, as well. Their lack of understanding for the technical language is their own special grave since they are forced to adopt and invent different tools and languages and swell the ranks of their members to be able to tackle all this extra payload.

But I've just committed a blunder. I've just used a term without defining it, a practice such observer teams are apt at doing without realizing it. The chaos it results from it is that every member has their own understanding and their own assumptions about what such undefined terms mean, how they should be employed and when. To fix that, an observer team is any team where the majority of its members understand and employ mostly an observer language. That is, the engineer above uses a technical language, while speakers outside the field, who don't speak mathematics in this case, use an observer language. The observer language is usually the most generic language one has learned to speak and handle, usually one's mother tongue, a language useful in daily activities and interactions at the marketplace or with friends. The further one stays away from the technical language the more one is a bystander vis-à-vis the respective field with all its intricacies and subtleties, so the terminology seems appropriate. This doesn't apply to an engineering field only. It might apply to cooking, sports or play-writing, but I'll keep it technical in this case just to emphasize the point.

Similarly to the beauty contests one starts to learn in high-school, this technical language and its prerequisites - like sitting alone and be able to concentrate for long stretches of time on useless questions, or knowing through numerous blunders that ones must be as careful as possible regarding their undefined terms - one also learns pretty early in life if one is to have even a marginal success at it in the long run. An engineer, for example, learns that there are quite different technical languages out there. One learns how to play with them, how to choose between them depending on the circumstances, one has even developed one or two such languages for their own amusement maybe, one learns how to break out of some of that strictness at the right moment to explore some what if's scenarios. Similarly, a table tennis player might have trained their backhand drive thousands of times, spiced it up with some spin after a while and then, if confident enough, might have tried their own original technique. They might have played a few other sports before taking up table tennis, so warm-up, physical training, hydration, stretching, knowing their body and its limits, endurance to pain, heat and cold are all prerequisites known to them before even touching a racket for the first time.

Speaking of which, just observe a table tennis wannabe that has not taken their time to master the backhand drive. They will either avoid it altogether and deem it unnecessary or invent their own inferior technique over time out of necessity. It is a sight to enjoy, with all its contortions and excuses for not hitting the ball. I would know, I am one of those wannabes. In the same vein, observe a software team not mastering the technical language. That ferocious monster will invent its own ad-hoc language, excuses and contortions over time. There will be justifications and explanations, sometimes intended for its own moral well-being and survival as to why so many experts, tools and processes are needed, possibly helped by the development of similar languages in other observer teams around the oh, so vast a planet - with so many teams, there is bound to exist some sort of overlapping of concepts due to the overlapping conditions in which these big-bellies operate. Without a technical language to back it up, observer teams become a walking house of tricks. Tricks so subtle even its members are not aware of them.

One of the biggest optic failures when looking at different languages from afar is assuming they only differ in their syntax, like English differs from Greek, a failure of the observers having never crossed the chasm between languages at that younger age. A failure in assuming they can both express past and present, colors, feelings, the latest news and such, but with different symbols and not much else. But different syntax is sometimes employed to express some special concept not available in that other language.

When scratching the surface of the technical language, the observers use those features they understand, usually the basic ones like if/else clauses and throw statements, not touching or even coming across the more deeper aspects of the field. If I don't understand it, it must not be important is a good rule of thumb, with the result that some approaches are used and over-used everywhere, the ones the observer understands, even where they are not needed or even detrimental to the project's success, like over-splitting the project into files, folders, sub-projects, sub-teams, assigning fixed roles to every member, measuring every action, planning everything in advance before starting to work on anything, reaching a consensus through voting by all members regardless of the topic and so on.

The observer teams have only one speed. It is the speed of the sprint or whatever process they have adopted or invented for themselves. All time must be filled up. No pauses. No wondering around. All booked, all accounted for. No sleep during workday, no change of seasons in mid-seasons, so to speak. Efficiency that leads to boredom, burnout and supersaturation to inefficiency. It is another effect due to lack of technical mastery. It adopts one language for doing things and it uses it throughout. It cannot break free from the jail it creates for itself even if for a moment. It cannot freely explore the countryside since it fears stepping into a gigantic foul-smelling dung. It would be a disaster for the neat-dressers. So they tend to stay within the confines of their warm offices. Like the above tennis player when asked to play a more physical style against this opponent, a more technical one against another. Wait! What? Styles? There is just one single speed our player has. Just watch them. Ping, pong, ping, pong, same stance, same speed, same tempo. It's all the same for them.

While the language the observer team develops has as its goal, ostensibly, to solve the technical problem it faces, it will invariably include elements designed for another special purpose, of keeping the team tightly knit and in good spirits. It develops internal measures and procedures for this. I would assume the bigger a team grows the more the observer language, with its internal jokes, gossip and special way of doing things, takes over and the technical aspects loose some of their value. In big teams, technical speakers have low real impact. There is a growing need for motivational speeches, marketing directed at the eternal observers to attract them towards the software career, though they might not have a natural affinity to it and will never be truly happy within it. The above tennis player, for example, might not have much in common with the field, though through money and the right words and emotions, they might be tempted to make the switch at their own disadvantage in the mental-health department.

The technical language would ideally serve as the point of truth. Without it, there is a need to draw-up hard rules in places where the observers cannot make a rational decision. Hard rules which break down in scenarios that were not thought of before or when applied blindly. I always like this hard-rule from the technical language of brewing tea. It goes something like boil up some water, put the tea in, steep for 15 minutes, and then enjoy. But not all teas are brewed equally. Sure, you can have a general rule for all teas and some drinkable potion will come out of it. But the results will be quite different. General, simplified procedures for big teams produce some kind of result but fail to take advantage of different scenarios. If all projects need to have a planning phase, git commits, branches, type systems, testing procedures and the like, even the small script done in a day to test a hypothesis will take a committee to implement and be done in a matter of weeks or months just because you have all this non-essential apparatus that one cannot get rid of or risk being getting rid of, being employed alongside it.

These are just a few of the side-effects, I'm sure you can think of others. But the most important effect on teams employing observer languages in high doses, and one possible reason for their lethargic temperament, is that they spend so much time and mental energy discussing, developing and exploring the solution to their project in their own observer language and not in the technical language, for reasons given above. And as such, the solution to the problem they are tackling is trapped inside their tools, diagrams, tickets, bullet-point lists, instant messaging channels, chats, video recordings, sprints, commits and branches all wrapped around in the undefined terms and assumed knowledge logged inside various team members' heads about how the project works or even about what its requirements are. You cannot access, play or consume such a project from the elegance and speed of a technical language, like other software tools, environments or programming languages, for example. You cannot test its correctness or roam free in the countryside and tame wild horses with it. Anytime you need to play, ask or answer big questions within such a project, you need a meeting of the chief observers, you need to draw more diagrams, generate more video and audio recordings, more bullet-point lists and more marketplace talk needs to take place. It becomes a game of guessing of what happens if I change this here or add this feature there. Fewer and fewer questions and of the lower caliber can be answered directly and with confidence in such an environment.

Some are born and bred right into such observer teams. Their first contact with the technical language is through the observer language, through the eyes of the observers, through the way they see, understand and organize their projects. For such newborns, anything else is just too different and too strange for their eyes. Indeed, forcing a transition to the technical language would burn their pupils, as has been the case for at least 2500 years, when the first case of such an accident was officially recorded. To a reverse voyager from alien lands though, it is a splendid sight and a real adventure when they find themselves in such teams. Through a twisted reverse of roles, they gradually become the observers themselves, the observer teams become the norm and the observer languages become the new technical languages everyone has to master or risk becoming irrelevant bystanders.