Learning as a Developer
As I already shared before, learning and brain science is one of my long-term interests. Over time, I have seen a huge number of research papers, non-fiction books, educational videos, tutorials, and coaches focusing on how to improve learning for students and professionals. This makes complete sense to me. We all understand that we live in a very rapidly changing world, and the ability to adapt, relearn, and learn faster plays a crucial role if you want to stay relevant in the industry.

At the same time, most of what I see is either strongly focused on science and medical topics or describes learning approaches in a very general way. For someone working in a highly practical field like programming, this can sound abstract or not immediately applicable. As a developer who is constantly trying to grow professionally, and as someone who genuinely enjoys learning even outside of IT, I decided to share a concrete example of how learning techniques and strategies can be applied to an IT learning path.

One approach that really resonated with me is described in a video by Justin Sung about remembering what you read.
How to Remember Everything You Read - YouTube
The key idea there is that learning a new topic can be divided into two main parts: consumption and digesting. And the most important part is digesting. How you digest information depends on the type of information you consume.
To explain different types of information and how we memorize them, he uses the PACER framework. PACER stands for Procedural, Analogous, Conceptual, Evidence, and Reference.
Procedural information is learned through practice. This is the “how to do” part. Analogous information works best when you connect new ideas to things you already know. When you learn something new, you try to link it to existing knowledge, experiences, or mental models.

If we look at the first type of information that developers often deal with, such as new programming models, approaches, or technologies like RAP, AIF, or OData, there is a strong procedural part. You need to know how to build something step by step, how to write the code, and how to make it work. At the same time, there is also an analogical part, which is the theory behind these technologies. A good example here is design patterns. On one side, there are core OOP principles and the ideas behind each pattern. This is where analogies help a lot. Inheritance can be compared to parent-child relationships, a factory pattern to a real factory that produces objects, and so on.
On the other side, design patterns also contain procedural information: how exactly to implement them in a specific language. In ABAP, this could be concrete language constructs like using a private constructor for a Singleton. To really learn this topic, your brain needs to work in both directions. You practice implementing the pattern, and at the same time you observe how the core principles are applied, how abstraction or inheritance is used, and how these principles help to solve a real problem.

About the importance of practice with new concepts I’ve also already mentioned here: From Templates to Real Projects: Practicing RAP on Something That Matters

Another important type is conceptual information. This includes facts, theory, and explanations. For example, how integration between systems works, or how the Control Framework works in ABAP. The Control Framework is actually a very good example, because it explains many strange behaviors that developers often face in their first screen-based reports. Once you understand the architecture behind it, a lot of things suddenly make sense. You can memorize that you need to call CL_GUI_CFW=>FLUSH in certain situations, but a much deeper understanding comes when you know why this method is needed and how it influences other things, such as RFC calls or screen synchronization.
For conceptual information, mapping is a very effective technique. Mind maps help to see connections between concepts and to understand the overall workflow inside a topic, instead of memorizing isolated facts. As one quote I really like says, our job is not to remember information word for word, but to recreate the network of knowledge that an expert has.

Consumption and digesting should always be balanced. Just quickly looking through an unfamiliar technology before an interview rarely works. Even if you manage to answer basic questions and pass the interview, it does not mean that you have really learned the technology. Real understanding comes when you try it on a project, face problems, search for solutions, and ideally later find more advanced explanations that confirm why something works the way it does. Sometimes you even figure it out on your own, and that moment is especially valuable.
The next type of information is evidence. For developers, this often comes in the form of real project cases. Something did not work, and after implementing a specific feature or approach, it finally did. These examples stay in memory much better because they are connected to real experience. For instance, you have a non-editable field coming from a text table, but the customer needs to edit it in a Fiori app, and the solution is to implement an augmenting operation. Or you have a benefit calculation where data comes from different sources, and this becomes a perfect real-life example of the Template Method pattern: one fixed process with different implementations of certain steps. These small mental pictures help to understand concepts much deeper and to see how theoretical ideas solve practical problems.
For evidence-based information, storing and rehearsing is extremely important. Looking back, I regret many times that I did not save at least short descriptions of approaches that I or my colleagues implemented in early years. This often leads to reinventing the wheel again and again. This is where ideas like conceptual maps or a “second brain” system become very useful.

Reference information is the last type. These are specific numbers or facts that you sometimes need to know, but they do not change your overall understanding of a concept. For example, the number of open cursors allowed in a program. For this type of information, storing and rehearsing is also the right approach.
The first three types, procedural, analogous, and conceptual, are the most important because they form the foundation of understanding. There is little sense in memorizing random evidence or reference facts if you do not understand the core of the topic. These details can be saved for later, but they should not be the main focus during learning.
If our goal is to become good professionals, or even experts in our field, simply reading through information is not enough. You need to digest it.
A good example of this approach for me is how I learned RAP. During that time, I had several constraints. I was working on a real project with an old system version where even CDS was not supported. The market situation was such that customers were not ready to move to new versions and technologies, so switching projects was not an option. At the same time, when you come to another market that constantly talks about cloud, AI, and cutting-edge technologies, you suddenly feel irrelevant because you lack both experience and understanding of how these new things work.
This is exactly the moment when you need to learn fast and efficiently. Fortunately, today we have much more opportunities for that, including cloud systems and trial versions. ABAP has become much more accessible than it used to be.

So how does this learning process look in practice? First, you face all the concepts and theory related to the HANA database. In my experience, the “ancestor” was always Oracle on old systems. This means you need to understand the differences and their consequences, because they directly influence how you write code and how you avoid bugs, performance, and memory issues later.
Second, there is the architecture of RAP itself, with its layers and responsibilities. This is strongly conceptual information. Then you move to implementation guides that explain how to build things with RAP. This is procedural information, and here practice is essential. During this process, you also collect reference and evidence information.
After that, you can dive deeper into more complex topics like augmenting and side effects. At this stage, the goal is not to just remember which keyword to put into which BDEF, but to understand why it is needed, how it solves a problem, and why the problem appears at all. You start asking yourself deeper questions, and this is where real expertise grows. Not from knowing a single keyword, but from understanding what is happening on a conceptual level, so you can adapt the solution to new situations and design better systems.

This is also why I create and constantly update my mind maps. They are still a work in progress, because learning never really stops, but they help me to structure knowledge and see connections.
I hope this example was useful and maybe inspired you to think differently about learning and professional growth.
Made on
Tilda