Becoming a better coder through better information-seeking behavior: my journey at Dwelo
When I came to Dwelo, I had minimal exposure to the tools I would use to create my internship project. Also known as “Virtual Communities”, it consisted of a table that rendered real-time data from thousands of virtual hubs for testing purposes done by the QA and Engineering team. Despite my limited skillset, It took me two weeks to be ready to start coding. Of course, two weeks watching tutorial videos and skimming through documentation pages could never be enough to sit down blindfolded and spill out the most elegant (and functional) code. But two weeks was enough for me to understand what my possibilities were. And — while I’m not a senior engineer but rather a rising sophomore at Stanford — that is the story I chose to share with those also beginning their journey in Computer Science.
—
It is 1983. A doctor performs heart surgery on a given patient. After making an incision, he suddenly realizes that he has forgotten what to do next. To make things worse, there was not a single doctor around he could go up to for him to refresh his memory. So, he resorts to his last option and pulls an old book he kept around since he was a medical student. He starts quickly thumbing through each page, searching for the information he needs to resume the operation. It takes him five minutes to find it. He puts the book back on the shelf and approaches the patient, but something is odd. From the time he made the last incision to when he came back, the patient had lost a significant amount of blood. Concerned, the doctor tries his best to speed up and finish the operation, but it is simply not enough. The patient is dead.
Now, what this example shows, besides my utter ignorance about real-life procedures of heart surgeries, is that retrieving information always comes with a cost: latency. In computer science, latency is the delay it takes from information to flow between two points. In our case, it is the delay it takes for the doctor to find the following procedure in his old medical book. Latency is a crucial concept because learning is precisely the ongoing process of reducing the latency of information retrieval/acquisition. Think of it this way. To do well in school, you first acquire information when engaging with a book chapter or listening to the teacher. Then, when doing assignments, you continuously retrieve the information by looking back at your notes. If extra information is needed, you go back to the original source by spending extra minutes reviewing the book chapter or asking the teacher for extra explanation. As you prepare to ace the exams, you start memorizing as much relevant information as you can. Finally, you get an “A,” which you interpret as evidence that you really learned that particular topic.
But have you noticed something here? Our memory is usually the lowest possible latency for information retrieval we can achieve. In other words, learning is the optimization process of lowering retrieval latency. So coming back to our example, even though the doctor never stopped helping the patient, one could fairly claim that he is to blame for the patient’s death because he should have memorized all procedures — he should’ve optimized his information retrieval capacity for the lowest possible latency.
Yet, although I use the term “information retrieval latency”, I don’t want you to misinterpret it as the decrease of the speed of using that particular information for a particular end — otherwise, schools would award those who could get more answers in a test in the shortest period of time. Rather, my argument is that learning is all about lowering the required steps to retrieve a particular piece of information, and that is usually done by simply memorizing that information. What one does with information and at which pace is a whole other story. Think of two biologists with the same level of knowledge trying to answer the question “What is DNA?”. The answers could be given in a significantly different amount of time, from the rehearsal of an entire 226-page book to a simple dictionary definition. Different contexts mean different amounts of retrieved information, even if the information retrieval latency is the same.
Now, before I proceed with the application of such concepts when it comes to learning, I want you to keep that idea about latency in the back of your mind for a second. For now, let us briefly pause to talk about linguistics. In particular, let us talk about two crucial surrounding concepts: syntax and semantics. Syntax refers to the procedural rules that encompass the different arrangements of symbols, such as words and phrases. Semantics encompasses the higher-order abstraction of the syntactic elements, such as meaning. When you are coding, you are writing stuff. It is different than writing English or mandarin, but syntax and semantics are present in the whole process.
This is where I would like to bring back our discussion of information retrieval latency and introduce the difference between syntactic vs. semantic latency. The key point relies on the fact that the number of steps of retrieving information about semantic and syntactic elements hugely varies between each other. It takes very few minutes to look up in a dictionary and find a word that captures the feeling of complete unperturbedness. Yet, it takes an undefined amount of time in reviewing the scientific literature to describe how one can attain ataraxia.
At first glance, it seems obvious that one should always prioritize lowering semantic latency when learning, but yet so many people make the mistake of getting too much concerned about syntax when learning how to code. Let me give you an example that illustrates the difference of how syntax and semantics play crucially different roles in programming. Suppose you are assigned the task of writing some code that prints “hello world” to the screen. To do so with a full understanding of the code, you first need to understand several semantic concepts. You need to understand that there is a terminal where you can output text (and, in some cases, the terminal can act as an entire operating system). Also, you need to understand that there is a function built in a standard library that receives the text and prints it to the terminal. After understanding all underlying semantic structures, you finally get to the syntax — and here is where a large set of possibilities is found.
Think about never understanding the semantics of it. How would you even start to think about this problem? Imagine all kinds of issues one could have (and oh boy, I’ve been there) by not realizing that there is such a thing as a standard library in most programming languages. This is where the concept of latency comes back to us. The key point is that it is much easier to retrieve syntactic information than to retrieve semantic information. Documentation pages, code examples, or a simple image like the one above can make you write “hello world” in very few minutes, but it cannot make you understand how that is achieved.
For this reason, when learning how to code, one should prioritize lowering the semantic latency while making syntactic latency decrease as a byproduct of constant semantic implementation. Let me not sound too confusing here: think of it as if someone tried to become a better writer by memorizing a whole dictionary. In theory, nothing makes it impossible for someone to do it, but would it be an effective strategy? Hardly. Writing well comes from well… writing. And to do so, one must first mentally concatenate pieces of meaning and then use the correct words that best accurately represent them. In doing so, one eventually gets better at picking out the most accurate words. Even though it might be true that some specific words lead to more persuasive phrases, prioritizing syntax over semantics is usually the fastest path towards obscurity. I’ll leave it to your personal reflection on how this same bad prioritization between syntax and semantics applies to written code.
Moreover, another reason — one we have already briefly mentioned — to prioritize lowering semantic latency is that syntactic latency has been extremely lowered due to the increased ease of searching syntactic elements. Visiting one or two pages on documentation pages, GitHub, StackOverflow will do the trick within a few minutes, which makes a complete waste of time trying to be obsessed with memorizing syntax. In fact, the sheer amount of time you spend trying to memorize syntax, such as by taking notes, is probably much larger than the amount of time you spend googling syntax.
Yet, so far, I only gave the prescription that one should prioritize lowering semantic latency. But how does one actually go about lowering its semantic latency? The answer here is a straightforward one: it is a skill. I have a joke that I occasionally tell friends that the last job in the world will consist of a person sitting in front of a white screen with a search bar in the middle. There is a tremendous amount of information on the internet, but information is not spread around evenly. In many cases, it takes much less energy to find low-order information (What year the United States was founded?) than high-order information (What is the history of the United States?). Both of these questions might seem like they share the same search process; you jot down some words on google and press enter. Yet, the number of steps differs significantly. Knowing how to search higher-order information is knowing how to navigate between hyperlinks, it is knowing how to identify new terms and keywords. It is knowing how to gain clarity from the timeline of how something was built. It is knowing how to read a page of documentation. It is knowing how to make the next jump. If you are familiar with the concept, I like to think that the process of retrieving information can be represented as a binary tree, where its root is the google query.
—
So let us come back to my internship experience. When I was first learning ReactJS, I first felt overwhelmed with the amount of information given to me all at once, and guilty that I couldn’t grasp everything at first. However, after not being obsessed with understanding every single argument a “memoization” hook should receive. Instead, I put more emphasis on remembering the fact that, whenever I was dealing with expensive functions that received the same inputs, I could significantly improve performance by using memoization, a technique that consists of caching repeated return values for the same inputs, and that I could do so using React hooks. If I ever encountered such a case in the code, I could easily look into its documentation page and quickly retrieve the appropriate syntax that would allow me to quickly implement it. And that is a big lesson I want to carry in life.
