Summary
When the university exam is at the door, an 18-year-old is expected to make a decision that will shape the rest of their life. In this episode, as two “dinosaurs” who have spent two-plus decades in this industry, we went straight at that pressure. We opened with “What kind of code is this?” and drifted from career choice to math anxiety, from the essence of engineering to technical debt, all the way to the future of AI. The core takeaway is clear: your choice at eighteen is not a life sentence; you can always redraw the path — as long as you still feel that intellectual satisfaction from solving the problem itself.
Video
Topics
- “What kind of code is this?” — looking at a junior’s code
- Choosing the industry before the university exam, and its pressure
- Why is making a career decision at 18 so hard?
- From civil engineering to software: Alper’s path
- An aviation dream, mathematical engineering: Burak’s story
- Is changing direction possible after a “wrong” choice?
- The importance of finding a mentor and a guide
- Does software really require heavy math?
- Engineering = problem solving (the Lego-block metaphor)
- Bringing a real-world problem into the computer
- “How do we know the software we built is successful?”
- Technical debt and idiomatic code
- A brief history of C++: Stroustrup and the standard library
- MySQL’s years-long bug, Notepad++ and Axios vulnerabilities
- Agile vs Waterfall, microservices vs monoliths
- The impact of AI on the software industry and the future
Deep Dive
1. A Decision Made at 18 Isn’t a Life Sentence
The university exam lands during the period when the blood boils hardest and the world looks entirely different than it actually is. At that age, most of us think our parents know nothing — unaware of the maturity, years later, where we’ll admit “they were right all along.” But here’s the point: at 18 you simply don’t have enough data points to know what you’ll love for a lifetime.
Alper’s own story is the clearest proof. After five years as a civil engineer, he realized his true place was in software, pivoted, and devoted the last 20-plus years to code. Burak’s road wasn’t straight either; it began with a passion for aviation and ran through mathematical engineering. Their shared conclusion is the same: the ability to pivot isn’t a flaw but a feature — to put it in developer terms, “a feature, not a bug.”
As journalist Nevşin Mengü aptly put it, you shouldn’t feel obligated to do the same thing until you die because of a choice you made when you were barely an adult. The only real failure is staying stuck in a loop that doesn’t serve you. This is also where a mentor’s value shows: someone who has already walked the path saying “go this way” saves you all that trial and error.
2. “What Kind of Code Is This?” and the Essence of Engineering
The line that gives this episode its name is, really, the familiar thought every senior has while looking at a junior’s code. But there’s a trap here: contrary to popular belief, software isn’t about stacking lines on a black screen — it’s the art of correctly bringing a real-world problem into the digital realm.
Alper’s analogy from his civil background fits perfectly: a software developer works like an engineer building a dam to tame a wild river. The civil engineer tames the river with a physical dam; the software architect simulates that process in a digital environment so it becomes useful for others. The essence of the work is to simulate a piece of business logic as effectively as possible.
The two great traps live here too: “software blindness” and over-engineering. Building systems more complex than you need just to show off a technical skill pulls you away from solving the actual problem. As Alper puts it, the best code is the code that solves the biggest problem with the fewest lines.
3. Math Anxiety: Software Isn’t as Heavy as You Think
Many young people give up on a software dream because their math grades are low. Yet the math required in software is generally lower than in civil or aerospace engineering. In Alper’s example: there, area and volume calculations demanded heavy integral knowledge; in software, the processes are now built on modular architecture and abstraction.
Today’s software work isn’t about inventing everything from scratch; it’s about combining Lego blocks — ready-made libraries — within a strong logical framework. The industry has reached an industrial maturity; we don’t reinvent the wheel, we stand on the shoulders of yesterday’s solutions. The skill isn’t in manufacturing the plastic brick, but in the architecture of assembling those bricks to solve a human problem. Math is an advantage, but having an engineering mindset is far more critical than being able to solve complex integrals.
4. Every Plane Flies, but Not Every Software Works
What separates aviation from software is hidden in the success criterion. In aircraft, the fault tolerance is zero; it either flies or falls. Software is far more dynamic.
“Every designed plane has flown, but not every designed software has been successful.”
Traditional engineering leans on physical guarantees: gravity doesn’t change, a material’s breaking point is known. Software has no such physical laws; it’s ephemeral. That’s why “it runs” doesn’t mean success — the real measure is whether the product is adopted by users and is maintainable. A technically flawless application that solves no one’s problem is a failure.
This is exactly why we moved from Waterfall to Agile: if we don’t show progress in small increments, we risk building the wrong thing from the start. A “technically successful” project is one written in idiomatic code — code that follows the language’s standards, so that someone else can maintain it three years from now.
5. Technical Debt and the Perfectionism Trap
Behind an application that looks great from the outside, technical debt of up to 80% may have piled up: poor-quality code, maintenance pain, hidden vulnerabilities. No product in software is flawless, and these flaws can cause serious reputational loss. Bugs can go unnoticed for years even in a giant like MySQL; unexpected vulnerabilities can surface in tools used by millions, like Notepad++ or Axios.
The brief history of C++ that Burak touched on is another face of this maturity: the standard library that Bjarne Stroustrup brought to the language became, over decades, the industry’s shared memory. Software is the skill of managing these flaws and keeping the system continuously up to date (maintenance). Instead of wrestling with a project that never ends in the name of perfectionism, you focus on writing sustainable, extensible code. Knowing that even 20-year-old systems can still throw bugs should, in fact, be reassuring.
6. The Developer in the AI Era: From Syntax to Directing
The fact that nearly every application got a “chat” interface after 2022 is proof of how fast the industry changes. While AI may take over the “grunt work” — routine coding — the need for human intelligence doesn’t end. There’s a point that gets overlooked here: energy efficiency. The human brain can solve complex, creative problems with far less energy than a high-compute model. For now, we remain the more efficient “processor.”
AI isn’t killing the profession, it’s shifting the role: we’re moving from the syntax level to the director level. The battle is no longer about stacking lines; it’s about managing complex architectures and reading the microservices–monolith tension correctly. What matters is asking AI the right questions and having the software notion to steer it. Tools change; the ability to define problems and build strategy is what lasts.
7. The Curiosity and Passion Filter
A lesson stuck with us from the ’90s, from an era without internet, taught by a teacher named “Samet Hoca.” He taught C/C++ and had the kind of wisdom that only comes from years of staring at a terminal. When a student said “I want to be a programmer,” he didn’t ask about their technical skills — he asked a sustainability question:
“Will you be able to do this job with love for 10 years, 20 years? Have you thought about this?”
Most people enter this field for the salary but hit the speed barriers quickly. You don’t go from 0 to 100 overnight; the grueling climb from junior to senior demands deep curiosity. In a field where the tools change every three years, your only defense against burnout is curiosity and excitement. Even the most experienced people “claw” at a single bug for days; but the intellectual joy taken from that clawing is the only thing that makes the work sustainable.
So what about you: If the tools you use today disappeared tomorrow, would you still feel that satisfaction from solving the problem itself? If your answer is “yes,” you’re ready for the long haul.
Infographic
