Programming: Memorize or Create? Why Understanding Beats Rote Learning

Many newcomers think that senior developers have memorized entire API manuals, but in reality they rely on deep understanding and repeated practice rather than rote memorization.

Programming, the author says, is roughly 70% understanding, 20% practice, and only 10% memorization. The small memorization portion should become a conditioned reflex built on that understanding.

For example, when working with files on Linux the essential functions are open(), read(), write(), and close(). Newcomers often worry about remembering parameters, but what truly matters is the core logic: opening a file requires a filename and mode, reading/writing needs a buffer and length, and closing requires a file descriptor. Specific parameter order can always be looked up with man 2 open. Understanding what a file descriptor is, why files must be opened before use, possible failure cases, and error codes is the real essence.

The author recounts an embedded Linux project involving CAN‑bus diagnostics using SocketCAN. Although he initially knew none of the SocketCAN APIs, he first studied the communication principles of CAN, consulted the official documentation, wrote a demo to verify the logic, and then implemented the business code. By repeatedly applying the underlying concepts, he could quickly understand and use the APIs, demonstrating that memorizing APIs leads to rapid forgetting.

Programming creativity is not about inventing entirely new wheels; it is about combining existing tools in novel ways, much like building with blocks. Deep comprehension of fundamentals enables such combination.

What should a programmer actually remember?

Programming paradigms such as object‑oriented design and design patterns.

Common idioms like linked‑list manipulation and multithread synchronization, which become ingrained through repeated use.

Typical pitfalls—areas prone to bugs or performance issues—that are learned from experience.

Specific API signatures and syntax details need not be memorized; they can be looked up when needed and will naturally stick after frequent use.

When hiring, the author does not test candidates on how many APIs they can recite. Instead, he presents a real problem and observes how they analyze, research, code, and debug. Those who quickly grasp the problem essence and flexibly apply tools are the truly good programmers, whereas those who rely on memorization often struggle with new challenges.

Therefore, programming should be treated as a craft rather than an exam: understand the principles, write code often, and consult documentation when necessary, allowing the knowledge that once seemed hard to remember to gradually internalize.