Most developers never think about memory. Not really. You declare a variable, use it and trust that everything gets cleaned up. The language handles it. The runtime handles it. It just works.

Then you write C++ and that abstraction evaporates.

In C++, memory is your problem. You allocate it, you use it and you are responsible for giving it back. Forget to, and you have a leak. Free it twice, and you have undefined behaviour. Access it after freeing it, and you have a bug that might not surface for hours, in a completely different part of the program, under a specific set of conditions you can’t reliably reproduce.

This sounds like a nightmare. In some ways it is. But it teaches you something that no amount of Python or TypeScript ever will: that memory is a finite, physical resource that your program is borrowing. Every object has a lifetime. Every allocation has a cost. The stack is fast and automatically managed; the heap is flexible and manually managed. These are not abstract concepts — they are the reality your program runs on, regardless of whether your language hides them from you.

Understanding this changes how you write code in any language. You start thinking about object lifetimes in Python, even though the garbage collector handles them. You become suspicious of large allocations in hot paths and you understand why passing by reference is sometimes faster than passing by value. You stop being surprised when a memory-hungry Python process slows to a crawl.

The lesson isn’t that you should write everything in C++. It’s that understanding what your language is doing on your behalf makes you a better programmer in that language: the abstraction is useful, but knowing what’s underneath it is more useful still.