LESSONS FOR MY PAST SELF

T L;DR Nobody is born a specialist in something but they become one by staying obsessed long enough to get good. The real power isn't in the programming itself, but in what it teaches you: how to see systems everywhere. Once you understand that reality is just nested systems all the way down—from your morning routine to the entire economy—you gain an almost unfair advantage. You stop playing other people's games. You stop competing. You start building.

I am someone who stumbled into programming through pure accident, and that accident changed the entire architecture of my life. If my cousin hadn't given me his old laptop when I was twelve, if I hadn't been curious enough to explore beyond just playing games, if I hadn't wondered how Minecraft mods actually worked—I genuinely don't know what trajectory my life would have taken.

This haunts me in the most beautiful way. Ray Bradbury wrote about how a butterfly stepping on a flower in the past could change the entire future. In chaos theory, we call this sensitive dependence on initial conditions—the butterfly effect. Small changes in starting points lead to dramatically different outcomes. My cousin's laptop was my butterfly.

I was a kid who loved games but had never thought about how they were made. The first time I held that laptop and could play something I'd only watched others play before, everything felt magical. But the real magic began when I started exploring the edges—wondering how the game worked, how it could be modified, how the digital world I was inhabiting actually functioned underneath its surface.

The first time I was using a computer and could play a game that I had only seen other people playing before. Everything was so magical that I think it was one of the best interactions I've ever had with a computer in my entire life, until I started exploring the edges of the game and visualizing how it was possible to modify the game and better understand how it really worked, and that's when it all started - programming mods for Minecraft. Not that I recommend this trajectory for beginners, it depends a lot on motivation. In my case, it seemed more rewarding than perhaps programming a moving image in Scratch, and I think that's the most important point - motivation. It's incredible to think that some of the best programmers I've ever met started very young and in ways not very different from this, whether programming mods in Minecraft, creating servers in Tibia, etc... And I think this gives an absurd advantage because being able to stay hooked for a sufficiently long period of time on something when you're young involuntarily makes you good at it.

If I could send a message back to that twelve-year-old boy holding his cousin's laptop for the first time, here's what I would tell him. Not the obvious things—not "buy Bitcoin" or "start earlier." The real lessons. The ones that took years to see clearly. The ones hidden beneath the surface.

Learn by doing

"The best way to learn anything is by putting energy into action, breaking free from inertia."

Real learning is cybernetic—it operates through feedback loops. You try something, observe the results, adjust your approach, and try again. Each iteration teaches you something that no amount of pure theory could convey. The system learns about itself through interaction with its environment.

Norbert Wiener, who coined the term "cybernetics," understood that control and communication in systems—whether biological, mechanical, or social—depend on feedback. When you learn by doing, you create a feedback loop between your actions and their consequences. You develop what cybernetics calls "requisite variety"—the range of responses necessary to handle the complexity of real-world situations.

Before AI, learning programming meant diving (at least for me) into what we now call "tutorial hell" the endless cycle of following step-by-step guides without ever building anything original. You'd have twenty browser tabs open: Stack Overflow for debugging, Wikipedia for concepts, documentation for syntax, random blogs for explanations. Each answer spawned three new questions. Each question opened three new tabs. You'd end up in an infinite domino effect of partial understanding.

The problem wasn't the information—it was the lack of context. Without a specific project to work on, everything remained abstract. You learned about variables without understanding why you needed them. You studied loops without having a genuine problem that required iteration to solve.

AI has put more leverage into this process, but the principle remains the same: learning happens fastest when you have skin in the game. When you're building something you care about, every concept becomes immediately relevant. The feedback loop tightens. The iteration cycle accelerates.

This principle extends far beyond code. Whether you're learning a musical instrument, a new language, cooking, martial arts, or starting startup, the pattern is identical: start doing, accept imperfection, iterate based on feedback.

Your first project will probably be rough. The second will be better. The third, even better. This isn't just practice—it's a cybernetic learning system where each iteration feeds intelligence into the next. You develop pattern recognition. You build intuition. You learn to navigate complexity without being overwhelmed by it.

Is cool how the true is condensed and traced by a lot of ways, in wich something that i learn with pain and is a must-read on the startup scene is the "Do Things that Don't Scale." from Paul Graham, He argues that the most successful companies often start by doing things manually, inefficiently, in ways that can't possibly work at scale. But this teaches them things about their users, their market, and their product that no amount of theoretical planning could reveal.

Thinking in systems

"Reality is just systems all the way down."

Programming taught me something profound about the nature of reality itself: everything is a system. Everything has inputs and outputs. Everything involves processing. Everything operates through feedback loops. Once you internalize this way of seeing, you gain what feels like X-ray vision for the world around you.

A system is any set of interconnected components that work together toward a common purpose. Your body is a system. Your family is a system. Your company is a system. The economy is a system. Your morning routine is a system. The way you make decisions is a system.

Each system has:

But here's the key insight that most people miss: the majority of real-world systems are absurdly inefficient. They're full of unnecessary manual processes, obvious bottlenecks, and infinite loops disguised as "that's how we've always done it."

Consider how a restaurant operates. Customers arrive (input), orders are taken and food is prepared (processing), meals are served (output), and customer satisfaction influences whether they return (feedback loop).

