Fragment of a comic with a simple explanation of what floating point numbers are



When it comes to improving the skills of a programmer, we often talk about testing, writing code for reuse, design patterns, readability.



This is all very important. But I want to talk about another way - to study in detail the operation of the systems that you use! For me personally, this is the main way to improve qualifications.



The point is that many programmers use technology without thinking about how it works. And that's okay. People perform assigned tasks. They are not required to understand the whole essence, because the details distract from the main task and often do not help in its implementation in any way.

Examples of "system details"

For example, here are the different types of programming and technologies that you can understand in detail.



Frontend JS:

• how the event loop works;
  
  
• HTTP methods such as GET and POST;
  
  
• what the DOM is and what you can do with it;
  
  
• same-origin policy and CORS.

CSS:

• how the rendering of inline and block elements differs;
  
  
• what is the "default stream";
  
  
• how flexbox works;
  
  
• how CSS decides which element to apply which selector (the "cascading" portion of the cascading style sheets).

System Programming:

• difference between stack and heap;
  
  
• how virtual memory works;
  
  
• how numbers are represented in binary form;
  
  
• what is symbol table;
  
  
• how code is loaded from external libraries (e.g. dynamic / static linking);
  
  
• how atomic instructions differ from mutexes.

You can use technology without understanding how it works (and that's okay!)

We work with many different systems. It is unreasonable to expect that everyone knows everything about all systems. For example, many developers create applications that can send email. It is likely that most of these developers do not fully understand how email works. This is a really complex system with many technology stacks! This is why abstractions are needed.



But if you start working with a system in more depth (for example, CSS, HTTP, goroutines, email) and do not quite understand how it works, then problems can arise.

Your bugs will show you when it's time to improve your mental model

When I lack a key understanding of a certain technology, this can be understood by indirect signs:

• due to the wrong mental model i make mistakes
  
  
• I'm trying to quickly fix these bugs, but I can't find the right questions to diagnose
  
  
• in the end I feel very upset

I think the really important skill is being able to understand what's going on . I gradually learned to recognize this feeling: “Okay, I’m really confused, I guess I don’t understand something about how this system works”.



A senior developer is not required to know absolutely everything, but must quickly recognize if he does not know something - and learn it. By the way, about them ...

We have to constantly learn new technologies because we work with so many types of systems!



For example, I am well versed in the fundamental concepts of C and web programming (for example, the theses at the beginning of the article), but when it comes to graphics / OpenGL / GPU, my knowledge is not enough. And sometimes it suddenly turns out that I lack a systemic understanding in a particular area, for example, CSS.



Of course, this is an unpleasant discovery - that you really do not understand how the system works with which you have been working for ten years ("Shouldn't I already know this? I've been using this for so long ..."). But this is completely normal! There are too many technologies, and we are constantly inventing something new, so that no one can be aware of everything.

How to approach exploring new areas

I like this pattern:

1. Please note that a question baffles us ("Hey, when I write await
   
   
   
   in a Javascript program, what's really going on?")
   
   
2. We break the general question into specific factual questions, for example: “When await
   
   
   
   does it work , how does it decide which part of the code will run next? Where is this information stored? "
   
   
3. Find out the answers to these questions (by writing a program, reading something on the Internet or asking colleagues)
   
   
4. Test your understanding by writing a program ("Hey, that's why I had this error await
   
   
   
   ! And I can fix it like this!")

The last step, “Test Understanding”, is really important. After all, we learn programming in order to write code! This is the whole point.



If you immediately use new knowledge - implement a new function, fix a bug, or just write a test demo - it becomes MUCH more real than if you just read about it. And then the chances are much higher that I will be able to use this knowledge in the future.

Knowing even the simplest facts helps a lot.

You don't have to learn something huge. For example, I didn't really know how floating point numbers work before. So I was nervous that something strange would happen that I don't understand.



And then one day in 2013 I attended a lecture by Stefan Karpinsky with an explanation of this topic (like in a comic book , only during the lecture we were told more strange details). And now I am quite confident with floating point numbers! I know the basic limitations and when they cannot be used (for representing integers greater than 2 ⁵³ ). It is now clear to me how difficult it is to implement numerically robust linear algebra algorithms - I personally have no idea how to do it. That is, I now see real boundaries your knowledge.

Connect new facts with information you already know

It's easy to repeat a phrase like "there are eight bits in one byte." It's true, but so what? The hardest thing (and much more useful!) Is to relate this information to what you already know about programming.



For example, take the fact "there are eight bits in a byte." Looking at a single line Hello



in the program's code, many questions can be asked, for example:

• How many bytes in memory are used to represent this string? (five!)
  
  
• Which bits does the letter correspond to
  
  
  
  ? (ASCII encoding is used here, so you can look at the ASCII table)
  
  
• If a running program outputs a string Hello
  
  
  
  , can you find in RAM where exactly these bytes are stored? How to do it?

Explore what is interesting to you personally - maybe you are not interested in how these strings are represented in memory, but really want to know how many bytes in Unicode are emoji with a heart? Or how floating point numbers work. The main thing is to ask questions!



If you associate new facts with already familiar concepts (emoji, floating point numbers or strings), then the information is absorbed much better.



Next, let's talk about two ways to obtain information: yes / no questions and computer experiments.

How to get information: ask yes / no questions

When I am talking to a well-informed person, it is better to start extracting information with really simple questions that can be answered simply "yes" or "no." I already wrote about this in How to Ask Good Questions , but I really like the topic, so let's talk about it again!



Such questions make you articulate your current mental model clearly. In addition, such questions are easier for a person to answer.



For example, here are a few different types of questions:

• Test your current knowledge
  
  
  • Example: "Is a pixel shader the same as a fragment shader?"

• Check how different concepts relate to each other
  
  
  • Example: "Does Shadertoy use OpenGL?"
    
    
  • Example: "Do video cards get information about triangles?"

• High-level questions about the core task of a technology
  
  
  • Example: "Does the orchestrator for MySQL proxy database queries?"
    
    
  • Example: "Does OpenGL give more or less control over the video card than Vulkan?"

With yes / no questions, you are in control

If you ask the open-ended question "How does X work?"

1. The person begins to tell a bunch of things that I already knew.
   
   
2. The person begins to tell a bunch of things that are not interesting to me.

Both are frustrating. But this is not the fault of the person you are asking the question to! After all, he cannot know what information you need. However, it is always unpleasant to interrupt him: "Oh no, sorry, please, this is not at all what I wanted to know!"



Although yes / no questions are more difficult to formulate, they provide accurate information on a specific topic. And you won't waste the specialist's time forcing them to explain a bunch of things that don't interest you.

Asking yes / no questions is not always easy

Sometimes things don't go well:



Me : Just to test my understanding, it works like that, right?

him : Not really, it works <completely different>

me (internally) : (brief moment of panic)

me : Okay, let me think about the next question for a moment.



It turns out my mental model was completely wrong. While this is very useful information on its own, it is extremely unpleasant. By asking a really specific question (although it is more effective!), You put yourself in a vulnerable position, because you have to reveal specific knowledge in which you are completely wrong!



In such a situation, I usually say that I need to think a moment. It is required to include a new fact in the mental model and formulate the following question.

How to get information: conduct an experiment

When there is no one to ask, I can google it, read the documentation - and sometimes I don't find anything.



But the great thing about computers is that you can often get answers from the computer itself!



Here are some questions I've had in the past - and what computer experiments have helped me find the answer:

• Are Atoms Faster or Slower than Mutexes? (Blog Article: Checking Mutexes and Atomics )
  
  
• If you add a user to a group, then the existing processes on behalf of this user are allocated to a new group? ( "How do groups work on Linux?" )
  
  
• If the server at address 0.0.0.0 has no network interfaces, is it possible to connect to this server? ( "What is a network interface?" )
  
  
• How is SQLite data actually organized on disk? ( "How does SQLite work? Part 1: pages!" )

Checking on a computer is a skill

It definitely takes time to formulate a question and then conduct a real experiment to test it.



But this is a really powerful tool! If you go beyond just Google, documentation, and conversations with colleagues, then you can do MUCH more.

Think about what knowledge you don't have

As I said, the point is not to understand absolutely everything. But the more experience you have, the more important it is to realize what knowledge you do not have! For example, here are five things I don't know (from a VERY long list):

• How database transactions and isolation levels work
  
  
• How vertex shaders work (in graphics)
  
  
• How font rendering works
  
  
• How BGP and Peering Works
  
  
• How multiple inheritance works in Python

I don't need these things right now. But I will almost certainly come across DB transactions one day, so I'm ready to explore this topic whenever I need it :)