Programming is translating between levels of rigour
Over the last 3 years, I think I've finally managed to summon up a decent answer to the question of "what does a programmer do?".
A programmer is someone that can translate to languages that allow for and require greater levels of rigour.
First, let me try to explain what I mean by rigour. It could also be interchanged with "the fuzzy limits a language has on the complexity it can express without becoming incoherent", but there are subtle differences.
i – Rigour in language
Take 5 languages, Butler English, American English, Modern Mathematics (say the subset used for LA), Python, Rust.
There’s a hierarchy of “rigour” that we can roughly create there with Butler English at the bottom and Rust at the top. That hierarchy arguably goes in reverse in terms of ease of learning, but let's ignore that aspect for now.
Butler English is a pidgin that was used by people from the Indian subcontinent (and more specifically the Tamil Nadu area) to communicate with the British invaders. It's basically the stereotype of "bad" English spoken in India taken to an extreme, to quote an example from Wikipedia:
One master call for come India … eh England. I say not coming. That master very liking me. I not come. That is like for India — that hot and cold. That England for very cold.
Being a pidgin it's characterized by a lack of rigour, a sentence could mean many things and often make sense only in context, as well as by variation among its speakers, someone from Chennai and someone from Kalkuta might have spoken something that, to outsiders, sounds like the same pidgin, but they'd hardly be able to understand each other.
Expressing anything complex in the language is impossible or difficult. You can't write a great novel using this language.
American English is more complex and standardized, but if you want to express anything mind-shattering you'd still probably switch to mathematics, or at least to a very niche academic dialect.
Whatever "American English" a 20-year-old student at Berkeley speaks is tangential with that spoken by an 80 years old cab driver in Florida, but only loosely so.
It's more rigorous, allows for more complexity, and varies less from speaker to speaker than Buttler English, but it still does so to a considerable degree.
Mathematics is much more rigorous than Latin, especially if you take the dialect of a specific field, say Linear Algebra (excluding that found in ML papers in a misguided attempt at sophistication which looks more like math-envy). LA is so consistent that it’s very likely nationality makes little difference in how one “speaks” it and in the vast majority of cases what’s written in it is unambiguous to an extreme. It’s rather hard to “misread” math, especially when you have a few people looking over the same text in order to spot each other’s interpretation errors.
There is variation in how it's written/spoken, but those mainly happen over time, and papers as early as the 60s are fairly readable to modern audiences, albeit unpleasant to digest.
I'd also argue it allows for greater degrees of complexity, theorems allow for abstractions/simplifications that are missing in normal languages.
While linear algebra can be invalid and fuzzy depending on the reader, Python can't.
There's a central authority for what constitutes valid python3.9, the cpython runtime. If you made a mistake your code will crash, assuming that bit ever gets "read".
All speakers must agree to this standard to use the language, otherwise, their code won't compile. Finally, it allows for building edifices like (early) Google, Reddit, Quora, Instagram, Ansible, and Openstack. This seems to make it much more complex than math. The complexity of what can be spelt out in math is more or less limited to what a single mathematician can understand during his lifetime, but the complexity of a codebase can be spread out across many, since running and modifying the codebase is not equivalent to understanding it.
So python allows for more rigour and more complexity than math and solves the different-dialect problem.
Rust is python on steroids, in that its rigour extends to new concepts that allow for more explicit instructions (e.g. ownership, moving, ARCs, unsafe-blocks, channels). More importantly, it catches errors at compile-time rather than runtime, and it catches more potential issues and "unexpected" forms of behaviour that python might miss and that would be "theoretically correct", but unlikely to have been meant that way by the programmer.
This allows for greater complexity. One can take a stab at building kernels, professional game engines, physics simulations, databases, networking stacks and other such projects using Rust.
So Rust ends up being more rigorous and homogenous than python while allowing for greater complexity.
ii - Transaltion
If you think of the "dynamic" between programmers and clients the interactions are usually something like: Requirements -> Clarifications -> Questions -> Initial implementation -> Solving edge cases -> MVP -> New Requirements -> Final product. Leaving aside a lot of debugging.
Someone tells you "Hey, I want you to build me an app that's like Spotify but for funny videos playlists"... and that begs a lot of questions, even with Spotify as the template.
Which language to use? Which libraries? Which server host? Which CDN? What level of availability? How to optimize between cost and speed... etc.
Those are very high-level questions, the low-level questions down to individual lines of code, to how the HTML is rendered in 10001 different devices.
The art of programming is about asking questions to which you can't infer an answer with high certainty, which the asked will know how to answer with high certainty. It's about asking for rigorous explanations where you can't figure them out and where getting things "just right" is critical.
Since English and Python are at whole different levels of rigour, any explanation in English will not be implementable in python perfectly, some gaps will need filling in, but a lot of times the gaps are "obvious" and you need not bother anyone else to reason through them.
I once asked "Is a trillion dollars worth of programming lying on the ground ?", that is to say, how come people pay 300k to hire people in the bay area when they could pay someone in Nepal with equivalent programming skills 30k.
Now I think it's the same reason why people can't hire a Japanese speaker to translate Burmese to Japanese, they require a translator, someone that understands both languages very well.
People living in the Bay Area have a shared language, a shared dialect, a shared culture. What they need is someone that "gets them" well enough to ask the smallest amount of questions possible when polishing their ideas with the rigour needed to run on computers. To perfectly "get" that dialect you need to use it, you need to live the culture which employs it and transforms it. So every time someone from SV is hiring a non-SV resident they are wasting some time bringing them up to speed with the language they are translating from.
iii - People
Of course, this boils things down to both the management and coding side being a lot about understanding different cultures.
If you "get" both the Bay Area language and the Ukrainian language, then you can serve as the bridge between speakers of rigorous languages in Ukraine and people with ideas and money to implement them in the Bay Area.
Similarly, if you "get" the Bay Area language as someone living in Russia, then there's no reason you can't ask for a wage equivalent to someone living there.
The problem here, as stated above, is that getting a perfect understanding of a language means living and breathing in the culture that uses it.
Could you find cultures with loads of capital but lack of technical talent in technical rigour? Probably
Could you find cultures with loads of technical talent but a lack of capital? Probably
Then understanding some of those cultures might be quite a valuable skill.
iv - Lost in translation
The problem, of course, is that things can get lost in translation. It's much easier to work with someone that speaks a rigorous language than transmit everything through a 3,4,5 or 100 long chain of people that do the translation.
This actually makes me question another idea I concerned myself with before, namely the presence of "imaginary problems" being solved by engineers for seemingly no reason in large organizations.
Maybe these are just a mishap of translation, which happens in e.g. a bank because banks try to "optimize" for cost and hire loads of programmers from countries with different cultures that are relatively poor. At the same time, banks are very old institutions that are lead by a class of elites speaking a language well understood by a few thousand other people living in the same gated upstate community. So you end up with very long communication chains.
Long communication chains also lead to principal-agent problems, which make it impossible for "the person in charge" to understand things went wrong until they see the finished product, if even then.
Norse cultures had warrior-poets that recorded their deeds in song. They may not have been the best warriors, but the others warriors weren't poets, so we know little about them. They may not have been the best poets, but the other poets weren't on the battlefield, so they had little to write about.
Similarly, early SV has businessmen-coders. People that funded Facebook, Google, Apple, Paypal and so on. They may not have been the best businessmen, but the other businessmen couldn't understand rigorous languages and implement their deals. They may not have been the best coders, but the other coders couldn't strike multi-million dollar deals for their products.
v - Learning languages
I am rather sceptical of endeavours like Lambda School. But I think they do get one thing right, "teaching a trucker to code" is only half programming skills, the other half is getting them to understand the cultures of the other programmers and of people rich or influential enough to start companies.
This view might seem quite sombre to some since it means one has to "adopt" the norms of other cultures in order to be good at anything tech-related, rather than it being a purely theoretical pursuit. I tend to disagree here, I think this is a generator for greater diversity, the good kind that makes everyone bring along the elements of their culture that are collaborative, that add new and interesting things, and drop old prejudices and brutal customs which are best left to the history books.
It's worth keeping in mind that this also forces people from "rich" cultures to adapt and accept the norms of cultures that are much less wealthy for purely arbitrary reasons. After all, business is business, and being a businessman that refuses to step outside of an "Ivy league culture" means you're missing out on communicating your ideas to millions of people with the talent to translate them into reality.
But I digress, I'm getting a bit too idealistic and too political for my taste.
The more important part of programming is communicating with other programmers. But those programmers might come from very different backgrounds and thus understand very different languages.
You can think of this as data scientists knowing R and system engineers knowing C, but among system engineers, the kind of C someone moding Linux knows is miles away from the kind of C a battery-efficient embedded systems developer speaks.
I'm very biased here since I like working across the spectrum. However, I can't help but feel like this "translation" viewpoint would encourage an approach where you try to learn a variety of languages and ecosystems for purely communicative reasons. I've worked with C++ for 2 years, I love it, under that definition of love which is a blend of hatred and passion; While I never plan to ever again touch it professionally, I think it gave me a way of speaking to very smart people from which I'd have been linguistically cut-off otherwise, unable to understand the wonders, potential and difficulties that their projects entail.
The other important takeaway here might be related to NLP, and how it might serve to bridge some previously very expensive linguistic gaps. But getting into that would entail an article of its own.
vi - Summary
To summarize everything:
- Programming can be thought of as the skill of translating ideas from less rigorous to more rigorous languages.
- A lot of the pay gaps and "skill gaps" in programming might be generated by linguistic and cultural gaps.
- Learning programming across the spectrum might be quite powerful even if you plan to specialize, simply because it gives you a way to work with more people.
- A lot of "mistakes" in large tech companies might be better thought of as translation issues rather than issues of agency, as I had previously thought (though increasing agency might still be a good fix for these).
- There might be more than surface-level reasons to learn the culture of your coworkers and of the kind of people you'd like to work with.
That's about all, I'm afraid I've spent many more words than necessary detailing this rather simple insight, but I think this is crucial to a way of thinking that has helped me both make sense of the world and navigate it, and I hope it may help others too.
I often end up writing about things that seem very obvious and then have
Published on: 1970-01-01
