In 2021, Don't Learn a New Programming Language

Java, Python, C#, Swift, Dart, Golang, Oh my!

Starting in 2021, you will see a barrage of new posts advising you to learn the new and hottest up and coming programming language. I have seen this trend for more than a decade, the time I have been actively developing software for a living. Every January brings a deluge of covert advertisements asking you to learn the “Top 10/Top 5” programming languages to learn in the new year. Don’t get me wrong; I am not asking you to give up on learning. The problem is that we only have so much attention. On the one hand, the return on investments of an obscure technology is small, while on the other hand, one does not want to miss out on the early mover advantage.

As a novice software engineer early in my career, I had faced the same dilemma. I did what I knew I could do - put in more hours, hoping that someday the effort would pay off. And pay off it did, only in a small way. As software engineers, or for that matter, any practitioner, there are incremental changes, and then there are disruptive changes that can bring a 10x change in how you do your job for the better. I admit languages like Haskell and Prolog expand your perspective, but I wanted something abstract yet useful in my practical day-job. I see now that there are two aspects to Software Engineering as a practice, and I am sure this is general enough to apply elsewhere. The two aspects are - Mental Models and Phenomenology.

Mental, who? And, Pheno-meno, what now? Read on.

Mental Models

Shane Parrish popularized the Mental-Model hype recently. For me, Alan Kay brought this idea home when he talks about a point of view being worth 80 IQ points. The idea is simple - you need different ways of thinking when confronted with a problem that is not up to your alley. By “up your alley,” I mean something you do not solve in your routine life. If you take the examples from building software, then an example is how writing SQL requires a different way of thinking than writing object-oriented code. This “way of thinking” is a Mental Model. Shane Parrish generalizes this concept. For example, one of my favorite mental models from the repertoire is Occam’ Razor. The principle is simple - simple explanations are better than complex ones. Numerous times, I am confronted with red-herrings when I debug. Occam’s Razor is a mental model that asks - Are you overcomplicating stuff?

What Mental Models would work for writing software? We see new programming languages and new frameworks popping up all the time. There is value in learning them, but we have only so much time, as I said before. If someone would start compiling Mental Models for Software Engineering, what would it entail? My understanding is that there would be a laundry list of programming languages, web frameworks, system’s programming, design, etc. I have been seeing them all the time in blog posts and books. What if there was a more, so to speak, robust repertoire of Mental Models?

When I started, I was not one to read specs and RFCs. It turns out, reading them and understanding them is better than trying to wrap your head around explanations in random websites and blogs. I have seen that a person who has read the Java Specification, particularly its Memory Model, understands Java memory problems better. The same goes for Internet RFCs. Understanding RFCs for, say, DNS gives you a different perspective about DNS and its evolution. I got started on reading specs by reading Sun Microsystems’ excellent documentation. One of the seniors in my workplace suggested that I go through them. It was one of the best pieces of advice I got.

Let’s go meta. Reading and understanding RFCs and Specs are good, but what if you could formulate your own specs and verify them. I will do you one better - what if the computer automates the verification. Formal Methods have come on their own in the past few years. Formal Methods are a honking great idea. If you really what to learn a new language next year, may I suggest you give learning a Formal Method language a try? You know there is a weapon in the first level of a video game that is just there until you circle back to it in the last level, Boss Fight, and it makes the fight super easy. Yeah! Formal Methods are that.

Formal Methods have a long and interesting history in hardware development. In recent years, tools like TLA+ have caught on with the software development communities too. Created by Leslie Lamport, TLA+ is a tool to simulate properties of any discrete event simulation system. It turns out that discrete event simulation is a good fit for modeling software systems and distributed systems. I have been following Hillel Wayne for a while now. Wayne has been popularizing using TLA+ and Alloy in software development processes for a while now.

Phenomenology

I admit that I am using the word Phenomenology loosely. When I say Phenomenology, I mean the muscle memory for doing programming-related tasks. Most modern programming languages, including Python, have come to a stage where there is more than one way to implement something. Updating your repertoire of code snippets for common programming tasks is a good way to be in the know of the changes in the programming language.

One of my favorite books is “Python cookbook”. It is a collection of recipes organized under such headings as - String recipes, Network recipes, etc. An in-depth discussion about the code snippets follows each recipe. Many folks recommend a book based on programming language semantics or syntax like “Fluent Python”. My recommendation has always been “Python cookbook”.

When I want to cook a new dish, I usually search the internet for its recipe. It might be valuable to get insights into the intricacies and nuances of cooking by reading “Salt, Fat, Acid, Heat” - but that is peace-time activity.

Lastly, if we want to compare phenomenology and mental models to memory models, then I would say if Formal Methods are declarative memory, then cookbooks are the procedural counterpart. Like Formal Methods helps in hashing out “what” needs to be done, cookbooks help implement details. Let’s face it - the devil is in the details. If you’re thinking about the obviousness of the last sentence, let me remind you that I have seen folks who are so caught up with the details that they forget about what they are building. If you understand the modularity of the separation, you stand a better chance of building robustness.

Crouching Fox Hidden Hedgehog

Isaiah Berlin, a philosopher, proposed a classification for learners - the Fox and the Hedgehog. The idea is that a fox knows many things, whereas the hedgehog knows one important thing. What I am suggesting here is a mixed bag - a chimera, crouching fox hidden hedgehog, or crouching hedgehog, hidden fox, if that tickles your fancy. There is value in having a deep knowledge about a domain, but there is more value in getting one level meta.

Takeaways

• Invest in learning a formal method, like TLA+ or Alloy.

• Have a repertoire of code snippets about common tasks handy.