The Non-Linear Path and the Feedback Loop You Have to Build Yourself
What self-teaching actually costs when there's no one to tell you if you're doing it right, and why the background you think was wrong might be exactly what you needed.
There’s a moment most people who switch into tech share, even if the details are different.
You’re sitting in a room—a lecture hall, an office, your parents’ living room—doing something that looks fine from the outside. You’re passing the tests. You’re showing up. But something underneath is quietly off, and you’ve been ignoring it long enough that you’ve stopped noticing it’s there.
That was me in my second year of civil engineering.
The mainstream path and where it leads
I chose civil engineering the way a lot of people in my generation chose their major: I followed the room. The conventional wisdom at the time was that engineers and doctors earned serious money. My parents believed it. My friends believed it. I didn’t think hard enough to question it.
So I sat the entrance exam at the most prestigious university in my country, passed, and enrolled in civil engineering. I told myself this was going right.
Halfway through, I understood that it wasn’t.
Not because the coursework was too hard. Civil engineering is rigorous, and the first two years are almost entirely foundation math: linear algebra, calculus, physics, structural mechanics. I worked through it. But there’s a difference between doing work and doing your work. I was putting in the effort. I wasn’t building anything I cared about.
What I was missing and what I couldn’t name for a long time was that I had always loved technology. I’d loved it since high school. I just hadn’t counted it when making the decision that mattered most. I’d let other people’s definitions of a good future override the thing I actually wanted to spend my time on.
That’s the trap the mainstream path sets: it replaces your judgment with consensus. And consensus doesn’t know what you’re for.
The part no one talks about
The moment I decided to change wasn’t dramatic. I went on a trip just to get out of my head, to stop running on autopilot for a few days. And somewhere in that space, things became clear in the way they only do when you stop trying to force them. I came back knowing what I wanted to do.
What came next was harder.
I had to tell my parents. They were supporting me financially. They had made sacrifices to get me into that university. The conversation was not easy. There was real disagreement, real pressure to stay the course. I don’t say this to make the story dramatic, I say it because this is the part that gets edited out of most “I switched careers” posts, and it shouldn’t be. Changing direction costs something. Pretending it doesn’t isn’t honest.
I eventually convinced them. I don’t remember exactly what I said. I think mostly I just kept showing that I had thought it through…that I wasn’t running away from something, but toward something I had actually examined.
Learning without a map
I started teaching myself technology in a way that, looking back, was less organized than I wanted to believe at the time.
English wasn’t my first language. Before I could learn to code, I needed to be able to actually read the material and the material was almost entirely in English. So I started buying books. Random ones. Self-help, novels, anything. I read with a dictionary next to me, slowly, until it became less slow. That was its own kind of self-teaching: not structured, not validated by anyone, just accumulated exposure until something clicked.
Then came the tech itself. I started with data science because I believed and still believe that data is a foundational currency in this era. It was a deliberate bet. But learning it in my city in 2019, without a bootcamp, without senior engineers to ask, without a community of people doing the same thing, was its own specific kind of hard.
The thing nobody tells you about self-teaching is that the content is not actually the hard part. YouTube, documentation, Stack Overflow; the content exists. What you’re missing when you teach yourself alone is the feedback loop. You build something. You don’t know if it’s good. You read the documentation. You don’t know if you understood it correctly. You follow a tutorial to the end. You have no way to tell whether you’ve actually learned anything or just executed instructions.
In a classroom, a professor tells you when you’re wrong. In a company, a senior engineer reviews your code. When you’re alone, you have to build those feedback loops yourself. You have to seek out things that can tell you whether you understand: build a project with actual constraints, not a tutorial project. Write code that has to work under a condition you didn’t design for. Try to explain a concept to someone else and notice where you can’t.
The self-teaching itself isn’t the obstacle. Building the system to validate it is what most people don’t talk about.
What the “wrong” major left behind
Here’s the thing I didn’t understand until years later: none of it was wasted.
Civil engineering taught me how to reason about systems under constraint. Load path analysis, redundancy design, fault isolation (the principle that a well-designed structure doesn’t fail all at once), that you build in independent paths so one failure doesn’t cascade into total collapse. I learned this in the context of buildings and bridges. But the mental model transferred.
The first time I heard “cascading failures” in a system design conversation, I already understood what it meant. Not because I’d read a distributed systems paper, but because I’d spent semesters thinking about what happens when load redistributes after a structural failure. The vocabulary was different. The underlying pattern was the same.
This is what I’d call fragment knowledge. Not every piece of what you learn has an obvious immediate use. Some of it sits dormant. But the dots connect…sometimes months later, sometimes years, in ways you couldn’t have predicted when you acquired them. The linear algebra I studied in my first two years of civil engineering is now how I think about transformations in machine learning. The structural reasoning is now how I think about infrastructure design. The things that looked like detours were laying foundations I didn’t know I needed.
If you’re coming from a non-CS background, for example biology, economics, history, anything, don’t assume what you learned is irrelevant. Assume you don’t yet know how it’s relevant. That’s a different posture, and it keeps you from throwing away something you’ll need later.
On AI, and what it can’t replace
There’s something I want to say clearly, because I see a lot of fear about it: AI is not going to make the path into this field pointless.
Here’s what I actually observe. AI tools are genuinely good at executing clearly-defined tasks quickly. They can generate code, explain concepts, debug known patterns, produce boilerplate at speed. That’s real, and it’s useful, and it will continue to improve.
What they can’t do and what they aren’t doing yet is accumulate the organizational scar tissue that makes an engineer actually effective. The ability to sense that a design is going to cause problems in production, not because you can prove it formally, but because you’ve seen that shape of problem before. The judgment to know when to push back on a requirement because you understand how it will interact with systems the requester can’t see. The instinct to ask the right question in a meeting before the wrong decision gets made.
These things come from experience. From having worked in organizations where the same class of mistake keeps appearing under different names. From having shipped something that seemed correct and watched it break in ways the specification never anticipated.
AI helps you go fast on the things it can model. The things it can’t model such as the messy, contextual, judgment-heavy parts of engineering still belong to humans. And those are, increasingly, the parts that matter most.
The useful frame isn’t “will AI replace engineers”, it’s “what does a good engineer do that AI amplifies rather than substitutes?” The answer involves systems thinking, organizational context, the ability to recognize subtle patterns before they become failures. All of which you build through experience. All of which your non-linear path is, right now, giving you.
The path you’re on is probably more useful than it looks
If you’re reading this uncertain about whether your current path is leading somewhere, I don’t have a way to promise you that it is. That depends on what you do with it.
But I can say this: the most useful things I know now came from places I didn’t expect. The language barrier became a skill. The wrong major became a way of thinking. The isolated self-teaching became a discipline for building feedback loops. None of it felt strategic at the time. It just felt like trying to get somewhere.
You don’t have to start in the right place. You don’t have to have the right background. You don’t have to already know where you’re going.
You have to start paying attention to what you’re actually building and be honest about when what you’re building doesn’t match what you care about.
That’s the only part I can’t do for you.
— Kimsang