DEV Community: My Linh Tran Vo

Speed code-reading

My Linh Tran Vo — Mon, 05 Jun 2023 18:19:19 +0000

This is the second post in my book review series of The Programmer's Brain by Felienne Hermans. The main point of this chapter is why code-reading is hard and how to speed-code in programming.

Normally, developers spend 60% of our time on average reading code than writing it. Yet, we rarely receive training on how to read code effectively, making this task seems harder than it needs to be. In my opinion, having the ability to read and analyse code written by other developers greatly enhances one's productivity.

Let's have a look at the example below, which is taken from the second chapter of the before mentioned book.

public class InsertionSort {
  public static void main (String [] args) {
    int [] array = {45,12,85,32,89,39,69,44,42,1,6,8};
    int temp;
    for (int i = 1; i < array.length; i++) {
      for (int j = i; j > 0; j--) {
        if (array[j] < array [j - 1]) {
          temp = array[j];
          array[j] = array[j - 1];
                        array[j - 1] = temp;
        }
      }
    }
    for (int i = 0; i < array.length; i++) {
      System.out.println(array[i]);
    }
  }
}

When you read the code snippet above, your brain engages in combining the knowledge stored in your long-term memory (LTM). If you're already familiar with the syntax of a for-loop or an array in Java, you can quickly recall that information.

Additionally, as you read the code snippet, your brain tries to retain key details like the array declaration with elements, the introduction of a temporary variable, the presence of a nested loop to iterate over the same array, and more. It may also recognise that this code implements the Insertion Sort algorithm, which can be a significant time-saver for those who have previously encountered it.


Felienne Hermans, 2.1.1 What just happened in your brain

Why code-reading is hard

Remembering a codebase you've never encountered before is akin to trying to recall the phone number of someone you've just met. It's not an easy task. When we try to remember something, we initially rely on our STM before transferring it to LTM. However, our STM has limited capacity (remember the RAM example?), making it challenging to retain large amounts of new information. Thus, to overcome this limit, our brain needs to collaborate with the LTM.

How to speed-code

To overcome the capacity limit of our STM, we can utilise a technique known as code chunking along with our knowledge of the programming language used in the code we are reading.

In essence, code chunking, also referred to as code grouping or code segmentation, is a programming technique that involves breaking down extensive code sections into smaller, more manageable chunks. These chunks are organised into logical sections or modules based on their functionality, purpose, or organisation.

Since code-chunking helps to read code better, we can then look at how to write chunkable code. One of the methods to help create chunkable code is by using design patterns. This refers to the general, reusable solutions and proven approaches to commonly occurring problems in software design. These patterns facilitate code comprehension by establishing a common language, providing problem-solving guidelines, organising code structures, promoting code reuse, and documenting design intent. By utilising design patterns, developers can more easily grasp the purpose, functionality, and structure of the codebase, leading to improved code comprehension.

Another method is to use comments. While it's true that code should ideally be self-explanatory, comments can be helpful in aiding code comprehension, particularly for novice programmers like myself. High-level comments can provide valuable insights into the codebase and assist in understanding its functionality.

Hermans also mentions another technique called leaving beacons. According to her:

Beacons typically indicate that a piece of code contains certain data structures, algorithms, or approaches.

class Node:                    # this is a beacon
    def __init__(self, key): 
        self.left = None       # this is another beacon
        self.right = None      # this is also a beacon
        self.val = key

In the given code snippet, thanks to these beacons we know that we have a class called Node that represents a node in a binary tree. Each node contains a value and references to its left and right nodes.

In summary, this chapter highlights the importance of effective code reading and presents techniques such as code chunking, comments, and leaving beacons to improve code comprehension. It offers valuable insights for both novice and experienced programmers, making it an interesting and informative read.

Confusion while coding

My Linh Tran Vo — Fri, 02 Jun 2023 11:03:42 +0000

This is the first post in my book review series.

