Cargo cult programming is killing the (Sri Lankan) software industry

Some months ago, I asked a self-identified "machine learning expert" to explain backpropagation to me. They could not. However, they knew how to NPM install Tensorflow and train a model.

I asked a "Kubernetes expert" to explain how containers achieve resource isolation, how it's different from machine virtualization and why it was more efficient. They could not. However, they could write a Dockerfile, run docker and use kubectl.

I asked a "Node.js expert" how Node.js can handle multiple concurrent disk operations within a single threaded event loop, even when the underlying operating system did not provide non-blocking disk I/O primitives. They could not even understand the question. But they knew all the latest Node.js frameworks.

I asked a "React.js expert" to compare different SPA approaches such as direct DOM manipulation, MVC driven client side templating, component-based DOM manipulation and compile-to-vanilla-JS. They didn't understand what I was asking. But they knew the names of all the popular React.js libraries and frameworks.

I asked a "database expert" proposing that we go for the "latest" database, whether they had done all the optimizing that was possible with the current "boring" database: tuning parameters, read-only replicas, materialized views, different storage engines etc. They hadn't. But they knew the names and features of all the "latest" databases.

Now before we proceed, let me introduce you to the concept of "cargo culting". Here's how Richard Feynman put it:

“In the [Pacific Islands] there is a Cargo Cult of people. During [World War II] they saw airplanes land with lots of good materials ("cargo"), and they want the same thing to happen now. So they’ve arranged to make things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas—he’s the controller—and they wait for the airplanes to land. They’re doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn’t work. No airplanes land. So I call these things Cargo Cult Science, because they follow all the apparent precepts and forms of scientific investigation, but they’re missing something essential, because the planes don’t land."

When a programmer behaves this way -- copying programming techniques or using "technologies" without understanding how they work or why they work -- it is called cargo cult programming. And it is killing our industry.

How? Unlike some people, I believe Sri Lankans have a high degree of untapped intelligence. It just needs to be focused and guided in the right direction. The right direction being engineering fundamentals. Instead, digital snake-oil salesmen, CV-padding careerists and imposters have taken young engineers' mindshare away from hardcore engineering, and have dissipated it across a jungle of buzzwords, marketing-speak and commercial products masquerading as engineering concepts and technologies. It is a waste of brain power more insidious than any brain drain.

Imagine a civil engineer trying to improve the load bearing properties of a structure by switching to a new brand of cement (because it is the "latest" and has nanoparticles) rather than doing the necessary calculations to determine the dimensions and composition of the required structure, as per the established standards of his profession. Imagine a physician saying "why do I have to understand how all these organs/cells work, when I can easily Google/Stackoverflow the symptoms and match them against the latest drugs or treatments?" Imagine an automotive engineer who knows the features of every new model of vehicle and its driving experience, but can barely change a spark plug, let alone know the principles of internal combustion or know how to design a better engine.

How do we fix this?

First, understand that many people we call engineers today are just "technicians": skilled professionals who know how to operate or assemble a technology, and perhaps do some basic maintenance. But they're unable to design or build new technologies. It is a painful truth, but the first step toward a cure is usually the admission that there is a disease.

Second, recognize that the solution does not lie in more and more technologies, frameworks, libraries, "patterns" or "paradigms". If you want to accelerate the performance of a system, you go down into the internals, not up towards more abstractions: you dig into the application code, then into the operating system and finally into the hardware itself. Similarly, if you want to accelerate a software engineer, you do not load him up with more and more "technologies". Instead, you improve their mastery of the fundamentals on which every technology is built: algorithms, data structures, network communication, operating systems and database theory. Basically, Computer Science 101.

Why? The more you understand internals, the simpler anything built upon those internals look. Every new technology becomes easier to learn. For example, for someone who understands network fundamentals and Unix, every "cloud" technology is simple, be it AWS, Azure or any other provider. For someone who understands the DOM and JavaScript engines, every front end framework is simple. For someone who is experienced with a system language like C, every other language is easy. Those who master internals never become obsolete. They don't require months of retraining every time a new technology pops up. They're usually just a quick read of the manual away from using it effectively.

Finally, stop talking in buzzwords. Stop talking about them in tech talks. Stop talking about them on social media. And most importantly, stop asking about them in interviews. Instead, focus on fundamentals. If you look at how top tech companies such as Google or Netflix interview software engineers, you will find that their coding and system design interviews never involve questions about specific technologies, languages or frameworks. In fact, if you answer a system design question by assembling off-the-shelf "technologies" (i.e. products), you will fail the interview.

For my part, I no longer expect entry level software engineering candidates to know the tech stack required for the job. All I expect is that they have a solid grasp of computer science fundamentals, and an in-depth knowledge of at least one thing, anything. This tells me that they have the ability to learn. I know at least one other hiring manager who has recently started a similar "no experience required" approach to hiring junior engineers. The next step would be to develop a similar approach for senior hires.

It's time to go back to basics.