But look closer and you'll see dozens of subsystems: inventory management, staff scheduling, kitchen workflows, payment processing, reservation systems. Each has its own inputs, processing, and outputs. Each has potential failure points and optimization opportunities.

Most restaurants operate with systems designed decades ago, unchanged despite technological advances that could dramatically improve efficiency. Orders still get lost. Inventory management is manual. Staff scheduling is chaotic. Customer preferences aren't tracked or utilized.

Someone with systems thinking can walk into almost any restaurant and immediately see a dozen ways to improve operations. The same applies to almost every business, organization, and process you encounter.

When Marc Andreessen wrote "Why Software Is Eating the World," he wasn't just talking about tech companies replacing traditional businesses. He was identifying a deeper trend: software-enabled systems thinking was becoming applicable to every industry.

Software forces you to think systematically. You can't write functional code without understanding inputs, outputs, data flow, and logic. This mental framework, once developed, becomes a lens for seeing improvement opportunities everywhere.

The companies that thrive in the software-eaten world aren't necessarily tech companies—they're companies that apply software thinking to traditional problems. Amazon applied software thinking to retail. Netflix applied it to entertainment. Tesla applied it to automotive manufacturing.

Elon Musk's approach to problem-solving exemplifies systems thinking combined with first principles reasoning. When SpaceX wanted to reduce rocket costs, they didn't try to negotiate better prices with suppliers. They asked: what are rockets actually made of? What do those materials cost? What does physics actually require versus what does industry convention assume?

They broke the system down to its fundamental components, understood the true constraints versus the artificial ones, then rebuilt the system from scratch. The result: rockets that cost 90% less than traditional aerospace companies thought possible.

Competition is for losers

"The Orthogonal Path to Victory"

This is perhaps the most counterintuitive lesson, and the most important. Peter Thiel argues in "Zero to One" that competition is for losers—not because competing is inherently bad, but because it's often a sign that you're playing someone else's game instead of creating your own.

The most powerful moves in life are orthogonal to what everyone else is doing. An orthogonal move is one that goes in a completely different direction from the competitive field—not opposite, but at a right angle.

Steve Jobs taking a calligraphy class in college seemed completely irrelevant to computer science. But years later, it became the foundation for Apple's revolutionary approach to typography and design. While other computer companies competed on technical specifications, Apple competed on aesthetics and user experience—an orthogonal dimension that proved far more valuable.

AlphaGo's move 37 in its match against Lee Sedol exemplifies this concept perfectly. Professional Go players analyzed the game for hours and couldn't understand why AlphaGo made that particular move—it seemed to violate centuries of accumulated Go wisdom. But five moves later, its genius became apparent. It wasn't playing the same game as its human opponent. It was playing a deeper game with a longer time horizon.

The phrase "play your own game" isn't just motivational speaking—it's strategic advice. When you compete directly with others, you're constrained by the rules and metrics they've chosen. When you create your own game, you get to define what winning looks like.

Richard Feynman exemplified this throughout his career. While other physicists focused on advancing within traditional academic hierarchies, Feynman followed his curiosity wherever it led. He worked on everything from quantum mechanics to biology to computing, often approaching problems from angles that seemed naive to specialists but led to breakthrough insights.

He wasn't trying to be the best physicist in the traditional sense—he was trying to understand the universe in his own way. This orthogonal approach made him one of the most influential scientists of the 20th century.

The Danger of Comparison

Social comparison is one of the most destructive forces in human psychology. When you measure yourself against others, you're always playing catch-up to someone else's definition of success. You're optimizing for metrics that may be completely irrelevant to your actual goals and values.

Everyone has a different starting point, different advantages, different constraints, different values. Comparing yourself to others is like comparing the score of a basketball game to the score of a chess match—the metrics are incompatible because the games are different.

The only meaningful comparison is with your past self. Are you growing? Are you learning? Are you moving in a direction that aligns with your values and interests? These are the only questions that matter.

Übermensch

Nietzsche's concept of the Übermensch (often mistranslated as "superman") is relevant here. Nietzsche wasn't advocating for genetic superiority—he was describing someone who creates their own values instead of accepting the values imposed by society.

Most people live their entire lives trying to meet other people's expectations, pursue other people's definitions of success, play games with rules they never agreed to. The Übermensch creates their own meaning, their own goals, their own measures of success.

This is what it means to play your own game. Not rejecting all social norms out of nihilism, but thoughtfully choosing which games are worth playing and which rules are worth following.

Conclusion

If I could actually send this letter back to that twelve-year-old boy with the laptop, I'm not sure he would understand it all. But maybe that's the point. The most important lessons can only be learned through experience, not explanation.

What I hope he would understand is this: that laptop isn't just a tool for playing games or even for learning to code. It's a gateway to seeing the world differently. It's an invitation to understand that reality itself operates on principles that can be learned, systems that can be improved, games that can be redesigned.

The technical skills will come and go. Programming languages will evolve. Technologies will become obsolete. But the way of thinking—the systems lens, the learning by doing, the courage to play your own game—these become part of how you see everything.

That's the real gift my cousin gave me, though neither of us knew it at the time. Not access to a computer, but access to a way of thinking that would shape everything that came after.

The butterfly has already flapped its wings. The future has already been changed. This letter is just an attempt to understand how.