Thirteen languages, one career.

When I tell people I've shipped production work in thirteen languages, the reaction is either "why" or "that doesn't count, most of them don't matter anymore." Both reactions are wrong. The languages still matter — not because I use Assembly every day, but because what each one taught me shows up in how I write GOGOGO LLC's multi-agent runtime today.

This is the honest list, the years that go with them, and the one thing each one made permanent in how I think.

The thirteen, in roughly chronological order

C — primary school, fascination

C was the first language that felt like a tool rather than a toy. Memory layout, pointer arithmetic, the difference between the stack and the heap. I still write multi-agent code with C-shaped intuitions about lifetime and ownership. When a Python script leaks memory through a closure I notice within a minute because C taught me to feel it.

C++ — high school, expansion

C++ taught me composition. Templates, polymorphism, RAII. It's also the language that taught me when not to use my full toolkit. Most of the C++ I'm proudest of looks like simpler C, with one or two abstractions in the spots that actually pay for themselves. That habit travelled — our runtime is full of decisions to not generalize.

C# — Turkish university lab, Windows era

C# was my Windows phase. WinForms, ASP.NET, Visual Studio's debugger. I learned how good tooling changes engineering culture. The static-analysis hints, the click-to-jump-to-definition, the structured exceptions — they all add up to less anxious code. I push the team to invest in tooling whenever a workflow has friction, and that instinct came from C#.

Python — uni then forever

Python is the language I use the most today. Multi-agent runtime, retrieval pipelines, evaluation harnesses, data ETL, scripts I write on Tuesdays that solve a problem and get thrown away on Wednesdays. Python's biggest gift was teaching me the shape of what's hard to type-check at runtime — which is exactly why I now write the runtime's critical paths with strict type contracts and pydantic schemas even though we don't have to.

Java — uni, server-side discipline

Java taught me what enterprise means. Verbose interfaces, dependency injection containers, the way a large team encodes its agreements into the language itself. I don't love Java but I respect what it does for teams of fifty. Some of our GoPeople backend interface decisions are Java-shaped: explicit boundaries, no surprises.

JavaScript / TypeScript — late 2010s, full-stack

JavaScript taught me to live with imperfect tools and ship anyway. TypeScript redeemed it. Most of the gogogollc.com and product UIs are TS now. The biggest TS gift: types as documentation that doesn't drift from the code. We use this aggressively across the multi-agent surface — agent contracts, tool schemas, message payloads — all typed end-to-end.

SQL — every year since

SQL isn't a language people brag about. It's the one I bet the company on. Every product's analytics layer is a SQL query I can read in fifteen seconds. SQL taught me that the data model is the product, in a way the application layer often isn't. We don't have a single ORM-only abstraction at GOGOGO; raw SQL still flows through the architecture in the places that matter most.

PHP — Turkcell BiP era, 2015

PHP was the messenger-bot era — AIML chatbot flows for BiP Messenger, Facebook Messenger, Telegram. I shipped fast, I shipped ugly, and the bots ran for years. PHP taught me to take deployment friction seriously. Anything I have to do twice to ship, I automate.

Swift — 2019, AR marketplace on Google Glass 2

Swift was my mobile chapter — AR marketplace shipped on Google Glass 2, then iOS apps. Swift's gift was opinionated language design — the Optional type, value vs reference semantics by default, the discipline of letting the compiler tell you what's possible vs not. We borrowed that into how we design agent state in the runtime today.

Kotlin — Android era

Kotlin was Android's escape valve from Java. Smart casts, null-safety, extension functions. Kotlin taught me that you can rescue a stagnant language with a careful redesign — which is what we did internally when we replaced our first 2024 runtime with the 2025 rewrite. Same idea: keep what works, fix what doesn't, don't break callers.

VB.NET — early-2010s freelance era

Yes, VB.NET. Some of the small-business clients I freelanced for in the early 2010s were on Windows + Office + Access stacks; I shipped real work in VB.NET. The lesson was hard: meet customers where they live, in the language their stack speaks. Most enterprise AI sales today come down to the same lesson. The pretty stack isn't the point; the customer's existing world is.

Assembly — uni, intermittent

Assembly was uni only. I won't write x86 again voluntarily. But the mental model — registers, instruction cycles, what actually happens under a high-level abstraction — that's permanent. When I look at a GPU inference cost graph for Goddo today, I'm thinking in something close to Assembly cycles.

MATLAB — engineering school, optimization

MATLAB was the optimization / signal-processing / control-theory phase. Not glamorous; I haven't opened it in years. But MATLAB is where I first wrote numerical loops over real data and thought about them as math. That habit is the entire reason I can read a transformer attention diagram without flinching.

What this means for the runtime

The GOGOGO multi-agent runtime — the thing all four of our products run on — has bits of each of these languages baked into its design philosophy:

• C-shaped lifetime intuitions in how we manage agent state and tear it down cleanly.
• C++ "don't over-generalize" in how we resist building agent abstractions until the third use case demands them.
• C# tooling discipline in how aggressively we invest in trace visualization and replay UI.
• Python's runtime introspection in how every agent step is reflected, traceable, replayable.
• Java boundary discipline in how product surfaces talk to the runtime — typed contracts, explicit handoffs.
• TypeScript end-to-end types in how the same agent contracts are typed from runtime through API through frontend.
• SQL-shaped data thinking in how we model the agent-event log as a queryable timeline.
• PHP ship-it pragmatism in how we let some agent paths exist as cron jobs before we promote them.
• Swift's opinionated state in how we model agent state as discriminated unions, not bags of fields.
• Kotlin's incremental rescue in how we replaced the v1 runtime in 2025 without breaking callers.
• VB.NET's customer-first in how we still ship Windows-friendly APIs for our enterprise customers.
• Assembly's cycle-counting in how we think about cost per agent run.
• MATLAB's math fluency in how we read the eval harnesses without flinching.

Why I won't drop the unfashionable ones

Most engineers in 2026 ship in three to five languages. The current sweet spot is Python + TypeScript + SQL + maybe Go or Rust. I get it. I do most of my own work there too. But dropping the older languages from the list of things I can read would be a mistake — because the legacy systems we integrate with at customer sites still run on them.

Last year we onboarded a customer whose ERP is still VB.NET. The integration took me one Sunday because I could read their code without translation. If I'd shed that language, the deal would have died waiting for a contractor.

“Programming languages are not fashion. Each one is a permanent way of seeing software that you do not unsee. The cost of keeping thirteen of them in your head is a few hours per year of refresher reading. The cost of losing one is a customer deal.”

What I'd tell a younger engineer

Pick the languages that match the work in front of you, not the work you wish existed. Ship something real in each. Then keep reading them after you stop writing them. The library of permanent intuitions you build is what makes you valuable in your forties, not which languages you wrote your first compiler in.

If you want to argue with any of this list, I'm easy to find. atakanozalan.com or ezagor if you prefer the handle.