The reason I've decided to write this serie is because I struggled a lot with reading and understanding code written by other developers, and I still do. It got even harder when I started focusing more on backend programming instead of frontend. Backend coding is quite different, and it requires a different way of reading.

I always wondered if other developers have a natural ability to read code like it's a regular language. For me, it wasn't that easy. I realised that it's a skill that can be acquired, so I looked for some guidance.

My current company provides free access to O'Reilly, an awesome platform with tons of engineering books. I found a book there called The Programmer's Brain by Felienne Hermans, and it caught my attention.

In the first chapter, the book directly addresses the challenge I face in understanding code: "Decoding your confusion while coding."

Confusion is what I've been feeling all along. Often, I find myself perplexed when deciphering patterns, classes, methods, and variables. Occasionally, I even forget the purpose of a method or variable as I navigate through the codebase.

According to the author, before we can truly grasp code, we must understand the reasons behind our confusion.

To put it simply, there are three types of confusion when reading code:

Lack of knowledge: Imagine reading code in a language you're not very familiar with. Every new syntax becomes a roadblock in your code-reading flow.
Lack of information: Imagine reviewing code in a pull request on GitHub. You come across a method that requires you to navigate to another method to understand what it does. But you can't do it directly in the GitHub interface without the help of your editor. You don't have enough information.
Lack of processing power: Think of a function where you understand every syntax and variable. But it involves calculations that are too complex to process mentally without writing down each step of the program.

These confusions stem from issues in different aspects of memory. Lack of knowledge relates to long-term memory (LTM), while lack of information relates to short-term memory (STM). On the other hand, lack of processing power refers to the working memory.

I find the metaphor used by the author quite insightful. It's like comparing LTM to the hard drive of a computer, STM to the RAM or cache, and the working memory to the brain's processor.

So, whenever we read code, our brain utilizes various areas of memory. I guess to enhance our ability to read code, we need to train ourselves to better utilize these cognitive processes.

Level up your skills with pair programming

My Linh Tran Vo — Thu, 01 Jun 2023 13:35:42 +0000

The focus of today's post is on the well-known concept in the developers' world: Pair Programming.

When I initially began learning coding, I discovered the concept of Pair Programming from my mentor, who also happens to be my husband. I realised how it aids in enhancing one's programming skills, although I naturally had doubts at first.

Given my introverted personality and struggle with imposter syndrome, it took me some time to gather the courage to actively approach my engineer colleagues and propose pairing sessions. Typically, I aimed to initiate such sessions at least once every sprint, occasionally even more frequently depending on the number of programming tasks relevant to the current sprint.

So what is Pair Programming about?

The name itself is self-explanatory. When practicing Pair Programming, you collaborate with a team member who ideally possesses seniority or more experience either in the programming language or the project you'll be working on.

What are the benefits of this method?

I was honestly surprised at how quickly my programming skills improved after just a few pairing sessions. It got me wondering, why did that happen?

One of the coolest things about pair programming is the interaction between you and your colleague during the session. In my limited experience with pairing, usually, one person takes the lead while the other follows along, providing comments and insights along the way. This collaboration generates new ideas and leads to better problem-solving (after all, two brains are better than one!). It's like having a study buddy, but for coding.

Pairing also serves as a way to reinforce the knowledge you gain from observing your teammate's approach to problem-solving. Instead of talking to a rubber duck (yes, some programmers do that), you're discussing your thoughts and explanations with an actual person. And let's be honest, bouncing ideas off a real person should yield better results than talking to an inanimate object.

What's next?

If you're a junior developer like me and still getting acquainted with the team, don't hesitate to suggest a pairing session with someone you feel comfortable with. Chances are, they'll be more than willing to join you.

Don't worry about potentially slowing down your colleague's workflow due to your limited knowledge and experience. Remember, for you, it's a valuable learning experience, and for your colleague, it's an excellent opportunity to practice mentoring and enhance their communication skills.

Happy pairing!