# Ali Gündoğdu , full content

> Full text of every published post, for language models and readers who want the whole thing in one place. English first, then Turkish.

# Writing (English)

## Working Hard Does Not Get It Done: The Open Loops in Your Head
URL: https://aligundogdu.com/open-loops-in-your-head
An unfinished task sits in your head like an open tab. Even when you step away, it keeps running in the background. Why working long is not the same as getting things done, and whether you really have to finish a task before you can put it down.

## A Perfect Memory, Right Up Until the Bill Is Paid

The way the story goes, it starts in a cafe.

The psychologist [Kurt Lewin](https://en.wikipedia.org/wiki/Kurt_Lewin) and his students were watching a large table place a long, complicated order. The waiter wrote nothing down. Dozens of items, who wanted what, which coffee took milk and which was black, all of it held perfectly in his head, all of it delivered without a single mistake. The meal ends, the bill is settled, everyone is about to leave. One of the students, half as a prank, calls the waiter back and asks him what had just been on the table. The waiter stares back, blank. That huge list, at his fingertips only minutes earlier, is gone.

One of the young researchers at that table was [Bluma Zeigarnik](https://en.wikipedia.org/wiki/Bluma_Zeigarnik). She read that blank stare not as a failure but as a clue. Why does the waiter remember everything while the tab is open, and forget it the moment it is paid? In 1927 she turned that hunch into an experiment. She gave people close to twenty small tasks. Some she let them finish, others she cut off halfway. Then she asked everyone which tasks they had worked on. The result was clear. People remembered the interrupted tasks about twice as well as the ones they had completed.

Today we call this the [Zeigarnik effect](https://en.wikipedia.org/wiki/Zeigarnik_effect). An unfinished task stays open in the mind like a bracket that never closes. It carries a small but stubborn tension, and that tension keeps working in a corner of your head until the task is done. The waiter's secret was not a good memory. It was that the open tab held him. When the tab closed, the bracket closed with it, and his mind let go.

## This Post Is Not Really About Waiters

It is not about memory experiments either. It is about why you come home in the evening exhausted, on a day when you did not really finish anything you could point to.

We all carry an equation in our heads, often without noticing it: working hard equals getting a lot done. The longer the hours at the desk, the more productive we are counted, and the more productive we count ourselves. But the equation fails even where work is easiest to measure. The economist [John Pencavel](https://en.wikipedia.org/wiki/John_Pencavel) studied factory data and found that once weekly hours pass a certain point, output per hour drops fast. Past that line the extra hours add almost nothing to what gets produced, and with the mistakes that come from fatigue, they start to subtract. Working more is, most of the time, not making more.

**Working hard usually does not get the job done. It just occupies more of your mind.**

To see why, you have to rethink where the tiredness actually comes from. Because on most days, what drains us is not the work we did.

## The Mind Is a Terrible Warehouse

Our working memory is embarrassingly small. The psychologist [George Miller](https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two) described the limit years ago with a famous phrase, seven plus or minus two, and later research pulled the number lower still. What we can hold alive in the mind at once is barely a handful. Everything else hangs somewhere, waiting for us to come back to it.

This is exactly where Zeigarnik's tension kicks in. Every unfinished task sits in the mind like an open tab, quietly burning energy in the background. One is harmless. But with fifteen tabs open at once, the mind turns into a low hum even if you have not touched any of them yet. When you move from one task to another, part of the last one comes with you. The researcher Sophie Leroy calls this attention residue. You are at the start of a new task, but a corner of your head is still stuck on the one before it. All day long, without ever fully doing a single task, you carry the residue of ten of them at once.

The real source of the tiredness is usually this: not the work you did, but the work you did not do and cannot forget. That unexplained weight that lands in the late afternoon, the low anxiety underneath it, is often the same thing. Nothing is in danger. Your mind is just worn out from holding dozens of unclosed brackets open at the same time.

## So Where Do All These Tabs Pile Up

Every task you do not write down somewhere picks your mind as the only place to live.

Working without a plan, moving forward without notes, sounds free and fluid. In practice it means carrying the whole inventory inside your head. The mind is a terrible warehouse for this. It leaks constantly, it pokes you at the worst moment with "you were supposed to do that too," and when you lie down at night it starts reading the entire list back to you from the top. The cost of having no plan is usually not the tasks that go undone. It is that inner voice that never goes quiet until they are.

Here a nice finding from psychology changes things. The researchers E. J. Masicampo and Roy Baumeister showed that you do not have to finish a task to release Zeigarnik's tension. Making a concrete plan for an unfinished task, a simple decision about when, where, and how you will do it, was enough to close that open bracket in the mind. The task was still not done, but the moment the mind understood it had been handed to a place it could trust, it loosened its grip. In the same way, there are studies showing that people who write down tomorrow's to do list before bed fall asleep faster. The list is what brings sleep, because the mind relaxes once it can pass the watch to paper.

**What empties the mind is not finishing the task. It is finding the task a place it can trust.**

That is exactly what the waiter was doing. He remembered the order because he had tied it to something, to the open tab. When the tab closed, he dropped the load. Our problem is that none of the tabs in our heads ever really close.

## Two Places I Have to Be Honest

If I leave what I have written so far as it is, it becomes misleading.

First: that tension is not all bad. The grip Zeigarnik saw is the same thing that pulls you back to a half finished task and gets it done. A mind where nothing tugs at you, fully emptied, does not get anywhere either. The goal is not to kill the tension but to hold it somewhere outside your head instead of inside it. What makes the difference is not that the task disappears, but that you get to stop carrying it.

Second, and this one is sneakier: the plan itself can turn into an escape. You can make the to do list so pretty, so long, that making the list quietly takes the place of the work. A flawless weekly plan drawn in three colors of ink can leave you at the end of the day with that "I worked so hard" feeling, without a single real thing getting done. A plan exists to make the work visible. The moment it stands in for the work, it has lost the plot. As much as this post argues for taking notes, it argues just as hard against turning the note into a ritual.

## A Deliberately Round Answer to "What Should I Do"

I am not going to put a clean prescription here, because there isn't one. Someone who journals in the morning and someone who leaves voice notes at night do not settle down with the same method. Some people do better with one tidy system, others with paper scattered across the desk. If you are looking for a method that works for everyone, the thing you are looking for does not exist. If it did, we would all have found it by now.

The only general truth worth offering is not the method but the logic under it: dump the open tasks in your head into a place you trust, give each one a "next step" instead of a "finish," and leave the rest to your own rhythm. To get a task off your mind, you do not have to complete it. You just have to know where and when you will come back to it.

At most, I can leave you a few questions to ask yourself now and then. Am I actually tired right now, or am I just carrying a lot of unclosed tasks at once? Do I really need to do this task, or am I only afraid of forgetting it? And at the end of the day: not what did I finish today, but how many open brackets did I manage to close into a safe place? No one but you can answer these, because only you know what your own mind needs to let go of in order to breathe.

## Settling the Tab

The waiter in the cafe forgot the list the moment it was paid. What made him forgetful was actually the sign of a healthy mind: being able to let go of an account once it closes. Our problem is not a bad memory. It is the opposite. None of our accounts ever really close. Everything stays forever on an open tab.

But the mind does not always wait for a task to be finished before it counts it "closed." It lets go the moment it knows where and when it will come back. You do not have to finish that huge list that wears you out at the end of the day. You only have to take each item off your mind and write it down somewhere you trust, the way the waiter let go of a settled bill.

Working hard is not a virtue, and it is not a measure. The real question is not how many hours you sat, but how many brackets you managed to close. And the tiredness, most of the time, does not come from the work. It comes from not being able to put it down.

---

## A 'Computer' Used to Be a Person
URL: https://aligundogdu.com/computer-used-to-be-a-person
Prompt engineer, context engineer, loop engineer... Titles go stale in a year. That is not a junk pile, it is a dial showing how fast the border is moving. Read through Moravec, Lindy, and the invisible ledger: what should you actually invest in?

1962. [John Glenn](https://en.wikipedia.org/wiki/John_Glenn) is sitting inside the [Friendship 7](https://en.wikipedia.org/wiki/Mercury-Atlas_6) capsule, waiting to become the first American to orbit the Earth. Every number of the flight, every orbital angle, has been worked out by the most powerful machine of its day: the new IBM 7090. But right before launch, Glenn asks for something strange. "Get the girl to check the numbers," he says. "If she says they're good, I'm ready to go."

That "girl" was [Katherine Johnson](https://en.wikipedia.org/wiki/Katherine_Johnson). At NASA she was a "computer", meaning a person who computes. Because in those years "computer" was not a machine, it was a job. People sitting at long desks, working out orbits by hand, on paper, most of them women. Glenn did not trust the million-dollar machine. He trusted the judgment of a person who could verify the machine's output with a pencil.

This scene is real, and it became a good film too: the 2016 movie <a href="https://www.imdb.com/title/tt4846340/" rel="nofollow noopener noreferrer" target="_blank">Hidden Figures</a>. It tells the story of Katherine Johnson and the computers who worked beside her. If you haven't seen it, consider it a debt this post owes you, add it to your list.

Within a few years that job disappeared. A "computer" was no longer a person sitting at the desk, it was a box sitting on top of it. But notice what was lost: the skill was not the point. What Katherine Johnson really did was know what to compute, sense whether a result made sense, smell when something was wrong. That skill did not vanish. It moved up: first into programming, then into engineering.

## A title is a border line

"Computer" was a title, and it had one job: to describe where the border between human and machine happened to be at that moment. As the border moved, the title changed with it. This is not a new story. Today the same film is just running on fast-forward.

To understand the speed, you have to lay two old ideas side by side.

The first is **[Moravec's paradox](https://en.wikipedia.org/wiki/Moravec%27s_paradox)**. In 1988, the robotics researcher Hans Moravec made an odd observation: it was easy to make a machine play chess, prove theorems, pass an IQ test. But making it do what a one-year-old does, seeing and understanding a room, walking, grasping the sentence "hand me that cup", was nearly impossible. It sounds backwards, but the logic is this. The skills we think are hardest (abstract reasoning, math) are the newest in evolutionary terms, a few thousand years old. The ones we think are easiest (seeing, sensing, keeping your balance) are millions of years old. And precisely because they are old, they run so deep that they are hard to copy.

The second is the **[Lindy effect](https://en.wikipedia.org/wiki/Lindy_effect)**. How long something is likely to survive in the future is proportional to how long it has already survived. An idea that has stood for forty years will probably last another forty; a forty-day trend is forgotten forty days later. The old is durable, the new is fragile.

Stack these two and something clear falls out: **Moravec's paradox is really the Lindy effect for skills.** The newer a skill is, and the more it is "named and describable step by step", the more easily it gets automated and the more fragile it is. The older, more tacit, and harder to describe it is, the more durable. AI is moving right along this slope: it takes the most describable, most surface-level work first.

## The jobs of the last three years

Now look at the recent titles. **Prompt engineering**: writing the right words to get a good output from the model. Then **context engineering**: giving the model the right context, the right data. Then **loop engineering**: instead of writing commands one by one, designing the loop that drives an agent toward a goal. There is roughly a year between each of them.

These are the very top of the Moravec slope: the newest, most describable layer. Expecting a job as procedural as "say the right magic word" to turn into a long-lived title is not realistic. And sure enough, it doesn't. Loop engineering had barely been named before the tools started adding commands like "/goal" and burying that loop inside themselves. The skeptics who say "this is just automation with a new name" are telling a truth too.

## But these are not junk

This is exactly where most people jump to the wrong conclusion: "If they go stale in a year, then they're empty, I won't bother."

They're not. The fact that these titles come and go this fast is not noise, it is a **measurement**. Each one is a milestone marking where the border between human and machine stood at that moment. Lined up together, they tell you one thing: how fast the border is moving. If we went from prompt to loop in a year, that is like the speedometer reading 200. Sneering at the gauge does not make the speed go away.

But there is a trap, and an old law of economics describes it exactly. **[Goodhart's law](https://en.wikipedia.org/wiki/Goodhart%27s_law)**: the moment a measure becomes a target, it stops being a good measure. If you read the title as a signal, it shows you the speed of the border; if you make it a target and say "I'm going to be a loop engineer", that title no longer measures reality, it measures the thing you are chasing. The only way to keep a signal a signal is to hold it at **arm's length**: close enough to notice the pattern, far enough not to game it.

The same principle works at a small scale too. The tokens you spend working with a model make your mental labor visible for the first time, labor that used to leave no trace anywhere, like a personal thermometer. But a thermometer shows the heat, not whether the meal is cooked. The moment you make your token count, or your title, into a target, both of them break. Tokens on the inside, titles on the outside: both are gauges to read, not medals to chase.

## Two traps

There are two traps here, and both are faces of the same mistake.

The first is **chasing**: tying your identity to every new title, changing your profile headline every three months, mistaking knowing the latest term for mastery. This is staring at the gauge so closely that you forget to drive the car.

The second is **refusing**, and this is the sneaky one: "These keep changing, so I won't invest in any of them, I won't learn them." It sounds mature, patient, even Lindy-minded. It isn't. This is not durability, it is hidden slowness. The border is moving without waiting for your permission. While you say "I don't take these seriously", the people who are learning to read the border are passing you. And the stance isn't sustainable either: once you build the habit of "not understanding the new", you start a little further behind on every new wave.

## The prescription: slow at the roots, fast at the leaves

So what is the right move? Moravec and Lindy hand you the same prescription.

At the roots, invest in the old and the hard to describe. Judgment. Knowing what matters. Sensing that a result "smells wrong", just like Katherine Johnson. Synthesis, taste, reading people. None of these has a title, none has a certificate. And more than that, they don't even show up in that token ledger: a counter can now catch your analysis, your experiments, your bug hunts, but no counter can catch the sentence you build while walking, the hunch that "something is off here", the decision about which work you should never do at all. The most valuable part is exactly the part [that shows up on no dashboard](/en/the-software-you-depend-on-has-an-owner). And the more invisible something is, the harder it is for the machine to copy; that is what Moravec said forty years ago. This is your durable capital.

At the leaves, be fast. Learn every new title but don't marry it. Get to know prompt, context, loop, and whatever comes next like weekend projects, understand what they are, note what they tell you about the border, then let them go. Roots grow slowly, leaves change every season. The healthy tree is the one that does both.

## And stranger ones are coming

Be sure of this: today's titles are not the last strange ones. Over the next few years we will hear names that sound ridiculous today. Some will live three months, some will be the seed of a new profession. You cannot know in advance which is which. But you can know this: if you become someone who can read them without clinging to any of them, you'll be ready whatever name arrives.

Katherine Johnson started out as a "computer". That job died, but she didn't. Because her real work was never computing; it was knowing whether the numbers were right. That skill, no matter which box you put on the desk, is still someone's job.

> The Turkish version of this piece is [here](/tr/loop-engineering-lindy).

---

## For a Production Desktop Product, Wails Is Still the Sanest Choice. Here Is What the Tables Don't Tell You.
URL: https://aligundogdu.com/shipping-a-wails-app
I built Seodisias with Wails; it runs in production on three operating systems, and I would pick Wails again without hesitation. This is the case for that confidence: using the bridge right, the signing chain, webview quirks, and building for three platforms from one Mac.

## The Comparison Table Was the Easy Part

I wrote about [why I picked Wails](/building-a-desktop-app-with-wails) in an earlier post. Electron felt heavy, Tauri's Rust side wore me down, and Wails hit the balance I wanted with Go's simplicity. That post ends with a table: bundle size 20 MB, learning curve moderate, build process smooth. All of it true. Looking back now, that table was the easiest part of the whole job.

Because choosing a tool is one thing, and shipping a real product with it is another. I built Seodisias, my SEO crawler, with Wails, and the process taught me this: every "Electron vs Tauri vs Wails" article on the internet describes the first five minutes. `wails init`, `wails dev`, a window on the screen. Those five minutes are magical, yes. But getting that window to open cleanly on someone else's computer took six months. This post is my notes from those six months. The part the table never shows.

Let me say this upfront: this is not a warning-off post, quite the opposite. I shipped with Wails, my product runs on three operating systems every day, and if I started over today I would pick Wails again. For anyone building a desktop product for production, I recommend it with a clear conscience. What follows is not a list of regrets; it is the set of subtleties nobody told me on the way in, the kind that turn into craft once you learn them.

## The Bridge Is Clean in the Demo and Collapses Under Load

Wails' most marketed feature is the bridge between Go and the frontend. You write a function in Go and call it from JavaScript as if it were local. In a demo it is enchanting. Write `GetUser()`, call it from the UI, get a user back. Five lines.

The problem is that real applications do not call `GetUser`. Seodisias is a crawler; a single scan produces thousands of rows. And I did the rookie thing: finish the crawl in Go, return the entire result to the UI in one shot. That is what the bridge is for, right?

It is not. Pushing thousands of rows through the bridge means serializing all of it to JSON, carrying it into the webview, and parsing it again on the other side. With a few hundred rows you never notice. With a few thousand, the app freezes, and your user starts reaching for the close button wondering if it crashed.

The lesson is simple but it took time to see: **the bridge is a control channel, not a data pipeline.** Use it to say "start this job", "cancel that", "how far along are we"; do not haul truckloads of data through it. The fix had two halves. On the Go side, the crawl no longer accumulates results and returns them wholesale; it emits events with `runtime.EventsEmit` as it progresses, and the frontend consumes the data piece by piece. On the screen, instead of rendering everything at once, there is virtual scrolling; only the visible rows are rendered while the rest wait in memory.

## Everything Is Async, and You Have to Make Peace with It

The second subtlety in the bridge is sneakier. A bound Go function may look synchronous from JavaScript, but it actually returns a Promise. You have to `await` it, or what you are holding is not data, it is a promise of data.

That sounds small, but it shapes the architecture from the start. Think of a long job, say a thirty-second crawl. If you `await` it and wait, the UI can say nothing for that entire time. If you want a progress bar, a "342 pages crawled" counter, you have to separate the call that starts the job from the channel that reports progress. Here too I ended up with events: the starting function returns immediately, and progress arrives on its own event stream.

And then there is cancellation, which no getting-started guide covers. The user starts a crawl and gives up halfway. That goroutine is still running, still firing requests. How do you stop it? The answer is native Go: `context.Context`. You thread the context you get at startup into the crawl, the cancel button cancels that context, and the running goroutine sees it and shuts down cleanly. Wails hands you this context, but what you do with it is up to you. Nobody tells you; you learn it the hard way.

## "Wails Doesn't Bundle Chrome" Is Not Purely Good News

Where does Electron's 150 MB come from? It embeds an entire Chromium. Wails does not; it uses the operating system's own webview. That is the source of the size advantage, and everyone writes it up as a win.

The part nobody writes: it means your app runs on a **different browser on every operating system**. WebView2 on Windows, which is the Edge engine. WebKit on macOS, Safari's engine. WebKitGTK on Linux. You assume all three render the same HTML the same way; they do not.

I got bitten in the place I least expected: fonts. A layout that looked spotless on macOS aligned a touch differently on Windows; a line shifted here, an icon crowded its label there. Date pickers, scroll behavior, support for certain CSS features all vary from webview to webview. I thought the sentence "it worked on my machine but wouldn't open on Windows" died with Electron. It did not die; it changed clothes. It no longer lives in the backend, it lives in CSS and webview differences.

The rule I took away: never develop on one OS and assume the rest will follow. I developed on a Mac, but I stopped calling any screen finished before testing it on Windows. This is Wails' hidden tax. Some of what you save in bundle size, you pay back in testing.

## The Truly Deadly Valley: Signing

Everything so far is a code problem. Code problems get solved; they are even fun. But the gap between a prototype and a shippable product has a valley in it, and the part that wore me down the most was not code.

I compiled the app, it worked, lovely. I told a friend, "download this and try it." macOS refused to open it: "damaged, would you like to move it to the Trash?" It was not damaged. It was unsigned. Gatekeeper treats every unsigned, un-notarized app this way. For the user to open it anyway, they have to type terminal commands or wrestle with settings. Nobody does that. I would not.

The steps of this valley are easy to list and hard to walk. On macOS: an Apple Developer account, a Developer ID certificate, signing the app, then submitting it to Apple's servers for notarization. Windows is its own story: skip signing and SmartScreen shows your user a red screen that says "unknown publisher, this app might harm your computer." Getting past that takes a code signing certificate, with its cost and its setup pain. On top of that, on Windows you get the separate chore of making sure the WebView2 runtime exists on the user's machine.

None of this is Wails' fault; it is operating system security policy. But Wails articles never mention it. They say "20 MB build, one command" and never write that making that 20 MB file openable on a user's machine will cost you weeks. Honestly: of Seodisias' six months, maybe two went into code, and the rest went into this kind of shippability work. Where the code ends is not where the product ends.

## The Build Is One Command, and I Ship Three Platforms from One Mac

`wails build` really is one command. And here Wails deserves real credit: today I produce all three platform builds from a single machine, my Mac. The Windows build comes straight off the Mac via cross-compilation; Go's cross-compile comfort largely survives in Wails. Linux is fussier, because system dependencies like WebKitGTK enter the picture; I solved that with Docker: a container that builds inside a Linux image, also one command. So there is no "maintain a machine park per platform" tax; one Mac and one Docker cover three operating systems.

What actually eats time is not the build but the signing chain I described above, which runs separately per platform. My concrete advice from this: script your release ritual at the first opportunity. I wired build, packaging, and signing into a single flow; "let me cut a release" went from an afternoon project to a ten-minute ritual. Every release you do by hand cools you off from shipping the next one; a scripted release makes you want to ship.

## The Go Side: Not Wails, Discipline

There is one more area where Wails is not directly at fault but the desktop makes you bleed: concurrency. A crawler manages hundreds of requests in parallel. Go's goroutine model is tailor-made for this, but tailor-made still needs measurements. On my first attempt I let five hundred goroutines loose at once; the target server rate-limited us, connections dropped, half-finished work piled up in memory.

The fix is not desktop-specific, but the desktop makes it visible: a semaphore that caps concurrent work, a worker pool, and a clean stop for everything in flight when the app closes. On a server, a goroutine leak can live unnoticed for months; on a desktop, if the window closes and the fans keep spinning, that is an instant complaint. The desktop forces discipline on you, because the user's machine is not a server you monitor.

## Would I Pick Wails Again

After all this shop talk, the question: starting over, would I still choose Wails? Yes. Without hesitation. Let me go a step further: if I were starting a production desktop product today, Wails would still be the sanest choice on the table.

Because most of the pain I described is not Wails-specific; it is the nature of shipping a desktop app. Signing, notarization, webview differences, distribution; I would have lived through all of it with Electron or Tauri too, and most of it more heavily. What Wails gave me was a backend written in Go's plain style, real progress without stalling on Rust's learning curve, and in the end an almost comically small application to hand to users: today's production build of Seodisias is 8 MB. I once put 20 MB in my comparison table; reality came in tidier than my own estimate. To anyone arriving from the Electron world, that number looks like a typo. It is not. The promise held, and the product keeps proving it in production every day.

But I read those shiny comparison tables differently now. The bundle-size row turned out even better than I claimed, today's build is 8 MB; and it is still the least important row in the table. The rows that matter are not in the table: pass control through the bridge, not data; test every webview separately; budget weeks for signing; automate distribution from day one. The real cost of a tool shows up not on the install screen, but on the day you get it to open cleanly on somebody else's computer.

So I will keep it short: pick Wails, but prepare for the work of shipping, not the five-minute demo. The table gets you in the door; what keeps you standing is everything the table leaves out.

And if you get stuck somewhere on this road, write to me. From the table that froze the bridge to Gatekeeper's "damaged" message, I have fallen into every one of these holes and climbed out of each with a note; sharing those notes is something I genuinely enjoy.

---

## The Software You Depend On Has an Owner. Their Decision Never Shows Up on Any Spreadsheet.
URL: https://aligundogdu.com/the-software-you-depend-on-has-an-owner
The tool you rely on can double its price one morning, close its doors, or claw a feature back. That risk isn't written on any roadmap. So who puts it on the table?

One morning a studio found out that a voice-animation tool it had bought years ago, a one-time payment for a lifetime license, had turned into a subscription costing tens of thousands of dollars a year. Same software, same screen, same work. The only thing that had changed was the mind of the person who owned that tool. And that mind wasn't written anywhere, not in the budget, not on the roadmap. Overnight, a cost they thought they had settled on paper reopened.

Don't read that as a single piece of bad luck. Around the same days three more stories crossed my path, none of them alike, all of them pressing on the same nerve. Managers who thought they could swap out their own teams for near-free with AI froze when the end-of-month invoice landed. A gaming platform hinted it could reclaim the digital games people had paid real money for if they hadn't logged in for a while. Another company was in the news for subscriptions that were deliberately made hard to cancel. Different worlds, different scales, but underneath, always the same sentence: the thing you use has an owner, and that owner can turn the rules any day, in any direction they like.

We engineers and product builders love to put one thing on top of another. We call someone's library, we lean on someone's cloud service, we fire requests at someone's model, and after a while we forget the ground underneath. We build floors on it as if it were our own land. But the ground under us is usually rented. And the strangest part of rent isn't the number written in the contract. It's that one side can change the contract.

## "It won't happen if you pick a good provider"

The objection I hear most often is this: these things happen to careless people. Pick a solid, established provider that everyone uses, and you've covered yourself. Tie yourself to some small, obscure tool and of course you're taking a risk, but standing behind the giants is safe.

I respect that objection, because it carries a grain of truth. A well-established provider really is less likely to vanish overnight. But the question is framed wrong. The point isn't whether the provider will still exist tomorrow. The point is whether, while it goes on existing, it will decide in your favor or its own. And being large doesn't mean it will decide in your favor. If anything, being large lowers its need to negotiate with you at all.

The companies that doubled a price, turned a lifetime license into a subscription, or shut off a free tier one morning were mostly not small and desperate. On the contrary, they were large enough to make that call comfortably, because they were sure they had pulled you far enough in. Once dependence is set, the provider's size is not your safety net, it's their leverage. The higher the cost of leaving, the more comfortably they raise your price. You don't even need bad intent to explain it. It's the most natural reflex a business has.

## The invisible rent

Here's the real issue: this risk has no place on any spreadsheet.

Think about what you actually estimate when you plan a piece of work. How many days it will take, how many people will work on it, which library you'll install. Maybe you even add the license fee as a line item. But nobody opens a line that says "if this tool triples its price three years from now" or "if this service claws that feature back." Because that line has no number. You don't know when it will happen, or whether it will happen at all. And because it's uncertain, you act as if it doesn't exist.

That's exactly where the danger sits. An invisible cost is dangerous not because it goes unmeasured, but because it never enters the table in the first place. A while ago, [writing about prioritization, I argued that the most honest box in RICE is Effort](/rice-prioritization): writing down what a piece of work will cost you broke the "this'll take two days" lie. But I'll admit it, most of the time I only wrote my own labor into that box. The chance that a tool I depend on might one day back me into a corner, I never put in Effort at all. Yet the most expensive labor is not the labor you spend. It's the labor someone else can decide to spend on your behalf.

The real cost of a piece of work is not just building it. The cost of leaving it, migrating off it, getting free of that dependence, is part of the cost too. And if you don't think about it while you're building, then on the day you need to get out, the provider sets the price, not you.

The sly part is how this cost grows quietly over time. The longer a dependence runs without trouble, the more you trust it, the more you build on top of it. Past a certain point you stop even seeing it as a dependence, it's just part of you now. But the truth is the opposite: the tool you've leaned on longest, trusted most, is the one that's most expensive to leave. Because that's where the roots go deepest. The provider knows this better than you do. It saves the price hike for the moment you've become most comfortable, most blind to it.

## AI didn't make this cheaper, it made it deeper

Lately everything has gotten sharper. [AI made producing cheaper](/ai-is-not-a-cheat-code), that's true. It has never been this easy to get an idea working. But that same ease tied you, without your noticing, to someone's model, someone's servers, someone's meter.

Remember those managers who froze at the invoice. Their mistake wasn't using AI. Their mistake was failing to see that the only thing that got cheaper was starting. Each request is a few cents on its own. But those cents pile up, not on a meter you're watching, but on a meter someone else is spinning on your behalf. As the unit cost falls, the total cost climbs quietly, and you're not the one setting the speed of that meter. The cheap start was the bait inviting you into an expensive dependence.

There's an old line: ride a borrowed horse and you'll be back on your own feet sooner than you think. Someone else's horse carries you a certain distance, you're fast, you don't tire, you're enjoying it. But the horse isn't yours. The day the owner pulls the reins, you're left standing wherever you happen to be. In the age of AI we've all been riding someone else's horse for a while now, and most of us never once stopped to think about whose horse it is.

## Now let me trip up my own argument

Someone who's read this far might think: if dependence is this dangerous, then don't tie yourself to anything, do it all yourself. Build your own infrastructure, write your own tools, need no one.

This is one of the answers that sounds strong but has misled me most over the years. Because there's no such thing as independence. Write everything yourself and this time you're dependent on the owner of the dozens of lines you wrote, the operating system you run on, your language, your compiler. There's no escape. And "I'll do it myself" carries its own cost: every wheel you reinvent is a weight you hoist onto your back and can never set down again.

More than that, the thing you think is free has an owner too. Behind that open-source library you stare at day and night, there is often a single person, getting nothing in return, running until they're spent. The morning that person says "I can't do this anymore" and walks away, the ground you thought was solid slips too. Free doesn't mean ownerless. It just means someone else is paying the bill for now.

So the solution isn't independence, because that isn't possible. The solution is to choose your dependence knowingly. To know, from day one, what you're leaning on, whose ground it is, and what it will cost you if one day you have to get up and leave. Not to pretend the risk away, but to name it.

## Knowing the ground

In practice I've boiled this down to a few questions, and I ask them of myself now before I start any work. Who owns this tool? If it doubles its price tomorrow, does my work stop or keep going? If I have to get out of here, can I take my data, my work, my labor with me, or does all of it stay behind their door? If I don't know the answers to these three, I think twice before building a floor on that ground.

None of this forbids depending on things. I too do my work every day leaning on other people's tools, there's no other way. But now, when I lean, I know the ground is rented. Being a tenant isn't the problem. Forgetting you're a tenant, knocking down walls, launching into expensive renovations, that's the problem. One of the quiet parts of [owning a product or a piece of work](/what-does-a-founding-engineer-do) is exactly this: mapping the land you stand on but don't own.

Engineering management is mostly remembered for the bright calls. But most of the job is this kind of bookkeeping that nobody applauds. Knowing what you depend on, knowing whose hand that dependence is in, and having already thought through what you'll do the day that hand tightens. The software you depend on has an owner. At the very least, you need to know who that owner is.

---

## Why Kings Wear Purple: The Color You Cannot Make by Saving the Day
URL: https://aligundogdu.com/why-kings-wear-purple
Tyrian purple cost more than gold because it was a system, not a recipe. Why day-saving companies drift, and how a plan turns luck into opportunity.

## The Color That Started with a Smell

The most expensive color in history was born in the worst-smelling workshops of the ancient world.

On the coast of today's Lebanon there was a port city called Tyre. The geographer Strabo wrote two things about it, side by side: the city was very rich, and living in it was not pleasant, because it smelled. Both facts had the same reason. The city's wealth came from dye workshops, built downwind of the town because of their smell.

Those workshops produced [Tyrian purple](https://en.wikipedia.org/wiki/Tyrian_purple). The source was not a flower or a mineral; it was a spiky sea snail. Inside each snail there is a small gland holding one or two drops of liquid. That liquid starts out yellowish. With air and light it turns green, then blue, and finally a deep, rich purple.

The numbers tell the real story. In 1909, the chemist [Paul Friedländer](https://en.wikipedia.org/wiki/Paul_Friedl%C3%A4nder_%28chemist%29) repeated the ancient process in his lab: from twelve thousand snails he got 1.4 grams of pure dye. Dyeing even the edge of a handkerchief needed thousands of animals and days of work. When the snail beds near their own coast ran out, the Phoenicians went looking for new bays; they spread across half the Mediterranean partly because of this snail.

Rome recorded the price officially. In Diocletian's price edict, purple-dyed silk costs more than its weight in gold. Wearing purple was first a matter of money, then a matter of law; step by step, the color was tied to the palace. In the Byzantine palace there was a birth room covered in purple stone. Emperors' children were born there and carried a title for life: born in the purple.

This post is not really about colors. It is about companies. But first we need to answer one question: how does a color become the symbol of an empire?

## For One Gram of Purple

The answer is not difficulty. The world is full of difficult work. The answer is the type of difficulty.

Making purple was not a one-time act of heroism; it was a system from end to end. Boats and divers to collect the snails. Logistics to bring them to the workshop before they spoiled. Hands that removed, salted and rested the glands. Masters who waited by the vats for days and knew the exact moment the color turned. Tones tuned by controlling how long the dye saw the light. And all of this repeated, not once, but with the same quality in every batch.

Purple was not a recipe. Purple was a production system. Tyre's real secret was not the liquid inside the vat; it was the order around the vat.

You cannot make purple with day-saving decisions. A workshop that collects snails today and gives up tomorrow, opens the vat early out of impatience, and changes its master every month will not produce purple. It will produce something, of course; but its name will be a stain, not a color.

My favorite detail is this: the color did not fade. According to Pliny, Tyrian purple did not run from the sun; it became more beautiful with time and light. Cheap dye washes out the first time. Purple shines as it ages.

Let's put that sentence aside, because we will need it soon: **a day-saving fix fades by the next morning; value produced by a system shines as it ages.**

## A Company Adrift in the Wind

Now let's move from the vats to the meeting room of a software company.

Our industry loves a simple idea: speed is everything. Be agile, decide fast, catch the wind. Half of it is true, but the question is incomplete. Speed is only speed when there is a direction. Without direction, its name is drifting. Wind is not bad; wind is what moves the ship. The difference is the rudder.

I don't need to describe the day-saving company in detail, because most of us have worked in one. The week's plan is set by Monday morning's email. The loudest customer becomes the roadmap. Every meeting is a fire meeting, and the word "urgent" has lost its meaning, because everything is urgent. After years inside the kitchen, I keep seeing the same two bills arrive.

First: you cannot invest in the right people. Hiring is a promise made for six months later. A company that does not know where it will be in six months cannot know who to hire; it collects firefighters for today's fire. Then the fire changes, and the wrong team remains. Training, mentoring, watering a plant that will flower in six months... these are not luxuries. They are the natural reflex of a company with a rudder. Nobody packs supplies for a journey with no destination.

Second: nothing accumulates. In a day-saving company, every solution belongs to that day. The crisis passes, everyone goes home tired but happy, and next week the same film starts again. The solved problem is not written down, the lesson does not become a system, the knowledge lives in the hero's head. Such a company has no memory; it has reflexes. And the difference between a reflex and a strategy is exactly the difference between a stain and purple.

The AI era did not soften this picture; it sharpened it. Every week a new model, every month a new miracle tool. For the day-saving company, each one is a new wind, which means a new course: one quarter a chatbot, the next quarter agents, the third quarter both left half-finished for that week's demo. The purple story explains what is really happening here. When production gets cheap, the color itself loses value; the value moves to the dye house. AI made output cheap for everyone. Everyone has the color now. The difference is the production system.

I wrote before that AI is [not a cheat code](/ai-is-not-a-cheat-code) but a power tool. However light the steering gets, the question of where to go stays with the driver. A company that answers that question differently every morning is not really answering it.

## The Hero Trap

Here I have to stop and be honest, because everything above would be unfair if I left it alone.

Saving the day is a skill. In the early stage it is almost the only skill. A startup that is still looking for its first customer, with three months of cash left, does not need a five-year masterplan discussion; that would be choosing curtains in a burning house. That period is called survival, and survival beats planning every time. For teams trying to cross [the valley between prototype and product](/the-prototype-illusion), sometimes the only right move is to keep swimming.

The problem starts when saving the day stops being an event and becomes an identity. The fire is no longer an exception; it is the operating model. And the company rewards it without noticing: the engineer who brings the system back at midnight gets the applause; the engineer who quietly works so that the fire never starts again gets "low visibility" in the performance review. Behavior flows to where the incentive is. A company that rewards firefighting is, without knowing it, raising arsonists. It is like the old story told about colonial Delhi: the government put a bounty on dead cobras, so people started breeding cobras, and when the bounty was cancelled the breeders released them all. The city ended up with more cobras than before. It is known as the cobra effect; a system that rewards the wrong thing produces the very thing it wanted to reduce.

The other side of the coin also kills: process worship. Companies that tie every task to a form, hold meetings about meetings, and cannot ship three lines of code without three signatures also die. They just die slower, and bored. The system I mean is not bureaucracy. **A system is making a decision once instead of a hundred times, and letting the flow carry the rest.** If the answer to "how do we deploy" lives in one person's head, there is no system; if it lives in a script anyone can run, there is. It is that simple.

## A Plan's Job Is to Catch Luck

I can hear the objection: what if the market changes? We made a masterplan, and six months later it is trash?

It will change. Very likely. There is an old military saying: no plan survives first contact. People always use it as an argument against planning; but the man who said it did not run his armies without plans. The value of a plan is not that it comes true. The value of a plan is that it makes the deviation visible. The person who knows where they are going senses trouble early and prepares plan B. The person who does not know where they are going cannot have a plan B, because there is no plan A; there is only today.

The last act of the purple story says exactly this. In 1856 in London, an eighteen-year-old chemistry student named [William Perkin](https://en.wikipedia.org/wiki/William_Henry_Perkin) was trying to synthesize quinine, a malaria medicine. The experiment failed. While cleaning the black sludge at the bottom of the flask, he noticed it dyed silk a bright purple. Mauveine, the first synthetic dye in history, was an accident. The color that had belonged to kings for thousands of years reached the shop windows of London within a few years.

At first sight, Perkin's story destroys the thesis of this post: the man won by accident, not by plan. Look closer and the opposite appears. That year, hundreds of students in London were cleaning dirty flasks. The eye that noticed the accident belonged to a mind that knew what it was looking for. And what turned the accident into a patent, a factory and a whole dye industry was not curiosity; it was the system Perkin quickly built around it. Luck hits everyone. When luck hits a prepared system, its name becomes opportunity. When it hits an unprepared company, its name becomes a nice memory.

A pivot works the same way. Changing course is not the absence of a plan; it is knowing where you turned. Without a map you cannot change course. You can only drift.

## Are You Making Purple, or Saving the Day?

When Constantinople fell in 1453, the palace workshops went silent, and the knowledge of true purple largely went with them. For centuries nobody could produce the color the old way. The secret of the vat died together with the master standing next to it. Knowledge that does not become a system is buried with its hero.

There are shortcuts to test which one your company is. I use three:

- **The same-fire test.** If the same problem caused a crisis twice in the last year, it is not an accident anymore. It is unpaid system debt.
- **The vacation test.** If one key person turns their phone off for two weeks, does the work stop? If it does, you do not have a company; you have a duty roster built around one person.
- **The memory test.** What written record remains from the last big crisis? If the answer is "everyone learned a lot", nobody learned anything. They just got tired.

Working in the workshops of Tyre brought no applause. Enduring the smell, waiting by the vat, doing the same job a thousand times with the same care. Nobody carved those masters' names into stone. But kings carried those masters' patience on their shoulders. Purple is not the color of the day-savers. It is the color of the people who endured the smell.

The wind blows on everyone; these days, harder than ever. For the ship with a rudder, wind is fuel. For the one without, it is fate.

---

## RICE Will Not Make the Call for You. It Makes You Ask the Question You Are Avoiding.
URL: https://aligundogdu.com/rice-prioritization
For most people RICE is a corporate spreadsheet. Its real job is not to calculate a score, but to sit you down in front of the questions you are afraid to answer. Why I still come back to it, on a big team and as a team of one.

Say you have ten things sitting in your backlog and no way to do them all at once. Which one goes first? This post is about a simple framework that helps with exactly that call: RICE scoring. But let me say it upfront. The real value of RICE is not the number it hands you. Its value is that it sits you down in front of the questions you have been running from.

Because the real problem in prioritization is not a lack of information. The real problem is a feeling that everyone who builds things knows. An idea lands in your head, and it looks so bright that it dazzles you. "If we add this, everything changes." A voice inside says "let's start now," and your hands are already on the keyboard.

That feeling is innocent on its own. What is dangerous is when it cuts in front of the work that actually matters. Three things the user is genuinely stuck on are sitting right there, and one bright but groundless idea swallows the whole roadmap. A product does not drown in junk. It drowns in the wrong order. Prioritization is the act of pulling up a chair and sitting down across from that bright, loud voice.

RICE does this with four questions. **R**each, how many people does it touch. **I**mpact, how much does it change things when it does. **C**onfidence, how sure are you. **E**ffort, what will it cost you. You multiply the first three, divide by effort, and a number is left in your hand. This formula, which came out of Intercom's product team, looks like a calculator on paper. For the curious, I even wrote a small tool to play with the score, which you can look at [here](https://github.com/aligundogdu/Rice-Score-Calculator). But the moment you mistake RICE for a calculator, you miss what it is actually for.

## "These frameworks are decoration for big companies"

The common belief goes like this: frameworks like RICE exist so that huge product teams can pass the time in meeting rooms. If you are a small team, or even someone working alone, fussing with these tables is a luxury. "I already know what to do, my gut is enough."

I respect that objection, because it is partly right. Intuition is a real thing, and the intuition of someone who has done a lot of work is not cheap. But the question is set up wrong. It is not "gut or spreadsheet." It is what your gut is not showing you.

Intuition fails hardest on the thing you want most. When you fall for an idea, your brain becomes that idea's lawyer, not its judge. What RICE does is call a prosecutor into that courtroom. And a good prosecutor asks the questions you are afraid to answer. Because most of what we call intuition is just an impulse wearing a disguise.

## The real work is asking the question, not finding the number

I misread RICE for years. I waited for the score like a prophecy. But each of those four boxes puts a question on the table that you would rather escape.

**R**each asks you "how many people, really?" The "everyone wants this" in your head, once you put it into numbers, usually turns into "actually a few hundred, and they use it once a month."

**I**mpact asks you "what changes when it lands?" Most features, looked at honestly, do not change the user's day. They only stroke your own "I shipped it" satisfaction.

**C**onfidence is the sneakiest one. "Do you know this, or do you hope it?" If your hand does not shake as you write a high number in that box, either you genuinely have the evidence, or you are fooling yourself. There is not much in between.

**E**ffort is the most honest mirror. Underestimating a task is the national sport of the person doing it. Putting effort into writing breaks the "it will take two days" lie.

As you can see, what is on the table here is not math but confession. What RICE actually gives you is not a score but the obligation to say your assumptions out loud. The number is just the sum of those confessions. There is an old saying that the worth is in the head, not in the crown it wears. The score is the crown, the ornament you show everyone. The real worth is the truth you were forced to tell yourself while filling in those boxes. This is why, when you push a decision through RICE, you usually see the answer before you finish the arithmetic.

## Getting ahead of the million-dollar assumption

The most damage comes from the people who speak with the most confidence. I have heard the classic line from an inexperienced product person too many times: "The moment we add this feature, we will make a million dollars." Under that sentence there is no measured Reach, no calculated Impact, only the sound of an excitement.

That excitement is innocent on its own. What is dangerous is when it cuts in front of the necessary work and pushes a team to spend months polishing something nobody asked for. RICE is made for this moment, because it does not ban the excitement, it just puts it in line. "Fine, your million-dollar idea is on the list too. Now let's run it through the same four questions." If the idea is genuinely strong, it comes out strong in the score and nobody can argue. If it is weak, it falls to the bottom of the queue on its own number, without a fight with anyone. You do not make the call, the process does. This also lowers the politics on a team. The argument stops being "whose idea is cooler" and becomes "which assumption is more solid."

A side benefit is this: RICE often pushes you toward the cheaper path. High Effort drags the score down. So the question "how do I deliver the same value with half the work" comes up on its own. Good prioritization does cost optimization without noticing.

## AI Made the Code Cheap, Not the Right Order

Something changed in the last few years. Building software with AI got both cheaper and faster. The distance between imagining a feature and seeing it run has never been this short. It sounds like news that makes prioritization pointless: if everything is this easy, just sit down and build all of it.

The sneaky part is right here. What got cheap is writing a feature. Choosing the right feature did not get cheap, it got more expensive. When production gets easy, the natural brake in front of adding features is lifted, and every bright idea turns into code instantly. Looked at one at a time, each is a few hours, a few tokens. But when they pile up without a plan, those small costs add to each other: tokens spent, context bloated, code no one looks at again, complexity you are forced to carry on your back. As the cost per feature drops, the total cost quietly climbs.

This is exactly why, as the "can I do it" question got cheaper, the "should I do it" question got more valuable. RICE makes you ask that second one. The easier production gets, the more decisive choosing the right order becomes. When the brake is expensive, everyone drives carefully. The real skill is knowing how to slow down when the brake is free.

## When No One Is Watching You

I saw this most clearly working alone. As someone who sits on the technical side, project management was never really my job. But when I was building my own things, no one was asking me "is this really a priority." I was the boss, the developer, and the so-called product manager. And on a team of one, fooling yourself is far easier than on a crowded team. There is no friction holding you back.

RICE stood in for that friction, right there. When I got carried away by an idea, I forced myself to sit in front of those four boxes. Often, because I could not write an honest number in the Confidence box, I gave up on a task that would have eaten weeks before I even started it. What saved me was not the score itself, but the truth I was forced to tell myself while filling in that box.

A small team is not exempt from this method. The opposite. The scarcer your resources, the bigger the price you pay for the wrong order. A big company absorbs a wrong priority, loses a few months, and moves on. In a one-person venture, the wrong priority is a survival question. [A working prototype does not make it a product](/the-prototype-illusion); in the same way, an idea being exciting does not make it a priority. Deciding what comes first is maybe the loneliest part of [owning the product](/what-does-a-founding-engineer-do).

## Do Not Hand the Wheel to a Number

I have defended RICE this far, so now let me trip up my own defense. Because the biggest danger of this method is seeing that it works and trusting it too much.

RICE is a navigation, not a steering wheel. The numbers you write in the four boxes are your guesses, not exact measurements. Confidence especially is the easiest place to inflate, on purpose or not. If you really want to get a task done, you unconsciously bend the other boxes toward that outcome too, and in the end you produce a score that confirms the decision you already made. I call this "the theater of objectivity." The table looks scientific, but you have filled it with your own bias.

So I never make the score the final word. When the navigation says "turn right," you do not close your eyes and turn, you first check whether there is a road there. When RICE rejects a decision, I stop and ask too: "Am I wrong, or is the table?" Sometimes the number saves me from my own laziness. Sometimes I sense something the number cannot see and go against the table, but now on purpose, not by accident. The number exists not to hide intuition but to test it. The moment you swap one for the other, RICE turns into one of those bad product managers you have seen, just one hiding behind a table.

## What You Are Really Weighing

In the end, what RICE taught me is far older than prioritization. These four boxes look like they are weighing a task, but they are really weighing you: what you actually know, what you are only hoping, which excitement you are hiding behind.

That is why, on a big team and alone, I come back to the same place. Not because I want a calculator. Because I need something that makes lying to myself harder. The score comes out, and I forget it. But the moment I am forced to answer those four questions honestly, I have already made the call.

---

## What Does a Founding Engineer Actually Do? The 'Founding' Is Misleading
URL: https://aligundogdu.com/what-does-a-founding-engineer-do
Founding engineer is one of the most sought-after technical roles of 2025. But most people get it wrong: they are not a founder, and the job is not mostly writing code. Backed by industry data, here is what the role really involves.

Over the last two years, one title has risen to the top of startup job posts: founding engineer. Sources that watch the industry closely, like The Pragmatic Engineer, describe it as one of the most sought-after technical positions of 2025, and someone even went as far as calling it Silicon Valley's biggest catch. But all that shine around the title has also created a real confusion about what it means. Most people get the founding engineer wrong.

Two mistakes circulate at once. The first is reading the "founding" in the name and assuming the person is a founder. The second is reading "engineer" and assuming the job is mostly writing code. The truth sits outside both. Drawing on industry data and the role's actual definition, this piece tries to clear up what a founding engineer really does.

## "Founding" Does Not Mean Founder

This is where the biggest mistake lives. The "founding" in the title says the person is part of the founding team, not that they are a founder. A founding engineer is often the company's first engineer, sometimes its first employee. But they do not sit in the same seat as the founders.

The clearest way to see the difference is the numbers. According to industry data, founders typically own somewhere between 20 and 50 percent of the company. The first engineer's median equity is around 1.5 percent, and by the fifth hire it drops to about 0.33 percent. So the founding engineer takes a big risk, arrives as early as a founder, carries as much as a founder, but does not get a founder's share. In return, they usually take a higher salary. That equation is the key to understanding the role: someone who works with a founder's mindset without being a founder.

## The Real Job: Not Code, but Owning the Product

The second mistake clears up here too. An early-stage startup has no separate product manager. So what is expected of a founding engineer is not just coding the work handed to them, but having an opinion about where the product should go. The shared emphasis across the sources that describe the role is this: there is no room here for a code monkey who only writes code.

In other words, a founding engineer's day is not spent burning through a task list of "build this." Deciding which feature is actually needed, and which one merely sounds nice, is part of the job. Technical decisions and product decisions merge inside the same person. So while the most visible part of the work is code, the real weight is outside the code.

## MVP, Hypothesis, and Failing Fast

A founding engineer's first concrete task is usually to build an MVP, the smallest working product that can test the startup's core assumption. The logic is simple but unforgiving: test the hypothesis first, scale and add features if it holds, learn early if it does not.

That also means some of the code written is born to die. A feature, a flow, sometimes a whole direction can hit reality and go in the bin. That was the point in the piece where I wrote about [how complexity quietly eats a product from the inside](/the-prototype-illusion): being able to build fast and fail fast beats building perfectly and realizing too late. A founding engineer's job is to keep that hypothesis loop spinning with limited resources and few people.

## Why It Is So Wanted in 2025

There are two reasons the role has become this popular lately, and both point in the same direction.

The first is the economic climate. In the first half of 2025, startups across most areas leaned toward leaner teams and more cautious growth. In that environment, the founding engineer became the person who does the work of several with a single strong hire. Much from few became the spirit of the moment.

The second is tooling. AI tools like Cursor, Claude Code, and Copilot have noticeably increased what a single senior engineer can ship in a week. I described this before as [AI being a force multiplier rather than a cheat code](/ai-is-not-a-cheat-code); the founding engineer is the most concrete expression of that multiplication. The direction is still human, but that human's reach is far wider than it used to be.

## The Other Side of the Coin

Up to here the role sounds appealing: arrive early, build a lot, steer the product. But to be honest, there is another side.

A founding engineer arrives as early as a founder, carries as much uncertainty as a founder, and often cannot even find anyone to approve their decision. They pick the wrong architecture, and they are the one sitting with the database that blows up at night. But when the company grows, they do not get a founder's share. This is the role's hidden invoice, and it is the part that needs to be seen clearly before the contract is signed. The appeal is real, but so is the price.

## Conclusion: Not a Title, but a Position

A founding engineer is neither a founder, as the name suggests, nor merely a coder, as the job is assumed to be. The shared picture from the industry data is this: the first engineer who thinks like a founder without being one, who owns the product while their share stays limited.

Building my own small projects, I came to know the nature of this work, even if only from a distance: while building a product at the kitchen table, the thing that tired me most was not the code, it was answering the question "should I even build this" anew every single day. A founding engineer lives that with the weight of a company on top, often alone. To look at the shine of the title and miss the position behind it misleads both the person hiring and the person about to take it. The point is not the shiny word, but knowing what the real work and the real share underneath it are.

---

## Should a CTO Write Code? Stop Asking the Wrong Question
URL: https://aligundogdu.com/should-a-cto-write-code
Should a CTO write code or not? The question itself is wrong. How the role changes with the company's stage, when to touch the keyboard, and when to stay away.

The same fight flares up again every week. On one side, the people who say "a CTO who writes code is a CTO who never learned to delegate." On the other, the ones who say "a CTO who steps away from the keyboard gives up their authority too." And in between, thousands of people sharing cartoons and picking sides. Everyone is certain; everyone mistakes their own story for everyone's story.

Every time I run into this fight, I think the same thing: they're arguing the wrong question.

"Should a CTO write code?" is as empty as asking "should a doctor perform surgery?" Which doctor? The ER physician, the radiologist, the chief of medicine? Looking for a universal answer to a question stripped of its context produces just one thing: professionals who've fallen out with each other.

So let's throw the question out as it is. Let's put a useful one in its place: **at which stage, in which context, should they write what?** As we look for the answer, we'll see there's no single job called "CTO"; as the company grows, the role keeps changing its shell.

## There's No Single Answer to "What Is a CTO?"

CTO is the loosest label in software. Two people carrying the same business card can have days that look nothing alike. One opens the IDE in the morning and ships code to production; the other is in the board room at that hour, defending a five-year technology budget. Both are CTOs, both are doing the job right.

The reason is simple. The role is tailored to the size of the company. At a five-person startup, the CTO is the lead engineer. At fifty, the conductor. At five hundred, the cartographer. One title, three separate professions.

Vadim Kravcenko sums it up in a single line: the smaller the company, the fewer people a CTO deals with; the bigger it gets, the less technology. One end of the spectrum is pure code, the other pure strategy. And most of us spend our careers sliding back and forth along that line.

This is exactly where the arguments go wrong. They put the CTO of a five-person startup and the CTO of a five-hundred-person company on the same scale, then fight over "should they write code?" It's the technology version of weighing apples against pears.

Let's walk the line together, from one end to the other.

## The CTO in a 5-Person Team: The Head Cook

In the Book of Dede Korkut, the old Turkic epic, there's a figure: the wise elder of the camp. Warrior, advisor, and healer all at once. He carries several jobs at the same time, because the camp is small, resources are tight, and the luxury of division of labor doesn't exist.

The CTO of a small startup is that wise elder.

In the morning you write the MVP's backend. At noon you give the customer a demo. In the evening you set up the deploy pipeline, and at night you chase a bug blowing up in production. The next morning you explain the architecture to an investor. You answer the "which stack?" question too, because there's no one else to ask.

There's no luxury here of "maybe I shouldn't write code." If you don't write it, who will? You've got an engineer or two beside you, maybe not even that. Whether the startup gets to breathe depends on how fast you touch the keyboard.

And the job isn't only code. Build or buy, that call is yours. The stack choice is yours. The first customer's technical question, the investor's "will it scale?" worry, who gets grabbed by the collar when production goes down, all of it is yours.

Here's the sneaky part: the first engineers you hire in this period build the company's technical character. The first five people set the temperament of the next fifty. You're writing that temperament, and in a way that outlasts any production code you'll ever write.

But a trap is waiting in ambush: **dependence on speed.**

You get so used to doing every job yourself that even after the team grows, you say "it's faster if I do it." That sentence is the very thing that keeps a startup running in place. Because yes, today you really are faster. But if you're still the one doing the work tomorrow, and six months from now, then why is the team standing there?

Picture a restaurant. Five tables. The chef is at the stove, on the menu, and at the register. Perfectly normal. But if that same chef tries to plate every dish by hand in a hundred-table dining room, everyone at the tables goes hungry.

The one rule of this period: **write code, but don't fall in love with it.** Let every commit also be a lesson. Pair program, write the architectural decision down, get what's in your head out. Because one day you'll put that keyboard down. If the team doesn't know what was in your head that day, the company stops right along with you.

At this stage your most valuable weapon is your technical depth. Framework, architecture, build-vs-buy, the final word on all of it is yours. But when you climb to the next step, that same weapon starts to feel heavy in your hand.

## The CTO in a 50-Person Team: The Conductor

There's a fine balance in the semah, the turning dance of the Alevi tradition: everyone spins on their own axis, but the turning is shared. There are individual movements, and above them all, a single whole. No one spins alone, no one mimics their neighbor. Everyone knows their place, and what emerges is greater than the sum.

Leading a fifty-person team is exactly this. And here the role changes at its root.

The most critical pull request no longer comes from you. You're no longer the one solving the nastiest bug. Maybe it's been weeks since you opened the IDE. All of it is normal.

Because your product is no longer code, it's the **team**. Your commits aren't merges, they're **decisions**. Your deploys aren't features, they're **processes**.

I remember the days I started my own agency. At first I touched every line of every project, chasing production errors at night. Then we became five, then ten. One day I realized the moments I added the most value weren't the ones where I wrote code. They were the ones where I explained the "why" behind a decision to a junior, settled a technical fight between two teams, translated technical debt into the language of money for a client. Being able to take a deep subject like [data integrity in distributed systems](/debezium-in-distributed-systems) and turn it into language everyone at the table understands, that's the most expensive skill of this stage.

This transition isn't easy, especially if you're someone who learned by doing. Stepping away from the keyboard feels like losing control. But you're doing the opposite: you're **multiplying** control. Ten people carrying your knowledge are always stronger than one person limited to it.

The day flows differently now too. You go into standup not to say "here's what I did yesterday," but to clear the rocks in front of people. Is there a blocked dependency, a pending architectural decision? In the afternoon, the customer, the retro, the technical-debt negotiation. You look at PRs, but not all of them; only the ones that set a precedent, the decisions that bend the architecture. In the evening, the map of the coming quarter: which investment, which debt, which talent.

The biggest trap of this period is **missing the code**. The thought "let me just ship that PR myself" will knock on your door every day. Sometimes it'll even be right, you really would do it faster. But every time you say "let me do it," you're stealing someone's turn to learn. Six months later you're doing it again, because that person never got to learn.

The hardest fight isn't with the team, it's with yourself. For someone who measured their worth in lines of code for years, ending the day having written none leaves a strange emptiness. Your contribution graph fades, and a voice inside says "I'm not producing anymore."

You are producing, actually. Your product just changed. What you produce now is people who can produce. Managing CRM teams in the energy sector in Europe, I saw this with my own eyes: the team's youngest engineer used a pattern I'd shown in pair programming a year earlier to solve the customer's most critical integration problem. That's when I understood, my best code had come out of someone else's hands.

## The CTO at 500+: The Cartographer

At this scale the role is entirely strategic. No code in daily life; maybe you haven't even opened a terminal in months. And that's right.

Because your job now is to set the company's technology direction and line it up with the business strategy. You present the five-year map to the board. You design the organization with your VPs of Engineering. Cloud migration, platform shifts, big build-vs-buy decisions all pass across your desk.

Your "code" is written in another language now: the strategy document, the org chart, the technology radar. Your output isn't a commit, it's **direction**.

There's a cliff here too: **losing touch with the tech.** Stopping writing code is right; stopping following technology is a disaster. The good CTOs at this scale keep their minds sharp either by experimenting on personal projects or by setting up regular deep-dive sessions with their most technical people. The ones who do neither become, three years later, the "former engineer" who can't answer a technical question in the board room.

And here a nice paradox shows up: at this scale your strongest weapon isn't your technical knowledge, it's your **ability to translate**. The person who answers the CFO's "why should we put money into this refactoring?" with a customer-churn number; who explains to the engineer "why is this feature being delayed?" with market data. The bridge standing between two worlds.

As Gerald Weinberg put it, no matter how technical it looks, everything is really a people problem. A platform migration isn't just a technical project, it's a transformation that changes how hundreds of people do their work. [The move from Mattermost to Matrix](/mattermost-matrix-migration) was a serious decision even on a small team; imagine the weight of that decision in a structure of hundreds.

## The CTO in the Age of AI: A New Equation

Few people, little ammunition, little time. These are often the conditions of a war of independence, and it's exactly that scarcity that breeds strategic intelligence. You're forced to use every resource you have by multiplying it.

The CTO's situation in the age of AI is similar. The resources are the same, but the multiplier on each one has changed. I've written at length before about [how AI is reshaping software](/ai-is-not-a-cheat-code); here I'll look at the side of that wave that hits the CTO role directly.

An engineer today produces code two or three times faster with AI-assisted tools. But this means not fewer engineers, but different engineers. People who can weigh the code AI spits out, steer it, and put it in its place.

This has three consequences for the CTO.

First, **"writing code" has been redefined.** You don't have to type every line by hand. But knowing which line needs to be written, seeing the quality of the code that comes out, provoking the tool in the right direction, that's the new technical competence.

Second, **the shape of the team shifts.** Agents now take on the simple work. That means rethinking the team plan from scratch. Which work goes to AI, which role transforms, which new role is born?

Third, and most important, **decision speed has gone up.** The prototype-test-iteration loop has shortened. An idea we used to say "let's put in a two-week sprint" we now turn into a working prototype in a few hours. As the cost of trying drops, the distance between strategy and tactics narrows too.

But careful: AI is a tool, not a strategy. "We use AI" is turning into a sentence as empty as "we use computers." The point is **where** and **how** you use the tool. The one making that call is still a human.

In this age the CTO carries one more debt: getting the team ready to work with AI. It doesn't end with "go install this tool." You have to make sure the engineer can run AI output through a critical eye, teach them where the tool stumbles, build a culture that holds the line between "code that works" and "code that's right." AI produces working code easily. Right code still asks for human judgment.

## So When Should You Touch the Keyboard?

So far we've drawn a line: code on a small team, strategy on a big one. Real life isn't that clean, of course. The CTO of a fifty-person team writes code now and then too, and the CTO of a five-hundred-person structure opens a terminal now and then too.

The question isn't "to write or not to write?" The question is: **why am I writing?**

Over the years I've picked up a few compasses for myself.

**Yes, touch it:**

- **In a crisis.** If production is on fire and you know that system's architecture best, stepping in is a responsibility. But once the fire is out, ask: could it be put out without me next time?
- **In a prototype.** Trying a new approach with your own hands raises the quality of your decision. Sometimes testing it directly is faster and more accurate than delegating and adding a translation layer in between. Just don't forget the [deadly valley between prototype and product](/the-prototype-illusion): a prototype is there to prove something, not to be the product itself.
- **To teach.** The code you write in pair programming isn't "let me do it, it's faster," it's knowledge transfer. That's worthwhile.
- **In your own garden.** In side projects and personal experiments, the door is always open to keep your technical muscles in shape.

**No, let it go:**

- **If you're saying "I'd do it faster."** That sentence is a confession that you couldn't delegate and didn't invest in your team.
- **If you're building a feature.** If the CTO has their own task in the sprint backlog, either the team is short-staffed or the priorities are tangled.
- **If you're writing for ego.** You don't need to prove "I can still write code." The team listens to you by the quality of your last decision, not the date of your last commit.
- **If you've become the bottleneck.** If nothing merges without your approval, if no one understands what you wrote, if the deploy stops when you're away, the problem isn't in the code, it's in you.

The essence of all of it in one sentence: writing code is a tool, not an identity. A CTO's identity shouldn't be "the person who writes code" but "the person who makes the right call." Sometimes the right call is to write code; most of the time it isn't. And this compass isn't fixed either; the same person, at the same company, turns a different way in a different period. When a new product line opens you might switch into prototype mode for a few weeks; during a big organizational change you might not write a line for months.

## The CTO's Real Code: Culture Engineering

A company's technology culture is the CTO's longest-living code. Frameworks change, languages evolve, architecture gets refactored. But how the team decides, how it meets failure, how it shares knowledge keeps running for years.

When I think about real CTO output, what comes to mind isn't the lines written, it's the mechanisms built:

- **The blameless postmortem.** Not the person who made the mistake, but the system that allowed it, is put on the table.
- **A transparent decision record.** ADRs, RFCs, technical writing circulating internally.
- **An environment where a junior can ask a question without flinching.** "There are no stupid questions" lives in the hallway, not on the wall.
- **Technical debt translated into the language of money.** Not "we should refactor this," but "this is the source of a third of the complaints."
- **A culture of experiment.** A climate where failure isn't punished and learning is rewarded.

None of this asks for a single line of code. But all of it asks for engineering discipline, patience, and empathy. And the paradox of it is that it asks for technical depth too; because only someone who knows how software is made down to their bones can build this culture.

Leading the software team at a security company, we had our most technically brilliant engineer. He solved every problem on his own. When the team grew, that "I'll handle everything" reflex paralyzed the team. No one took initiative, because the expectation "he'll do it anyway" had set in. My job wasn't to stop that person, it was to build the mechanism that would multiply his knowledge. A code-review standard, a pair-programming routine, a documentation habit. These spread what was in one head to ten.

That's the CTO's real code: building **systems** that multiply knowledge, speed up decisions, and turn mistakes into lessons. The best code is the code no one notices; it looks like infrastructure, invisible, but it holds everything up.

## From the Wrong Question to the Right Answer

We set out with "should a CTO write code?" I hope that by the time we got here, it's clear how incomplete that question is.

The right thing isn't a single question, it's a series of them:

- Which stage of the company am I in?
- Where does my team need me most?
- Do I create more value by writing code, or some other way?
- Can someone else write tomorrow the code I'm writing today?
- Is my reason for writing the team's need, or my own?

The answer changes from person to person, company to company, even month to month. That's the beauty of the role: there's no fixed job description, no fixed "right." The only constant is the constant changing of shells. From head cook to conductor, from there to cartographer. And at every step, asking again: "what's the right thing now?"

Let's go back to the fight we started with: both sides are right, both are wrong. Because the question itself is contextless, and a contextless question has no answer. The person who knows the context best is the one sitting in that chair. Being able to set the ego aside and ask "where's the biggest bottleneck right now?" is a more valuable skill than technical intelligence.

In the end, a CTO's real job is neither writing code nor not writing it. The real job is being able to honestly answer, every day, the question "where do I create the biggest impact today?" The answer is some days in a terminal window, most days in front of a whiteboard, every day among people. And maybe most important of all: never stopping asking this question. Technology doesn't stop, the company doesn't stop, the market doesn't stop; so the CTO mustn't stop either. This question is the most critical unit test a CTO rewrites for themselves every quarter.

> The Turkish version of this piece is [here](/tr/cto-kod-yazmali-mi).

---

## Is PHP Dead?
URL: https://aligundogdu.com/is-php-dead
Taking the old "Is PHP dead?" question and walking it through PHP's history and its technical turns, this piece argues that it is still a living, growing language.

**In short:**

I'm writing this to ask, one more time in 2024, that old _**"Is PHP dead?"**_ question , the one that crept into our lives in the 2010s and still gets used to farm followers and engagement on social media , and to take a small nostalgia tour along the way.

## What Does It Mean for a Language to Die?

Before I start, I think it is better to define death first.

For a language to die, development on it first has to stop. Then new projects built with it have to slow down or end. Once those two things happen, the rest , "closed to innovation", "can't keep up", "lost its modernity" , complete themselves automatically.

Any language outside these conditions has not died, even if only a handful of people still use it.

## So, What About PHP?

Now that we have pinned down what _death_ and a _dead language_ mean, let's take PHP and pull the calendar back to **2005**. Maybe a lot of you were still a twinkle in your father's eye back then :) but to understand how a process ends, it helps to know how it began, so we have to go this far back.

If we look at the debates of that period:

- the rise and heavy buzz of what we called web 2.0 \[[1](https://www.wired.com/2006/01/breaking-down-the-hype-of-web-2dot0/)\]\[[2](https://www.oreilly.com/pub/a/web2/archive/what-is-web-20.html)\]\[[3](https://www.historyofinformation.com/detail.php?id=1654)\],
- social media platforms starting to settle into our lives \[[1](https://www.educba.com/what-is-social-media/)\],
- Google starting to grow \[[1](https://www.fool.com/investing/high-growth/2006/02/01/googles-2005-growth-story-fool-by-numbers.aspx)\]\[[2](https://www.webdesignmuseum.org/gallery/google-2005)\]\[[3](https://economictimes.indiatimes.com/tech-life/43-key-moments-in-googles-18-year-history/2002/slideshow/48981584.cms)\]\[[4](https://hbr.org/2010/05/how-i-did-it-googles-ceo-on-the-enduring-lessons-of-a-quirky-ipo)\],
- e-commerce starting to enter our lives \[[1](https://www.ebay.com/)\]\[[2](https://www.amazon.com/)\] ,
- a technology like ajax spreading across the web \[[1](https://www.studysmarter.co.uk/explanations/computer-science/computer-network/what-is-ajax/#:~:text=AJAX%20stands%20for%20Asynchronous%20JavaScript,for%20Asynchronous%20Java%20and%20XML.)\]\[[2](https://www.oracle.com/technical-resources/articles/enterprise-architecture/ajax-introduction.html)\]\[[3](https://simpleprogrammer.com/history-internet-14-google-and-ajax-apps/)\]

if we define it as the period when all of this began, we wouldn't be making a mistake.

PHP, in that period, could not keep up with these needs with its current version, and even when it could, it did not solve them in a [developer friendly](https://www.quora.com/What-does-it-mean-for-a-tool-to-be-developer-friendly) , that is, **developer-friendly** , way.

So naturally, we were expecting signs of modernization from PHP. And in the same years, [version 5.0 was announced](https://news-web.php.net/php.announce/50).

With this [version](https://www.php.net/ChangeLog-5.php):

- OOP entered the language,
- we met PDO,
- error handling was improved,
- DOM and XML parsing were improved,
- MySQL support became built-in,
- some performance improvements were made.

I think this release brought very revolutionary features to the language for its time, but it still fell behind the spirit-of-the-age features and developer-friendly touches that frameworks like [Ruby On Rails](https://rubyonrails.org/2005/10/19/rails-1-0-the-release-candidate-2), announced in the same period, brought.

Within the next few years, the "PHP is dead" myth started to get thrown around.

Because from those years up to the 2010s, many languages and frameworks grew in popularity and pulled a lot of php developers toward themselves. Frameworks like [Python Django](https://www.djangoproject.com/) started winking at the web world, [NodeJS](https://nodejs.org/en) showed up and made the rules of the game get rewritten, [Ruby On Rails](https://rubyonrails.org/) kept gaining popularity.

Alongside these:

Even though PHP's reach kept growing thanks to being used in many open-source projects, it carried this image for a long time , old versions having to be supported, insecure products appearing because of bad coding habits. On top of that, the maintenance and update cost of old code growing and getting harder, PHP's own pace of development dropping, and even its 6th version never being released and getting shelved , these were all factors in the language losing its popularity, I'd say. (yes, me, personally, included)

I think PHP took a big step to save the situation between version 5.2 and 5.4 but it wasn't enough, and with [version 7, released in 2015](https://www.php.net/releases/7_0_0.php), bigger overhauls cleared away most of the language problems I listed above.

By then, riding the hype train, the other languages and frameworks I mentioned were already well into their golden age. At the software house I ran back then, I had also started using languages like NodeJs and .Net beyond PHP, picking the tool for the need. You can also reach [my other piece from 2014](/tr/neden-laravel-kullanmiyorum) where I touched on the subject.

During PHP's path from version 5.4 up to 7.0, a lot of modern updates and renewals were made, and thanks to that the frameworks giving the language its strength started to develop and move forward. And with [composer](https://getcomposer.org/), released in 2012, an even bigger revolution took shape , we can say it brought order and structure to PHP :)

Right now PHP's version 8 line is being developed; you can watch the development from [https://github.com/php/php-src/commits/master/](https://github.com/php/php-src/commits/master/) and [https://www.php.net/releases/](https://www.php.net/releases/). _As I was writing this blog post, the last commit was 3 hours ago and some security improvements had been merged into the master branch._

After this short history and nostalgia tour, let's come to today.

## Is It Still Alive?

PHP today is still in use and, even if the frequency of use has dropped, it carries on as a language/platform where new projects are still produced. Its ecosystem develops along the way too, adapts itself simply to what we call "Modern Web Development", and moves forward. These updates can be criticized, and you can draw conclusions by comparing it with other languages and frameworks, but all of those conclusions and criticisms become useful only when they step outside a purely personal statement. For instance: say a developer who had trouble with PHP in 2014 may have moved to another language and framework , but if in 2024 they still say PHP is dead with their knowledge from back then, that is that person's own problem.

Those who know me know I'm not a zealot for any one language, because I think acting in a work- and result-oriented way matters. The point isn't languages; the point is whether claims are made with arguments or without. By the death definition I made at the start, **I can say PHP is not dead**. As with every other topic in this blog, I chose to write my own opinion and my arguments in this post.

## How Much Longer Will It Live?

Instead of giving a rote answer to this, it will be more correct to answer according to the changing age and its needs.

For example, if I answer by taking some of today's needs:

- More and more applications now require heavy processing for users; seeing this, PHP added the JIT after version 8.0 and became more performant thanks to the advantage it brings. \[[1](https://php.watch/versions/8.0/JIT#:~:text=Just%2DIn%2DTime%20compilation%20is,virtual%20machine%20\(Zend%20VM\).)\]\[[2](https://wiki.php.net/rfc/jit)\]
- As the importance of data and types grows by the day, PHP again added many new language features to version 8.0; [union types](https://php.watch/versions/8.0/union-types), [named arguments](https://stitcher.io/blog/php-8-named-arguments), [match expression](https://www.php.net/manual/en/control-structures.match.php), [attributes](https://www.php.net/manual/en/language.attributes.overview.php) , and started giving us developers more flexible and powerful support for writing code.
- With the standardization that formed through frameworks like [Symfony](https://symfony.com/) and [Laravel](https://laravel.com/), teams started building applications faster and stronger,
- For the real-time applications our age requires, tools like [Swoole](https://openswoole.com/), [ReactPHP](https://reactphp.org/), [frankenPHP](https://frankenphp.dev/) started producing high-performance results,
- I don't even feel the need to bring up things like Docker, since php adapted to it quickly,
- Tools like [wordpress](https://wordpress.org/) and [magento](https://about.magento.com/Magento-Commerce), which solve needs like blogs and e-commerce, are still being developed and used,
- PHP has no claim in artificial intelligence, so they don't push in that direction; so if your goal is AI, there's no need to insist on PHP , Python will do the job for you,
- Likewise, in things like systems programming, even though tools/frameworks like phar and phalcon showed some promise, they fell behind [GO](https://go.dev/), I'd say; so if your goal is to build high-performance system tools, you can prefer [GO](https://go.dev/).

When you take these points together, I can say PHP can live a good while longer.

In short, a language/framework does not **die** as long as it keeps striving to answer needs.

## Finally

This piece is not one that praises PHP; it is just a piece that takes up the subject of a language dying, specifically through PHP. I too have criticisms about PHP and the frameworks used in many of the projects I'm responsible for, but because I can't spread these personal matters into a general "PHP is dead", I wrote this post.

Thanks for reading.

> The Turkish version of this piece is [here](/tr/php-oldu-mu).

---

## Data Integrity in Distributed Systems and the Debezium Call
URL: https://aligundogdu.com/debezium-in-distributed-systems
Trying to keep several databases consistent, I hit polling, spaghetti code, and the dual write curse. The fix was to stop asking the database 'what changed' and listen to its log instead: CDC and Debezium.

## Many Places, One Truth

A distributed system, at its simplest, is parts in different places acting as if they were one network. You run search on MeiliSearch, but the real data sits in PostgreSQL. Your marketing tool runs on its own MySQL. Your website is in one database, your accounting in another. They all work together for the same product.

The trouble starts right there: all of these parts have to see the same truth. Data that changes in one has to change in the other, or a user updates something in one place and sees the old version in another. This piece is about the pain of keeping that consistent, and the fix I eventually settled on.

![Different databases and services working together as a single network in a distributed system](/images/blog/dagitik-sistemlerde-debezium/dagitik.webp)

## The Hard Ways to Stay Consistent

The first methods that come to mind for syncing databases usually dig you into a deeper hole.

**Polling.** Let a worker run on a schedule and go update the data. Sounds reasonable, but as the database grows these queries do full table scans and lock the CPU. It is never truly real time; the gap between the two only widens. And you cannot catch deleted rows, because a select cannot see the absence of a row. So you end up writing a second control layer just for that.

**Spaghetti code and coupling.** Burying the sync logic inside application code. Say you have a `UserService`, and when a user updates their profile you also need to update ElasticSearch. You add an ElasticSearch call inside the method. Now `UserService` does not just do user work; if ElasticSearch is slow the "Update" button is slow, if that service errors the button breaks. It did its own job fine, but the dependency you glued on took it hostage.

**The dual write curse.** The sneakiest enemy of distributed systems. You say "I write the user to the database, then right after I push an event to RabbitMQ." You are writing to two separate places with no guarantee both succeed. If the queue is down at that moment, the data stays in the database but the event never goes out, and when the queue comes back it has no idea about that record. Missing data, duplicate data, silent inconsistency.

![A broken connection between a database and a message queue, the risk of data falling out of sync](/images/blog/dagitik-sistemlerde-debezium/dualwrite.webp)

**Race conditions.** Thought to be rare, but in chained event sequences and async setups the order gets tangled. When more than two places update, one write lands on top of something that has not been created yet, and you get an error.

## The Fix: Stop Asking "What Changed?"

Underneath all of these is one wrong reflex: constantly asking the database "what changed in you?"

But the database already notes every operation somewhere. PostgreSQL calls it the WAL (Write Ahead Log), MySQL calls it the Binlog. Even if the database crashes, these logs bring it back. The fix is right there: without touching application code or loading the database with extra queries, listen to those logs directly. We call this Change Data Capture, CDC for short.

So who reads the logs? Parsing a raw log file is an engineering job on its own. This is where Debezium comes in. Debezium introduces itself to the database as a replica; the moment the engine writes "this row was added, that row was deleted" to the log, Debezium catches it, turns it into standard JSON, and drops it onto Apache Kafka. (A line I like, by the way: if you solve a problem with Kafka, congratulations, now you have two problems.)

What happens to the pain once you move to this architecture?

- **Dual write ends.** No more "write to the DB and push to the queue." You only write to the DB, and Debezium turns what was written into an event, reliably. This is the basis of the outbox pattern.
- **Polling ends.** No `SELECT *`, no extra load on the database. Reading the log is nearly free for it.
- **Hard delete is solved.** When you delete a row, the log gets "this ID was deleted"; Debezium catches that too and tells you "delete this from ElasticSearch as well."
- **Closest to real time.** Instead of a cron job's five-minute delay, you catch changes in milliseconds.

## How the Flow Works

A simple flow to picture it:

- The **application** just sends `INSERT INTO users...` to PostgreSQL and is done.
- **PostgreSQL** writes the data to disk and records it in the WAL.
- **Debezium** sees that change in the WAL instantly.
- **Kafka** receives it from Debezium as a message.
- The **consumers** (ElasticSearch, cache, marketing tool) listen to that message and take the data.

So that complex orchestra starts playing in sync, taking its cues from a single conductor: the database logs.

![A one-way data path from a database log to a connector, then an event stream, then several consumers](/images/blog/dagitik-sistemlerde-debezium/flow.webp)

Here is where I have to be honest: there is no free lunch. Debezium is a great tool, but it brings Kafka to manage, schema changes to handle, and an operational cost. Writing a cron job is easier than running Kafka. But if data consistency in a scaling system is keeping you up at night, that cost is small next to sleeping well.

## There Is No Perfect Code, Only Manageable Chaos

Building a distributed system is not like clicking Lego together. In Lego the pieces are fixed; in software they keep moving, networks drop, servers sulk. What we call seniority is really the sum of the nights spent next to databases blowing up in production. The clearest thing I learned in there: there is no perfect code, only manageable chaos.

Debezium and CDC are the approach that makes that chaos manageable, pulling the sync work out of spaghetti code and tying it to a single source of truth. I wrote [elsewhere](/the-prototype-illusion) about how complexity quietly eats a product from the inside; the point here is the same: protecting simplicity with a method.

In my architecture calls, the priority was never just saving the day, it was sleeping well at night. Because good engineering is not only that the code runs, but that the people keeping it alive are at peace too. Healthy, consistent, commit-heavy days.

> The Turkish version of this piece is [here](/tr/dagitik-sistemlerde-debezium).

---

## Mattermost's 10,000 Message Limit and How I Moved to Matrix
URL: https://aligundogdu.com/mattermost-matrix-migration
One morning Mattermost put our team's memory behind a 10,000 message wall. I weighed the options honestly, moved to the Matrix protocol, and wrote my own tool for the migration.

## When the Castle Gate Closed

Two years ago, setting up the communication stack for an early-stage startup, we had two roads in front of us. One was the closed systems, paid per user in dollars, where the data sits in the cloud and out of your hands. The other was an open setup where we held all the strings ourselves.

When you run a startup in Turkey, cost is not a line item for savings; it is a survival question. [Mattermost](https://mattermost.com/), with its Community Edition back then, gave us exactly what we wanted: our own server, behind our own firewall, with us as the real owner of the data. Built on Go and React, deeply integrated with GitLab, loved by tech teams. For that day, it was the right call.

Then Mattermost quietly turned Community Edition into "Entry Edition" and put a [10,000 message limit](https://docs.mattermost.com/product-overview/editions-and-offerings.html) next to it. This is not a technical limit, it is an artificial barrier. Cutting a team off from its past messages is not just restricting a feature; it is locking that team's memory behind a paywall.

## Data Is Not Just Bytes

A company's data is more than the space it takes in a database. The tone of a message from two years ago, the logic of a decision made during a crisis, the post-mortem written after a failure. They add up to how the company thinks.

This is why I take the memory question seriously. In the heart of Anatolia, at Hattusa, the Hittites carved their victories and their famines alike into clay tablets, because what is not written down is forgotten, and what is forgotten gets repeated. What we call "company culture" today is those clay tablets moved into database rows. Cut off access to your past, and every decision about the future turns into a guess.

So here was my call to make: accept the limit and rent our memory month to month, or take the strings back into our own hands?

## Weighing the Options Honestly

We were leaving Mattermost, but for where? Every option had its own snag.

[Rocket.Chat](https://www.rocket.chat/) looks strong but can get heavy architecturally, and it carries the same potential to push enterprise features like LDAP behind a tighter paywall later. The risk of watching the same film again. Zulip's topic-based model is great, but the limits on mobile push notifications and the technical cost of self-hosting mean other bottlenecks down the road for a fast-moving team.

It would not be honest to ignore Discord either. If I scored only on user experience and stability, it would beat everyone on the list. But a technology lead's desk does not say only "ease of use"; "sustainability" and "legal ground" take up as much room as code quality. If you run a startup in Turkey, Discord is not a safe harbor: access blocks, data kept in a closed box and outside the country. Waking up to find your main channel shut by a court order is not risk management, it is your operation simply stopping. I could not leave one uncertainty only to take shelter in another.

## A Protocol, Not Software

[Matrix](https://matrix.org/) and its reference server [Synapse](https://github.com/element-hq/synapse) came onto my radar. You have to see Matrix as a protocol, not a piece of software. The way email is not owned by a single company, the way you can mail from Gmail to Outlook, Matrix promises that same open ground for messaging.

Let me be honest: I do not cling to Matrix blindly either. Today Element carries most of the ecosystem, and one day they could take the same road Mattermost did. But the decentralized nature of the protocol is an insurance policy. If one server tries to restrict me, moving the data to another server or standing up my own is far easier than escaping a closed system. I have seen enough storms to learn not to fully trust anything in tech. For now, this is the freest option I have.

## When the Market Won't Hand You a Key

The decision was made, but when I looked at the existing bridge tools I found a clumsy setup. Most arrive with configurations that wear you out at install time, and they cannot resume from where they stopped after an error. Manual transfers between servers, half-finished migrations. And a half-migrated archive with broken metadata is, in practice, an archive that never existed.

This is where the maker in me took over. What I needed was a tool that let me run the whole process from my own machine instead of wrestling with remote servers. I could not find it, so I wrote it, [letting AI speed up](/ai-is-not-a-cheat-code) the plan I already had in my head. That is how [MatrixMigrate](https://github.com/aligundogdu/matrixmigrate) was born.

The tool is still growing. To get a clean start, I set up and delete Synapse dozens of times, chasing the question "where could this break?" every round. Because if I do not lay the foundation of the migration well, I will fight the same memory problem on Matrix tomorrow. The aim is not to throw data from one place to another, but to build a transfer path that checks itself step by step and keeps the error margin small.

## Ownership Is Not Paying the Bill

This process showed me again that in tech, ownership is not something you get by paying the bill. Ownership is the control you hold over your data. A few things I wrote down for myself:

- **Memory cannot be a bargaining chip.** A team's past should not be held hostage for a price increase.
- **Ownership comes from the protocol.** Trusting a protocol rather than a single piece of software is the first step toward independence.
- **If the market won't hand you a key, you forge it yourself.** What looks "impossible" is often just code that has not been written yet.

Mattermost's business model pushed us into this move today; similar winds may blow on the Matrix side tomorrow. But a technology lead's real job is not which harbor the ship docks at, it is keeping the cargo, the company's memory, safe. For now, we are building our own bridge and walking, with our memory on our shoulders, onto freer ground.

> The Turkish version of this piece is [here](/tr/mattermost-matrix-tasinma).

---

## The Prototype Illusion and the Vasa Syndrome
URL: https://aligundogdu.com/the-prototype-illusion
Why a working prototype is not a product: the vitamin versus painkiller test, design over-engineering, and when to hold or cross the line on demands.

## The Ship That Could Not Float

In August 1628, the Stockholm harbor was a stage. By the order of King Gustavus Adolphus of Sweden, the warship [Vasa](https://en.wikipedia.org/wiki/Vasa_(ship)) slid into the water in front of a great crowd. It was the engineering marvel of its age. The King had demanded firepower no ship had carried before and pushed his engineers to add an extra deck of cannons. Power alone was not enough either. The ship had to carry the glory of an empire, so its hull was loaded with hundreds of carved wooden statues, gold leaf, and heavy ornament.

Thirteen hundred meters out of the harbor, a light breeze tilted the ship to one side. Those mighty cannons, those dazzling sculptures, that perfect design had thrown the balance off so badly that Vasa sank within minutes.

The engineers had met every one of the King's demands. More features, more magnificence. On paper, everything was spectacular. They had forgotten one thing only: the ship needed to float.

Today, in technology, hundreds of Vasas slide into the water every single day.

We tend to celebrate code that compiles, tests that turn green, and pixels lined up to perfection. Yet after years spent inside the kitchen, one truth keeps returning to me. **Even the most flawless algorithm, if it does not ease a human pain, is just noise that warms up the processor.** What Vasa's carved statues were, the clean architecture of an app nobody opens is exactly that.

So let me have a plain conversation with you about why those flawless worlds we build at our desks shatter the moment they hit the dust of the street. Why do ideas we call "perfectly logical" fail to become products? The Anatolian poet Yunus Emre said that real knowledge is knowing yourself. In our world, knowing yourself means knowing who your code serves, what pain it touches, and which business value it carries.

## Alchemy in the Kitchen and the Prototype Illusion

A product usually begins in a quiet, sterile laboratory. Research and development is a playground for technical people. No cost pressure, no customer complaints, only possibilities.

This stage is an intellectual tour around a problem. As the book Pürüzlü Mükemmellik, or Rough Perfection, puts it, sometimes you have to slow down in order to speed up. The deep research done here is the foundation that saves you from crushing technical debt later. But a danger waits right here too, and its name is kitchen blindness.

There is a mountain between a chef tuning a sauce to his own taste and that same dish served to five hundred people in a dining hall. As developers, we fall in love with the technology itself. The sentence "this database handles a million transactions per millisecond" thrills us. The real question is quieter: does our user need a million transactions?

What we hold at the end of this process is a prototype. You press a button, complex things happen in the dark, and a result lands on the screen. This is the moment the technical team cheers. Yet a prototype is a beautiful ghost that has no soul yet.

The sharp observation by Jason Fried and DHH, the authors of [Rework](https://www.amazon.com/Rework-Jason-Fried/dp/0307463745), belongs here: prototypes are ideas in their rawest form. A prototype that works is not a product. A prototype is proof of a technical hypothesis. A product is a commercial and human contract. I would split the two like this:

- **Prototype:** "Look, this technology works."
- **Product:** "Look, this technology improves your life, and it is worth your money and your time."

Anything with no customer waiting for it, no pain to soothe, seen only as a technical challenge, never moves past the prototype stage. Use the most advanced AI models in the world if you like. If you create no concrete value in the life of the person who uses that model, what you have built is an expensive hobby. I have argued [elsewhere](/ai-is-not-a-cheat-code) that AI is not a cheat code but power steering, a force multiplier in the hands of someone who already knows where the car is going. The point holds here too. The tool can be as strong as you want, but the hand on the wheel has to know the destination.

## The Graveyard of Rational Ideas

The biggest handicap of the engineering mind is treating the world like a clean equation. For us, it has to be A plus B equals C.

- **Premise:** People struggle to track their invoices.
- **Solution:** I built a perfect invoice tracking system.
- **Expectation:** Everyone will use it.

Real life does not run on that arithmetic. People are not machines that make logical choices. They act on habit, on fear, on emotion.

A logical idea is not a sellable idea. There is a question we ask often: is your product a vitamin or a painkiller?

- **Vitamin:** Good if you take it, healthy in the long run, but life goes on if you forget. A reporting tool with slightly deeper analysis.
- **Painkiller:** When your head is splitting, you hunt for an open pharmacy at midnight. A system that turns the cash flow back on when it stops.

Most of the ideas that feel logical to us are vitamins in pretty packaging. To leave their comfort zone and learn something new, customers need more than a logical reason. They need a burning one.

The Rework philosophy says scratch your own itch. The best products rarely come out of market research reports. They come from a founder solving a problem they live with. But there is a fine line. The spot where you itch may not matter to anyone else. Falling in love with your own idea is the costliest mistake a leader can make. When you validate that idea, you have to be ruthless.

## Design or Function

We all know the quiet war that never ends in software. On one side, the backend with the pride of being the engine that does the work. On the other, the design team with the insistence of being the face that meets the user.

This fight usually happens on the wrong ground. "How beautiful should the design be?" is the wrong question. The right one is this: how does design clear a path for function without standing in front of it?

The over-engineering trap we fall into while writing code has a twin in design. A design without function is an empty box. A function without design is a treasure no one can use. The balance lives in pragmatism, not in either extreme.

If you build a corporate product, you have to understand your user's psychology. That person is not opening the software for pleasure. They open it to get through the shift. Their need is not wow-effect animations, shadowed buttons, or icons that look like artwork. Their need is clarity. Is the button where it should be? Is the error message readable? Is the data table legible? In a corporate product, design exists to reduce cognitive load. Every extra effort poured into it past that point only makes the product clumsy. A clean, decent design that meets the standard is perfection itself here. Anything more is waste.

For consumer products the texture is different, but the core logic holds: do not wait for perfect. The design has to be professional enough to earn trust. But crafting every screen pixel by pixel is a slow suicide that delays your time to market. The strategy is an acceptable start. The product goes to the field, and you watch the reflexes. Which menu are users trying to click? Which color pulls their eye? Where does the flow get stuck? Design evolves at the user's fingertips, not at your desk. As Pürüzlü Mükemmellik puts it, life is rough, and sterile lab designs rarely survive the chaos of the real world.

Remember, Vasa had a magnificent design too, and it could not float. The goal is not a painting for a museum wall. It is a ship that crosses the ocean.

## Mental Eclipses

The architectures drawn on whiteboards in air-conditioned rooms are always wonderful. Everything is modular, everything scales. If this happens, that kicks in. If traffic spikes, servers multiply on their own. Then you go down to the field, put the product in front of real users, and the mental eclipses begin.

I want to repeat that striking line from Rework: planning is guessing. Drawing one-year and two-year roadmaps in technology is not far from fortune-telling. Nobody knows where the market, the technology, or the competition will sit six months from now. We keep making the same mistake, "let us finish the product and then launch." A product never finishes. It is not a statue to carve and set aside. It is a garden, and it asks for constant pruning, care, and attention.

The hardest strategic problem I meet in the teams I lead is this: trying to stretch one customer's special request across all customers. A customer says, "when I pull a report, make the rows red and sort the data in reverse." For a developer, coding that is fifteen minutes. Slipping into "sure, we'll handle it" mode is easy. For the product manager and the technical lead, it is the start of a nightmare. The questions pile up. Will this be open only to this customer? Or do we bolt a whole "Report Customization Module" onto the system?

This is where teams drown. While saying "let us please everyone, let us be flexible," they build a Frankenstein. Undefined, leaking settings from every seam, impossible to use. Structures designed for flexibility at the desk show up as complexity in the field. And complexity is the greatest enemy of software.

A real technology leader is not the one who says "we can do this." It is the one who can say "we should not do this, because it betrays the spirit and the simplicity of the product." The difficulty is not in writing the code. It is in deciding what not to write.

## The Product Lifecycle

You took the product live. Congratulations, the real trouble starts now. Let me borrow a line from Rumi: yesterday is gone, and everything said belongs to yesterday. Today calls for new words.

A live product is a living organism. It grows, it gets hungry and eats your servers and resources, it gets sick with bugs, and it wants attention in the form of support. In this cycle, the most critical thing is your stance toward customer demands.

The famous line attributed to Henry Ford, "if I had asked people what they wanted, they would have said faster horses," is almost a constitution for product management. I know Ford never actually said it, but using it in a piece like this has a flavor of its own.

A customer is always right about the problem and usually wrong about the proposed solution. When a customer says "give me an export to Excel button," what they really mean is, "I cannot analyze my data inside your interface, so I want to flee to the harbor I trust." Your job is not to add that button, which is the easy road. It is to strengthen the analysis the product offers. There is a canyon between doing what the customer says and solving what the customer suffers from.

So what do you do when your product vision collides with what customers ask for?

Sometimes you hold the line. You stay stubborn about your core value proposition. If you promised simplicity, you do not complicate the product because five percent of users want it. Saying no is a muscle that grows with use. You do not wreck the experience of ninety-nine percent for the one percent.

Sometimes you cross the line on purpose. If the market has shifted at its foundation, stubbornness becomes foolishness. If the AI wave turned a feature that was indispensable yesterday into dead weight today, do not be afraid to throw it away. Follow the business value, even at the cost of burning your own technical foundation.

## Do Not Fear the Burning

Working on projects that touched different geographies taught me one thing. Building a product is not creating an engineering marvel. Building a product is melting human psychology, commerce, aesthetics, and engineering in the same pot.

Your smooth plans at the desk will break in the field. The service you swore would never crash will go silent in the most important demo. The interface you labored over for days will strike a customer as too complicated. Your most logical idea will lose to the irrationality of the market. All of it is part of the process, part of that rough perfection. As the poet Nazim Hikmet wrote, if I do not burn, if you do not burn, if we do not burn, how will the darkness ever turn to light?

To find the right product, you have to risk burning inside the code, making mistakes, tearing prototypes down and building them again. Always with a single aim: not a technical success, but a value that lives in real hands and real workflows out in the field. I have written about the messy, rewarding work of [actually shipping one such product](/building-a-desktop-app-with-wails) end to end.

The leaders of the future will not be the ones who only know code. They will be the ones who can manage the fine line where code touches the human. Will your ship be a Vasa, ornate and fragile, or a vessel that holds against the storm and carries its crew to the far shore? The choice hides not in the first line of code you write, but in the first dream you build. The Turkish version of this piece lives [here](/tr/prototip-olumcul-vadi).

---

## AI Is Not a Cheat Code, It's the New Power Steering
URL: https://aligundogdu.com/ai-is-not-a-cheat-code
Every time a new tool arrived, someone called it 'not real programming'. AI is in that seat now. But the point was never the tool, it is who holds the wheel.

## The "Real Programming" Debate Never Ended

Stay in this industry long enough and you see the same fight come back in new clothes. From the days I printed my first "input" to the screen with QBasic to today, chasing data consistency in distributed systems, one question never changes: what is real programming?

Once, if you did not know Assembly, you were not a developer. Then C arrived and the line became "if you do not command the operating system, you do not count." When IDEs grew and code completion entered our lives, some called it plain laziness. Today the same look has turned to AI and vibe coding. Many of my old-school colleagues are on the defensive, saying "ban it", "this is not real coding."

That defense will not stop the coming wave. Same as last time.

## Factory Chimneys

No point painting a rosy picture, let's be honest. AI changed the color of the competition. A textile factory once needed a worker at every sewing machine; automation replaced most of them with machines. A fully unmanned factory is still a utopia, but factories where ten operators do the work of a hundred are real.

Software is going through a similar break. Companies now want one person, with AI agents, to do the work a five-person team used to do. And they will get it. For a developer doing standard, easily replaceable work, the risk of being out of a job is a plain reality in front of us. Clawing out every line by hand will not be the life raft that saves you here; the stubbornness may slow you down enough to get you cut.

## What Really Matters: Who Holds the Wheel

But there is a fine and vital line here. However good vibe coding is today, it is not a magic wand. In complex, many-layered architectures especially, the hacky moves a senior reaches for to save the moment are something AI cannot yet pull off cleanly on its own.

For someone who does not know how to code, setting out with "I can build anything with AI" is a big illusion. They might ship a simple interface, sure. But once data consistency, scalability, and security enter the picture, they will most likely produce a system that works but is ready to blow under the hood.

> A small note: I am reading this as of today. By the time this is published, much better models may come out and make this paragraph wrong. Fine. I am still speaking from today.

Vibe coding does not turn someone who does not understand the work into a master. For a developer who does understand it, with solid foundations, it is a huge force multiplier. If you know the architecture, AI becomes your best assistant. If you do not, it just helps you hit the wall faster. I lived this while building my [migration tool](/mattermost-matrix-migration): AI gave me speed, but the one who knew where to go was still me.

## Is Wearing Glasses Cheating

Is it cheating for someone with bad eyesight to wear glasses, or is it a tool that lets their real ability show?

Here is a more mechanical example. Driving a truck used to take muscle. When power steering arrived, driving did not die; the need for muscle just dropped. But a softer wheel does not mean someone without a license can take that truck down a mountain road. AI is our power steering today: it tires the skilled driver less, and it sends the novice off the road.

There is also time. The most abundant resource used to be time; people could carve stone for years and bring out something lasting. Today it is the scarcest thing we have. Every minute you delay shipping your idea, someone on the other side of the world may be building the same one. That is AI's real promise: what it gives back is time.

## A Prediction: More Developers, Not Fewer

Above, I said standard, repetitive work will get automated. But unlike most people, I do not conclude from that "AI will take developers' jobs." What I see is not job loss, it is a shift in the role.

As AI makes building software cheaper, more software gets built. Thousands of small tools, internal systems, and automations that were never worth the cost suddenly make sense. Demand does not shrink, it widens. And someone has to hold the wheel on that work. So my prediction is not a gradual decrease but an increase: the need for developers who write fewer lines but give more direction, verify more, and hold the system together will keep growing.

There are a couple of places I have to be honest. The first is the cost of AI itself. Where the price of running it, the compute, tokens, and licenses, goes, who pays it, how pricing finally settles, that part is still foggy. Maybe it gets cheap and reaches everyone, maybe it stays expensive in the hands of a few giants.

The second, and we talk about it less: as the cost of producing software drops, where do developer salaries go? I can pull this both ways. On one side, as building gets cheaper more work appears, and demand for people who truly understand the work rises, which pushes pay up. On the other, the "AI already does it, you just manage it" framing can feed pressure to get the same work for less. Maybe both happen at once: the value and pay of standard work fall, while the value and pay of the person who carries the system rise. A kind of polarization.

I will not pretend to know any of this. The one thing I see clearly is that demand for developers who understand the work will rise. But the economics of that work, both the cost of the tool and the price of the person, has not settled yet.

## Friend or Foe

I did not write this to romanticize "AI is your best friend, trust it." The truth is, AI may not be your friend. It might be a cold competitor that pushes you out of your comfort zone and eyes your job.

But I am sure of this: it is not your enemy either. It is just a force standing there. Handing all your work over to it is one choice; using it as a single station, an accelerator inside your development loop, is another. In my team I built the second kind. Stop wasting time being hostile to it. How you use it, where you turn the wheel, is your call. But that vehicle is sitting in the garage, and your competitors already turned the key.

> The Turkish version of this piece is [here](/tr/ai-vibecoding-hidrolik-direksiyon).

---

## Building a Desktop App with Wails in 2025
URL: https://aligundogdu.com/building-a-desktop-app-with-wails
Notes from shipping a cross-platform desktop application with Go and web tech.

## The Journey Starting with QBasic

I made and sold my very first application with [QBasic 4.5](https://dos.zone/qbasic-1991/).
Of course, it wasn’t a great business venture. A customer simply wanted me to take an input on the screen, run it
through a few formulas, and produce an output.
In its simplest form, it was no different from a programmable calculator. It was finished in no time, and I received a
fee that could barely be considered “pocket money.”

:::gallery
/images/blog/08/wails-notes/qbasic-png.png
:::
*QBasic interface.*

From that day on, interfaces prepared with DOS’s limited colors always caught my attention.

:::gallery
/images/blog/08/wails-notes/dosgui-2.png

/images/blog/08/wails-notes/dosgui-3.png

:::
*Typical business applications of the DOS era.*

:::gallery
/images/blog/08/wails-notes/dosgui-4.avif

/images/blog/08/wails-notes/dosgui-1.png
:::
*Typical business applications of the DOS era.*

Back then, the screens of ticket offices and accounting firms looked to me like amazing UX designs.
80 columns, 25 rows... but functional, fast, and easy to understand for the user.
And I can’t describe how happy I am today to see the revival of developments in the [TUI](https://github.com/topics/tui)
category.

---

## Windows and My First Desktop Experiences

MS-DOS gave way to Windows. Installed with stacks of floppy disks on simple processors, Windows took the computer world
to an entirely new place.

My first desktop application was written with **mIRC’s scripting language**.
Thinking about it now, it sounds silly, but because the learning curve was so easy, I actually developed a non-IRC app
with mIRC.
In theory, it was a simple class schedule tracking software. I even drew the buttons with Paint.

:::gallery

/images/blog/08/wails-notes/mirc-1.png

/images/blog/08/wails-notes/mirc-2.jpg
:::
*mIRC screenshots.*

---

## Visual Basic 6.0: Real Package Programs

Then I met Visual Basic 6.0.
For me, it was a great love. Was it one-sided, or did it love me back? I’m still not sure :)

:::gallery
/images/blog/08/wails-notes/visual-basic.jpeg
:::
*Visual Basic 6.0 IDE.*

The first real “package program” I ever wrote was with VB6.
At the time, I couldn’t put it into words, but the object and event-driven logic and the magical IDE environment deeply
impressed me.

For a while, I was like an “OCX miner,” spending my time testing every OCX file in the system directory.
Every new library felt like a new toy.

---

## The Search for Cross-Platform Independence

Over time, devices diversified: Windows, Linux, macOS…
Different systems started running in every home and workplace.

This increased the need for cross-platform applications.
The days of patching things up with simple OCX controls were behind us.
Toolkits came into play.

Then Web 2.0 arrived.
Efforts once spent on desktop applications slowly shifted to the web.
The rest, as they say, is history...

> Maybe I skipped some milestones in this timeline. After all, I’m an old man now :) Bear with me.

---

## [Electron](https://www.electronjs.org/): Beautiful But Heavy

Today, we still haven’t completely gotten rid of desktop applications, nor have we become fully dependent on them.
Cross-platform development remains a vital need.
And now, mobile apps are part of the equation too.

In recent years, **Electron** has addressed much of this need.

With JavaScript, Node.js, and TypeScript, I can handle many of my tasks.
The idea of developing a desktop app entirely with JS is very exciting.
But when it comes to practice, things change.

Especially when:

- Direct communication with OS APIs is needed,
- Small and optimized build outputs are targeted,

Electron can become frustrating.
Developing the UI with React or Vue is delightful, but for OS-level interaction, I started looking for easier solutions.

---

## [Tauri](https://v2.tauri.app/): Beautiful But Hard

This is when I came across **Tauri**.
Rust for the backend, any framework I want for the frontend.
And since it doesn’t embed Chrome, the build sizes are tiny.

But the Rust side was tough for me.
Wrestling with config files, struggling with the command structure...
Fun for Rust experts, not so much for me.
I eventually realized the tool meant to make my work easier was actually adding more burden.

---

## [Wails](https://wails.io/): The Solution I Was Looking For

And then came **Wails**...

### My List of Requirements

- Easy to adapt and start developing
- Easy cross-platform builds
- Small file size
- No surprises after compilation
- Built-in garbage collector
- No JS headaches for OS-specific solutions
- Ability to use my preferred frontend framework without extra adapters

### Electron vs Tauri vs Wails

| Feature                  | Electron                         | Tauri                    | Wails                    |
|--------------------------|----------------------------------|--------------------------|--------------------------|
| **Backend Language**     | Node.js                          | Rust                     | Go                       |
| **Frontend Flexibility** | React, Vue, Angular, Svelte etc. | React, Vue, Angular etc. | React, Vue, Angular etc. |
| **File Size**            | 150+ MB                          | 10-20 MB                 | 10-25 MB                 |
| **Performance**          | Heavy                            | Fast but requires Rust   | Fast and balanced        |
| **CORS Issues**          | Yes                              | No                       | No                       |
| **Learning Curve**       | Low                              | Steep                    | Medium (Go is easy)      |
| **OS API Access**        | Difficult                        | Strong but complex       | Simple and clean         |
| **Build Process**        | Heavy                            | Moderate                 | Fast and smooth          |

### Key Advantages of Wails

- **True cross-platform experience:** One command for Windows, macOS, and Linux builds.
- **Small file size:** Around 20 MB builds instead of Electron’s massive 150 MB packages.
- **Powerful Go backend:** Not as complicated as Rust. Concurrency, file I/O, and API integration are easy.
- **Direct OS API access:** Instead of CORS headaches, you just write a 5-line function in Go and call it from JS.
- **Frontend freedom:** React, Vue, Svelte, or Angular... use whatever you like directly.
- **Stable build process:** The “it worked on my machine but not on Windows” era is over.

### A Simple Scenario

Let’s say in an application you:

- Take a CSV file from the user,
- Parse and process it with the Go backend,
- Display it in a table with Vue,
- Simultaneously fetch data from an API without worrying about **CORS**.

With Electron: a 200 MB package and messy configs.
With Tauri: you need to learn Rust.
With Wails: thanks to Go’s simplicity, less code, less trouble.

---

## Conclusion

From that simple calculator I wrote with QBasic
to the cross-platform applications I build with Wails today...
The journey has been long, but the feeling remains the same: a computer making you achieve things way beyond your size.

And for me right now, that feeling has a name: **Wails**.

---


# Yazılar (Türkçe)

## PHP Ölmedi, Senin Baktığın Yer Ölmüş
URL: https://aligundogdu.com/tr/php-olmedi-baktigin-yer-olmus
Herkes PHP'yi gömerken arka planda trafiği taşıyan Symfony uygulaması hala çalışıyor. Dilin ölüp ölmediği değil, senin nereye baktığın mesele. Üretimden dürüst bir cevap.

## Birkaç Ayda Bir Duyduğum Cümle

Bir toplantıda, bir işe alım görüşmesinde ya da genç bir geliştiricinin ağzından, hafif bir acımayla aynı cümle geliyor: "PHP mi hala?"

O cümleyi kuran kişi genelde haklı olduğundan emin. Takip ettiği timeline'da PHP'yi kimse konuşmuyor, izlediği konferans sahnelerinde adı geçmiyor, o hafta çıkan hiçbir gösterişli araç onunla yazılmamış. Delil ona göre ortada, dil ölmüş.

İşin tuhaf tarafı şu: o cümleyi duyduğum günlerden birinde, arka planda benim için para kazanan, trafiği taşıyan, gecenin üçünde tek bir uyarı üretmeden çalışan şey de bir PHP uygulamasıydı. Bir [Symfony](https://symfony.com/) servisi. Sıkıcı, gösterişsiz, ortada. Kimsenin bahsetmediği ama faturayı ödeyen taraf orasıydı.

Bu yüzden "PHP öldü mü" sorusunu bir daha duyduğumda artık dili savunmaya geçmiyorum. Çünkü soru yanlış kurulmuş. Ölen bir şey varsa o dil değil, sana onun öldüğünü düşündüren yer.

## Ölen Dil Değil, Baktığın Sahne

Bir teknolojinin "canlı" olup olmadığına dair sezgimizi genelde üç yerden topluyoruz: sosyal medya akışı, konferans sahneleri ve yeni araçların etrafındaki heyecan. Üçü de gerçek yerler. Ama üçünün de ortak bir yanlılığı var, hepsi **yeniyi** ödüllendirir. Bir şeyin orada görünür olması için yeni, tartışmalı ya da parlak olması gerekir.

PHP bunların hiçbiri değil artık. Yeni değil, tartışmalı değil, parlak hiç değil. Otuz yaşında bir dil, üstelik gençken çok kötü alışkanlıklar edinmiş, imajını uzun süre sırtında taşımış bir dil. Böyle bir şeyin akışta yer bulması için ya rezalet bir güvenlik açığı vermesi ya birinin onu tekrar gömmeye kalkması lazım. İkisi de "canlılık" değil, sadece görünürlük.

Buradaki hata ince ama pahalı: sahnede görmediğin şeyi yok saymak. Oysa yazılımın büyük kısmı sahnede değil. Bankanın arka ofisinde, bir e-ticaret sitesinin sipariş kuyruğunda, bir belediyenin başvuru formunda, on yıldır çalışan ve çalışmaya devam etmesi beklenen kodda. O katman gürültü yapmaz. Gürültü yapmadığı için de "ölü" sanılır. Halbuki bir yazılım için en yüksek övgü, hakkında konuşulacak hiçbir şeyin olmamasıdır.

Timeline'ın sana anlattığı, teknolojinin nabzı değil, teknolojinin modası. İkisini karıştırınca, sessizce işini yapan her şeyi ölü ilan edersin.

## PHP Nerede Yaşıyor

Somut konuşalım, çünkü "canlı" demek kolay, göstermek zor.

PHP'nin geçmişini, 2005'ten bugüne nasıl adım adım toparlandığını daha önce bir [nostalji turunda](/tr/php-oldu-mu) yazmıştım, onu tekrar etmeyeceğim. Beni bugün ilgilendiren geçmiş değil, elimin altında ne olduğu.

Elimin altında olan şey şu: modern bir PHP projesi açtığımda karşılaştığım dil, o "PHP mi hala" diyen kişinin kafasındaki dil değil. Tipli, statik analizden geçen, düzgün bir bağımlılık yönetimi olan, hata verdiğinde nedenini söyleyen bir dil. Symfony gibi bir çatı, kodu benim için değil, ekip için standart hale getiriyor. Yeni gelen bir geliştirici projeye baktığında nereye ne koyacağını tahmin edebiliyor, çünkü herkes aynı yere koyuyor. Bu, tek başına dahi bir geliştiricinin marifetinden çok daha değerli.

Performans tarafında da o eski "PHP yavaş" cümlesi artık tembellik. Dil, 8.x serisinde JIT'i içine aldı, [FrankenPHP](https://frankenphp.dev/) gibi çalışma zamanları uygulamayı ayakta tutup her istekte sıfırdan doğmasını engelledi. Yani PHP'nin klasik "her istek temiz sayfa" modeli, isteyen için artık bir zorunluluk değil, bir tercih.

Ama beni asıl ikna eden bunların hiçbiri değil. Beni ikna eden, [kendi araçlarımdan birini](/tr/seodisias-hikayesi) ayakta tutarken ya da bir müşteri servisini yıllarca taşırken, dilin bana çıkardığı sürpriz sayısı. O sayı çok düşük. Sıkıcılığın en güzel tarafı bu, sürpriz üretmemesi. Bir dilin canlılığını ölçmek istiyorsan, etrafındaki heyecana değil, onu üretimde taşıyan insanların ne sıklıkla panik yaptığına bak.

## Nerede Kaybediyor, Dürüst Olalım

Buraya kadar okuyup "adam PHP fanatiği" diye düşünüyorsan, dur. Ben bir dilin müptelası değilim, iş ve sonuç odaklı çalışmayı severim. Bir aracı savunmak, onun her işe yaradığını iddia etmek değildir. Aksine, bir aracı gerçekten tanıyorsan nerede eline yatmadığını da bilirsin.

PHP'nin kaybettiği yerler net. Yapay zeka tarafında hiçbir iddiası yok, olması da gerekmiyor. Bir model eğitecek, veri hattı kuracaksan Python'a gidersin, ben de giderim, ısrar etmenin anlamı yok. Yüksek performanslı sistem araçları, tek dosya dağıtılan komut satırı programları, ciddi eşzamanlılık isteyen altyapı işleri istiyorsan Go çoktan o boşluğu doldurdu. Bunları PHP ile zorlamak, tornavidayla çivi çakmaya benzer, olur ama neden.

Dürüstlük burada yetkinlikten önce gelir. Bir şeyin her yerde en iyi olduğunu söyleyen biri ya bilmiyordur ya satıyordur. PHP, web uygulamalarının o geniş, sıkıcı, iş yapan ortasında hala çok iyi. Bu cümlenin "hala" kısmı bir zayıflık değil, otuz yıldır o ortada durabilmenin kanıtı. Ama o ortanın dışına çıktığın anda, PHP senin dilin değil. Bunu kabul etmek dili küçültmez, sana onu doğru yerde kullanma özgürlüğü verir.

Zaten [Laravel yerine neden Symfony tarafında durduğumu](/tr/neden-laravel-kullanmiyorum) yıllar önce yazarken de mesele dili yüceltmek değildi, hangi aracın hangi işe oturduğunu konuşmaktı. Bugün de aynı yerde duruyorum.

## Asıl Soru "Öldü mü" Değil

"Bir dil öldü mü" sorusu, cevaplaması kolay göründüğü için sevilir. Halbuki yanlış soru. Bir dil, geliştirilmesi tamamen durduğunda, yeni proje üretilmesi bittiğinde ölür. PHP'de ikisi de olmadı, bugün bile deposuna baktığında saatler önce atılmış bir commit görürsün. Yani teknik anlamda tartışma çoktan bitmiş.

Sorulması gereken şey daha kişisel: **bu araç, senin bugünkü ihtiyacına cevap veriyor mu?** Cevap işine göre değişir. Bir haber sitesi, bir üyelik sistemi, bir e-ticaret arka ucu, bir iç panel kuruyorsan cevap büyük ihtimalle evet. Gerçek zamanlı bir oyun sunucusu ya da bir makine öğrenmesi hattı kuruyorsan cevap hayır. İki durumda da dilin ölü olup olmaması seni ilgilendirmiyor, senin işine oturup oturmadığı ilgilendiriyor.

"PHP öldü" cümlesinin kendisi bunun en güzel kanıtı. O cümle on beş yıldır ölmüyor. Ölseydi, onu tekrar tekrar söylemeye gerek kalmazdı. Bir şeyi sürekli gömmen gerekiyorsa, o şey büyük ihtimalle sandığından daha canlıdır.

## Sahnedeki Işık ve Kuytudaki Priz

O "PHP mi hala" diyen kişiye artık uzun bir savunma yapmıyorum. Bir şey soruyorum sadece: bugün kullandığın bankanın, alışveriş yaptığın sitenin, doldurduğun formun arkasında ne dönüyor, gerçekten biliyor musun?

Sahnedeki ışık her zaman en yeni olanın üstünde. Ama evi ayakta tutan, sahnenin ışığı değil, kuytudaki prizdir. Priz gösterişsizdir, kimse fotoğrafını çekmez, hakkında konuşulmaz. Sadece çalışır. PHP, uzun zamandır o priz. Ve bir şeyi öldürmek için önce ona ihtiyacın olmaması gerekir. Baksana, hala ihtiyacın var.

---

## Çok Çalışmak İş Bitirmez: Zihnindeki Açık Hesaplar
URL: https://aligundogdu.com/tr/cok-calismak-is-bitirmez
Bitmemiş işler zihinde açık bir sekme gibi durur; sen çalışmasan da onlar çalışır. Çok çalışmak neden verimli çalışmak değildir, ve kafadaki yükü indirmek için işi bitirmek şart mı?

## Ödenene Kadar Kusursuz Bir Hafıza

Anlatıldığına göre hikaye bir kahvede başlar.

Psikolog [Kurt Lewin](https://en.wikipedia.org/wiki/Kurt_Lewin) ve öğrencileri, kalabalık bir masanın uzun uzadıya sipariş verişini izler. Garson hiçbir şey yazmaz. Onlarca kalemi, kimin ne istediğini, hangi kahvenin sütlü hangisinin sade olduğunu kusursuz aklında tutar ve eksiksiz getirir. Yemek biter, hesap ödenir, herkes kalkmak üzeredir. Öğrencilerden biri, biraz oyunbozanlık olsun diye garsonu geri çağırır ve az önce masada ne olduğunu sorar. Garson boş boş bakar. Birkaç dakika önce parmaklarının ucunda duran o koca liste, uçup gitmiştir.

Masadaki genç araştırmacılardan birinin adı [Bluma Zeigarnik](https://en.wikipedia.org/wiki/Bluma_Zeigarnik). O boş bakışı bir kusur değil, bir ipucu olarak görür. Neden garson, hesap açıkken her şeyi hatırlıyor da, ödendiği an unutuyor? 1927'de bu sezgiyi bir deneye çevirir. İnsanlara yirmiye yakın küçük iş verir; kimini bitirmelerine izin verir, kimini yarıda böler. Sonra hepsine hangi işleri yaptıklarını sorar. Sonuç nettir: denekler, yarıda kesilen işleri tamamladıklarına kıyasla yaklaşık iki kat daha iyi hatırlıyordu.

Bugün buna [Zeigarnik etkisi](https://en.wikipedia.org/wiki/Zeigarnik_effect) diyoruz. Bitmemiş bir iş, zihinde kapanmayan bir parantez gibi açık kalır. Küçük ama ısrarcı bir gerilim taşır ve o gerilim, iş kapanana kadar kafanın bir köşesinde çalışmaya devam eder. Garsonun sırrı iyi bir hafıza değildi; açık hesabın onu tutmasıydı. Hesap kapanınca parantez de kapandı, zihin bıraktı.

## Bu Yazı Aslında Garsonlar Hakkında Değil

Bu yazı hafıza deneyleri hakkında da değil. Akşam eve döndüğünde, gün boyu "aslında" pek somut bir şey bitirmediğin halde neden o kadar yorgun olduğun hakkında.

Kafamızda bir denklem taşırız, çoğu zaman farkında bile olmadan: çok çalışmak eşittir çok iş. Masada geçen saat ne kadar uzunsa o kadar üretken sayılırız; kendimizi de öyle sayarız. Oysa bu denklem, işin en ölçülebilir olduğu yerde bile tutmaz. İktisatçı [John Pencavel](https://en.wikipedia.org/wiki/John_Pencavel)'in fabrika verileri üzerine çalışması, haftalık mesai belli bir eşiği geçtikten sonra saat başına düşen üretimin hızla düştüğünü gösterir. Belli bir noktadan sonra fazladan oturulan saatler çıktıya neredeyse hiçbir şey eklemez; hatta yorgunluğun getirdiği hatalarla eksiltmeye başlar. Daha çok çalışmak, çoğu zaman daha çok iş çıkarmak değildir.

**Çok çalışmak çoğu zaman iş bitirmez; sadece zihnini daha çok işgal eder.**

Bunu anlamak için önce yorgunluğun nereden geldiğini yeniden düşünmek gerekiyor. Çünkü çoğu gün bizi tüketen şey, yaptığımız işler değil.

## Zihin Berbat Bir Depodur

Çalışma belleğimiz utanç verecek kadar küçüktür. Psikolog [George Miller](https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two) yıllar önce bu sınırı meşhur bir sayıyla, "yediye artı eksi iki" ile tarif etmişti; sonraki araştırmalar rakamı daha da aşağı çekti. Aynı anda zihinde canlı tutabildiğimiz şey bir avuçtan ibarettir. Geri kalan her şey, biz ona dönene kadar bir yerde asılı bekler.

İşte Zeigarnik'in gerilimi tam burada devreye girer. Bitmemiş her iş, zihinde açık bir sekme gibi durur ve arka planda sessizce enerji tüketir. Bir tanesi zararsızdır. Ama on beş sekme aynı anda açıkken, henüz hiçbirine dokunmamış olsan bile zihin bir uğultuya döner. Bir işten diğerine geçtiğinde, öncekinin bir kısmı da seninle gelir; araştırmacı Sophie Leroy buna "dikkat kalıntısı" adını verir. Yeni işin başındasındır ama kafanın bir köşesi hala bir öncekinde takılıdır. Gün boyu tek bir işi tam anlamıyla yapmadan, on işin kalıntısını birden taşırsın.

Yorgunluğun asıl kaynağı çoğu zaman budur: yaptığın iş değil, yapmadığın ama unutamadığın işler. Kaygının, akşamüstü çöken o açıklanamaz ağırlığın altında da genellikle aynı şey yatar. Tehlikede olan bir şey yoktur; sadece zihnin, kapanmamış onlarca parantezi aynı anda açık tutmaktan yorulmuştur.

## Peki Bu Sekmeler Nerede Birikir

Bir yere yazmadığın her iş, saklanacak tek yer olarak zihnini seçer.

Plansız çalışmak, not almadan ilerlemek kulağa özgür ve akışkan gelir. Gerçekte ise bütün envanteri kafanın içinde taşımak demektir. Zihin bu iş için berbat bir depodur: sürekli sızdırır, en olmadık anda "ya şunu da yapacaktın" diye dürter, gece yatağa uzandığında bütün listeyi baştan okumaya başlar. Plansızlığın bedeli, yapılmayan işler değildir çoğu zaman; yapılana kadar hiç susmayan o iç sestir.

Burada psikolojinin güzel bir bulgusu işleri değiştiriyor. Araştırmacılar E. J. Masicampo ve Roy Baumeister, Zeigarnik'in gerilimini dağıtmak için işi bitirmenin şart olmadığını gösterdi. Yarım kalan bir işe dair somut bir plan yapmak, yani onu ne zaman, nerede, nasıl yapacağına dair basit bir karar vermek, zihindeki o açık parantezi kapatmaya yetiyordu. İş hala yapılmamıştı; ama zihin, onun güvenilir bir yere emanet edildiğini anladığı an sıkı tutuşunu gevşetiyordu. Benzer şekilde, uyumadan önce ertesi günün yapılacaklarını kağıda dökenlerin daha çabuk uykuya daldığını gösteren çalışmalar var. Liste, uykuyu getiren şeydir; çünkü zihin nöbeti kağıda devredince rahatlar.

**Zihni boşaltan şey işi bitirmek değil, işe güvenilir bir yer bulmaktır.**

Garson da tam bunu yapıyordu. Hesabı hatırlaması, onu bir yere, açık adisyona bağladığı içindi. Adisyon kapanınca yükü de bıraktı. Bizim derdimiz, kafamızdaki adisyonların hiçbirinin gerçekten kapanmaması.

## Dürüst Olmam Gereken İki Yer

Buraya kadar yazdıklarım tek başına bırakılırsa yanıltıcı olur.

Birincisi: o gerilim tamamen kötü değil. Zeigarnik'in gördüğü o tutunma, aynı zamanda yarım kalan bir işe geri dönmeni, onu bitirmeni sağlayan şeydir. Hiçbir işin "çekmediği", tamamen boşalmış bir zihin de bir yere varamaz. Amaç gerilimi yok etmek değil, onu kafanın içinde değil, dışarıda bir yerde tutmak. Farkı yaratan, işin kaybolması değil, senin onu taşımayı bırakabilmen.

İkincisi, ve bu daha sinsi: planın kendisi bir kaçış haline gelebilir. Yapılacaklar listesini o kadar güzelleştirir, o kadar çoğaltırsın ki, liste yapmak işin yerine geçer. Üç renk kalemle çizilmiş kusursuz bir haftalık plan, tek satır gerçek iş çıkmadan da seni gün sonunda "çok çalıştım" hissiyle yorabilir. Plan, işi görünür kılmak için vardır; işin yerine geçtiği an amacından sapar. Bu yazı ne kadar not almanı savunuyorsa, notu bir törene çevirmene o kadar karşı.

## Ne Yapmalı Sorusuna Yuvarlak Bir Cevap

Buraya kesin bir reçete koymayacağım, çünkü yok. Sabah defter tutan biriyle gece sesli not bırakan biri aynı yöntemle rahatlamaz. Kimine tek bir düzenli sistem, kimine masaya saçılmış kağıtlar iyi gelir. Herkese uyan bir yöntem arıyorsan, aradığın şey yok; olsaydı hepimiz çoktan bulmuştuk.

Verilebilecek tek genel doğru, yöntemin kendisi değil, altında yatan mantık: kafandaki açık işleri güvendiğin bir yere boşalt, her birine "bitir" değil sadece "bir sonraki adım" ver, ve gerisini kendi ritmine bırak. Bir işi kafandan indirmek için onu bitirmen gerekmiyor; nereye, ne zaman döneceğini bilmen yetiyor.

Belki en fazla, ara sıra kendine sorabileceğin birkaç soru bırakabilirim. Şu an yorgun muyum, yoksa sadece çok sayıda kapanmamış işi aynı anda mı taşıyorum? Bu işi gerçekten yapmam mı gerekiyor, yoksa sadece unutmaktan mı korkuyorum? Ve günün sonunda: bugün ne bitirdim değil, kaç açık parantezi güvenli bir yere kapatabildim? Cevapları senin dışında kimse veremez; çünkü kendi zihninin neyi bıraktığında nefes aldığını bir tek sen bilirsin.

## Hesabı Kapatmak

Kahvedeki garson, listeyi ödendiği an unuttu. Onu unutkan yapan şey, aslında sağlıklı bir zihnin işaretiydi: kapanan bir hesabı bırakabilmek. Bizim sorunumuz kötü hafıza değil, tam tersi; hiçbir hesabın gerçekten kapanmaması, her şeyin sonsuza kadar açık adisyonda kalması.

Ama zihin bir işi "kapandı" saymak için mutlaka bitmesini beklemez. Nereye ve ne zaman döneceğini bildiğinde de bırakır. Gün sonunda seni yoran o koca listeyi bugün bitirmen gerekmiyor. Sadece, garsonun ödenmiş hesabı bıraktığı gibi, her birini kafandan indirip güvendiğin bir yere yazman yeterli.

Çok çalışmak bir erdem değil, bir ölçü de değil. Asıl mesele kaç saat oturduğun değil, kaç parantezi kapatabildiğin. Ve yorgunluk, çoğu zaman işten değil, bırakamamaktan gelir.

---

## Production Masaüstü Ürünü İçin En Mantıklı Seçim Hala Wails, İşte Tabloların Yazmadığı İncelikleri
URL: https://aligundogdu.com/tr/wails-incelikleri
Seodisias'ı Wails ile yazdım, production'da ve üç işletim sisteminde çalışıyor; bugün baştan başlasam yine Wails derdim. Bu yazı o güvenin gerekçesi: köprünün doğru kullanımı, imza zinciri, webview farkları ve tek Mac'ten üç platforma build almak.

## Karşılaştırma Tablosu En Kolay Kısımdı

Wails'e neden geçtiğimi [ayrı bir yazıda](/tr/wails-notlarim) anlatmıştım. Electron ağır geldi, Tauri'nin Rust tarafı beni yordu, Wails ise Go'nun sadeliğiyle tam aradığım denge oldu. O yazının sonunda bir tablo var: dosya boyutu 20 MB, öğrenme eğrisi orta, build süreci sorunsuz. Hepsi doğru. Ama bugün dönüp baksam, o tablo aslında işin en kolay kısmıydı.

Çünkü bir aracı seçmek başka, onunla gerçek bir ürün göndermek başka. [Seodisias'ı](/tr/seodisias-hikayesi) Wails ile yazdım ve o süreç bana şunu öğretti: internetteki her "Electron vs Tauri vs Wails" yazısı ilk beş dakikayı anlatıyor. `wails init`, `wails dev`, ekranda bir pencere. O beş dakika büyülü, evet. Ama o pencereyi başka birinin bilgisayarında sorunsuz açtırmak altı ay sürdü. Bu yazı o altı ayın notları. Tabloda görünmeyen kısım.

Baştan da söyleyeyim: bu bir vazgeçirme yazısı değil, tam tersi. Wails'le production'a çıktım, ürünüm her gün üç işletim sisteminde çalışıyor ve bugün baştan başlasam yine Wails derdim. Production için masaüstü ürün geliştirecek birine gönül rahatlığıyla öneriyorum. Aşağıdakiler pişmanlık listesi değil; o karara giderken kimsenin bana anlatmadığı, öğrenince işin keyfine dönüşen incelikler.

## Köprü Demoda Temiz, Yükte Çöküyor

Wails'in en çok pazarlanan özelliği Go ile frontend arasındaki köprü. Go'da bir fonksiyon yazıyorsun, JavaScript'ten sanki yerel bir fonksiyonmuş gibi çağırıyorsun. Demoda büyüleyici. `GetUser()` yaz, arayüzden çağır, kullanıcı gelsin. Beş satır.

Sorun şu ki gerçek uygulamalar `GetUser` çağırmıyor. Seodisias bir crawler; tek bir taramada binlerce satır veri üretiyor. Ben de acemi refleksiyle ne yaptım: taramayı Go'da bitir, sonucun tamamını tek seferde arayüze döndür. Köprü zaten bunun için var, değil mi?

Değil. O binlerce satırı köprüden geçirmek demek, hepsini JSON'a serialize etmek, webview'e taşımak, orada tekrar parse etmek demek. Birkaç yüz satırda fark etmiyorsun. Birkaç bin satırda uygulama donuyor. Kullanıcı "çöktü mü acaba" diye pencereyi kapatmaya hazırlanıyor.

Dersin özü basit ama görmesi zaman aldı: **köprü bir veri hattı değil, bir kontrol hattı.** Ona "şu işi başlat", "şunu iptal et", "durum ne" dedirteceksin; içinden kamyon kamyon veri geçirmeyeceksin. Çözüm iki taraflı oldu. Go tarafında tarama artık sonucu biriktirip toptan dönmüyor; ilerledikçe `runtime.EventsEmit` ile arayüze olay yayıyor. Frontend bu olayları dinliyor, veriyi parça parça alıyor. Ekranda da her şeyi bir anda basmak yerine sanal kaydırma var; sadece görünen satırlar render ediliyor, gerisi bellekte bekliyor. Aynı problemi [Seodisias'ın hikayesinde](/tr/seodisias-hikayesi) kısaca anmıştım; işte teknik karşılığı bu.

## Her Şey Asenkron, Ve Bunu Kabul Etmelisin

Köprüdeki ikinci incelik daha sinsi. Go'da yazdığın bound fonksiyon, JavaScript tarafında senkron görünse de aslında bir Promise dönüyor. Yani `await` etmen gerekiyor, etmezsen elinde bir veri değil, bir söz kalıyor.

Bu kulağa küçük geliyor ama mimariyi baştan etkiliyor. Uzun süren bir işi, mesela yarım dakikalık bir taramayı düşün. Onu `await` edip beklersen arayüz o süre boyunca hiçbir şey söyleyemez. Kullanıcıya bir ilerleme çubuğu, bir "342 sayfa tarandı" sayacı göstermek istiyorsan, işi başlatan çağrı ile ilerlemeyi bildiren kanalı ayırmak zorundasın. Ben burada da olaylara döndüm: taramayı başlatan fonksiyon hemen dönüyor, ilerleme ayrı bir olay akışından geliyor.

Bir de iptal meselesi var ki bunu hiçbir başlangıç rehberi anlatmıyor. Kullanıcı bir taramayı başlattı, yarısında vazgeçti. O goroutine hala çalışıyor, hala istek atıyor. Onu nasıl durduracaksın? Cevap Go'nun kendi içinde: `context.Context`. Uygulama açılışında gelen context'i taramaya taşıyorsun, iptal düğmesi bu context'i cancel ediyor, çalışan goroutine bunu görüp temiz kapanıyor. Wails sana bu context'i veriyor, ama onunla ne yapacağın sana kalmış. Kimse söylemiyor, sonradan öğreniyorsun.

## Wails "Chrome Gömmüyor" Diyor, Bu İyi Haber Değil Sadece

Electron'un 150 MB'ı nereden geliyor? İçine bütün bir Chromium gömdüğü için. Wails bunu yapmıyor, işletim sisteminin kendi webview'ini kullanıyor. Boyut avantajının kaynağı bu. Herkes bunu bir zafer olarak yazıyor.

Yazmayan kısım şu: bu, uygulamanın her işletim sisteminde **farklı bir tarayıcıyla** çalıştığı anlamına geliyor. Windows'ta WebView2, yani Edge motoru. macOS'ta WebKit, yani Safari'nin motoru. Linux'ta WebKitGTK. Üçü de aynı HTML'i aynı gösterir sanıyorsun; göstermiyor.

Ben bunu en beklemediğim yerde yedim: fontlar. macOS'ta tertemiz duran arayüz, Windows'ta bir tık farklı hizalanıyordu; bir yerde satır kayıyor, bir yerde ikon metne yapışıyordu. Tarih seçici, kaydırma davranışı, bazı CSS özelliklerinin desteği webview'den webview'e değişiyor. "Bende çalışıyordu ama Windows'ta açılmadı" cümlesinin Electron'la öldüğünü sanıyordum. Ölmedi, sadece kılık değiştirdi: artık backend'de değil, CSS'te ve webview farklarında yaşıyor.

Buradan çıkardığım kural: geliştirmeyi tek işletim sisteminde yapıp "nasılsa hepsinde aynıdır" dememek. Ben Mac'te geliştiriyordum ama Windows'ta düzenli test etmeden hiçbir arayüzü bitmiş saymadım. Bu, Wails'in gizli vergisi. Boyuttan kazandığını test yükünde bir miktar geri ödüyorsun.

## Asıl Ölümcül Vadi: İmza

Şimdiye kadar anlattıklarım kod problemleri. Çözülüyor, keyifli bile. Ama üretimle prototip arasındaki [o ölümcül vadiyi](/tr/prototip-olumcul-vadi) burada bir kez daha geçtim ve beni en çok yıpratan kısım kod değildi.

Uygulamayı derledim, çalışıyor, güzel. Bir arkadaşıma "şunu indir bir dene" dedim. macOS uygulamayı açmayı reddetti: "hasarlı, çöp kutusuna taşımak ister misiniz." Hasarlı falan değildi. İmzasızdı. Gatekeeper imzasız ve notarize edilmemiş her uygulamaya bu muameleyi yapıyor. Kullanıcının uygulamayı açması için terminalden komut girmesi ya da ayarlarla boğuşması gerekiyor. Kimse bunu yapmaz. Ben yapmazdım.

Bu vadinin adımlarını saymak kolay, geçmek değil. macOS tarafında bir Apple Developer hesabı, bir Developer ID sertifikası, uygulamayı imzalamak, sonra Apple'ın sunucusuna gönderip notarize ettirmek. Windows tarafında ayrı bir hikaye: imzalamazsan SmartScreen kullanıcıya "bilinmeyen yayıncı, bu uygulama bilgisayarınıza zarar verebilir" diye kırmızı bir ekran gösteriyor. Onu geçmek için bir code signing sertifikası, ve o sertifikanın maliyeti ve kurulum derdi. Üstüne Windows'ta WebView2 çalışma zamanının kullanıcıda kurulu olmasını garantilemek gibi ayrı bir başlık.

Bunların hiçbiri Wails'in suçu değil, işletim sistemlerinin güvenlik politikası. Ama Wails yazıları bundan hiç bahsetmiyor. "20 MB build, tek komut" diyorlar, o 20 MB'lık dosyanın kullanıcının makinesinde açılabilmesi için haftalarca uğraşacağını yazmıyorlar. Dürüst olayım: Seodisias'ın altı ayının belki iki ayı kodla, geri kalanı bu tür "gönderilebilirlik" işleriyle geçti. Kodun bittiği yer, ürünün bittiği yer değil.

## Build Tek Komut, ve Üç Platformu Tek Mac'ten Çıkarıyorum

`wails build` gerçekten tek komut, doğru. Ve burada Wails'in hakkını teslim etmek gerekiyor: bugün üç platformun build'ini de tek makineden, Mac'imden çıkarıyorum. Windows build'ini doğrudan Mac'ten cross-compile ile alıyorum; Go'nun cross-compile rahatlığı Wails'te büyük oranda korunmuş. Linux tarafı biraz daha nazlı, çünkü işin içine WebKitGTK gibi sistem bağımlılıkları giriyor; onu da Docker'la çözdüm: Linux imajında build alan bir konteyner, o da tek komut. Yani "her platform için ayrı makine parkı kur" derdi yok; bir Mac ve bir Docker, üç işletim sistemi.

Asıl vakit yiyen kısım build değil, az önce anlattığım imza zinciri; o platform başına ayrı yürüyor. Benim buradan çıkardığım somut tavsiye şu: release ritüelini ilk fırsatta scriptleştir. Ben build, paketleme ve imza adımlarını tek bir akışa bağladım; "yeni sürüm çıkarayım" düşüncesi bir öğleden sonra projesi olmaktan çıkıp on dakikalık bir ritüele döndü. Elle yaptığın her sürüm, seni bir sonraki sürümü çıkarmaktan soğutur; scriptleşen sürüm ise çıkarma isteği uyandırır.

## Go Tarafı: Wails Değil, Disiplin

Bir de Wails'in doğrudan sorumlu olmadığı ama masaüstünde canını yakan bir alan var: eş zamanlılık. Crawler yüzlerce isteği paralel yönetiyor. Go'nun goroutine modeli bu iş için biçilmiş kaftan, ama biçilmiş kaftan da ölçü ister. İlk denememde beş yüz goroutine aynı anda salıverdim; karşı sunucu rate limit'e takıldı, bağlantılar koptu, yarım kalan işler bellekte birikti.

Çözüm masaüstüne özel değil, ama masaüstünde daha görünür: aynı anda kaç iş çalışacağını sınırlayan bir semaphore, bir worker havuzu, ve uygulama kapanırken çalışan her şeyin temiz durması. Sunucuda bir goroutine sızıntısı fark edilmeden aylarca yaşayabilir; masaüstünde kullanıcı uygulamayı kapattığında pencere kapanıp arka planda işlemcinin dönmeye devam etmesi anında şikayet konusu olur. Masaüstü seni disipline zorluyor, çünkü kullanıcının makinesi senin izlediğin bir sunucu değil.

## Yine Wails Der miydim

Bütün bu dertleşmeden sonra soru şu: baştan başlasam yine Wails mi seçerdim? Evet. Tereddütsüz. Hatta bir adım öteye gideyim: bugün production için bir masaüstü ürünü geliştirecek olsam, en mantıklı seçim hala Wails.

Çünkü anlattığım dertlerin çoğu Wails'e özel değil; masaüstü uygulaması göndermenin doğasında var. İmza, notarize, webview farkları, dağıtım; bunları Electron'la da Tauri'yle de yaşardım, üstelik çoğunu daha ağır yaşardım. Wails'in bana verdiği şey, backend'i Go'nun sadeliğiyle yazabilmek, Rust'ın öğrenme eğrisine takılmadan iş görebilmek ve sonunda kullanıcıya şaka gibi küçük bir uygulama teslim edebilmekti: Seodisias'ın bugünkü production build'i 8 MB. Vaktiyle tabloya 20 MB yazmıştım; gerçek, kendi tahminimden bile derli toplu çıktı. Electron dünyasından gelen biri için bu rakam bir yazım hatası gibi görünüyor, değil. O söz tutuldu, ürün bugün production'da her gün çalışarak tutmaya devam ediyor.

Ama artık o parlak karşılaştırma tablolarına başka gözle bakıyorum. "Dosya boyutu" satırı tahminimden bile iyi çıktı, bugünkü build 8 MB; ve o satır yine de tablonun en önemsiz satırı. Asıl satırlar tabloda yok: köprüden veri değil kontrol geçir, her webview'i ayrı test et, imza için hafta ayır, dağıtımı ilk günden otomatikleştir. Bir aracın gerçek maliyeti kurulum ekranında değil, onu başkasının bilgisayarında sorunsuz açtırdığın gün ortaya çıkıyor.

Yunus'un dediği gibi, "az söz erin yüküdür." Ben de sözü uzatmayayım: Wails'i seç, ama beş dakikalık demoya değil, gönderme işinin kendisine hazırlan. Tablo seni içeri alır; seni ayakta tutan, tablonun yazmadığı incelikler olur.

Ve bu yolda takıldığın bir yer olursa bana yaz. Köprüde donan tablodan Gatekeeper'ın "hasarlı" mesajına kadar bu çukurların hepsine düştüm, hepsinden bir notla çıktım; o notları paylaşmayı seviyorum.

---

## Krallar Neden Mor Giyer: Günü Kurtaranların Üretemediği Renk
URL: https://aligundogdu.com/tr/krallar-neden-mor-giyer
Sur moru ağırlığınca altından pahalıydı çünkü tarif değil sistemdi. Günü kurtaran şirket neden savrulur, plan şansı nasıl fırsata çevirir?

## Kokuyla Başlayan Renk

Tarihin en pahalı rengi, dünyanın en kötü kokan atölyelerinde doğdu.

Bugünkü Lübnan kıyısında bir liman kenti: Sur. Antik adıyla Tyre. Coğrafyacı Strabon bu şehri anlatırken iki notu yan yana düşer: şehir inanılmaz zengindir ve içinde yaşamak pek keyifli değildir, çünkü kokar. İkisinin sebebi aynıdır. Şehrin serveti, koku yüzünden yerleşimin rüzgar altına kurulmuş boya atölyelerinden çıkar.

O atölyelerde üretilen şeyin adı [Sur moru](https://en.wikipedia.org/wiki/Tyrian_purple). Kaynağı ne bir çiçek ne bir maden; dikenli bir deniz salyangozu. Her salyangozun içinde, küçük bir salgı bezinde saklı bir iki damla sıvı var. O sıvı önce sarımsı; havayla ve ışıkla temas ettikçe yeşile, maviye, en sonunda derin ve doygun bir mora dönüyor.

Rakamsız olmaz, çünkü hikayenin ağırlığı rakamda. 1909'da kimyager [Paul Friedländer](https://en.wikipedia.org/wiki/Paul_Friedl%C3%A4nder_%28chemist%29) bu antik işlemi laboratuvarda tekrarladı: on iki bin salyangozdan 1,4 gram saf boya çıkarabildi. Bir kaftan boyamak bir yana, bir mendil kenarı için bile binlerce canlı ve günlerce emek gerekiyordu. Fenikeliler kıyılarındaki salyangoz yatakları tükendikçe yeni koylar aradı; Akdeniz'in yarısına, biraz da bu salyangozun peşinde yayıldılar.

Roma bu emeğin fiyatını resmen kayda geçirdi. Diocletianus'un fiyat fermanında mor boyalı ipek, ağırlığınca altından pahalıdır. Mor giymek önce servet işiydi, sonra yasa işi oldu; renk adım adım saraya bağlandı. Bizans sarayında duvarları mor taşla kaplı bir doğum odası vardı; imparator çocukları orada doğar ve ömür boyu bir unvan taşırdı: moru içinde doğan.

Bu yazı aslında renkler hakkında değil, şirketler hakkında. Ama oraya geçmeden önce cevaplanması gereken bir soru var: bir renk nasıl imparatorluk sembolü olur?

## Bir Gram Mor İçin

Cevap zorluk değil. Dünya zor işle dolu. Cevap, zorluğun türünde.

Mor üretmek tek seferlik bir kahramanlık değildi; uçtan uca bir sistemdi. Salyangozu toplayan tekneler ve dalgıçlar. Canlıyı bozulmadan atölyeye ulaştıran lojistik. Salgı bezlerini ayıklayan, tuzlayan, bekleten eller. Kazanların başında günlerce süren bekleyiş ve rengin döndüğü o kısacık anı tanıyan ustalar. Işığa maruz kalma süresiyle oynayarak tutturulan tonlar. Ve bütün bunların bir kez değil, her partide aynı kaliteyi verecek şekilde tekrarlanması.

Mor bir tarif değildi. Mor bir üretim sistemiydi. Sur'un asıl sırrı kazanın içindeki sıvı değil, kazanın etrafındaki düzendi.

Günü kurtaran kararlarla mor üretemezsiniz. Salyangozu bugün toplayıp yarın vazgeçen, kazanı sabırsızlıktan erken açan, ustası her ay değişen bir atölyeden mor çıkmaz. Bir şey çıkar elbette; ama adı mor değil, leke olur.

İşin bana en çok dokunan detayı ise şu: bu renk solmazdı. Plinius'un aktardığına göre Sur moru güneşten kaçmaz, zamanla ve ışıkla daha da güzelleşirdi. Ucuz boya ilk yıkamada akar. Mor, eskidikçe parlar.

Bu cümleyi bir kenara koyalım, birazdan lazım olacak: **günü kurtaran çözüm ertesi sabah solar; sistemle üretilen değer eskidikçe parlar.**

## Rüzgarda Savrulan Şirket

Şimdi kazanların başından bir yazılım şirketinin toplantı odasına geçelim.

Sektörün sevdiği bir ezber var: hız her şeydir. Çevik ol, anında karar ver, rüzgarı yakala. Ezberin yarısı doğru, ama soru eksik sorulmuş. Hız ancak bir yön varsa hızdır; yön yoksa adı savrulmaktır. Rüzgar kötü değildir, yelkenliyi yürüten de odur. Fark dümende.

Günü kurtarma modunda çalışan şirketi uzun uzun tarif etmeme gerek yok, çoğumuz içinde bulunduk. Haftanın planını pazartesi sabahı gelen mail belirler. En yüksek sesle bağıran müşteri, yol haritası olur. Her toplantı bir yangın toplantısıdır ve "acil" kelimesi anlamını yitirmiştir, çünkü her şey acildir. Yıllardır mutfağın içinde bu modun iki faturasını tekrar tekrar gördüm.

Birincisi: doğru insana yatırım yapamazsınız. İşe alım, altı ay sonrası için verilmiş bir sözdür. Altı ay sonra nerede olacağını bilmeyen şirket, kimi işe alacağını da bilemez; bugünkü yangına itfaiyeci toplar. Sonra yangın değişir ve elde yanlış takım kalır. Eğitim, mentorluk, bir insanın altı ay sonra açacağı çiçeğe bugünden su vermek... bunlar lüks değildir, dümeni olan şirketin doğal refleksidir. Dümen yoksa o refleks de yoktur; kimse varış noktası bilinmeyen bir yolculuk için azık hazırlamaz.

İkincisi: hiçbir şey birikmez. Günü kurtaran şirkette her çözüm o güne aittir. Kriz atlatılır, herkes yorgun ama mutlu evine gider, ertesi hafta aynı film başa sarar. Çözülen sorun yazılmaz, öğrenilen ders sistemleşmez, bilgi kahramanın kafasında yaşar. Böyle şirketin hafızası yoktur, refleksleri vardır. Refleksle strateji arasındaki fark da tam olarak lekeyle mor arasındaki farktır.

Yapay zeka çağı bu tabloyu hafifletmedi, sertleştirdi. Her hafta yeni bir model, her ay yeni bir mucize araç. Günü kurtaran şirket için bunların her biri yeni bir rüzgar, yani yeni bir rota: bir çeyrek chatbot yapılır, sonraki çeyrek ajanlara dönülür, üçüncü çeyrekte ikisi de yarım bırakılıp o haftanın demosuna koşulur. Oysa olan biteni görmek için morun hikayesine dönmek yeterli. Üretim ucuzladığında rengin kendisi değersizleşir; değer, boyahaneye kayar. Yapay zeka çıktıyı herkes için ucuzlattı. Renk artık herkesin elinde. Fark, üretim sisteminde.

Yapay zekanın gücü çoğaltan bir araç olduğunu [hidrolik direksiyon benzetmesiyle](/tr/ai-vibecoding-hidrolik-direksiyon) anlatmıştım. Direksiyon ne kadar hafiflerse hafiflesin, nereye gidileceği sorusu şoförde kalır. O soruya her sabah farklı cevap veren şirket, aslında hiç cevap vermiyordur.

## Kahramanlık Tuzağı

Burada durup dürüst olmam gereken bir yer var; buraya kadar yazdıklarım tek başına bırakılırsa haksızlık olur.

Günü kurtarmak bir beceridir. Erken aşamada neredeyse tek beceridir. İlk müşterisini arayan, kasasında üç aylık nefesi kalan bir girişimin oturup beş yıllık masterplan tartışması yapması, yanan evde perde seçmeye benzer. O dönemin adı hayatta kalmaktır ve hayatta kalmak, plana her zaman üstündür. [Prototip vadisini](/tr/prototip-olumcul-vadi) geçmeye çalışan ekipler için bazı dönemlerde tek doğru, yüzmeye devam etmektir.

Patoloji, günü kurtarmanın olay olmaktan çıkıp kimlik olmasıyla başlar. Yangın artık istisna değil, işletim modelidir. Şirket de bunu fark etmeden ödüllendirir: gece yarısı sistemi ayağa kaldıran mühendis alkışlanır; o yangının bir daha hiç çıkmaması için sessizce çalışan mühendis, performans görüşmesinde "görünürlüğü düşük" bulunur. Teşvik neredeyse, davranış oraya akar. Yangın söndürmeyi ödüllendiren şirket, farkında olmadan kundakçı yetiştirir. Sömürge dönemi Delhi'sinde anlatılan hikaye gibi: yönetim kobralardan kurtulmak için ölü kobraya ödül koymuş, halk ödül için kobra yetiştirmeye başlamış. Ödül kalkınca elde kalanlar sokağa salınmış ve şehirde kobra öncekinden çok olmuş. Kobra etkisi diye bilinir; yanlış şeyi ödüllendiren sistem, azaltmak istediği şeyi üretir.

Madalyonun öbür yüzünü de söylemezsem olmaz: süreç fetişizmi. Sistem kuruyoruz diye her işi forma bağlayan, üç imzasız satır kod çıkmayan, toplantının toplantısını yapan şirketler de ölür. Sadece daha yavaş ve daha sıkıcı ölürler. Benim kastettiğim sistem, bürokrasi değil. **Sistem, yüz kere vereceğin kararı bir kere verip gerisini akışa bağlamaktır.** "Deploy nasıl yapılır" sorusunun cevabı bir kişinin kafasındaysa o şirkette sistem yoktur; herkesin çalıştırabildiği bir script'in içindeyse vardır. Fark bu kadar yalın.

## Planın İşi Şansı Yakalamak

İtirazı duyar gibiyim: peki ya piyasa değişirse? Masterplan yaptık diyelim, altı ay sonra çöpe giderse?

Gider. Büyük ihtimalle gider. Eski bir kurmay sözü vardır: hiçbir plan, sahayla ilk temasta hayatta kalmaz. Bu söz hep planlamaya karşı bir koz gibi kullanılır; oysa sahibi, ordularını plansız yönetmiş biri değildi. Planın değeri aynen gerçekleşmesi değildir. Planın değeri, sapmayı görünür kılmasıdır. Nereye gittiğini bilen insan aksaklığı erken sezer, B planını önceden kurar. Nereye gittiğini bilmeyenin B planı olamaz; çünkü A planı da yoktur, sadece o gün vardır.

Morun hikayesinin son perdesi tam bunu anlatır. 1856'da Londra'da [William Perkin](https://en.wikipedia.org/wiki/William_Henry_Perkin) adında on sekiz yaşında bir kimya öğrencisi, sıtma ilacı kinini sentezlemeye çalışıyordu. Deney başarısız oldu. Kabın dibinde kalan siyah çamuru temizlerken, çamurun ipeği parlak bir mora boyadığını fark etti. Tarihin ilk sentetik boyası olan mauveine bir kazadır. Binlerce yıl kralların tekelinde duran renk, birkaç yıl içinde Londra vitrinlerine indi.

Perkin hikayesi ilk bakışta bu yazının tezini yıkar gibi görünüyor: adam planla değil, kazayla kazandı. Dikkatli bakınca tam tersi çıkar. O yıl Londra'da deney kabı temizleyen yüzlerce öğrenci vardı. Kazayı fark eden göz, ne aradığını bilen bir kafanın gözüydü. Kazayı patente, fabrikaya, koca bir boya endüstrisine çeviren şeyse merak değil, Perkin'in etrafına hızla kurduğu sistemdi. Şans herkese çarpar. Hazırlıklı sisteme çarpan şansın adı fırsat olur. Hazırlıksız şirkete çarpanınki, güzel bir anı.

Pivot da böyledir. Yol değiştirmek plansızlık değildir; nereden saptığını bilmektir. Haritası olmayan rota değiştiremez, sadece sürüklenir.

## Mor mu Üretiyorsunuz, Günü mü Kurtarıyorsunuz

1453'te Konstantinopolis düştüğünde saray atölyeleri sustu ve gerçek morun üretim bilgisi büyük ölçüde onlarla birlikte gitti. Yüzyıllar boyunca kimse o rengi eski usulle üretemedi. Kazanın başındaki ustayla birlikte kazanın sırrı da öldü. Sistemleşmeyen bilgi, kahramanıyla birlikte gömülür.

Bir şirketin mor mu ürettiğini, günü mü kurtardığını anlamanın kestirme yolları var. Ben üç test kullanıyorum:

- **Aynı yangın testi.** Aynı sorun son bir yılda iki kez kriz çıkardıysa o artık kaza değil, ödenmemiş sistem borcudur.
- **Tatil testi.** Kilit bir insan iki hafta telefonunu kapatsa iş durur mu? Duruyorsa elinizdeki şirket değil, bir insanın etrafına kurulmuş nöbet çizelgesidir.
- **Hafıza testi.** Son büyük krizden geriye yazılı ne kaldı? Cevap "herkes çok şey öğrendi" ise kimse bir şey öğrenmemiştir, sadece yorulmuştur.

Sur'un atölyelerinde çalışmak alkışlı bir iş değildi. Kokuya katlanmak, kazan başında beklemek, aynı işi bin kere aynı özenle yapmak. Kimse o ustaların adını bir kitabeye yazmadı. Ama krallar, omuzlarında o ustaların sabrını taşıdı. Mor, günü kurtaranların değil, kokuya katlananların rengidir.

Rüzgar herkese esiyor; bu aralar her zamankinden sert. Dümeni olana rüzgar yakıttır. Olmayana, kader.

---

## 'Computer' Bir Zamanlar Bir İnsandı
URL: https://aligundogdu.com/tr/loop-engineering-lindy
Prompt engineer, context engineer, loop engineer... Unvanlar bir yılda eskiyor. Bu bir çöp yığını değil, sınırın ne hızla kaydığını gösteren bir kadran. Moravec, Lindy ve görünmez defter ışığında: neye yatırım yapmalı?

1962\. [John Glenn](https://en.wikipedia.org/wiki/John_Glenn), [Friendship 7](https://en.wikipedia.org/wiki/Mercury-Atlas_6) kapsülünün içinde, Dünya'nın yörüngesine çıkacak ilk Amerikalı olmayı bekliyor. Uçuşun her sayısı, her yörünge açısı, o güne kadarki en güçlü makine tarafından hesaplanmış: yeni IBM 7090. Ama Glenn kalkıştan önce tuhaf bir şey istiyor. "Kızı çağırın," diyor, "sayıları o kontrol etsin. O 'tamam' derse giderim."

O "kız", [Katherine Johnson](https://tr.wikipedia.org/wiki/Katherine_Johnson)'dı. NASA'da bir "computer", yani bir hesaplayıcıydı. Çünkü o yıllarda "computer" bir makine değil, bir meslekti. Uzun masalarda oturup yörüngeleri elle, kağıt üstünde hesaplayan insanlar, çoğu kadın. Glenn, milyonlarca dolarlık makineye değil, o makinenin çıktısını kalemle doğrulayan bir insanın muhakemesine güvendi.

Bu sahne gerçek, ve güzel bir filme de konu oldu: 2016 yapımı <a href="https://www.imdb.com/title/tt4846340/" rel="nofollow noopener noreferrer" target="_blank">Gizli Sayılar (Hidden Figures)</a>. Katherine Johnson ve yanındaki hesaplayıcıları anlatır. Görmediyseniz, bu yazının borcu olsun, listenize ekleyin.

Birkaç yıl içinde o meslek yok oldu. "Computer" artık masada oturan bir insan değil, masanın üstünde duran bir kutuydu. Ama dikkat: kaybolan şey, hesaplama becerisiydi. Katherine Johnson'ın asıl yaptığı, neyin hesaplanacağını bilmek, çıkan sonucun mantıklı olup olmadığını sezmek, yanlışın kokusunu almaktı. O beceri kaybolmadı, yukarı taşındı: önce programlamaya, sonra mühendisliğe.

## Bir unvan, bir sınır çizgisi

"Computer" bir unvandı ve tek bir işi vardı: insanla makine arasındaki sınırın o an nerede olduğunu tarif etmek. Sınır kımıldadıkça unvan da değişti. Bu yeni bir hikaye değil. Bugün aynı film, çok daha hızlı sarılıyor.

Bu hızı anlamak için iki eski fikri yan yana koymak gerekiyor.

Birincisi **[Moravec Paradoksu](https://en.wikipedia.org/wiki/Moravec%27s_paradox)**. Robotik araştırmacısı Hans Moravec, 1988'de tuhaf bir gözlem yaptı: Bir makineye satranç oynatmak, teorem ispatlatmak, zeka testi çözdürmek kolaydı. Ama bir yaşındaki çocuğun yaptığını, bir odayı görüp anlamayı, yürümeyi, "şu bardağı bana ver" cümlesini kavramayı yaptırmak neredeyse imkansızdı. Ters gibi duruyor ama mantığı şu: Bizim en zor sandığımız beceriler (soyut akıl, matematik) evrimsel olarak en yeni olanlar, birkaç bin yıllık. En kolay sandıklarımız (görmek, sezmek, dengeyi bulmak) ise milyonlarca yıllık. Ve tam da eski oldukları için o kadar derine işlemişler ki kopyalanmaları zor.

İkincisi **[Lindy Etkisi](https://en.wikipedia.org/wiki/Lindy_effect)**. Bir şeyin gelecekte ne kadar yaşayacağı, şimdiye kadar ne kadar yaşadığıyla orantılıdır. Kırk yıldır ayakta olan bir fikir muhtemelen kırk yıl daha yaşar; kırk günlük bir trend, kırk gün sonra unutulur. Eski dayanıklıdır, yeni kırılgan.

Bu ikisini üst üste koyunca net bir şey çıkıyor: **Moravec Paradoksu, aslında becerilerin Lindy Etkisi'dir.** Bir beceri ne kadar yeni ve ne kadar "adı konmuş, adım adım tarif edilebilir" ise, o kadar kolay otomatikleşir ve o kadar kırılgandır. Ne kadar eski, örtük ve tarif etmesi zorsa, o kadar dayanıklıdır. Yapay zeka da tam bu eğim boyunca ilerliyor: önce en tarif edilebilir, en yüzeydeki işi alıyor.

## Son üç yılın meslekleri

Şimdi son dönemin unvanlarına bak. **Prompt engineering**: doğru kelimeleri yazıp modelden iyi çıktı almak. Sonra **context engineering**: modele doğru bağlamı, doğru veriyi vermek. Sonra **loop engineering**: tek tek komut yazmak yerine, ajanı hedefe süren döngüyü tasarlamak. Aralarında kabaca birer yıl var.

Bunlar Moravec eğiminin en tepesi: en yeni, en tarif edilebilir katman. "Doğru sihirli sözü söyle" kadar prosedürel bir işin uzun ömürlü bir unvana dönüşmesini beklemek gerçekçi değil. Nitekim dönüşmüyor da. Loop engineering daha adını yeni almışken, araçlar "/goal" gibi komutlar ekleyip o döngüyü kendi içlerine gömmeye başladı bile. "Bu aslında yeniden adlandırılmış otomasyon" diyen kuşkucular da bir doğruyu söylüyor.

## Ama bunlar çöp değil

İşte tam burada çoğu kişi yanlış sonuca atlıyor: "Madem bir yılda eskiyorlar, o zaman boş şeyler, takmayayım."

Değiller. Bu unvanların bu kadar hızlı gelip gitmesi bir gürültü değil, bir **ölçüm**. Her biri, insanla makine arasındaki sınırın o an nerede durduğunu işaretleyen bir kilometre taşı. Üst üste dizildiklerinde sana tek bir şey söylüyorlar: sınır ne kadar hızlı hareket ediyor. Prompt'tan loop'a bir yılda geçtiysek, bu, arabanın hız göstergesinin 200'ü göstermesi gibidir. Göstergeyi küçümsemek hızı yok etmez.

Ama bir tuzağı var ve iktisadın eski bir yasası tam bunu tarif ediyor. **[Goodhart Yasası](https://tr.wikipedia.org/wiki/Goodhart_yasas%C4%B1)**: bir ölçü hedefe dönüştüğü an, iyi bir ölçü olmaktan çıkar. Unvanı bir sinyal olarak okursan sana sınırın hızını gösterir; onu bir hedef yapıp "loop engineer olacağım" dersen, o unvan artık gerçeği değil, senin kovaladığın şeyi ölçer. Sinyali sinyal olarak tutmanın tek yolu onu **kol mesafesinde** tutmaktır: örüntüyü fark edecek kadar yakın, oyunu bozacak kadar uzak.

Aynı ilke küçük ölçekte de işliyor. Bir modelle çalışırken harcadığın token'lar, eskiden hiçbir yerde iz bırakmayan zihinsel emeğini ilk kez görünür kılıyor, kişisel bir termometre gibi. Ama termometre ısıyı gösterir, yemeğin pişip pişmediğini değil. Token sayını da, unvanını da hedef yaptığın an ikisi de bozulur. İçeride token, dışarıda unvan: ikisi de okunacak birer gösterge, kovalanacak birer madalya değil.

## İki tuzak

Ortada iki tuzak var ve ikisi de aynı hatanın yüzleri.

Birincisi **kovalamak**: Her yeni unvana kimliğini bağlamak, profil başlığını üç ayda bir değiştirmek, en son terimi biliyor olmayı ustalıkla karıştırmak. Bu, göstergeye o kadar yakından bakmaktır ki arabayı sürmeyi unutursun.

İkincisi **reddetmek**, ve asıl sinsi olan bu: "Bunlar sürekli değişiyor, o yüzden hiçbirine yatırım yapmam, öğrenmem." Kulağa olgun, sabırlı, hatta 'Lindy'ci geliyor. Değil. Bu bir dayanıklılık değil, gizli bir yavaşlıktır. Sınır senin iznini beklemeden hareket ediyor. Sen "ben bunları ciddiye almam" derken, sınırı okumayı öğrenenler seni geçiyor. Üstelik bu duruş sürdürülebilir de değil: Bir kere "yeniyi anlamama" alışkanlığını edindin mi, her yeni dalgada biraz daha geriden başlarsın.

## Reçete: derinde yavaş, yüzeyde hızlı

Peki doğrusu ne? Moravec ve Lindy birlikte aynı reçeteyi veriyor.

Derinde, eski ve tarif edilmesi zor olana yatır. Muhakeme. Neyin önemli olduğunu bilmek. Bir sonucun "yanlış koktuğunu" sezmek, tıpkı Katherine Johnson gibi. Sentez, damak tadı, insanları okumak. Bunların hiçbirinin bir unvanı yok, bir sertifikası yok. Dahası, o token defterinde bile görünmüyorlar: analizini, denemeni, hata avını bir sayaç artık yakalayabiliyor, ama yürürken kurduğun cümleyi, "burada bir terslik var" sezgisini, hangi işi hiç yapmaman gerektiğine dair kararı hiçbir sayaç yakalayamıyor. En değerli kısım, tam da [hiçbir tabloda görünmeyen](/tr/bagimli-oldugun-yazilimin-bir-sahibi-var) kısımdır. Ve bir şey ne kadar görünmezse, makinenin onu kopyalaması o kadar zordur; Moravec'in kırk yıl önce söylediği de buydu. Senin dayanıklı sermayen bu.

Yüzeyde ise hızlı ol. Her yeni unvanı öğren ama onunla evlenme. Prompt'u da, context'i de, loop'u da, sıradakini de birer hafta sonu projesi gibi tanı, ne olduklarını anla, sınır hakkında ne söylediklerini not et, sonra bırak. Kökler yavaş büyür, yapraklar her mevsim değişir. Sağlıklı ağaç ikisini birden yapandır.

## Ve daha tuhafları geliyor

Şundan emin ol: Bugünküler son garip unvanlar değil. Önümüzdeki birkaç yılda bugün gülünç gelecek isimler duyacağız. Bir kısmı üç ay yaşayacak, bir kısmı yeni bir mesleğin çekirdeği olacak. Hangisinin hangisi olduğunu önceden bilemezsin. Ama şunu bilebilirsin: Onları okumayı bilen ama hiçbirine yapışmayan biri olursan, hangi isim gelirse gelsin hazır olursun.

Katherine Johnson bir "computer" olarak işe başladı. O meslek öldü, ama o ölmedi. Çünkü onun asıl işi hesaplamak değildi; sayıların doğru olup olmadığını bilmekti. O beceri, masanın üstüne hangi kutu konursa konsun, hala birinin işi.

---

## Bağımlı Olduğun Yazılımın Bir Sahibi Var. Onun Kararı da Hiçbir Tabloda Görünmez.
URL: https://aligundogdu.com/tr/bagimli-oldugun-yazilimin-bir-sahibi-var
Kullandığın araç bir gün fiyatını katlayabilir, kapısını kapatabilir, özelliğini geri alabilir. Bu risk hiçbir yol haritasında yazmaz. Peki onu tabloya kim koyacak?

Bir sabah bir stüdyo, yıllar önce bir kereye mahsus ödeyip ömür boyu kullanma hakkı aldığı bir sesli animasyon aracının artık yıllık on binlerce dolarlık bir aboneliğe döndüğünü öğrendi. Aynı yazılım, aynı ekran, aynı iş. Değişen tek şey, o aracın sahibinin fikriydi. Ve o fikir, stüdyonun ne bütçe tablosunda ne de yol haritasında yazıyordu. Bir gecede, kağıt üzerinde çözülmüş sandıkları bir masraf, geri açıldı.

Bunu tek bir talihsizlik sanma. Aynı günlerde birbirine hiç benzemeyen üç hikaye daha geçti önümden, hepsi aynı sinire dokunuyordu. Kendi ekiplerini yapay zekayla neredeyse bedavaya değiştirebileceğini sanan yöneticiler, ay sonu gelen faturayı görünce donup kalmıştı. Bir oyun platformu, uzun süre giriş yapmayan kullanıcıların parayla satın aldıkları dijital oyunları geri alabileceğini ima etti. Bir başka şirket, iptal etmesi bilerek zorlaştırılmış abonelikleriyle konuşuluyordu. Farklı dünyalar, farklı ölçekler, ama zeminde hep aynı cümle: kullandığın şeyin bir sahibi var, ve o sahip kuralları istediği gün, istediği yöne çevirebilir.

Biz mühendisler ve ürün kuranlar, bir şeyin üstüne bir şey inşa etmeyi seviyoruz. Birinin kütüphanesini çağırırız, birinin bulut servisine yaslanırız, birinin modeline istek atarız, ve bir süre sonra o zemini unuturuz. Sanki kendi toprağımızmış gibi üstüne kat çıkarız. Oysa altımızdaki zemin çoğu zaman kiralık. Ve kiranın en tuhaf tarafı, sözleşmede yazan rakam değil, sözleşmeyi tek tarafın değiştirebilmesi.

## "İyi sağlayıcı seçersen başına gelmez"

En sık duyduğum itiraz şu: bu tür şeyler dikkatsizlerin başına gelir. Sağlam, köklü, herkesin kullandığı bir sağlayıcı seçersen kendini garantiye almış olursun. Küçük, meçhul bir araca bağlanırsan tabii ki risk alırsın, ama devlerin arkasında durmak güvenlidir.

Bu itiraza saygım var, çünkü bir doğruluk payı taşıyor. Köklü bir sağlayıcının bir gecede yok olma ihtimali gerçekten daha düşük. Ama soru burada yanlış kurulmuş. Mesele sağlayıcının yarın var olup olmayacağı değil. Mesele, var olmaya devam ederken senin lehine mi yoksa kendi lehine mi karar vereceği. Ve büyük olması, o kararı senin lehine vereceği anlamına gelmez, tam tersine, büyük olması seninle pazarlık etme ihtiyacını azaltır.

Fiyatı katlayan, ömür boyu lisansı aboneliğe çeviren, ücretsiz katmanı bir sabah kapatan şirketlerin çoğu küçük ve çaresiz değildi. Aksine, seni yeterince içeri çektiklerinden emin oldukları için o kararı rahatça verebilecek kadar büyüktüler. Bağımlılık bir kez kurulduktan sonra, sağlayıcının boyu senin güvencen değil, onun kaldıracı olur. Çıkmanın maliyeti ne kadar yüksekse, sana o kadar rahat zam yapar. Bunu kötü niyetle bile açıklamana gerek yok; bir işletmenin en doğal refleksidir.

## Görünmeyen kira

Asıl mesele şu: bu riskin hiçbir tabloda yeri yok.

Bir işi planlarken neyi hesapladığını düşün. Kaç gün süreceğini, kaç kişinin çalışacağını, hangi kütüphaneyi kuracağını yazarsın. Belki lisans bedelini bile bir kalem olarak eklersin. Ama "bu araç üç yıl sonra fiyatını üçe katlarsa" ya da "bu servis o özelliği geri alırsa" diye bir satır kimse açmaz. Çünkü o satırın bir rakamı yok. Ne zaman olacağını, olup olmayacağını bilmiyorsun. Belirsiz olduğu için de, sanki yokmuş gibi davranıyorsun.

İşte tehlike tam burada. Görünmeyen bir maliyet, ölçülmediği için değil, tabloya hiç girmediği için tehlikelidir. Bir süre önce [önceliklendirmeyi konuşurken RICE'ın en dürüst kutusunun Effort olduğunu yazmıştım](/tr/rice-onceliklendirme): bir işin sana neye mal olacağını yazmak, o "iki günde biter" yalanını bozuyordu. Ama itiraf edeyim, o kutuya ben de çoğu zaman sadece kendi emeğimi yazdım. Bağlandığım aracın bir gün beni köşeye sıkıştırma ihtimalini Effort'a hiç koymadım. Halbuki en pahalı emek, senin harcadığın değil, başkasının senin adına harcamaya karar verebildiği emektir.

Bir işin gerçek maliyeti sadece onu kurmak değil. Onu terk etmenin, taşımanın, o bağımlılıktan kurtulmanın bedeli de o maliyetin parçası. Ve bunu kurarken düşünmezsen, kurtulman gerektiği gün fiyatı sağlayıcı belirler, sen değil.

İşin sinsi tarafı, bu maliyetin zamanla sessizce büyümesi. Bir bağımlılık ne kadar uzun süre sorunsuz çalışırsa, ona o kadar güvenir, üstüne o kadar çok şey inşa edersin. Bir noktadan sonra onu bir bağımlılık olarak görmeyi bile bırakırsın, artık senin bir parçandır. Oysa gerçek tam tersi: en uzun süredir yaslandığın, en çok güvendiğin araç, çıkışı en pahalı olandır. Çünkü en derine o kök salmıştır. Sağlayıcı da bunu senden iyi bilir. Zammı en rahat, en görünmez hale geldiğin ana saklar.

## Yapay zeka bunu ucuzlatmadı, derinleştirdi

Son dönemde her şey daha da keskinleşti. [Yapay zeka üretmeyi ucuzlattı](/tr/ai-vibecoding-hidrolik-direksiyon), bu doğru. Bir fikri çalışır hale getirmek hiç bu kadar kolay olmamıştı. Ama aynı kolaylık, seni hiç fark etmeden birinin modeline, birinin sunucusuna, birinin sayacına bağladı.

O faturayı görünce donan yöneticileri hatırla. Onların hatası yapay zekayı kullanmak değildi. Hatası, ucuzlayan tek şeyin başlamak olduğunu görememekti. Her istek tek başına birkaç kuruş. Ama o kuruşlar, kimsenin baktığı bir sayaçta değil, birinin senin adına döndürdüğü bir sayaçta birikiyor. Birim maliyet düşerken toplam maliyet sessizce tırmanıyor, ve o sayacın hızını sen ayarlamıyorsun. Ucuzlayan başlangıç, seni pahalı bir bağımlılığa davet eden yemdi.

Eski bir laf vardır, el atına binen tez iner. Başkasının atı seni bir yere kadar götürür, hızlısın, yorulmazsın, keyiflisin. Ama o at senin değil. Sahibi dizginini çektiği gün, kaldığın yerde yaya kalırsın. Yapay zeka çağında hepimiz bir süredir başkasının atına biniyoruz, ve çoğumuz o atın kime ait olduğunu bir an olsun düşünmedik.

## Şimdi kendi argümanıma çelme takayım

Buraya kadar okuyan biri şöyle düşünebilir: madem bağımlılık bu kadar tehlikeli, o zaman hiçbir şeye bağlanma, her şeyi kendin yap. Kendi altyapını kur, kendi aracını yaz, kimseye muhtaç olma.

Bu, kulağa güçlü gelen ama beni yıllar içinde en çok yanıltan cevaplardan biri. Çünkü bağımsızlık diye bir şey yok. Her şeyi kendin yazarsan, bu sefer de yazdığın onlarca satırın, kullandığın işletim sisteminin, dilinin, derleyicinin sahibine bağımlı olursun. Kaçış yok. Üstelik "kendim yaparım" kararının kendi bedeli var: yeniden icat ettiğin her tekerlek, sırtına aldığın ve bir daha indiremediğin bir yük.

Dahası, bedava sandığın şeyin de bir sahibi var. Gece gündüz baktığın o açık kaynak kütüphanenin arkasında çoğu zaman tek bir insan durur, karşılığında hiçbir şey almadan, tükenene kadar. O insan bir sabah "artık yapamıyorum" deyip çekildiğinde, senin sağlam sandığın zemin de kayar. Ücretsiz olması sahipsiz olduğu anlamına gelmiyor. Sadece bedelini şimdilik başka birinin ödediği anlamına geliyor.

O yüzden çözüm bağımsızlık değil, çünkü öylesi mümkün değil. Çözüm, bağımlılığını bilerek seçmek. Neye yaslandığını, o zeminin kime ait olduğunu, ve bir gün oradan kalkman gerekirse bunun sana neye mal olacağını, daha ilk gün açıkça bilmek. Riski yok saymak değil, adını koymak.

## Zemini bilmek

Bunu pratikte birkaç soruya indirebiliyorum, ve artık bir işe başlamadan kendime soruyorum. Bu aracın sahibi kim? Yarın fiyatı ikiye katlarsa işim durur mu, yoksa yürür mü? Buradan çıkmam gerekirse verilerimi, işimi, emeğimi yanıma alabiliyor muyum, yoksa hepsi onun kapısının ardında mı kalıyor? Bu üç sorunun cevabını bilmiyorsam, o zemine kat çıkmadan önce iki kere düşünüyorum.

Bunların hiçbiri bağlanmayı yasaklamıyor. Ben de her gün başkalarının araçlarına yaslanarak iş yapıyorum, başka türlüsü de olmaz. Ama artık yaslanırken zeminin kiralık olduğunu biliyorum. Kiracı olmak sorun değil; kiracı olduğunu unutup duvarları yıkmaya, pahalı tadilatlara girişmek sorun. [Bir ürüne ya da işe sahip çıkmanın](/tr/founding-engineer-ne-is-yapar) sessiz kısımlarından biri de bu: üstünde durduğun ama sana ait olmayan toprağın haritasını çıkarmak.

Mühendislik yöneticiliği çoğu zaman parlak kararlarla anılır. Oysa işin büyük kısmı, kimsenin alkışlamadığı bu tür defter tutmaktan ibaret. Neye bağlı olduğunu bilmek, o bağın kimin elinde olduğunu bilmek, ve o el bir gün sıkıldığında ne yapacağını çoktan düşünmüş olmak. Bağımlı olduğun yazılımın bir sahibi var. En azından o sahibin kim olduğunu, senin tanıman gerekiyor.

---

## RICE Skorlaması Kararı Senin Yerine Vermez. Doğru Soruyu Sana Sordurur.
URL: https://aligundogdu.com/tr/rice-onceliklendirme
RICE, çoğu kişi için kurumsal bir tablo. Oysa asıl işi skoru hesaplamak değil, seni cevabından korktuğun soruları sormaya zorlamak. Büyük ekipte de, tek kişilik girişimde de neden hala ona dönüyorum.

Diyelim ki backlog'unda bekleyen on tane iş var ve hepsini aynı anda yapmana imkan yok. Hangisi önce gelecek? Bu yazıda, tam da o karara yardım eden basit bir çerçeveden bahsedeceğim: RICE skorlaması. Ama baştan söyleyeyim, RICE'ın asıl değeri sana verdiği sayıda değil. Değeri, sormaktan kaçtığın soruların karşısına seni oturtmasında.

Çünkü önceliklendirmede asıl sorun bilgi eksikliği değil. Asıl sorun, bir şey üreten herkesin tanıdığı o his. Aklına bir fikir düşer, öyle parlak görünür ki gözünü kamaştırır. "Bunu eklersek her şey değişir." O an içinden bir ses "hemen başlayalım" der, ve elin çoktan klavyeye gitmiştir.

O his tek başına masum. Tehlikeli olan, onun asıl gereken işlerin önüne geçmesi. Kullanıcının gerçekten tıkandığı üç şey dururken, parlak ama dayanaksız bir fikir bütün yol haritasını yutar. Ürün çöple boğulmaz, yanlış sırayla boğulur. Önceliklendirme dediğimiz şey, işte tam o parlak sesin karşısına bir sandalye çekip oturmaktır.

RICE bunu dört soruyla yapıyor. **R**each, kaç kişiye dokunuyor. **I**mpact, dokunduğunda ne kadar fark yaratıyor. **C**onfidence, bundan ne kadar eminsin. **E**ffort, sana neye mal olacak. İlk üçünü çarpıp emeğe bölüyorsun, elinde bir sayı kalıyor. Intercom'un ürün ekibinin çıkardığı bu formül, kağıt üzerinde bir hesap makinesi gibi durur. Meraklısına, bu skoru kurcalamak için küçük bir hesap aracı da yazmıştım, isteyen [buradan](https://github.com/aligundogdu/Rice-Score-Calculator) bakabilir. Ama RICE'ı bir hesap makinesi sandığın an, asıl değerini kaçırırsın.

## "Bu çerçeveler büyük şirketlerin süsü"

Yaygın inanç şu: RICE gibi çerçeveler, koca ürün ekipleri toplantı odalarında vakit geçirsin diye var. Küçük bir ekipsen, hatta tek başına iş yapan biriysen, bu tablolarla uğraşmak lüks. "Ben zaten ne yapacağımı biliyorum, sezgim yeter."

Bu itiraza saygım var, çünkü kısmen haklı. Sezgi gerçek bir şeydir ve çok iş yapmış birinin sezgisi ucuz değildir. Ama burada soru yanlış kurulmuş. Mesele "sezgi mi, tablo mu" değil. Mesele, sezginin sana neyi göstermediği.

Sezgi en çok, en çok istediğin şeyde yanılır. Bir fikre gönül verdiğinde beynin artık o fikrin avukatı olur, hakimi değil. RICE'ın yaptığı şey, o davaya bir savcı çağırmak. Ve iyi bir savcı, cevabından korktuğun soruları sorar. Çünkü çoğu zaman sezgi sandığımız şey, kılık değiştirmiş bir dürtüden başka bir şey değildir.

## Asıl iş, sayıyı bulmak değil, soruyu sormak

RICE'ı yıllarca yanlış anladım. Skoru bir kehanet gibi bekledim. Oysa o dört kutunun her biri, kaçmak isteyeceğin bir soruyu masaya koyuyor.

**R**each sana "gerçekten kaç kişi?" diye sorar. Kafandaki "herkes bunu ister" cümlesi, sayıya dökülünce çoğu zaman "aslında birkaç yüz kişi, onlar da ayda bir" olur.

**I**mpact sana "dokununca ne değişecek?" diye sorar. Çoğu özellik, dürüstçe bakınca, kullanıcının gününü değiştirmez, sadece senin "yaptım" hazzını okşar.

**C**onfidence en sinsi olanı. "Bunu biliyor musun, yoksa umuyor musun?" O kutuya yüksek bir sayı yazarken elin titremiyorsa, ya gerçekten kanıtın vardır ya da kendini kandırıyorsundur. Arada pek bir şey yoktur.

**E**ffort ise en dürüst ayna. Bir işi hafife almak, yapan insanın milli sporudur. Emeği yazıya dökmek, o "iki günde biter" yalanını bozar.

Gördüğün gibi burada matematik değil, itiraf var. RICE'ın sana verdiği asıl şey bir skor değil, varsayımlarını yüksek sesle söyleme zorunluluğu. Sayı sadece o itirafların toplamı. Eski bir deyiş vardır, keramet baştadır tacda değildir. Skor tacdır, herkese gösterdiğin süs. Asıl keramet, o kutuları doldururken kendine söylemek zorunda kaldığın gerçektir. Bu yüzden bir kararı RICE'a soktuğunda çoğu zaman hesabı bitirmeden cevabı görürsün.

## Milyon dolarlık varsayımın önüne geçmek

En çok zararı, en çok özgüvenle konuşan verir. Deneyimsiz bir ürün insanının klasik cümlesini çok duydum: "Bu özelliği eklediğimiz an milyon dolar kazanacağız." Bu cümlenin altında ölçülmüş hiçbir Reach, hesaplanmış hiçbir Impact yoktur, sadece bir hevesin sesi vardır.

Bu heves tek başına masum. Tehlikeli olan, asıl gereken işlerin önüne geçip ekibi aylarca kimsenin istemediği bir şeyi cilalamaya itmesi. RICE bu noktada biçilmiş kaftan, çünkü hevesi yasaklamaz, sadece sıraya sokar. "Tamam, milyon dolarlık fikrin de listede. Şimdi onu da aynı dört soruya sokalım." Fikir gerçekten güçlüyse skordan güçlü çıkar, kimse itiraz edemez. Zayıfsa, kimseyle kavga etmeden, kendi sayısıyla sıranın sonuna düşer. Kararı sen vermezsin, süreç verir. Bu, bir ekipte politikayı da azaltır. Tartışma "kimin fikri daha havalı" olmaktan çıkıp "hangi varsayım daha sağlam" olmaya döner.

Bir yan faydası da şu: RICE seni çoğu zaman daha ucuz yola iter. Yüksek Effort, skoru aşağı çeker. Böylece "aynı faydayı yarı emekle nasıl veririm" sorusu kendiliğinden gündeme gelir. İyi önceliklendirme, farkında olmadan maliyet optimizasyonu yapar.

## AI Kodu Ucuzlattı, Doğru Sırayı Değil

Son yıllarda bir şey değişti. AI ile yazılım üretmek hem ucuzladı hem hızlandı. Bir özelliği hayal etmekle onu çalışır görmek arasındaki mesafe hiç bu kadar kısa olmamıştı. Kulağa önceliklendirmeyi gereksiz kılan bir haber gibi geliyor: madem her şey bu kadar kolay, otur hepsini yap.

Sinsi olan tam burada. Ucuzlayan şey bir özelliği yazmak. Doğru özelliği seçmek ucuzlamadı, hatta daha da pahalılaştı. Üretim kolaylaşınca özellik eklemenin önündeki doğal fren kalkar, her parlak fikir anında koda döner. Tek tek bakınca her biri birkaç saat, birkaç token. Ama plansız yığıldıklarında o küçük maliyetler birbirine eklenir: harcanan token, şişen bağlam, kimsenin bir daha bakmadığı kod, sırtında taşımak zorunda kaldığın karmaşıklık. Özellik başına maliyet düşerken, toplam maliyet sessizce yukarı tırmanır.

İşte bu yüzden "yapabilir miyim" sorusu ucuzladıkça, "yapmalı mıyım" sorusu daha da değerlendi. RICE tam da o ikinci soruyu sordurur. Üretim ne kadar kolaylaşırsa, doğru sırayı seçmek o kadar belirleyici hale gelir. Fren pahalıyken herkes dikkatli sürer; asıl ustalık, fren bedavayken yavaşlamayı bilmektir.

## Kimse seni denetlemezken

Bunu en net, tek başıma iş yaparken gördüm. Teknik tarafta duran biri olarak proje yönetimi hiçbir zaman asıl işim olmadı. Ama kendi işlerimi kurarken kimse bana "bu gerçekten öncelik mi" diye sormuyordu. Patron da bendim, geliştirici de, sözde ürün müdürü de. Ve tek kişilik bir ekipte kendini kandırmak, kalabalık bir ekipten çok daha kolay. Seni tutan bir sürtünme yok.

RICE tam orada, o sürtünmenin yerini tuttu. Bir fikre kapıldığımda kendimi o dört kutunun karşısına oturmaya zorladım. Çoğu zaman Confidence kutusuna dürüst bir sayı yazamadığım için, haftalarımı yiyecek bir işe başlamadan vazgeçtim. Beni kurtaran skorun kendisi değildi, o kutuyu doldururken kendime söylemek zorunda kaldığım gerçekti.

Küçük ekip bu yöntemden muaf değil. Tam tersi. Kaynağın ne kadar azsa, yanlış sıraya ödeyeceğin bedel o kadar büyük. Büyük şirket yanlış önceliği absorbe eder, birkaç ay kaybeder, devam eder. Tek kişilik bir girişimde yanlış öncelik, doğrudan hayatta kalma meselesi. [Prototipin çalışıyor olması onu ürün yapmaz](/tr/prototip-olumcul-vadi); aynı şekilde bir fikrin heyecan vermesi de onu öncelik yapmaz. Neyin önce geleceğine karar vermek, [ürüne sahip çıkmanın](/tr/founding-engineer-ne-is-yapar) belki de en yalnız kısmı.

## Direksiyonu Sayıya Bırakma

Buraya kadar RICE'ı savundum, şimdi kendi savunmama bir çelme takayım. Çünkü bu yöntemin en büyük tehlikesi, işe yaradığını görüp ona fazla güvenmek.

RICE bir navigasyon, direksiyon değil. Dört kutuya yazdığın sayılar senin tahminlerin, kesin ölçümler değil. Özellikle Confidence, isteyerek ya da istemeyerek en kolay şişirilen yer. Bir işi gerçekten yaptırmak istiyorsan, farkında olmadan diğer kutuları da o sonuca doğru büker, ve sonunda önceden verdiğin kararı doğrulayan bir skor üretirsin. Buna "objektiflik tiyatrosu" derim. Tablo bilimsel görünür ama içine kendi önyargını doldurmuşsundur.

O yüzden skoru hiçbir zaman son söz yapmam. Navigasyon "sağa dön" dediğinde gözünü kapatıp dönmezsin, önce öyle bir yol var mı diye bakarsın. RICE bir kararı reddettiğinde de durup sorarım: "Ben mi yanılıyorum, tablo mu?" Bazen sayı beni tembelliğimden kurtarır. Bazen de sayının göremediği bir şeyi sezerim ve tablonun tersine giderim, ama artık bilerek, tesadüfen değil. Sayı sezgiyi gizlemek için değil, sınamak için var. İkisini birbirinin yerine koyduğun an, RICE da senin gördüğün o kötü ürün müdürlerinden birine dönüşür, sadece bir tablonun arkasına saklanan.

## Neyi tartıyorsun

Sonunda RICE'ın bana öğrettiği şey, önceliklendirmeden çok daha eski. Bu dört kutu, bir işi tartıyor gibi görünüp aslında seni tartar: gerçekten ne bildiğini, neyi umduğunu, hangi hevesin arkasına saklandığını.

Bu yüzden büyük ekipte de, tek başımayken de aynı yere dönüyorum. Bir hesap makinesi istediğim için değil. Kendi kendime yalan söylemeyi zorlaştıran bir şeye ihtiyacım olduğu için. Skor çıkar, unuturum. Ama o dört soruyu dürüstçe cevaplamak zorunda kaldığım an, kararı çoktan vermiş olurum.

---

## Founding Engineer Ne İş Yapar? Adındaki 'Founding' Sizi Yanıltmasın
URL: https://aligundogdu.com/tr/founding-engineer-ne-is-yapar
Founding engineer, 2025'in en aranan teknik rollerinden biri. Ama çoğu kişi onu yanlış biliyor: kurucu değildir, ve işi sadece kod yazmak hiç değildir. Sektör verileriyle, bu rol gerçekte ne yapar?

Son iki yılda startup ilanlarında bir unvan öne çıktı: founding engineer. Pragmatic Engineer gibi sektörü yakından izleyen kaynaklar bu rolü 2025'in en aranan teknik pozisyonlarından biri olarak tarif ediyor, hatta birileri "Silikon Vadisi'nin en gözde transferi" demeye kadar götürdü. Ama unvanın bu parlaklığı, etrafında ciddi bir kavram kargaşası da yarattı. Çoğu kişi founding engineer'ın ne olduğunu yanlış biliyor.

İki yanlış birden dolaşıyor. Birincisi, adındaki "founding" yüzünden onu kurucu sanmak. İkincisi, "engineer" yüzünden işini sadece kod yazmak sanmak. Gerçek, ikisinin de dışında. Bu yazı, sektör verilerine ve rolün gerçek tanımına dayanarak, founding engineer'ın aslında ne iş yaptığını netleştirmeye çalışıyor.

## "Founding" Kurucu Demek Değil

En büyük yanlış burada. Unvandaki "founding", kişinin kurucu ekibin bir parçası olduğunu söyler, kurucu olduğunu değil. Founding engineer çoğu zaman şirketin ilk mühendisi, hatta ilk çalışanıdır. Ama masada kurucularla aynı koltukta oturmaz.

Bu farkı en net gösteren şey rakamlar. Sektör verilerine göre kurucular tipik olarak şirketin yüzde 20 ila 50'sine sahip olur. İlk mühendisin medyan hisse payı ise yüzde 1,5 civarında, ve bu beşinci çalışana gelindiğinde yüzde 0,33'e kadar düşer. Yani founding engineer büyük risk alır, kurucu kadar erken gelir, kurucu kadar çok şey taşır, ama kurucu kadar pay almaz. Karşılığında genelde daha yüksek bir maaş alır. Bu denklem rolü anlamanın anahtarı: kurucu zihniyetiyle çalışan ama kurucu olmayan kişi.

## Asıl İş: Kod Değil, Ürüne Sahip Çıkmak

İkinci yanlış da burada çözülüyor. Erken aşamadaki bir startup'ta ayrı bir ürün müdürü yoktur. Bu yüzden founding engineer'dan beklenen, sadece verilen işi kodlamak değil, ürünün nereye gideceğine dair fikir sahibi olmaktır. Rolü tarif eden kaynakların ortak vurgusu şu: bu işte "sadece kod yazan code monkey"e yer yoktur.

Yani founding engineer'ın günü, "şunu yap" denen bir görev listesini tüketmekle geçmez. Hangi özelliğin gerçekten gerektiğine, hangisinin sadece kulağa hoş geldiğine karar vermek de işin içindedir. Teknik kararla ürün kararı, aynı kişinin içinde birleşir. Bu yüzden işin en görünür kısmı kod olsa da, asıl ağırlık kodun dışındadır.

## MVP, Hipotez ve Hızlı Yanılmak

Founding engineer'ın ilk somut görevi genellikle bir MVP, yani startup'ın temel varsayımını test edecek en küçük çalışan ürünü inşa etmektir. Mantık basit ama acımasız: önce hipotezi test et, tutarsa özellik ekle ve ölçekle, tutmazsa erken öğren.

Bu da demek oluyor ki yazılan kodun bir kısmı en baştan ölmek için doğar. Bir özellik, bir akış, bazen bütün bir yön, gerçeğe çarpınca çöpe gidebilir. [Karmaşıklığın bir ürünü içten içe nasıl kemirdiğini](/tr/prototip-olumcul-vadi) anlattığım yazıdaki mesele de buydu: hızlı kurup hızlı yanılabilmek, mükemmel kurup geç anlamaktan iyidir. Founding engineer'ın işi, bu hipotez döngüsünü kısıtlı kaynakla, az kişiyle döndürmektir.

## 2025'te Neden Bu Kadar Aranıyor

Rolün son dönemde bu kadar popülerleşmesinin iki nedeni var, ikisi de aynı yöne bakıyor.

Birincisi, ekonomik iklim. 2025'in ilk yarısında startup'lar çoğu alanda daha yalın ekiplerle, daha temkinli büyümeye yöneldi. Bu ortamda founding engineer, tek bir güçlü işe alımla birkaç kişinin işini gören kişi haline geldi. Az kişiyle çok iş, dönemin ruhu oldu.

İkincisi, araçlar. Cursor, Claude Code, Copilot gibi yapay zeka araçları, tek bir kıdemli mühendisin bir haftada çıkarabileceği işi belirgin biçimde artırdı. Bunu daha önce [yapay zekayı bir hile değil, gücü çoğaltan bir araç olarak](/tr/ai-vibecoding-hidrolik-direksiyon) tarif etmiştim; founding engineer tam da bu çoğaltmanın en somut karşılığı. Yön hala insanın, ama o insanın menzili eskisinden çok daha geniş.

## Madalyonun Öbür Yüzü

Buraya kadar rol kulağa cazip geliyor: erken gel, çok şey inşa et, ürüne yön ver. Ama dürüst olmak gerekirse öbür yüzü de var.

Founding engineer kurucu kadar erken gelir, kurucu kadar belirsizlik taşır, çoğu zaman kararını onaylayacak bir merci bile bulamaz. Yanlış mimariyi de o seçer, gece patlayan veritabanının başında da o oturur. Ama şirket büyüdüğünde kurucularla aynı payı almaz. Bu, rolün gizli faturasıdır ve sözleşmeyi imzalamadan önce net görülmesi gereken kısımdır. Cazibesi gerçek, ama bedeli de gerçek.

## Sonuç: Bir Unvan Değil, Bir Konum

Founding engineer, ne adındaki gibi bir kurucu, ne de işinin sandığı gibi sadece bir kodlayıcıdır. Sektör verilerinin ortak resmi şu: kurucu gibi düşünen ama kurucu olmayan, ürüne sahip çıkan ama payı sınırlı kalan ilk mühendis.

Kendi küçük projelerimi kurarken bu işin doğasını uzaktan da olsa tanıdım: [bir ürünü mutfak masasında kurarken](/tr/seodisias-hikayesi) en çok yorulduğum şey kod değildi, "bunu yapmalı mıyım" sorusunu her gün yeniden cevaplamaktı. Founding engineer bunu bir de şirketin ağırlığıyla, çoğu zaman tek başına yaşıyor. Unvanın parlaklığına bakıp da arkasındaki bu konumu görmemek, hem işi alanı hem alacak olanı yanıltır. Asıl mesele, parlak kelimenin değil, altındaki gerçek işin ve gerçek payın ne olduğunu bilmek.

---

## CTO Kod Yazmalı mı? Yanlış Soruyu Sormayı Bırakın
URL: https://aligundogdu.com/tr/cto-kod-yazmali-mi
CTO kod yazmalı mı yazmamalı mı? Bu sorunun kendisi yanlış. Şirketin aşamasına göre CTO rolü nasıl dönüşür, ne zaman klavyeye dokunulur, ne zaman uzak durulur?

Aynı tartışma her hafta yeniden alevleniyor. Bir yanda "kod yazan CTO, delege etmeyi beceremeyen CTO'dur" diyenler. Öbür yanda "klavyeden uzaklaşan CTO, otoritesini de bırakır" diyenler. Aralarında karikatür paylaşıp saf tutan binlerce insan. Herkes emin, herkes kendi hikayesini herkesin hikayesi sanıyor.

Ben bu kavgaya her denk geldiğimde tek bir şey düşünüyorum: yanlış soruyu tartışıyorlar.

"CTO kod yazmalı mı?" sorusu, "doktor ameliyat yapmalı mı?" demek kadar boş. Hangi doktor? Acil servis hekimi mi, radyolog mu, başhekim mi? Bağlamı sökülmüş bir soruya evrensel cevap aramanın tek ürünü, birbirine küsmüş profesyoneller oluyor.

O yüzden soruyu olduğu gibi çöpe atalım. Yerine işe yarar bir tane koyalım: **hangi aşamada, hangi bağlamda, neyi yazmalı?** Cevabı ararken göreceğiz ki CTO diye tek bir iş yok; şirket büyüdükçe rol da kabuk değiştiriyor.

## "CTO Nedir?" Sorusunun Tek Bir Cevabı Yok

CTO, yazılım dünyasının en gevşek etiketi. Aynı kartviziti taşıyan iki insanın günü hiç benzemeyebilir. Biri sabah IDE'yi açıp production'a kod gönderiyordur, öteki o saatte board odasında beş yıllık teknoloji bütçesini savunuyordur. İkisi de CTO, ikisi de işini doğru yapıyor.

Sebebi basit. Rol, şirketin boyuna göre dikiliyor. Beş kişilik bir startup'ta CTO baş mühendistir. Elli kişide orkestra şefidir. Beş yüz kişide haritacıdır. Tek unvan, üç ayrı meslek.

Vadim Kravcenko meseleyi tek cümlede topluyor: şirket küçüldükçe CTO daha az insanla, büyüdükçe daha az teknolojiyle uğraşır. Spektrumun bir ucu saf kod, öteki ucu saf strateji. Ve çoğumuz kariyerimiz boyunca bu çizgi üzerinde sağa sola kayıp duruyoruz.

Tartışmaların hatası tam burada. Beş kişilik startup'ın CTO'suyla beş yüz kişilik şirketin CTO'sunu aynı teraziye koyuyorlar, sonra "kod yazmalı mı?" diye dövüşüyorlar. Elmayla armudu tartmanın teknoloji hali.

Gelin çizgiyi baştan sona birlikte yürüyelim.

## 5 Kişilik Ekipte CTO: Baş Aşçı

Dede Korkut'ta bir tip vardır: obanın bilge kişisi. Aynı anda savaşçı, danışman ve şifacıdır. Tek başına birkaç işi birden taşır, çünkü oba küçüktür, kaynak dardır, işbölümü lüksü yoktur.

Küçük startup'ın CTO'su işte o bilge kişidir.

Sabah MVP'nin backend'ini yazarsın. Öğlen müşteriye demo geçersin. Akşam deploy hattını kurarsın, gece production'da patlayan bug'ın peşine düşersin. Ertesi sabah yatırımcıya mimariyi anlatırsın. "Hangi stack?" sorusunu da sen cevaplarsın, çünkü soracak başka kimse yok.

Burada "kod yazmasam mı?" diye bir lüks yok. Sen yazmazsan kim yazacak? Yanında bir iki mühendis vardır, belki o da yoktur. Startup'ın nefes alıp alamaması, senin klavyeye ne kadar çabuk dokunduğuna bağlı.

Üstelik iş koddan ibaret değil. Build mı yoksa satın al mı, kararı sende. Stack seçimi sende. İlk müşterinin teknik sorusu, yatırımcının "ölçeklenir mi?" kaygısı, production çökünce kimin yakasına yapışılacağı, hepsi sende.

İşin sinsi tarafı şurada: bu dönemde aldığın ilk mühendisler şirketin teknik karakterini kuruyor. İlk beş kişi, gelecek ellinin huyunu belirliyor. O huyu sen yazıyorsun, hem de yazdığın hiçbir production kodundan daha kalıcı biçimde.

Ama bir tuzak pusuda bekliyor: **hıza bağımlılık.**

Her işi kendin görmeye öyle alışırsın ki, ekip büyüdükten sonra bile "ben yapsam daha çabuk olur" dersin. Bu cümle, startup'ı yerinde saydıran şeyin ta kendisi. Çünkü evet, bugün gerçekten daha hızlısın. Ama yarın da, altı ay sonra da işi sen görüyorsan, ekip orada neden duruyor?

Bir lokanta düşün. Beş masalık. Şef hem ocakta, hem menüde, hem kasada. Gayet normal. Ama aynı şef yüz masalık salonda her tabağı kendi eliyle çıkarmaya kalkarsa, masadaki herkes aç kalır.

Bu dönemin tek kuralı şu: **kod yaz, ama koda aşık olma.** Her commit aynı zamanda bir ders olsun. Pair programming yap, mimari kararı yaz, kafandakini dışarı çıkar. Çünkü o klavyeyi bir gün bırakacaksın. O gün ekip senin kafandakini bilmiyorsa, şirket de seninle birlikte duruverir.

Bu aşamada en kıymetli silahın teknik derinliğin. Framework, mimari, build-vs-buy, hepsinde son söz sende. Ne var ki bir üst basamağa çıktığında, aynı silah elinde ağırlaşmaya başlar.

## 50 Kişilik Ekipte CTO: Orkestra Şefi

Semahta ince bir denge vardır: herkes kendi ekseninde döner, ama dönüş ortaktır. Tek tek hareketler var, hepsinin üstünde bir bütün var. Kimse yalnız dönmüyor, kimse de komşusunu taklit etmiyor. Herkes yerini biliyor, ortaya çıkan şey toplamdan büyük.

Elli kişilik bir ekibi yönetmek tam da bu. Ve rol burada kökten değişiyor.

En kritik pull request artık senden çıkmıyor. En çetrefil bug'ı artık sen çözmüyorsun. Belki IDE'yi açmayalı haftalar oldu. Hepsi normal.

Çünkü artık senin ürünün kod değil, **ekip**. Commit'lerin merge değil, **karar**. Deploy'ların feature değil, **süreç**.

Kendi ajansımı kurduğum günleri hatırlıyorum. Başlarda her projenin her satırına dokunurdum, geceleri production hatalarını kovalardım. Sonra beş kişi olduk, on kişi olduk. Bir gün fark ettim ki en çok değer kattığım anlar kod yazdığım anlar değildi. Bir junior'a bir kararın "neden"ini anlattığım, iki takımın teknik kavgasını çözdüğüm, müşteriye teknik borcu para diliyle tercüme ettiğim anlardı. [Dağıtık sistemlerde veri bütünlüğü](/tr/dagitik-sistemlerde-debezium) gibi derin bir konuyu masadaki herkesin anlayacağı dile çevirebilmek, bu aşamanın en pahalı becerisi.

Bu geçiş kolay değil, hele "yaparak öğrenmiş" biriysen. Klavyeden uzaklaşmak, kontrolü kaybetmek gibi gelir. Oysa tam tersini yapıyorsun: kontrolü **çoğaltıyorsun**. Bilgini taşıyan on kişi, bilginle sınırlı tek kişiden her zaman güçlüdür.

Gün de başka türlü akıyor artık. Standup'a "dün ne yaptım" demek için değil, önündeki taşları kaldırmak için giriyorsun. Tıkanan bir bağımlılık var mı, bekleyen bir mimari karar var mı? Öğleden sonra müşteri, retrospektif, teknik borç pazarlığı. PR'lara bakıyorsun ama hepsine değil; sadece emsal oluşturanlara, mimariyi eğip büken kararlara. Akşam ise gelecek çeyreğin haritası: hangi yatırım, hangi borç, hangi yetenek.

Bu dönemin en büyük tuzağı **kodu özlemek**. "Şu PR'ı ben çıkıversem" düşüncesi her gün kapını çalacak. Bazen de haklı çıkacak, gerçekten daha hızlı yaparsın. Ama her "ben yapayım" deyişinde birinin öğrenme sırasını çalıyorsun. Altı ay sonra yine sen yapıyorsun, çünkü o kişi öğrenemedi.

İşin en zor kavgası ekiple değil, kendinledir. Yıllarca değerini yazdığı satırla ölçmüş biri için, günün sonunda tek satır kod yazmamış olmak garip bir boşluk bırakır. Katkı grafiğin soluklaşır, içinden bir ses "artık üretmiyorum" der.

Üretiyorsun aslında. Sadece ürünün değişti. Artık ürettiğin şey, üretebilen insanlar. Avrupa'da enerji sektöründe CRM ekipleri yönetirken bunu çıplak gözle gördüm: ekibin en genç mühendisi, bir yıl önce pair programming'de gösterdiğim bir kalıbı kullanıp müşterinin en kritik entegrasyon sorununu çözmüştü. O an anladım, en iyi kodum başkasının elinden çıkmıştı.

## 500+ Kişide CTO: Haritacı

Bu ölçekte rol tümüyle stratejik. Günlük hayatta kod yok, belki aylardır terminal bile açmadın. Ve bu doğru.

Çünkü artık işin şirketin teknoloji yönünü belirlemek ve onu iş stratejisiyle aynı hizaya getirmek. Board'da beş yıllık haritayı sunuyorsun. VP of Engineering'lerle organizasyonu tasarlıyorsun. Cloud migration, platform değişimi, büyük build-vs-buy kararları senin masandan geçiyor.

Senin "kodun" başka bir dilde yazılıyor: strateji belgesi, organizasyon şeması, teknoloji radarı. Çıktın commit değil, **yön**.

Burada da bir uçurum var: **teknik kopuş.** Kod yazmayı bırakmak doğru, teknolojiyi takip etmeyi bırakmak felaket. Bu ölçekteki iyi CTO'lar zekalarını ya kişisel projelerde deney yaparak ya da en teknik insanlarla düzenli derin dalış oturumları kurarak diri tutuyor. Hiçbirini yapmayan, üç yıl sonra board'da teknik soruya cevap veremeyen "eski mühendis" oluyor.

Ve burada güzel bir paradoks çıkıyor karşına: bu ölçekte en güçlü silahın teknik bilgin değil, **tercüme yeteneğin**. CFO'ya "neden bu refactoring'e para koyalım?" sorusunu müşteri kaybı rakamıyla cevaplayan; mühendise "neden bu feature erteleniyor?" sorusunu pazar verisiyle açıklayan biri. İki dünyanın arasında duran köprü.

Gerald Weinberg'in dediği gibi, ne kadar teknik görünürse görünsün her şey aslında bir insan meselesidir. Bir platform göçü yalnızca teknik bir proje değil, yüzlerce insanın iş yapma biçimini değiştiren bir dönüşümdür. [Mattermost'tan Matrix'e taşınma](/tr/mattermost-matrix-tasinma) küçük bir ekipte bile ciddi bir karardı; yüzlerce kişilik bir yapıda o kararın ağırlığını düşün.

## AI Çağında CTO: Yeni Bir Denklem

Az insan, az cephane, az zaman. Bir kurtuluş mücadelesinin koşulları çoğu zaman böyledir, ve işte o darlık stratejik zekayı doğurur. Elindeki her kaynağı katlayarak kullanmak zorunda kalırsın.

AI çağında CTO'nun durumu buna benziyor. Kaynaklar aynı, ama her birinin çarpanı değişti. [AI'ın yazılımı nasıl dönüştürdüğünü](/tr/ai-vibecoding-hidrolik-direksiyon) daha önce uzun uzun yazmıştım; burada o dalganın doğrudan CTO rolüne çarpan tarafına bakacağım.

Bir mühendis bugün AI destekli araçlarla eskinin iki üç katı hızda kod üretiyor. Ama bu, daha az mühendis değil, daha başka mühendis demek. AI'ın kustuğu kodu tartabilen, yönlendirebilen, yerine oturtabilen insanlar.

Bunun CTO için üç sonucu var.

Birincisi, **"kod yazmak" yeniden tanımlandı.** Her satırı elin yazmak zorunda değilsin. Ama hangi satırın yazılması gerektiğini bilmek, çıkan kodun kalitesini görmek, aracı doğru yöne kışkırtmak, işte yeni teknik yetkinlik bunlar.

İkincisi, **ekibin şekli oynuyor.** Basit işleri artık agent'lar üstleniyor. Bu da ekip planını sıfırdan düşünmek demek. Hangi iş AI'a gider, hangi rol dönüşür, hangi yeni rol doğar?

Üçüncüsü, ve en mühimi, **karar hızı arttı.** Prototip, test, iterasyon döngüsü kısaldı. Eskiden "iki haftalık sprint'e alalım" dediğimiz bir fikri, bugün birkaç saatte çalışan bir prototipe çeviriyoruz. Denemenin maliyeti düştükçe, strateji ile taktik arasındaki mesafe de daralıyor.

Ama dikkat: AI bir araç, strateji değil. "Biz AI kullanıyoruz" demek, "biz bilgisayar kullanıyoruz" demek kadar içi boş bir cümleye dönüşüyor. Mesele aracı **nerede** ve **nasıl** kullandığın. O kararı verecek olan hala insan.

Bu çağda CTO'nun bir yeni borcu daha var: ekibini AI ile çalışmaya hazırlamak. "Şu tool'u kurun" demekle bitmez bu. Mühendisin AI çıktısını eleştirel gözle süzebilmesini sağlamak, aracın nerede tökezlediğini öğretmek, "çalışan kod" ile "doğru kod" arasındaki çizgiyi koruyan bir kültür kurmak gerek. AI çalışan kodu kolay üretiyor. Doğru kod hala insan kararı istiyor.

## Peki Ne Zaman Klavyeye Dokunmalı?

Buraya kadar bir çizgi çektik: küçük ekipte kod, büyük ekipte strateji. Gerçek hayat bu kadar temiz değil tabii. Elli kişilik ekibin CTO'su da ara sıra kod yazar, beş yüz kişilik yapının CTO'su da ara sıra terminal açar.

Soru "yazmalı mı, yazmamalı mı?" değil. Soru şu: **neden yazıyorum?**

Yıllar içinde kendime birkaç pusula edindim.

**Evet, dokun:**

- **Kriz anında.** Production yandıysa ve o sistemin mimarisini en iyi sen biliyorsan, araya girmek sorumluluktur. Ama yangın söndükten sonra şunu sor: bir dahakine bensiz söndürülebilir mi?
- **Prototip anında.** Yeni bir yaklaşımı kendi elinle denemek, kararının kalitesini yükseltir. Bazen doğrudan denemek, delege edip arada bir çeviri katmanı oluşturmaktan hızlı ve isabetli olur. Yalnız [prototip ile ürün arasındaki ölümcül vadiyi](/tr/prototip-olumcul-vadi) unutma: prototip bir şeyi kanıtlamak içindir, ürünün kendisi değil.
- **Öğretmek için.** Pair programming'de yazdığın kod "ben yapayım çabuk olsun" değil, bilgi aktarımıdır. Bu makbul.
- **Kendi bahçende.** Yan projelerde, kişisel deneylerde teknik kasları diri tutmak için kapı hep açık.

**Hayır, bırak:**

- **"Ben daha hızlı yaparım" diyorsan.** Bu cümle, delege edemediğinin ve ekibine yatırım yapmadığının itirafıdır.
- **Feature geliştiriyorsan.** CTO'nun sprint backlog'unda kendi task'ı varsa, ya kadro eksiktir ya öncelik karışmıştır.
- **Ego için yazıyorsan.** "Hala kod yazabiliyorum" ispatına ihtiyacın yok. Ekip seni son commit'inin tarihine değil, son kararının kalitesine bakarak dinler.
- **Darboğaz olduysan.** Senin onayın olmadan merge çıkmıyorsa, yazdığını kimse anlamıyorsa, sen yoksan deploy duruyorsa, sorun kodda değil, sende.

Hepsinin özü tek cümle: kod yazmak bir araçtır, bir kimlik değil. CTO'nun kimliği "kod yazan kişi" değil, "doğru kararı veren kişi" olmalı. Bazen doğru karar kod yazmaktır, çoğu zaman değildir. Ve bu pusula sabit de değil; aynı insan, aynı şirkette, farklı dönemde farklı yöne döner. Yeni bir ürün hattı açılırken birkaç hafta prototip moduna geçebilirsin; büyük bir organizasyon değişiminde aylarca satır yazmayabilirsin.

## CTO'nun Asıl Kodu: Kültür Mühendisliği

Bir şirketin teknoloji kültürü, CTO'nun en uzun ömürlü kodudur. Framework değişir, dil evrilir, mimari refactor edilir. Ama ekibin nasıl karar verdiği, hatayı nasıl karşıladığı, bilgiyi nasıl paylaştığı yıllarca çalışmaya devam eder.

Gerçek CTO çıktısını düşününce aklıma yazılan satırlar değil, kurulan mekanizmalar geliyor:

- **Suçlamayan postmortem.** Hata yapan kişi değil, hataya izin veren sistem masaya yatırılır.
- **Şeffaf karar kaydı.** ADR'ler, RFC'ler, içeride dolaşan teknik yazılar.
- **Junior'ın çekinmeden soru sorabildiği ortam.** "Aptal soru yoktur" lafı duvarda değil, koridorda yaşar.
- **Teknik borcun para diline çevrilmesi.** "Bunu refactor etmeliyiz" değil, "bu, şikayetlerin üçte birinin kaynağı."
- **Deney kültürü.** Başarısızlığın cezalandırılmadığı, öğrenmenin ödüllendirildiği bir iklim.

Bunların hiçbiri tek satır kod istemiyor. Ama hepsi mühendislik disiplini, sabır ve empati istiyor. Ve işin paradoksu, teknik derinlik de istiyor; çünkü bu kültürü ancak yazılımın nasıl yapıldığını iliklerine kadar bilen biri kurabilir.

Bir güvenlik şirketinde yazılım ekibini yönetirken, teknik olarak en parlak mühendisimiz vardı. Her problemi tek başına çözerdi. Ekip büyüyünce o "her şeyi ben hallederim" refleksi takımı felç etti. Kimse inisiyatif almıyordu, çünkü "nasılsa o yapar" beklentisi yerleşmişti. Benim işim o kişiyi durdurmak değil, bilgisini çoğaltacak mekanizmayı kurmaktı. Code review standardı, pair programming rutini, dokümantasyon alışkanlığı. Bunlar tek kişinin kafasındakini on kişiye yaydı.

İşte CTO'nun asıl kodu bu: bilgiyi çoğaltan, kararı hızlandıran, hatayı derse çeviren **sistemler** kurmak. En iyi kod, kimsenin fark etmediği koddur; altyapı gibi görünmez ama her şeyi ayakta tutar.

## Yanlış Sorudan Doğru Cevaba

Yola "CTO kod yazmalı mı?" diye çıktık. Umarım buraya geldiğimizde bu sorunun ne kadar eksik olduğu ortadadır.

Doğru olan tek bir soru değil, bir dizi soru:

- Şirketin hangi aşamasındayım?
- Ekibimin bana en çok ihtiyaç duyduğu yer neresi?
- Kod yazarak mı, başka türlü mü daha çok değer üretiyorum?
- Bugün yazdığım kodu yarın başkası yazabilir mi?
- Yazma sebebim ekibin ihtiyacı mı, benim ihtiyacım mı?

Cevap kişiden kişiye, şirketten şirkete, hatta aydan aya değişir. Rolün güzelliği de burada zaten: sabit bir iş tanımı yok, sabit bir "doğru" yok. Tek sabit, sürekli kabuk değiştirmek. Baş aşçıdan orkestra şefine, oradan haritacıya. Her basamakta da "şimdi doğru olan ne?" diye yeniden sormak.

Baştaki kavgaya dönelim: iki taraf da haklı, iki taraf da haksız. Çünkü sorunun kendisi bağlamsız, bağlamsız soruya da cevap olmaz. Bağlamı en iyi bilen kişi, o koltukta oturanın ta kendisi. Ego'yu bir yana bırakıp "şu an en büyük darboğaz nerede?" diye sorabilmek, teknik zekadan kıymetli bir yetenektir.

Sonuçta CTO'nun asıl işi ne kod yazmak ne de yazmamak. Asıl iş, her gün "bugün en büyük etkiyi nerede yaratırım?" sorusunu dürüstçe cevaplayabilmek. Cevap kimi gün bir terminal penceresinde, çoğu gün bir beyaz tahtanın önünde, her gün insanların arasında. Ve belki en önemlisi: bu soruyu sormayı hiç bırakmamak. Teknoloji durmuyor, şirket durmuyor, pazar durmuyor; o yüzden CTO da durmamalı. Bu soru, CTO'nun kendine her çeyrek yeniden yazdığı en kritik unit test.

> Yazının İngilizce versiyonuna [bu linkten](/should-a-cto-write-code) ulaşabilirsin.

---

## Seodisias: Ücretsiz Bir SEO Aracını Neden Yazdım
URL: https://aligundogdu.com/tr/seodisias-hikayesi
Kendi sitemi göremediğim bir gece, SEO analizinin neden hep bir ödeme duvarının ardında olduğunu sordum. Sonra ücretsiz, verisi cihazından çıkmayan bir crawler yazmaya oturdum.

## Su Gibi Olması Gereken Şey

Denizli'de, evime on beş dakika mesafede iki bin yıllık bir su kemeri var. İlk bakışta yıkık taş yığını. Ama eğilip bakınca, Roma mühendislerinin suyu şehrin her köşesine aynı basınçla taşımak için yaptığı hesabı görüyorsun. Zengin mahalleye de, çarşıya da, hamama da aynı su akıyordu. Su bir ayrıcalık değildi, herkesin hakkıydı.

Dijital dünyada çoğu zaman bunun tersini yapıyoruz. En basit bilgiyi bile bir kapının ardına koyuyoruz, üstüne fiyat etiketi asıyoruz. Bu yazı, o kapılardan birini kırmaya çalışan küçük bir aracın hikayesi.

## "İyi Araç Paralı Olur" Diye Bir Mit Var

SEO'ya ilk adım attığında karşına çıkan tablo nettir: her şey paralı. Screaming Frog'un ücretsiz sürümü 500 URL ile sınırlı. Ahrefs ayda 99 dolar, Semrush 130. Her birinin bir kapısı, kapının üstünde bir etiketi var. Ve sektörde kimsenin yüksek sesle söylemediği bir kabul dolaşır: ciddi analiz istiyorsan ciddi para ödeyeceksin.

Bir saniye durup şunu sormak istiyorum: SEO analizinin temelinde ne var? Bir siteye HTTP isteği atmak. Dönen HTML'i ayrıştırmak. Başlık etiketini okumak, meta açıklamayı kontrol etmek, başlık hiyerarşisini çıkarmak, linkleri takip etmek, durum kodlarını kaydetmek.

Bunların hiçbiri sır değil. HTTP protokolü açık, HTML açık, Google'ın kendi dokümantasyonu açık, robots.txt düpedüz bir metin dosyası. O zaman bu bilgiyi okuyan araç neden bir kasanın arkasında? Cevap basit: bu araçlar teknik analiz satmıyor sadece, arayüz satıyor, kolaylık satıyor, çoğu zaman da verini kendi sunucusunda işleyip sana geri satıyor.

Karmaşık işlerin, backlink profillerinin, dev veri setlerinin paralı olmasına bir itirazım yok; onlar gerçekten maliyetli. Ama kendi sitendeki kırık linki görmek? Bu su gibi olmalı.

Bu rahatsızlık bende soyut başlamadı. Bir gece kendi projemin SEO durumuna bakmak istedim, Screaming Frog'u açtım, 500 URL limitine takıldım. Site altı yüz küsur sayfaydı, kalanını göremiyordum. Lisans için yıllık 259 dolar isteniyordu, sırf kendi siteme bakmak için. O an "bu kadar temel bir şey için neden birine para veriyorum?" diye sordum. Sorunun cevabını aramak yerine, aracı yazmaya oturdum.

## Gece Yarısı, Mutfak Masası

Seodisias şık bir planlama toplantısında doğmadı. Çocuklar uyuduktan sonra, mutfak masasında bir laptop ve bir bardak çayla başladı.

İlk hafta sadece crawler'ın iskeletini yazdım. Bir URL al, istek at, HTML'i ayrıştır, başlığı bul. Kulağa basit geliyor ama iş detayda tökezliyor. Yönlendirme zincirlerini takip etmek, zaman aşımını yönetmek, karşı sunucuyu boğmadan taramak, göreli linkleri tama çevirmek, robots.txt'ye saygı göstermek. Her biri ayrı bir küçük problem.

İkinci hafta eş zamanlı taramanın yarattığı kaosla tanıştım. Beş yüz goroutine aynı anda istek atınca sunucu rate limit'e takılıyor, bağlantılar kopuyor, yarım kalan ayrıştırmalar bellekte zombi gibi dolaşıyor. Go'nun eş zamanlılık modeli güçlü ama disiplin ister. Semaphore deseni, worker havuzu, düzgün kapanış. Her birini sıfırdan kurdum, her biri bir gece.

Üçüncü hafta arayüzle boğuştum. Wails'in Go ile JavaScript arasındaki köprüsü temiz çalışıyor, ama binlerce satır tarama verisini ekrana taşırken performans çöküyor. Sanal kaydırma, tembel render, parça parça veri aktarımı. Bunları çözmeden uygulama kullanılabilir değildi.

Bir ay sonra ilk gerçek taramayı yapıp kendi siteme baktığımda, ekranda yüzlerce satır akarken bir an durdum. Çalışıyordu. Paralı araçlarda gördüğüm her temel metrik, şimdi kendi yazdığım kodun çıktısıydı. "Bunu paylaşmalıyım" dedim.

Ama bir yan projeyi paylaşılabilir bir ürüne çevirmek, onu yazmaktan zor; [prototiple gerçek ürün arasındaki o ölümcül vadiyi](/tr/prototip-olumcul-vadi) burada bir kez daha geçtim. Hata mesajları anlaşılır mı? Windows'ta fontlar bozuluyor mu? macOS imzasız uygulamayı "güvenilmez" diye mi işaretliyor? Toplam altı ay sürdü. Romantik bir süreç değildi; çoğu zaman "neden uğraşıyorum" diye sordum. Cevap hep aynıydı: çünkü bu araç var olmalı. Bunu kovalamak bana tanıdık, çünkü keyif almadığım kodu uzun süre taşıyamıyorum, taşımaya çalışınca da projeyi bırakıyorum. Modüler başlamamın, gece yarısı bir hatayı düzeltirken hala keyif alabilmek istememin sebebi bu.

## Neden Lokal, Neden Go

İlk soru hep "neden SaaS değil?" oldu. Çünkü SaaS demek, kullanıcının verisinin benim sunucumdan geçmesi demek. Biri sitesini taratınca tüm URL yapısı, başlıkları, link grafiği bende olurdu. Onu saklamak, korumak, mevzuata uygun işlemek benim sorumluluğum olurdu. Ben varsayılan olarak kullanıcının verisine hiç dokunmak istemedim.

Masaüstünde her şey kullanıcının makinesinde kalıyor: tarama verisi yerel bir SQLite'ta, raporlar yerel dosyalarda. Tek başına kullandığın sürece hiçbir şey dışarı çıkmıyor. İleride ekip işbirliği ya da AI destekli analiz bulut gerektirecek, ama o her zaman senin bilinçli tercihin olacak. Varsayılan yerel, paylaşım yalnızca sen istersen.

Go'yu performans için seçtim; bir crawler yüzlerce isteği paralel yönetmek zorunda ve goroutine modeli bu işe biçilmiş kaftan. Wails ise masaüstünü Electron'un şişkinliği olmadan çözdü, Go arka uç ile web ön yüzünü 15 MB'lık bir uygulamada birleştirdi. Wails'le ilk kavgamı [ayrı bir yazıda](/tr/wails-notlarim) anlatmıştım. İçeride 32 bağımsız analiz modülü var; her biri tek bir işe bakıyor, biri başlık etiketine, biri SSL'e, biri robots.txt'ye. Yeni bir kontrol eklemek, mevcut sistemi bozmadan mümkün oluyor.

Bu arada AI'ı bu işin neresine koyduğumu merak edersen: kod yazarken onu bir hile değil, [hidrolik direksiyon gibi](/tr/ai-vibecoding-hidrolik-direksiyon) gücü çoğaltan bir araç olarak kullanıyorum. Yönü hala ben veriyorum.

## İsim Nereden Geliyor

Bir gece geç saatte, terminalde ilk başarılı taramayı izlerken "buna bir isim lazım" dedim. Denizli'nin antik kentlerini düşündüm. Laodicea'nın hemen yanında, taş işçiliğiyle ünlü Aphrodisias var.

SEO + Aphrodisias = Seodisias.

Aphrodisias'ın taş ustaları taşa şekil vermezdi, taşın içindeki şekli bulurdu. Bu araç da bir siteye hükmetmiyor, içindeki gerçeği ortaya çıkarıyor. İsim o gece kaldı, bir daha değiştirmedim.

## Dürüst Olmak Gerekirse

Bu alan boş değil. Screaming Frog yıllardır bu işin kralı; olgun, derin, kalabalık bir kullanıcı tabanı var. Sitebulb, SiteGuru ve daha niceleri mevcut. Peki neden bir tane daha?

Çünkü hiçbiri aynı anda şu üçünü vermiyor: **ücretsiz, lokal ve limitsiz.** Screaming Frog ücretsizde 500 URL ile sınırlı, ücretlisi yıllık 259 dolar. Web tabanlı araçlar verini kendi sunucusundan geçiriyor. Seodisias veriye dokunmuyor, limit koymuyor, kayıt istemiyor. Bir aracın senden ne istediği, seni nasıl gördüğünü ele verir: veri isteyen araç seni müşteri görür, hiçbir şey istemeyen araç kullanıcı.

Eksikleri de söyleyeyim. Screaming Frog'un yıllarca biriktirdiği özellik derinliği henüz Seodisias'ta yok. Backlink analizi yok, çünkü o gerçekten sunucu tarafı altyapı isteyen bir iş. Ama temel teknik SEO denetimi için, paralı alternatiflerin yaptığının çoğunu yapıyor, üstelik tek kuruş istemeden.

## Peki Para Nasıl Kazanılacak

Haklı bir soru. Plan basit: temel analiz sonsuza dek ücretsiz; ekip işbirliği ve AI destekli öneriler ücretli katmanda. Tek başına çalışan biri tüm temel özelliklere her zaman bedava erişecek. Beş kişilik bir ekip ortak rapor istiyorsa, AI'dan otomatik öneri ya da Jira entegrasyonu lazımsa, ticari katman orada devreye giriyor. Tanıdık bir model: WordPress'in yaptığı da bu. Çekirdek bedava, ekosistem ve kurumsal ihtiyaçlar paralı.

Şunu da net söyleyeyim, çünkü bir vaat değil tasarım kararı: temel SEO analizi her zaman ücretsiz kalacak. Çekirdeği kısıtlayıp sonra para istemek, bu projenin baştan reddettiği şey.

## Yarın Ne Var

Bugünkü hali vizyonun belki üçte birini karşılıyor. Sıradaki büyük adım, AI destekli analiz katmanı: tarama sonuçlarını bir modele verip "bu sitenin en kritik üç sorunu ne ve nasıl düzeltilir" sorusuna sade, aksiyon alınabilir bir cevap almak. Prototipini çalıştırdım, sonuçlar umut verici. Sonrası karşılaştırmalı analiz (siteyi bir ay arayla tarayıp farkı görmek) ve modül sayısını artırmak.

Bir de daha büyük bir bahis var. Arama, AI cevaplarına doğru kayıyor; sitenin yalnızca Google'da değil, ChatGPT ya da Perplexity'de nasıl göründüğü önem kazanıyor. Seodisias'ın yönü oraya, AI görünürlüğünü ölçebilen bir araca doğru.

## Suyun Akışı

Laodicea'nın su kemerleri artık su taşımıyor. Ama arkasındaki ilke hala geçerli: kaynağı herkese aç, eşit dağıt, kimseyi susuz bırakma.

Seodisias bunun küçük, dijital bir denemesi. Büyük her yapı tek bir taşla başlar; bu da bir mutfak masasında, gece yarısı, bir bardak çayla başladı. İndirmek istersen [seodisias.com](https://seodisias.com) orada. Ve sen de kendi işini kuruyorsan, mümkünse su kemerlerini halka açık tut. Çünkü su akarken herkes kazanır.

---

## Mattermost'un 10.000 Mesaj Sınırı ve Matrix'e Taşınma Hikayem
URL: https://aligundogdu.com/tr/mattermost-matrix-tasinma
Mattermost bir sabah kurumsal hafızamızı 10.000 mesajlık bir duvarın arkasına koydu. Alternatifleri dürüstçe tarttım, Matrix protokolüne geçtim ve taşıma için kendi aracımı yazdım.

## Kalenin Kapısı Kapanınca

İki yıl önce, daha yolun başında bir startup olarak iletişim altyapımızı kurarken önümüzde iki yol vardı. Biri, kullanıcı başına dolarla ödenen, verinin bulutta ve bizim kontrolümüz dışında durduğu kapalı sistemler. Diğeri, ipleri tamamen elimizde tutabileceğimiz açık bir yapı.

Türkiye'de bir girişim yönetiyorsan maliyet bir tasarruf kalemi değil, hayatta kalma meselesidir. [Mattermost](https://mattermost.com/), o dönemki Community Edition'ıyla tam aradığımız şeyi verdi: kendi sunucumuzda, kendi güvenlik duvarımızın arkasında, verinin gerçek sahibi olduğumuz bir ortam. Go ve React üzerine kurulu, GitLab ile derin entegrasyonu olan, teknik ekiplerin sevdiği bir araç. O gün için doğru karardı.

Sonra Mattermost, Community Edition'ı sessizce "Entry Edition" yaptı ve yanına bir [10.000 mesaj sınırı](https://docs.mattermost.com/product-overview/editions-and-offerings.html) koydu. Bu teknik bir limit değil, yapay bir bariyer. Bir ekibin geçmiş mesajlarına erişimini kesmek, sadece bir özelliği kısıtlamak değil; o ekibin hafızasını bir ödeme duvarının arkasına kilitlemek.

## Veri Sadece Bayt Değildir

Bir kurumun verisi, veritabanında kapladığı yerden ibaret değil. İki yıl önceki bir mesajdaki ton, bir kriz anında alınan kararın mantığı, bir hatadan sonra yazılan post-mortem. Hepsi birleşip şirketin nasıl düşündüğünü oluşturuyor. 10.000 mesaj sınırı, tam da bu birikimi kesip atıyor.

Bu yüzden hafıza meselesini ciddiye alıyorum. Anadolu'nun kalbinde Hattuşaş'ta Hititler, kazandıkları savaşı da kaybettikleri kıtlığı da kil tabletlere kazırdı. Çünkü yazıya geçmeyen unutulur, unutulan da aynı hatayı tekrar eder. Bugün "kurum kültürü" dediğimiz şey, o kil tabletlerin veritabanı satırlarına taşınmış hali. Geçmişine erişimin kesilirse, geleceğe dair her kararın bir tahmine dönüşür.

Karar vermem gereken nokta buydu: bu sınırı kabul edip hafızamızı her ay kiralık mı tutacaktık, yoksa ipleri yeniden elimize mi alacaktık?

## Masadaki Seçenekleri Dürüstçe Tartmak

Mattermost'tan çıkacaktık, ama nereye? Her seçeneğin kendi pürüzü vardı.

[Rocket.Chat](https://www.rocket.chat/) güçlü görünüyor ama mimari olarak hantal kalabiliyor, üstelik kurumsal özellikleri (LDAP gibi) her an daha sıkı bir ödeme duvarının arkasına geçirme potansiyeli taşıyor. Aynı filmi bir daha izleme riski. Zulip'in konu-bazlı yapısı muhteşem, ama mobil bildirim tarafındaki kısıtlar ve self-hosted kurulumun teknik maliyeti, dinamik bir ekip için ileride başka tıkanıklıklar demek.

Discord'u görmezden gelmek de dürüst olmaz. Sadece kullanıcı deneyimi ve stabilite üzerinden puanlasaydım, listedeki herkesi geçerdi. Ama bir teknoloji liderinin masasında yalnızca "kullanım kolaylığı" yazmaz; "sürdürülebilirlik" ve "hukuki zemin" de en az kod kalitesi kadar yer kaplar. Türkiye'de bir startup yönetiyorsan Discord güvenli bir liman değil: erişim engelleri, kapalı bir kutuda ve ülke dışında tutulan veri. Bir sabah ana iletişim kanalının mahkeme kararıyla kapandığını görmek risk yönetimi değil, doğrudan operasyonun durması olur. Bir belirsizlikten çıkıp başka bir belirsizliğe sığınamazdım.

## Yazılım Değil, Protokol

Radarıma [Matrix](https://matrix.org/) ve referans sunucusu [Synapse](https://github.com/element-hq/synapse) girdi. Matrix'i bir yazılım değil, bir protokol olarak görmek gerekiyor. Bugün e-posta nasıl tek bir firmanın tekelinde değilse, Gmail'den Outlook'a mail atabiliyorsak, Matrix de iletişim için aynı açık zemini vaat ediyor.

Dürüst olayım: Matrix'e de körü körü bağlanmıyorum. Ekosistemin büyük kısmını bugün Element üstleniyor ve günün birinde onlar da Mattermost'un yoluna sapabilir. Ama protokolün merkeziyetsiz doğası bir sigorta sunuyor. Bir sunucu beni kısıtlamaya kalkarsa, veriyi başka bir sunucuya taşımak ya da kendi yapımı kurmak, kapalı bir sistemden kaçmaktan çok daha kolay. Teknoloji dünyasında hiçbir şeye tam güvenmemeyi öğrenecek kadar fırtına gördüm. Şu an elimdeki en özgür seçenek bu.

## Pazar Anahtarı Vermeyince

Karar verilmişti, ama mevcut köprü çözümlerine bakınca karşımda hantal bir yapı buldum. Çoğu, kurulumda bile insanı yoran konfigürasyonlarla geliyor, bir hata anında kaldığı yerden devam edemiyordu. Sunucular arası manuel taşımalar, yarım kalan aktarımlar. Yarım aktarılmış, metadata'sı bozulmuş bir arşiv ise aslında hiç olmamış bir arşivdir.

Burada içimdeki maker devreye girdi. İhtiyacım olan şey, uzak sunucularla boğuşmak yerine kendi makinemden tüm süreci yönetebileceğim bir araçtı. Pazarda bulamadığım bu çözümü, planlamamı [AI ile hızlandırarak](/tr/ai-vibecoding-hidrolik-direksiyon) yazdım. [MatrixMigrate](https://github.com/aligundogdu/matrixmigrate) böyle doğdu.

Bu araç hala gelişiyor. Temiz bir başlangıç için onlarca kez Synapse kurup siliyorum, her seferinde "nerede takılırız?" sorusunun peşine düşüyorum. Çünkü göçün temelini sağlam atmazsam, yarın Matrix'te de aynı hafıza sorunuyla boğuşurum. Amacım veriyi bir yerden bir yere fırlatmak değil, hata payını en aza indiren, adım adım kendini doğrulayan bir geçiş hattı kurmak.

## Mülkiyet, Faturayı Ödemek Değildir

Bu süreç bana şunu bir kez daha gösterdi: teknolojide mülkiyet, faturayı ödeyince sahip olunan bir şey değil. Mülkiyet, verinin üzerinde kurduğun egemenliktir. Birkaç şeyi de kendime not ettim.

- **Hafıza pazarlık kozu olamaz.** Bir ekibin geçmişi, fiyat artışı için rehin tutulacak bir şey değil.
- **Sahiplik protokolden gelir.** Bir yazılıma değil, bir protokole güvenmek bağımsızlığın ilk adımı.
- **Pazar anahtar vermiyorsa, anahtarı kendin döversin.** Çoğu zaman "imkansız" diye görünen şey, sadece henüz yazılmamış koddur.

Mattermost'un iş modeli bugün bizi bu göçe zorladı, yarın Matrix tarafında da benzer rüzgarlar esebilir. Ama bir teknoloji liderinin asıl işi gemiyi hangi limana bağladığı değil, içindeki yükün, yani kurumsal hafızanın güvende kalmasıdır. Bunun nasıl bir karar olduğunu, [CTO'nun rolünü tartıştığım yazıda](/tr/cto-kod-yazmali-mi) daha geniş anlatmıştım. Biz şimdilik kendi köprümüzü kurup hafızamızı omuzlayarak daha özgür bir zemine yürüyoruz.

> Yazının İngilizce versiyonuna [bu linkten](/mattermost-matrix-migration) ulaşabilirsin.

---

## Prototip ile Ürün Arasındaki Ölümcül Vadi
URL: https://aligundogdu.com/tr/prototip-olumcul-vadi
Çalışan bir prototip neden ürün değildir? Vitamin mi ağrı kesici mi, tasarım aşırılığı ve müşteri taleplerinde çizgiyi ne zaman korumalı.

## Yüzemeyen Gemi

1628'in ağustosunda Stockholm limanı bir tören yeriydi. İsveç Kralı Gustavus Adolphus'un emriyle yıllarca üzerinde çalışılan savaş gemisi [Vasa](https://en.wikipedia.org/wiki/Vasa_(ship)), büyük bir kalabalığın önünde suya indirildi. Çağının mühendislik harikasıydı. Kral daha önce hiçbir gemide görülmemiş bir ateş gücü istemiş, mühendisleri fazladan top bataryaları eklemeye zorlamıştı. Güç de yetmezdi, gemi aynı zamanda imparatorluğun ihtişamını taşımalıydı. Gövdesi yüzlerce ahşap oyma heykelle, altın varakla, ağır süslemeyle donatıldı.

Vasa limandan ayrıldıktan 1300 metre sonra hafif bir rüzgarla yan yattı. O görkemli toplar, o göz kamaştıran heykeller, o kusursuz tasarım, geminin dengesini öyle bozmuştu ki dakikalar içinde sulara gömüldü.

Mühendisler kralın bütün taleplerini eksiksiz yerine getirmişti. Daha çok özellik, daha çok görkem. Kağıt üzerinde her şey kusursuzdu. Yalnızca tek bir şeyi unutmuşlardı: geminin yüzmesi gerekiyordu.

Bugün teknoloji dünyasında her gün yüzlerce Vasa suya iniyor.

Çoğu zaman kodumuzun derlenmesiyle, testlerin yeşil yanmasıyla, arayüzün piksel piksel kusursuzluğuyla övünürüz. Oysa yıllarca mutfağın içinde durduktan sonra gördüğüm tek bir gerçek var. **En mükemmel algoritma bile bir insanın derdine derman olmuyorsa, işlemci ısıtan bir gürültüden ibarettir.** Vasa'nın oymalı heykelleri neyse, kimsenin açmadığı bir uygulamanın tertemiz mimarisi de odur.

Bugün masadaki o steril dünyaların neden sokağın tozuna çarpınca dağıldığını konuşmak istiyorum. Çok mantıklı dediğimiz fikirler neden ürünleşemiyor? Yunus Emre'nin "ilim ilim bilmektir, ilim kendin bilmektir" düsturunu bir kenara yazalım. Bizim dünyamızda ilim, yazdığın kodun kime, neye, hangi iş değerine hizmet ettiğini bilmektir.

## Mutfaktaki Simya ve Prototip İllüzyonu

Ürün, çoğu zaman sessiz ve steril bir laboratuvarda doğar. Araştırma ve geliştirme, biz teknik insanlar için bir oyun parkıdır. Maliyet baskısı yok, müşteri şikayeti yok, yalnızca olasılıklar var.

Bu aşama bir sorunun etrafında atılan entelektüel bir turdur. Pürüzlü Mükemmellik kitabının dediği gibi, hızlanmak için bazen yavaşlamak gerekir. Buradaki derin araştırma, ileride bizi büyük teknik borçlardan kurtaracak temeli atar. Ama tam burada bir tehlike pusuya yatar: mutfak körlüğü.

Bir şefin kendi damak tadına göre sos hazırlamasıyla aynı yemeği beş yüz kişilik bir salonda servis etmesi arasında dağlar vardır. Geliştiriciler olarak araştırma sürecinde teknolojinin kendisine aşık oluruz. "Bu veritabanı milisaniyede milyon işlem kaldırıyor" cümlesi bizi heyecanlandırır. Asıl soru şudur: bizim kullanıcımızın milyon işleme ihtiyacı var mı?

Bu sürecin sonunda elimize geçen şeye prototip deriz. Bir düğmeye basarsın, arkada karmaşık işler döner, ekrana bir sonuç düşer. Teknik ekibin zafer çığlığı attığı andır. Oysa prototip, henüz ruhu olmayan güzel bir hayalettir.

[Rework](https://www.amazon.com/Rework-Jason-Fried/dp/0307463745)'un yazarları Jason Fried ve DHH'nin keskin tespiti tam burada devreye girer: prototipler, fikirlerin en çiğ halidir. Bir prototipin çalışıyor olması onu ürün yapmaz. Prototip bir teknik hipotezin kanıtıdır. Ürün ise ticari ve insani bir sözleşmedir. İkisinin arasındaki farkı ikiye ayırabilirim:

- **Prototip:** "Bakın, bu teknoloji çalışıyor."
- **Ürün:** "Bakın, bu teknoloji hayatınızı iyileştiriyor, buna para ve zaman vermeye değer."

Müşterisi hazır olmayan, bir acıyı dindirmeyen, yalnızca teknik bir meydan okuma olarak görülen her şey prototipten öteye gidemez. Dünyanın en ileri yapay zeka modellerini kullanabilirsin. O modeli kullanacak insanın hayatında somut bir değer yaratmıyorsan, yaptığın şey pahalı bir hobiden ibaret kalır. Yapay zekanın bir oyuncak değil, doğru kullanıldığında hidrolik direksiyon gibi gücü çoğaltan bir araç olduğunu [başka bir yazıda](/tr/ai-vibecoding-hidrolik-direksiyon) anlatmıştım. Buradaki mesele de aynı: araç ne kadar güçlü olursa olsun, direksiyonu tutan elin nereye gittiğini bilmesi gerekir.

## Rasyonel Fikirlerin İrrasyonel Mezarlığı

Mühendis zihninin en büyük handikabı, dünyayı düz bir denklem sanmaktır. Bizim için her şey A artı B eşittir C olmalıdır.

- **Önerme:** İnsanlar faturalarını takip etmekte zorlanıyor.
- **Çözüm:** Kusursuz bir fatura takip sistemi kodladım.
- **Beklenti:** Herkes bunu kullanacak.

Gerçek hayatın matematiği böyle işlemez. İnsanlar mantıklı karar veren makineler değil, alışkanlıklarına, korkularına ve duygularına göre davranan varlıklardır.

Bir fikrin mantıklı olması satılabilir olduğunu garanti etmez. Sektörde sık sorulan bir soru vardır: ürünün bir vitamin mi, yoksa bir ağrı kesici mi?

- **Vitamin:** Alırsan iyi olur, sağlığa faydalıdır, ama almayı unutsan da hayatın akar. Daha detaylı analiz sunan bir raporlama aracı gibi.
- **Ağrı kesici:** Başın çatlarken gece yarısı nöbetçi eczane ararsın. Şirketin nakit akışı durduğunda onu yeniden açan bir sistem gibi.

Bize mantıklı görünen fikirlerin çoğu, aslında güzelce paketlenmiş vitaminlerdir. Müşteri konfor alanını bozup yeni bir ürün öğrenmek için mantıklı bir sebepten fazlasını ister. Yakıcı bir ihtiyaç gerekir.

Rework felsefesi "kaşınan yerini kaşı" der. En başarılı ürünler genellikle pazar araştırması raporlarından değil, kurucunun kendi yaşadığı bir derde çare aramasından doğar. Ama ince bir çizgi var. Senin kaşındığın yer başkasının umurunda olmayabilir. Kendi fikrine aşık olmak, bir liderin yapabileceği en büyük hatadır. Fikrini doğrularken acımasız olacaksın.

## Tasarım mı, İşlevsellik mi?

Yazılım dünyasının bitmek bilmeyen o sessiz savaşını hepimiz biliriz. Bir yanda işi yapan motor olmanın kibriyle backend, öbür yanda kullanıcıyı karşılayan yüz olmanın ısrarıyla tasarım ekibi.

Bu kavga genellikle yanlış zeminde yapılır. "Tasarım ne kadar güzel olmalı?" yanlış sorudur. Doğru soru şudur: tasarım, işlevselliğin önüne geçmeden ona nasıl yol açar?

Kod yazarken düştüğümüz aşırı mühendislik tuzağının bir benzeri tasarımda da var. İşlevsiz bir tasarım boş bir kutudur, tasarımsız bir işlevsellik ise kullanılamayan bir hazinedir. Denge pragmatizmde gizli.

Kurumsal bir ürün geliştiriyorsan, kullanıcının psikolojisini anlaman gerekir. O insan yazılımı keyif için değil, mesaisi bitsin diye açıyor. İhtiyacı wow efekti yaratan animasyonlar, gölgeli düğmeler ya da sanat eseri gibi ikonlar değil. İhtiyacı netlik. Düğmenin yeri belli mi, hata mesajı anlaşılır mı, tablo okunabilir mi? Kurumsal üründe tasarım, bilişsel yükü azaltmak için vardır. Buraya harcanan her fazladan efor ürünü hantallaştırır. Eli yüzü düzgün, standartlara uyan temiz bir tasarım, bu dünyada mükemmelliğin ta kendisidir. Fazlası israftır.

Son kullanıcıya hitap eden işlerde durum biraz farklı, ama temel mantık aynı: mükemmeli bekleme. Tasarımın, kullanıcının güvenini kazanacak kadar profesyonel olması şarttır. Ama her ekranı piksel piksel işlemek, ürünün sahaya çıkışını geciktiren bir intihardır. Strateji kabul edilebilir bir başlangıç olmalı. Ürün sahaya iner, kullanıcıların refleksi izlenir. Hangi menüye tıklamaya çalışıyorlar, hangi renk dikkatlerini çekiyor, akış nerede tıkanıyor? Tasarım masa başında değil, sahada, kullanıcının parmak ucunda evrimleşir. [Pürüzlü Mükemmellik](https://www.kitapyurdu.com/kitap/puruzlu-mukemmellik/406815.html)'te dendiği gibi hayat pürüzlüdür, steril laboratuvar tasarımları gerçeğin kaosunda çoğunlukla tutmaz.

Unutma, Vasa'nın da muhteşem bir tasarımı vardı ama yüzemedi. Amacımız müzede asılacak bir tablo değil, okyanusu geçecek bir gemi yapmak.

## Akıl Tutulmaları

Klimalı toplantı odalarında beyaz tahtaya çizilen mimariler her zaman harikadır. Her şey modüler, her şey ölçeklenebilir. Şu olursa bu devreye girer, trafik artarsa sunucular kendiliğinden çoğalır. Sahaya inip ürünü gerçek kullanıcılarla buluşturduğun an, akıl tutulmaları başlar.

Rework'teki o çarpıcı cümleyi hatırlatmak isterim: planlama, sadece tahmindir. Teknoloji dünyasında bir, iki yıllık yol haritaları çıkarmak fal bakmaktan farksızdır. Altı ay sonra pazarın, teknolojinin ve rekabetin nerede olacağını kimse bilemez. Çoğu zaman "ürünü bitirip öyle çıkalım" hatasına düşeriz. Oysa ürün asla bitmez. Ürün yontulup kenara konan bir heykel değil, sürekli bakım, budama ve ilgi isteyen bir bahçedir.

Yönettiğim ekiplerde karşıma çıkan en zorlu stratejik mesele şu: bir müşterinin özel isteğini bütün müşterilere uyarlamaya çalışmak. Müşteri gelir, "raporları alırken satırlar kırmızı olsun, veriler tersten sıralansın" der. Geliştirici için bunu kodlamak on beş dakikadır. "Hallederiz abi" moduna girmek çok kolaydır. Ürün yöneticisi ve teknik lider içinse bu bir kabusun başlangıcıdır. Sorular birikir. Bu özellik yalnızca bu müşteriye mi açık olacak? Yoksa sisteme "Rapor Özelleştirme Modülü" adında devasa bir yapı mı ekleyeceğiz?

Ekipler tam burada boğulur. "Herkesi memnun edelim, ürünümüz çok esnek olsun" derken ortaya ne olduğu belirsiz, her yerinden ayar fışkıran, kullanımı imkansız bir Frankenstein çıkar. Masa başında esneklik diye tasarlanan yapılar, sahada karmaşıklık olarak geri döner. Karmaşıklık ise yazılımın en büyük düşmanıdır.

Gerçek bir teknoloji lideri "bunu yapabiliriz" diyen değil, "bunu yapmamalıyız, çünkü ürünün ruhuna ve sadeliğine aykırı" diyebilen kişidir. Zorluk kodu yazmakta değil, neyi yazmayacağına karar vermektedir. Bir liderin asıl işinin klavyeye dokunmak değil, doğru anda dokunmamak olduğunu [CTO'nun rolünü tartıştığım yazıda](/tr/cto-kod-yazmali-mi) daha geniş anlatmıştım.

## Ürünün Yaşam Döngüsü

Ürünü canlıya aldın. Tebrikler, asıl dert şimdi başlıyor. Mevlana'nın o eşsiz sözünü hatırlayalım: "Dünle beraber gitti cancağızım, ne kadar söz varsa düne ait. Şimdi yeni şeyler söylemek lazım."

Canlıdaki ürün yaşayan bir organizmadır. Büyür, acıkır, yani sunucu ve kaynak tüketir. Hastalanır, yani hatalar çıkarır. İlgi ister, yani müşteri desteği. Bu döngüde en kritik konu, müşteri talepleri karşısındaki duruşundur.

Henry Ford'a atfedilen o meşhur söz, "insanlara ne istediklerini sorsaydım daha hızlı atlar derlerdi", ürün yönetiminin anayasası gibidir. Bu sözü Ford'un gerçekten söylemediğini biliyorum, ama böyle yazılarda kullanmanın tadı bambaşka.

Müşteri sorununda her zaman haklıdır, çözüm önerisinde ise çoğu zaman yanılır. Sana "bir Excel'e aktar düğmesi koy" diyen müşteri aslında şunu söylüyordur: "Senin arayüzünde verimi analiz edemiyorum, güvendiğim limana, Excel'e kaçmak istiyorum." Senin işin o düğmeyi koymak değil, ürünün içindeki analiz yeteneğini güçlendirmektir. Müşterinin dediğini yapmakla derdini çözmek arasında dağlar vardır.

Peki ürün vizyonun müşteri talebiyle çatıştığında ne yaparsın?

Bazen çizgiyi korursun. Ürünün ana değer önerisinde inatçı olursun. Basitlik vaat ediyorsan, müşterilerin yüzde beşi istiyor diye ürünü karmaşıklaştırmazsın. "Hayır" demek bir kastır, çalıştırdıkça güçlenir. Yüzde birin istediği bir özellik için yüzde doksan dokuzun deneyimini bozmazsın.

Bazen de çizgiyi bilerek bozarsın. Pazarın dinamikleri temelden değiştiyse inat etmek aptallıktır. Yapay zeka dalgası dün vazgeçilmez olan bir özelliği bugün gereksiz kıldıysa, o özelliği çöpe atmaktan korkma. Teknik altyapını yakmak pahasına bile olsa iş değerini takip et.

## Yanmaktan Korkma

Farklı coğrafyalara dokunan projelerde öğrendiğim şu: ürün geliştirmek bir mühendislik harikası yaratmak değildir. Ürün geliştirmek; insan psikolojisini, ticareti, estetiği ve mühendisliği aynı potada eritmektir.

Masadaki pürüzsüz planların sahada bozulacak. "Asla patlamaz" dediğin servis en kritik müşteri demosunda sessiz kalacak. Günlerce uğraştığın arayüzü müşteri "çok karışık" bulacak. En mantıklı fikrin pazarın mantıksızlığına yenilecek. Bunların hepsi sürecin, o pürüzlü mükemmelliğin parçası. Nazım Hikmet'in dediği gibi: "Sen yanmasan, ben yanmasam, biz yanmasak, nasıl çıkar karanlıklar aydınlığa?"

Doğru ürünü bulmak için kodun içinde yanmayı, hata yapmayı, prototipleri yıkıp yeniden kurmayı göze almak gerekir. Ama hep tek bir hedefle: teknik bir başarı değil, sahada gerçek ellerde yaşayan bir değer üretmek.

Geleceğin liderleri yalnızca kodu bilenler değil, kodun insana değdiği o ince çizgiyi yönetebilenler olacak. Senin gemin Vasa gibi süslü ama kırılgan mı olacak, yoksa fırtınaya dayanıp mürettebatını karşı kıyıya taşıyan bir gemi mi? Seçim, yazdığın ilk satır kodda değil, kurduğun ilk hayalde gizli.

---

## AI Bir Hile Değil, Yeni Nesil Hidrolik Direksiyon
URL: https://aligundogdu.com/tr/ai-vibecoding-hidrolik-direksiyon
Her yeni araç çıktığında 'bu gerçek yazılımcılık değil' diyenler oldu. AI da o sırada. Ama mesele aracın kendisi değil, direksiyonu kimin tuttuğu.

## "Gerçek Yazılımcılık" Tartışması Hiç Bitmedi

Bu sektörde yeterince kaldıysan, aynı kavganın kılık değiştirip durmadan geri geldiğini görürsün. QBasic ile ekrana ilk "input"u yazdırdığım günlerden bugün dağıtık sistemlerde veri bütünlüğü kovaladığım günlere kadar değişmeyen tek soru: gerçek yazılımcılık nedir?

Bir zamanlar Assembly bilmeyene yazılımcı denmezdi. Sonra C geldi, "işletim sistemine hükmetmiyorsan sayılmazsın" dendi. IDE'ler gelişip kod tamamlama hayatımıza girince, kimileri buna düpedüz "tembellik" dedi. Bugün aynı bakış AI ve vibe coding'e dönmüş durumda. Eski tüfek meslektaşlarımın çoğu savunmaya geçmiş, "yasaklansın", "bu gerçek kodlama değil" diyor.

Bu savunma, yaklaşan dalgayı durdurmaya yetmeyecek. Bir kez daha.

## Fabrika Bacaları

Pembe tablo çizmeye gerek yok, gerçekçi olalım. AI rekabetin rengini değiştirdi. Eskiden bir tekstil fabrikasında her dikiş makinesinin başında bir işçi olurdu; otomasyon çoğunun yerini makineye bıraktı. Bugün tamamen insansız fabrika hala ütopya, ama yüz kişinin işini on operatörle yöneten fabrikalar gerçek.

Yazılımda da benzer bir kırılma var. Firmalar artık beş kişilik bir ekibin işini, AI ajanlarıyla tek kişiye yaptırmak istiyor. Yaptıracaklar da. Yeri kolayca doldurulabilen standart işi yapan yazılımcı için işsizlik riski, kaçınılmaz bir gerçek olarak önümüzde duruyor. Bu noktada her satırı elle tırnaklamak seni kurtaran bir can simidi değil; tam tersine, bu inat seni yavaşlatıp eleyebilir.

## Asıl Mesele: Direksiyonu Kim Tutuyor

Ama burada ince ve hayati bir çizgi var. Vibe coding bugün ne kadar başarılı olsa da bir sihirli değnek değil. Özellikle karmaşık, çok katmanlı mimarilerde, kıdemli bir geliştiricinin o anı kurtarmak için başvurduğu o "hacky" çözümleri AI tek başına henüz kusursuz çıkaramıyor.

Hiç kod bilmeyen birinin "AI ile her şeyi yaparım" diye yola çıkması büyük bir yanılgı. Basit bir arayüz çıkarabilir, evet. Ama işin içine veri bütünlüğü, ölçeklenebilirlik ve güvenlik girince, büyük ihtimalle "çalışan ama kaputun altı patlamaya hazır" bir sistem üretir.

> Bir not düşeyim: bunu bugünden yorumluyorum. Bu yazı yayına girene kadar çok daha iyi modeller çıkıp bu paragrafı geçersiz kılabilir. Olsun, ben yine de bugünden konuşuyorum.

Vibe coding, işten anlamayanı bir anda usta yapmaz. İşten anlayan, altyapısı sağlam geliştirici içinse devasa bir güç çarpanıdır. Mimariyi biliyorsan, AI en iyi asistanın olur. Bilmiyorsan, duvara daha hızlı çarpmanı sağlar. Seodisias'ı yazarken bunu bizzat yaşadım, [o hikayeyi ayrı anlatmıştım](/tr/seodisias-hikayesi): AI hızı verdi, ama nereye gideceğini bilen yine bendim.

## Gözlük Takmak Hile mi

Gözleri bozuk birinin gözlük takması hile mi, yoksa potansiyelini ortaya çıkaran bir araç mı?

Daha mekanik bir örnek vereyim. Eskiden kamyon sürmek kas gücü isterdi. Hidrolik direksiyon gelince şoförlük ölmedi, sadece kas gücü gerekliliği azaldı. Ama direksiyonun yumuşaması, ehliyetsiz birinin o tırı dağ yolunda sürebileceği anlamına gelmiyor. Bugün AI da bizim hidrolik direksiyonumuz: usta şoförü daha az yorar, acemiyi yoldan çıkarır.

Bir de zaman var. Eskiden en bol kaynak zamandı; insanlar yıllar süren sabırla taş işleyip eser çıkarabiliyordu. Bugün en kıt kaynak o. Fikrini üretime dökmediğin her dakika, dünyanın bir ucunda bir başkası aynı fikri hayata geçiriyor olabilir. AI'ın asıl vaadi de bu: kazandırdığı şey zaman.

## Bir Tahmin: Daha Az Değil, Daha Çok Yazılımcı

Yukarıda standart, tekrar eden işin otomatikleşeceğini söyledim. Ama buradan, çoğu kişinin aksine, "AI yazılımcıların işini alacak" sonucunu çıkarmıyorum. Gördüğüm şey iş kaybı değil, rol kayması.

AI yazılım yapmayı ucuzlattıkça, daha çok yazılım yapılır hale gelecek. Maliyeti yüzünden hiç yapılmayan binlerce küçük araç, iç sistem, otomasyon birden mantıklı olacak. Talep daralmıyor, genişliyor. Ve birinin o işin direksiyonunu tutması gerekiyor. Bu yüzden benim öngörüm kademeli bir azalma değil, artma: daha az satır yazan ama daha çok yön veren, doğrulayan, sistemi bir arada tutan yazılımcıya ihtiyaç giderek büyüyecek.

Dürüst olmam gereken birkaç yer var. Birincisi AI'ın kendi maliyeti. Onu çalıştırmanın bedeli, yani compute, token, lisans, nereye gidecek, kim ödeyecek, fiyatlandırma nasıl oturacak, burası hala sisli. Belki ucuzlar ve herkesin eline geçer, belki birkaç devin elinde pahalı kalır.

İkincisi, ve bunu daha az konuşuyoruz: yazılım üretmenin maliyeti düşerken, yazılımcının maaşı nereye gidecek? Bunu iki yöne de çekebilirim. Bir yandan, üretmek ucuzladıkça daha çok iş doğar ve işi gerçekten anlayan kişiye talep artar, bu da ücretleri yukarı iter. Öbür yandan, "AI zaten yapıyor, sen sadece yönetiyorsun" algısı, aynı işi daha azına yaptırma baskısını besleyebilir. Belki ikisi aynı anda olur: standart işin değeri ve ücreti düşerken, sistemi sırtlayan kişinin değeri ve ücreti yükselir. Bir tür kutuplaşma.

Bunların hiçbirini biliyormuş gibi yapmayacağım. Net gördüğüm tek şey şu: işi anlayan yazılımcıya talep artacak. Ama o işin ekonomisi, hem aracın maliyeti hem de insanın ücreti tarafında, henüz oturmadı.

## Dost mu, Düşman mı

Bu yazıyı "AI en iyi dostundur, güven ona" demek için yazmadım. Doğrusu şu: AI dostun olmayabilir. Hatta seni konfor alanından çıkaran, işine göz diken soğuk bir rakip de olabilir.

Ama şundan eminim: düşmanın da değil. Orada duran bir güç sadece. Tüm süreçlerini ona devredip otomatikleştirmek bir tercih; onu geliştirme döngünde sadece bir istasyon, bir hızlandırıcı olarak kullanmak da bir tercih. Ben yönettiğim ekipte ikincisini kurdum, ve [bunun nasıl bir karar olduğunu](/tr/cto-kod-yazmali-mi) ayrıca yazmıştım.

Düşmanlık ederek vakit kaybetme. Onu nasıl kullanacağın, direksiyonu nereye kıracağın senin işin. Ama o araç garajda duruyor ve rakiplerin kontağı çoktan çevirdi.

> Yazının İngilizce versiyonuna [bu linkten](/ai-is-not-a-cheat-code) ulaşabilirsin.

---

## Dağıtık Sistemlerde Veri Bütünlüğü ve Debezium Kararı
URL: https://aligundogdu.com/tr/dagitik-sistemlerde-debezium
Birden çok veritabanını tutarlı tutmaya çalışırken polling, spagetti kod ve dual write lanetine çarptım. Çözüm, veritabanına 'ne değişti' diye sormayı bırakıp loglarını dinlemekti: CDC ve Debezium.

## Birden Çok Yer, Tek Gerçek

Dağıtık sistem, en sade haliyle, farklı yerlerdeki parçaların tek bir ağmış gibi davranması demek. Aramayı MeiliSearch'te yaparsın ama asıl veri PostgreSQL'de durur. Pazarlama aracın kendi MySQL'inden çalışır. Web siten bir veritabanında, muhaseben başka birinde. Hepsi aynı ürün için birlikte çalışır.

Sorun da tam burada başlar: bu parçaların hepsi aynı gerçeği görmek zorunda. Birinde değişen veri, ötekinde de değişmeli. Yoksa kullanıcı bir yerde güncellediği şeyi başka yerde eski haliyle görür. Bu yazı, o tutarlılığı sağlamak için çektiğim çileyi ve sonunda oturduğum çözümü anlatıyor.

![Farklı veritabanları ve servislerin tek bir ağ gibi birlikte çalıştığı bir dağıtık sistem](/images/blog/dagitik-sistemlerde-debezium/dagitik.webp)

## Tutarlılığı Sağlamanın Zor Yolları

Veritabanları arası senkronu çözmek için akla ilk gelen yöntemler, çoğu zaman insanı daha derin bir çukura sokar.

**Polling.** Bir worker belli aralıklarla çalışsın, gidip verileri güncellesin. Kulağa makul geliyor, ama veritabanı büyüdükçe bu sorgular full table scan yapıp CPU'yu kilitler. Üstelik asla gerçek zamanlı olmaz; aradaki boşluk hep büyür. Bir de silinen kayıtları yakalayamazsın, çünkü select ile bir satırın yokluğunu göremezsin. Bu da seni ikinci bir kontrol katmanı yazmaya zorlar.

**Spagetti kod ve bağımlılık.** Senkron mantığını uygulama koduna gömmek. Diyelim `UserService` var, kullanıcı profilini güncelleyince ElasticSearch'ü de güncellemen gerekiyor. Metodun içine ElasticSearch çağrısı eklersin. Artık `UserService` sadece kullanıcı işi yapmaz; ElasticSearch yavaşsa "Güncelle" butonu yavaşlar, o servis hata dönerse buton bozulur. Aslında işini yapmıştı, ama yapıştırdığın bağımlılık onu rehin aldı.

**Dual write laneti.** Dağıtık sistemlerin en sinsi düşmanı. "Kullanıcıyı veritabanına yazarım, hemen sonra RabbitMQ'ya bir event atarım" dersin. İki ayrı yere yazıyorsun ve ikisinin birden başarılı olacağına dair hiçbir garantin yok. Kuyruk o an çökerse, veri veritabanında durur ama event hiç gitmez. Kuyruk geri geldiğinde de o veriyi bilmez. Eksik veri, çift veri, sessiz tutarsızlık.

![Bir veritabanı ile mesaj kuyruğu arasında kırılmış bir bağlantı, verinin senkrondan çıkma riski](/images/blog/dagitik-sistemlerde-debezium/dualwrite.webp)

**Race condition.** Nadir sanılır ama art arda bağlı event zincirlerinde, asenkron yapılarda sıra karışır. İki ayrı yerden fazlasında güncelleme olunca, biri henüz oluşmadan üstüne yazılmaya çalışılır ve hata alırsın.

## Çözüm: "Ne Değişti?" Diye Sormayı Bırakmak

Bu sorunların hepsinin altında tek bir yanlış refleks var: veritabanına sürekli "sende ne değişti?" diye sormak.

Oysa veritabanı her işlemini zaten bir yere not ediyor. PostgreSQL buna WAL (Write Ahead Log), MySQL Binlog diyor. Veritabanı çökse bile bu günlükler sayesinde ayağa kalkıyor. Çözüm tam burada: uygulama koduna dokunmadan, veritabanına ek sorgu yüklemeden, doğrudan bu günlükleri dinlemek. Buna Change Data Capture, kısaca CDC diyoruz.

Peki bu logları kim okuyacak? Ham log dosyasını ayrıştırmak başlı başına bir mühendislik işi. İşte burada Debezium giriyor. Debezium kendini veritabanına bir replika gibi tanıtır; motor "şu satır eklendi, bu satır silindi" diye loga yazdığı an Debezium onu yakalar, standart bir JSON'a çevirip Apache Kafka'ya bırakır. (Bu arada sevdiğim bir laf: bir sorunu Kafka ile çözüyorsan, tebrikler, artık iki sorunun var.)

Bu mimariye geçince çilelere ne oluyor?

- **Dual write biter.** Artık "hem DB'ye yaz hem kuyruğa at" yok. Sadece DB'ye yazarsın, Debezium yazılanı garantili biçimde event'e çevirir. Outbox pattern'in temeli bu.
- **Polling biter.** `SELECT *` yok, veritabanına ek yük yok. Log okumak veritabanı için neredeyse bedava.
- **Hard delete çözülür.** Bir satırı sildiğinde loga "şu ID silindi" düşer; Debezium bunu da yakalar ve "bunu ElasticSearch'ten de sil" diye haber verir.
- **Gerçek zamanlıya en yakın.** Cron'un beş dakikalık gecikmesi yerine milisaniye mertebesinde.

## Akış Nasıl İşliyor

Kafada canlanması için sade bir akış:

- **Uygulama** sadece PostgreSQL'e `INSERT INTO users...` atar, işini bitirir.
- **PostgreSQL** veriyi diske yazar ve WAL'a işler.
- **Debezium** WAL'daki bu değişikliği anında görür.
- **Kafka**'ya Debezium bunu bir mesaj olarak bırakır.
- **Tüketiciler** (ElasticSearch, cache, pazarlama aracı) o mesajı dinler ve veriyi kendine alır.

Böylece o karmaşık orkestra, tek bir şeften, yani veritabanı loglarından talimat alarak senkron çalmaya başlar.

![Veritabanı logundan bir bağlayıcıya, oradan event akışına ve birçok tüketiciye giden tek yönlü veri hattı](/images/blog/dagitik-sistemlerde-debezium/flow.webp)

Dürüst olmam gereken yer şu: bedava peynir yok. Debezium harika bir araç, ama beraberinde Kafka yönetimini, şema değişikliklerini ve operasyonel bir maliyeti getiriyor. Cron job yazmak Kafka yönetmekten kolaydır. Ama ölçeklenen bir sistemde veri tutarlılığı uykunu kaçırıyorsa, bu bedel gece rahat uyumanın yanında küçük kalıyor.

## Mükemmel Kod Yoktur, Yönetilebilir Kaos Vardır

Dağıtık sistem kurmak, lego birleştirmeye benzemez. Lego'da parçalar sabittir; yazılımda parçalar sürekli hareket eder, ağlar kopar, sunucular nazlanır. Kıdem dediğimiz şey de aslında prod'da patlayan veritabanlarının başında geçirdiğimiz gecelerin toplamı. Bu süreçte öğrendiğim en net şey şu: mükemmel kod yoktur, yönetilebilir kaos vardır.

Debezium ve CDC, işte o kaosu yönetilebilir kılan, senkron işini spagetti koddan kurtarıp tek bir gerçeklik kaynağına bağlayan bir yaklaşım. Karmaşıklığın ürünü nasıl içten içe kemirdiğini [başka bir yazıda](/tr/prototip-olumcul-vadi) anlatmıştım; buradaki mesele de aynı: sadeliği bir yöntemle korumak.

Mimari kararlarımda önceliğim hiçbir zaman sadece günü kurtarmak değil, gece rahat uyumak oldu. Çünkü iyi mühendislik sadece kodun çalışması değil, o kodu yaşatanların da huzurlu olması demek. Sağlıklı, tutarlı ve bol commit'li günler.

> Yazının İngilizce versiyonuna [bu linkten](/debezium-in-distributed-systems) ulaşabilirsin.

---

## Wails Notlarım
URL: https://aligundogdu.com/tr/wails-notlarim
İlk yazdığım masaüstü uygulamasından bugüne, basit bir zaman çizelgesi ile Wails'i anlatmaya çalıştım.

## QBasic ile Başlayan Yolculuk

İlk uygulamamı [QBasic 4.5](https://dos.zone/qbasic-1991/) ile yapıp satmıştım.  
Tabii ki müthiş bir ticaret değildi. Bir müşteri, ekranda girdiği değeri birkaç formülden geçirip çıktı üretmemi
istemişti.  
Basit haliyle programlanabilir bir hesap makinesinden farksızdı. Çok kısa sürede bitti, karşılığında da “harçlık”
sayılabilecek bir ücret aldım.

:::gallery
/images/blog/08/wails-notes/qbasic-png.png
:::
*QBasic arayüzü.*

O günden sonra DOS’un sınırlı renkleriyle hazırlanmış arayüzler hep dikkatimi çekmeye başladı.

:::gallery
/images/blog/08/wails-notes/dosgui-2.png

/images/blog/08/wails-notes/dosgui-3.png

:::
*DOS döneminin tipik iş uygulamaları.*

:::gallery
/images/blog/08/wails-notes/dosgui-4.avif

/images/blog/08/wails-notes/dosgui-1.png
:::
*DOS döneminin tipik iş uygulamaları.*

O dönem otobüs bileti satan büroların, muhasebe firmalarının ekranları bana harika UX tasarımları gibi görünüyordu.  
80 sütun, 25 satır... ama kullanıcı için işlevsel, hızlı ve anlaşılır.

Hatta bugün tekrar popülerleşen [TUI](https://github.com/topics/tui) kategorisindeki gelişmelerden nasıl mutlu oluyorum anlatamam.

---

## Windows ve İlk Masaüstü Deneyimlerim

MS-DOS yerini Windows’a bıraktı. Basit işlemcili bilgisayarlara bol disketle kurulan Windows, bilgisayar dünyasını
bambaşka bir noktaya taşıdı.

İlk masaüstü uygulamamı **mIRC script dili**yle yazdım.  
Şimdi düşününce saçma gelse de, sırf öğrenme eğrisi çok kolay olduğu için IRC dışı bir uygulamayı mIRC ile
geliştirdim.  
Teoride basit bir ders programı takip yazılımıydı. Butonları bile Paint ile çizmiştim.

:::gallery

/images/blog/08/wails-notes/mirc-1.png

/images/blog/08/wails-notes/mirc-2.jpg
:::
*mIRC ile ilgili ekran görüntüleri.*

---

## Visual Basic 6.0: Gerçek Paket Programlar

Sonra Visual Basic 6.0 ile tanıştım.  
Bu, benim için büyük bir aşk oldu. Tek taraflı mıydı yoksa o da beni seviyor muydu, bilmiyorum :)

:::gallery
/images/blog/08/wails-notes/visual-basic.jpeg
:::
*Visual Basic 6.0 IDE’si.*

Gerçek anlamda yazdığım ilk “paket programı” VS6.0 ile oldu.  
O zamanlar adını koyamasam da object ve event bazlı çalışma mantığı ve IDE’nin büyülü ortamı beni etkiledi.

Bir dönem “ocx madencisi” gibi system dizinindeki OCX dosyalarını denemekle meşguldüm.  
Her yeni kütüphane, yeni bir oyuncak gibiydi.

---

## Platform Bağımsızlık Arayışı

Zamanla cihazlar çeşitlendi: Windows, Linux, macOS…  
Her evde, her işyerinde farklı sistemler çalışmaya başladı.

Bu da platform bağımsız uygulamalara olan ihtiyacı artırdı.  
Basit OCX kontrolleriyle idare edilen günler geride kaldı.  
Toolkit’ler devreye girdi.

Sonra Web 2.0 geldi.  
Masaüstü uygulamalarına harcanan emek yavaş yavaş web’e kaydı.  
Sonrası zaten malum...

> Belki bu zaman çizelgesinde atladığım noktalar vardır. Neticede ben artık yaşlı bir insanım :) Mazur görün.

---

## [Electron](https://www.electronjs.org/): Güzel Ama Ağır

Bugün geldiğimiz noktada ne masaüstü uygulamalarından kurtulabildik, ne de tamamen onlara bağımlı kaldık.  
Cross-platform uygulama geliştirme hala çok önemli bir ihtiyaç.  
Üstelik bu denkleme mobil uygulamalar da dahil oldu.

Son yıllarda hayatımıza giren **Electron** bu ihtiyacı büyük ölçüde karşıladı.

JavaScript, Node.js ve TypeScript ile birçok işimi çözebiliyorum.  
Bir masaüstü uygulamasını tamamen JS ile geliştirme fikri çok heyecan verici.  
Ama iş pratiğe dökülünce durum değişiyor.

Özellikle:

- İşletim sistemi API’leriyle doğrudan haberleşmek gerektiğinde,
- Küçük ve optimize build çıktıları hedeflendiğinde,

Electron keyif kaçırıcı olabiliyor.  
React veya Vue ile arayüz geliştirmek çok keyifli olsa da OS ile iletişim kısmı için daha kolay çözümler aramaya
başladım.

---

## [Tauri](https://v2.tauri.app/): Güzel Ama Zor

Bu noktada **Tauri** ile yollarım kesişti.  
Backend’de Rust, frontend’de istediğimiz framework.  
Üstelik Chrome’u içine gömmediği için build boyutları çok küçük.

Ama Rust tarafı bana epey zor geldi.  
Config dosyalarıyla uğraş, command yapısıyla boğuş…  
Rust’u bilenler için keyifli ama benim için değil.  
Sonunda fark ettim ki işimi kolaylaştırması gereken araç, bana ekstra yük oluyordu.

---

## [Wails](https://wails.io/): Aradığım Çözüm

Ve **Wails**...

### İhtiyaç Listem

- Kolay adapte olup geliştirme yapabilmek
- Kolay şekilde cross-platform build alabilmek
- Dosya boyutunun küçük olması
- Derleme sonrası sürprizlerin olmaması
- Dahili bir GC (çöp toplayıcı) olması
- İşletim sistemi özelinde çözümler için beni JS ile uğraştırmaması
- İstediğim frontend kütüphanesiyle ek adaptör olmadan geliştirme yapabilmek

### Electron vs Tauri vs Wails

| Özellik                | Electron                        | Tauri                       | Wails                    |
|------------------------|---------------------------------|-----------------------------|--------------------------|
| **Backend dili**       | Node.js                         | Rust                        | Go                       |
| **Frontend esnekliği** | React, Vue, Angular, Svelte vs. | React, Vue, Angular vs.     | React, Vue, Angular vs.  |
| **Dosya boyutu**       | 150+ MB                         | 10-20 MB                    | 10-25 MB                 |
| **Performans**         | Ağır                            | Hızlı ama Rust bilgisi şart | Hızlı ve dengeli         |
| **CORS sorunları**     | Var                             | Yok                         | Yok                      |
| **Öğrenme eğrisi**     | Düşük                           | Dik                         | Orta (Go öğrenmek kolay) |
| **OS API erişimi**     | Zor                             | Güçlü ama karmaşık          | Basit ve temiz           |
| **Build süreci**       | Ağır                            | Orta                        | Hızlı ve sorunsuz        |

### Wails’in Öne Çıkan Avantajları

- **Gerçek cross-platform deneyimi:** Tek komutla Windows, macOS ve Linux build’i.
- **Küçük dosya boyutu:** Electron’un 150 MB’lık dev paketleri yerine 20 MB civarında build.
- **Go ile güçlü backend:** Rust kadar karmaşık değil. Concurrency, file I/O, API entegrasyonu çok kolay.
- **Doğrudan OS API erişimi:** CORS sorunlarıyla uğraşmak yerine Go’da 5 satırlık fonksiyon yazıp JS’den çağırıyorsun.
- **Frontend özgürlüğü:** React, Vue, Svelte veya Angular… Ne istersen doğrudan kullanabiliyorsun.
- **Stabil build süreci:** “Bende çalışıyordu ama Windows’ta açılmadı” dönemi sona eriyor.

### Basit Bir Senaryo

Diyelim ki bir uygulamada:

- Kullanıcıdan bir CSV dosyası alıyorsun,
- Go backend ile parse edip işliyorsun,
- Vue arayüzünde tablo olarak gösteriyorsun,
- Aynı anda bir API’ye fetch atıyorsun ve **CORS derdine düşmüyorsun**.

Electron ile yapsan: 200 MB paket ve karmaşık config.  
Tauri ile yapsan: Rust öğrenmek şart.  
Wails ile: Go’nun sadeliği sayesinde az kod, az dert.

---

## Sonuç

QBasic ile yazdığım o basit hesap makinesinden  
Wails ile geliştirdiğim cross-platform uygulamalara...  
Yol uzun ama his aynı: bilgisayarın sana boyundan büyük işler yaptırabilmesi.

Ve benim için şu an o hisin adı: **Wails**.

---

## PHP öldü mü ?
URL: https://aligundogdu.com/tr/php-oldu-mu
"PHP öldü mü?" sorusunu tarihsel ve teknik gelişmeler ışığında ele alan bu yazı, PHP'nin geçmişten günümüze evrimini tartışarak hala yaşayan ve gelişen bir dil olduğunu ortaya koyuyor.

**Özet:**

Bu yazıyı, günümüz sosyal medyasında takipçi ve etkileşim kasmak için kullanılan ve 2010'lu yıllarda hayatımıza giren
_**"PHP Öldü mü"**_ sorusunu 2024 yılında tekrar sormak ve ufak bir nostalji turu yaptırmak için yazıyorum.

### **Bir Dilin Ölmesi Nedir ?**

Yazıya başlamadan önce, ölümü tanımlamanın daha doğru olduğunu düşünüyorum;

Bir dilin ölmesi için ilk olarak o dilin geliştirilmesinin durdurulmuş olması gerekiyor. Ardından o dil ile yeni proje
üretilmesinin azalması veya bitmesi gerekiyor. Zaten bu iki madde gerçekleştikten sonra "yeniliklere açık olmama", "
kendini geliştirememe", "Modernliğini kaybetme" gibi alt maddeler otomatik olarak tamamlanmış oluyor.

Bu yukarıdaki maddeler dışında kalan diller kullanıcı sayısı bir avuç insan bile olsa ölmemiştir.

### **Peki ya PHP ?**

_Ölüm_ ve _Ölü dil_ kavramını netleştirdiğimize göre PHP 'yi ele alalım ve takvimlerimizi **2005** yılına çekelim, Belki
bir çoğunuz bu tarihlerde portakalda vitamindi :) sürecin sonucunu anlamak için başını bilmekte fayda olduğu için bu
kadar geriye gitmek gerekiyor.

bu dönemin tartışmalarını ele alırsak;

- web 2.0 dediğimiz kavramın yükselişe geçtiği ve bolca
  konuşulduğu \[[1](https://www.wired.com/2006/01/breaking-down-the-hype-of-web-2dot0/)\]\[[2](https://www.oreilly.com/pub/a/web2/archive/what-is-web-20.html)\]\[[3](https://www.historyofinformation.com/detail.php?id=1654)\],
- sosyal medya platformlarının hayatımızda yer etmeye başladığı \[[1](https://www.educba.com/what-is-social-media/)\],
- google'un büyümeye
  başladığı \[[1](https://www.fool.com/investing/high-growth/2006/02/01/googles-2005-growth-story-fool-by-numbers.aspx)\]\[[2](https://www.webdesignmuseum.org/gallery/google-2005)\]\[[3](https://economictimes.indiatimes.com/tech-life/43-key-moments-in-googles-18-year-history/2002/slideshow/48981584.cms)\]\[[4](https://hbr.org/2010/05/how-i-did-it-googles-ceo-on-the-enduring-lessons-of-a-quirky-ipo)\],
- e-ticaretin artık hayatımıza girmeye başladığı \[[1](https://www.ebay.com/)\]\[[2](https://www.amazon.com/)\] ,
- ajax gibi bir teknolojisinin web geneline
  yayılmaya \[[1](https://www.studysmarter.co.uk/explanations/computer-science/computer-network/what-is-ajax/#:~:text=AJAX%20stands%20for%20Asynchronous%20JavaScript,for%20Asynchronous%20Java%20and%20XML.)\]\[[2](https://www.oracle.com/technical-resources/articles/enterprise-architecture/ajax-introduction.html)\]\[[3](https://simpleprogrammer.com/history-internet-14-google-and-ajax-apps/)\]

başladığı dönem olarak tanımlarsak hata etmiş sayılmayız.

PHP ise bu dönemde, bu ihtiyaçlara mevcut sürümü ile yetişemiyor, yetişse bile
bunu [developer friendly](https://www.quora.com/What-does-it-mean-for-a-tool-to-be-developer-friendly) yani **yazılımcı
dostu** şekilde çözemiyordu.

Haliyle bu dönemde PHP den modernleşme belirtileri bekliyorduk. Nihayetinde aynı
yıllarda[5.0 versiyonu duyuruldu](https://news-web.php.net/php.announce/50).

Bu [versiyon](https://www.php.net/ChangeLog-5.php) ile;

- Dile OOP kavramı girdi,
- PDO kavramı tanıştık,
- Error Handling geliştirildi,
- Dom ve Xml parsing işlemleri iyileştirildi,
- Mysql Desteği yerleşik hale getirildi,
- Bazı performans iyileştirmeleri yapıldı.

Bence bu sürümle birlikte dile, dönemine göre çok devrimsel özellikler gelse de aynı dönem
duyurulan [Ruby On Rails](https://rubyonrails.org/2005/10/19/rails-1-0-the-release-candidate-2) gibi Frameworklerin
getirdiği dönemin ruhuna uygun özellikler ve developer dostu dokunuşların gerisinde kaldı.

Takip eden bir kaç sene içerisinde de "PHP öldü" miti ortaya atılmaya başladı.

Çünkü takip eden yıllardan itibaren 2010'lu yıllara kadar, bir çok dil ve framework popülerliğini arttırdı ve bir çok
php geliştiricisini kendisine çekti. [Python Django](https://www.djangoproject.com/) gibi frameworkler ile web alemine
göz kırpmaya başladı, [NodeJS](https://nodejs.org/en) çıkarak oyunun kurallarının yeniden yazılmasını
sağladı, [Ruby On Rails](https://rubyonrails.org/) popülerliğini arttırdı.

Bu gelişmelerin yanında;

PHP nin bir çok açık kaynakta kullanılması sebebi ile yaygınlığı artsa da; eski sürümlerin desteklenmek zorunda
kalınması, kötü kodlama alışkanlıkları sebebi ile güvensiz ürünlerin ortaya çıkması sebebi ile uzun bir süre bu imajı
üstünde taşıdı. Bunlara ek olarak eski kodların bakım ve güncelleme maliyetlerini çoğalarak zorlaşması, PHP nin gelişim
hızının da düşmesi ve hatta 6. nolu versiyonunun yayınlanmayarak rafa kaldırılması da dilin popülerliğini yitirmesine
sebep olan etmenler diyebilirim. (evet ben kendim bizzat)

Bence 5.2 versiyonu ile 5.4 versiyon geçişi arasında PHP durumu kurtarmak için büyük bir adım atsa da yeterli olmadı
ve [2015 yılında yayınlanan 7. versiyonu](https://www.php.net/releases/7_0_0.php) ile daha major düzenlemeler ile
yukarıda saydığım dile ait sorunların büyük bir kısmı ortadan kaldırıldı.

Zaten bu süre zarfında Hype treni ile birlikte saydığım diğer diller ve frameworkler altın çağlarını çoktan yaşamaya
başlamıştı bile. O dönem kurduğum yazılım evinde ben de PHP dışında NodeJs, .Net gibi ihtiyaca yönelik dilleri
kullanmaya başlamıştım. Konuya değindiğim 2014 tarihli diğer yazıma
da [buradan ulaşabilirsiniz](https://aligundogdu.com/neden-laravel-kullanmiyorum/).

PHP nin 5.4 versiyonu ve 7.0 a kadar olan sürecinde çok fazla modern güncelleme ve yenileme yapıldı bu sayede dile güç
katan frameworkler gelişmeye ve ilerlemeye başladı. 2012 yılında yayınlanan [composer](https://getcomposer.org/)
sayesinde ise çok daha büyük bir devrim oluşarak PHP ye dirlik ve düzeni getirdi diyebiliriz :)

Şu an PHP'nin 8 sürüm numaralı versiyonları geliştiriliyor geliştirme
süreçlerine [https://github.com/php/php-src/commits/master/](https://github.com/php/php-src/commits/master/)
ve [https://www.php.net/releases/](https://www.php.net/releases/) bu adreslerden gözleyebilirsiniz. _Ben blog yazısını
yazdığım sırada en son commit 3 saat önce atılmıştı ve bazı güvenlik iyileştirmeleri master brancha merge edilmişti._

Bu kısa geçmiş ve nostalji turundan sonra günümüze gelelim.

## **Hala yaşıyor mu ?**

PHP bugün halen kullanılan ve kullanım sıklığı azalsa da yeni proje üretilen bir dil/platform olarak hayatına devam
ediyor. PHP nin ekosistemi de bu vesile gelişerek "Modern web Development" dediğimiz kavrama kendini basit şekilde
adapte ediyor ve ilerliyor. Bu güncellemeler eleştirilebilir, diğer dil ve frameworkler ile karşılaştırılarak
çıkarımlar da yapılabilir ancak bu çıkarımların ve eleştirilerin tamamı kişisel bir söylem dışına çıktığında faydalı
olur. Mesela; farzı misal 2014 yılında PHP ile sorun yaşayan bir developer başka bir dil ve frameworke geçmiş olabilir
ama 2024 yılında hala o zamanki bilgisi ile PHP öldü diyorsa bu o kişinin kendi sorunudur.

Bilenler bilir, bir dilin müptelası değilimdir çünkü iş ve sonuç odaklı hareket etmenin önemli olduğunu düşünürüm. Konu
diller değil konu iddiaların argümanlı ya da argümansız olması ile alakalı. Yazının başında yaptığım ölüm tanımına göre *
*PHP ölmedi diyebilirim**. bu konu da blog içerisinde yazdığım tüm diğer konular da benim fikrim ve argümanlarımı bu
blog yazısında yazmayı tercih ettim.

### **Daha Ne kadar yaşar ?**

Bu soruya ezberden bir cevap vermek yerine, değişen çağ ve ihtiyaçlara göre cevap vermek daha doğru olacaktır.

mesela bugünün bazı ihtiyaçlarını ele alarak cevap verecek olursam;

- Artık bir çok uygulama, kullanıcılar için yoğun işlem gerektiriyor bu durumu gören PHP 8.0 versiyonundan sonra JIT 'i
  sisteme ekledi ve sağladığı avantaj sayesinde daha performanslı hale
  geldi. \[[1](https://php.watch/versions/8.0/JIT#:~:text=Just%2DIn%2DTime%20compilation%20is,virtual%20machine%20\(Zend%20VM\).)\]\[[2](https://wiki.php.net/rfc/jit)\]
- Uygulamalarda verilerin ve tiplerin önemi her geçen gün artarken PHP yine 8.0
  versiyonuna; [union types](https://php.watch/versions/8.0/union-types), [named arguments](https://stitcher.io/blog/php-8-named-arguments), [match expression](https://www.php.net/manual/en/control-structures.match.php), [attributes](https://www.php.net/manual/en/language.attributes.overview.php)
  gibi birçok yeni dil özelliğini ekleyerek biz geliştiricilere daha esnek ve güçlü bir kod yazma desteği sunmaya
  başladı.
- [Symfony](https://symfony.com/) ve [Laravel](https://laravel.com/) gibi frameworkler ile oluşan standartlaştırma ile
  birlikte ekipler daha hızlı ve güçlü şekilde uygulamalar geliştirmeye başladı,
- Çağımızın gereksinimleri olan gerçek zamanlı çalışan uygulamalar
  için [Swoole](https://openswoole.com/), [ReactPHP](https://reactphp.org/), [frankenPHP](https://frankenphp.dev/tr/)
  gibi araçlar yüksek performanslı sonuçlar üretmeye başladı
- Docker vs gibi konuları dillendirmeye bile gerek duymuyorum zira php kendini buna hızlıca adapte edebildi,
- Blog, Eticaret gibi ihtiyaçlarına çözüm üreten; [wordpress](https://wordpress.org/)
  ve [magento](https://about.magento.com/Magento-Commerce) gibi araçlar halen geliştirilip kullanılmakta,
- Yapay zeka konusunda PHP nin bir iddiası yok o yüzden bunun üzerine gitmiyorlar o yüzden amacınız AI ise PHP ile ısrar
  ettirmenize gerek yok, Python işinizi görecektir
- Aynı şekilde Sistem programlama vs gibi konularda da her ne kadar phar ve phalcon gibi araçlar/frameworkler umut
  vadetmiş olsa da [GO](https://go.dev/) nun gerisinde kaldılar diyebilirim o yüzden amacınız yüksek performanslı sistem
  araçları geliştirmek ise [GO](https://go.dev/) yu tercih edebilirsiniz.

bu maddeler ele alındığında PHP nin daha uzun süre yaşayabileceğini söyleyebilirim.

özetle bir dil/framework ihtiyaçlara cevap verebilmek için çabaladığı sürece **ölmez**.

### **Son Olarak**

Bu yazı PHP öven bir yazı değildir sadece bir dilin ölmesi konusunu PHP özelinde ele alan bir yazıdır. Benim de
sorumluluğumdaki bir çok projede kullanılan PHP ve Frameworkler ile ilgili eleştirilerim vs var ama bu kişisel konuları
genele yayarak PHP öldü diyemediğim için bu yazıyı yazdım.

Okuduğunuz için teşekkürler.

> Yazının İngilizce versiyonuna [bu linkten](/is-php-dead) ulaşabilirsin.

---

## Neden Laravel kullanmıyorum
URL: https://aligundogdu.com/tr/neden-laravel-kullanmiyorum
Laravel Framework'ün üzerine düşünceler ve sonuçları hakkında bir blog yazısı.

Yaptığım projelerde, süreçleri, işlemleri birbiri ile güzelce anlaşabilecek şekilde yapmaya gayret ederim. Birbirleri
ile tam bir otomasyon ile anlaşamayan her bir süreç ileride sorun çıkarıp, projenin aksamasına sebep olabilir. Bununla
birlikte her çıkan sorun bir geriye dönük ilgi gerektirerek ek maliyet çıkardığı istenmeyen bir durum oluşturur.
<br/>
<br/>
Bu yüzden projeleri kodlarken kullandığım araçları seçerken
biraz "kıl" davranırım.
<br/>
<br/>
Kullanılan araç bana hız kazandırıyor mu ? Yeni bir versiyonu çıktığında geçmişe yönelik desteği nasıl ? Bir sorun
çıktığında bu sorunu google araması ile çözüme ulaşabiliyor muyum ? Kim tarafından geliştiriliyor ? canı istediği zaman
commit yapan birisi tarafından mı geliştiriliyor.
<br/>
<br/>
Mevzu teknoloji ve yazılım ise, "daha iyisi" olmayacağını bilecek kadardır bu işi yapıyorum, Hani framework daha iyi ?
sorusunun cevabı bence yoktur, Hangi bilgisayar daha iyi sorusunun cevabı bence spesifik değildir, En iyi programlama
dili hangisi sorusuna cevap aramak vakit kaybıdır benim için.
<br/>
<br/>
"İhtiyacımı görecek en iyisi hangisi ?" sorusunu sormak bizi daha çabuk çözüme ulaştırır diye düşünüyorum,
<br/>
<br/>
En iyi programlama dili hangisi yerine "linux ortamında konsol işlemleri yapacağım hangi dil kendini bu konuda
geliştirmiş ?"
<br/>
<br/>
Web tarafında api isteklerine cevap verecek bir proje yapacağım, hangi dil bu konuda gelişmiş ? diye sormak bence en
iyisi.
<br/>
<br/>
Firma olarak Windows Ce kullanan el terminali yazılımından , Facebook uygulamasına kadar bir çok sektöre çözüm
üretiyoruz. Kullanacağımız araçları, "bu platform için en verimli araçlar hangileri ?" sorusunu sorarak seçiyoruz.
<br/>
<br/>
En iyi dil PHP'dir diye diretseydik, windows ce kullanan bir el terminaline kod yazamayacaktık. Yada en iyi dil .net'dir
deseydik, Linux sunucusunda Bash script ile çözebileceğimiz bir başka sorun için .net ile çözüm aramaya çalışacaktık.(
çözüm bulamayacaktık.)
<br/>
<br/>
Yazılım geliştirme içerisinde Fanatikçe karar almanın faydadan çok zarar getireceğini düşünüyorum.
<br/>
<br/>
Çok yakın bir tarihe kadar PHP 'nin en büyük sorunlarından birisi gelişmiş ve genele yayılmış bir paket yöneticisinin
olmaması idi,
<br/>
<br/>
![logo-composer-transparent](/images/blog/logo-composer-transparent.png)
<br/>
<br/>
her ne kadar resmi olarak çıkmasa da çok yakın bir geçmişte [composer](https://getcomposer.org/) oluşturularak, php'nin
bu eksiği çok büyük ölçüde giderildi.
<br/>
<br/>
Bu işte sözü geçen büyük firmalar bile kendini composer içerisine eklediği için topluluğun composer konusunda ciddi
olduğunu da görmüş olduk.
<br/>
<br/>
Composer sayesinde artık proje içerisinde kullanacağımız repolara çok
daha [kolay şekilde ulaşıyoruz](https://packagist.org/). Tek bir dosya üzerinden repoları yönetip projemize dahil
edebiliyoruz.
<br/>
<br/>
Composer ile popüler olan bir çok repo, bir kişinin geliştirmekte olduğu "şeylerden" uzaklaşıp farklı sorunlar ile
karşılaşan insanların [pull requestleri](http://emirbozkir.com/blog/git-ve-github-nedir/) ile birlikte gelişip büyüyor.
Bu sayede kendi içinde bir hata takip ve dokümantasyon sistemi oturmuş oluyor.
<br/>
<br/>
Yani kullandığınız araçların sorunlarına ve çözümlerine direk o araçların github sayfalarından ulaşabiliyoruz.
<br/>
<br/>
bununla birlikte, composer bize php'nin oop gücünü daha iyi kullanmamızı sağlıyor,
kullandığı [autoload mimarisi](http://www.php-fig.org/psr/psr-0/) sayesinde gerçek bir mvc deneyimi yaşayabiliyoruz.
<br/>
<br/>
Bu işe başladığımda ve devamında etrafımda hep kaliteli yazılımcılar olduğundan ötürü,
<br/>
<br/>
"OOP dediğin şey çok kullanılan fonksiyonların, sınıf dosyaları içine konulup lazım olunca çağrılması değil mi canım"
<br/>
<br/>
fikrinden kurtulmak çok uzun sürmedi benim için.
<br/>
<br/>
Bu yüzden Kendi Frameworkümü kendim yazdım dediğim dönemler sadece 1-2 proje ile sınırlı kaldı :)
<br/>
<br/>
Konunun en başına dönecek olursak,
<br/>
<br/>
Yaptığınız proje çevre şartları değişmediği sürece sorunsuz şekilde çalışmalıdır, "Kitap gibi çalışıyor" deyiminin
hakkını vermelidir.
<br/>
<br/>
Daha önceki bir yazımda, [Müşteriye göre şekillenmek](http://aligundogdu.com/musteriye-gore-sekillenmek/) konusuna
değinmiştim.
<br/>
<br/>
İsteklere göre şekillenmek için çok esnek bir yapıya sahip olmanız gerekiyor. Projenizin, sonradan gelen isteklere göre
şekillendirirken kırılmaması çok önemli bir faktör olarak ilk sıraya çıkıyor.
<br/>
<br/>
Kullandığınız her bir aracı bir lego parçası gibi düşünebilirsiniz,
<br/>
<br/>
ne kadar ufak parçalar ile çalışırsanız, o kadar esnek projeler üretebilirsiniz ve projenin alacağı şekil, sizin hayal
gücünüze kalacağı için ortaya muazzam işler çıkabilir.
<br/>
<br/>
İşte bu yüzden composer çıktığından bu yana, tek bir framework'e bağlı kalmak yerine, frameworklerin güzel tarafları ile
daha esnek araçlar üretebileceğini düşünüyorum.
<br/>
<br/>
Gelelim bu durumda Laravel'i neden kullanmadığıma,
<br/>
<br/>
**1- Sadece ben, hep ben, ben olmuşum laravel !**
<br/>
<br/>
Laravel Tek ADAM projesi, bunu ben değil Laravel'i yazan arkadaş diyor,

<br/>
<br/>

<script src="//platform.twitter.com/widgets.js" async charset="utf-8"></script>
https://twitter.com/taylorotwell/status/420577120188768257
<br/>
<br/>
Laravel asla bir community projesi olarak başlamadı.
<br/>
<br/>
Tek bir geliştiricinin "Php ile Ruby gibi yazsak nasıl olur ?"   fikri üzerine, yine benim az önce bahsettiğim şekilde
ufak araçların composer ile bir araya getirmesinden ibaret.
<br/>
<br/>
[CodeIgniter](http://www.codeigniter.com/)'ın geliştirilmesinin durdurulmasının ardından, ortaya çıkan, "basit, günü
kurtaran bir framework" ihtiyacını karşılayabilecek yetkinlikte bir framework laravel.
<br/>
<br/>
Yani beni, geçmişe yönelik destek ilgilendirmiyor, günü kurtarmak için yazılım yapıyorum laravel ile yapıp geçeceğim
diyorsanız Laravel tam size göre.
<br/>
<br/>
**2- Biz bir aileyiz ama kararları ben veririm!**
<br/>
<br/>
Opensource topluluğuna göz kırpan bir projeyi temelden ilgilendiren kararları tek adam tarafından alınması sonucu ortaya
çıkan sonuçları geçmişte gördük,
<br/>
<br/>
Mesela Pardus'un sonunun başlangıcı, topluluk redmine istediği halde
jira'da [direten](https://www.mail-archive.com/gelistirici@pardus.org.tr/msg09665.html) proje başları
sayesinde [olmuştu](http://zzz.fisek.com.tr/seyir-defteri/pardusun-yeni-camia-listesi-jira-ve-pardusun-ozgur-yazilim-ilkeleri/),
<br/>
<br/>
Yine Ubuntu'da , pencere butonlarının topluluğun istememesine rağmen sağda değilde solda diretilmesi örnek olarak
verilebilir, Söz ubuntu'dan açılmışken, ubuntu firmasının unity'den tutunda arama bilgilerinizin başkaları ile
paylaşılmasına kadar olan bir yelpaze bile ortaya çıkan şey Open Source olsa bile kararı biz vereceğiz! diretmesinden
başka bir şey değil.
<br/>
<br/>
Ubuntuyu birinci işletim sistemi olarak kullanmayı bırakmama sebepte bu tutumlarıdır. Benim gibi bir çok kişi var.
<br/>
<br/>
hal böyle olunca,
<br/>
<br/>
projeye gelen pull request'leri bile merge etmek yerine kendisi copy paste ile sisteme ekleyen bir adam'a ne kadar
güvenebilirim ?
<br/>
<br/>
[https://github.com/laravel/framework/graphs/contributors](https://github.com/laravel/framework/graphs/contributors)  bu
linkten de görebileceğiniz gibi laravel'in büyük bir kısmı @taylorotwell tarafından yazılmış gözüküyor.
<br/>
<br/>
adam fırsat bulduğu her platformda "Ehe naber ? laraveli ben yaptım, benim bu proje" demekten kendini alamıyor.
<br/>
<br/>
**3- Versiyonlama sorunları.**
<br/>
<br/>
Can alıcı kısım bu aslında. Laravel  [Semantic Versiyonlama](http://semver.org) ile yazılmıyor, örnek verecek olursak,
<br/>
<br/>
bir yazılımın 1.2.4 versiyonu ile 1.2.5 versiyonu arasında çok büyük değişiklikler olmaz, yani siz bu aracı kullanırken
1.2.4 versiyonunu 1.2.5 versiyonuna yükselttiğinizde projenizin çalışmasına devam etmesini beklersiniz.
<br/>
<br/>
Laravel'de durum böyle değil, 1.2.4 versiyonunda desteklediği bir kütüphaneyi yada metodu, 1.2.5 versiyonunda komple
kaldırmış ve yerine bambaşka bir metod eklemiş olabiliyor. Böyle olunca bu gün yazdığınız kod, laravel güncellendikten
sonra tamamen çalışmaz hale gelebiliyor.
<br/>
<br/>
Mesela, Python 2 varken ve halen geliştirme süreci devam ediyorken, Python 3 çıkmasının ve onunda geliştirilmesinin
sebebi budur,
<br/>
<br/>
yada Opencart 1.5.5.6 sürümü varken Opencart 2.0.0.0 'ın çıkmasındaki sebep budur,
<br/>
<br/>
köklü değişiklikler olduğunda sizin ürününüzü kullananların "mağdur" olmaması için bu tarz versiyonlama sistemi
kullanılır. Bu her şeyden önce "saygı" sorunudur.
<br/>
<br/>
Temel amacımız sorunsuz çalışan bir sistem ise, bu şekilde "ya ruby'de şu özellik var, laravelde neden yok demesin
millet, bende bunu ekleyeyim o zaman" diyerek kafasına göre versiyonlama yapan bir adamın ortaya çıkardığı üründen ne
kadar fayda bekleyebiliriz ?
<br/>
<br/>
**4- Kullanıcıların sorun çıktığında çözüme ulaşmasının önünü tıkamak.**
<br/>
<br/>
Geçtiğimiz günlerde Laravel, github üzerindeki issüeleri sildi ve artık sorunları forumlardan
sorulmasını [istedi](http://laravel-news.com/2014/09/laravel-removes-github-issues/).
<br/>
<br/>
Hem kafana göre versiyonlama ile işler yapacaksın, hem sorun çıktığında "buralar çok karışık oluyor" gerekçesi ile çözüm
yollarını tıkayacaksın.
<br/>
<br/>
Benim hızlıca çözüme ulaşma kriterim de burada çuvallıyor, üstelik "Laravel Auth Problem", "Laravel Orm Problem" gibi
çok genel aramalarda çıkan sonuçların içinde bir de hangi versiyon olduğunu aramak zorundayım.
<br/>
<br/>
**5- Standart üretme çabası ile saçmalama.**
<br/>
<br/>
Php 'de [interface](http://www.cagataybulut.com/2013/07/abstract-interface-nedir.html) olarak kullanılan şeyleri alıp,
bunların adına [Contracts](https://github.com/illuminate/contracts) [diyor](https://github.com/illuminate/contracts).
<br/>
<br/>
Php'nin adı çıkmış bir kere, Çok dağınık, düzensiz kod yazılmasına izin veriyor, hali hazırdaki interafece özelliğinin
adını değiştirip yeni ve ayrı bir sistem gibi sunalım gibi bir düşünce hakim.
<br/>
<br/>
Bu hem kısa hem de uzun vadede çok daha büyük sorunlara gebe kalacak bir düşünce, topluluk desteğini hiçe sayıp her
şey "benden" geçecek dedikten sonra, kullandığınız her aracın contratsını yazacaksınız demek tutarsızlık.
<br/>
<br/>
Laravel ile kodlama yaparken yine kör dövüşü yapıp, ben contracts yazmam diyorsanız Laravel kullanmanın anlamı ne o
zaman ?
<br/>
<br/>
Hali hazırda Composer paketleri içerisinde görüp beğenip kullanmak istediğiniz bir aracın kendi interface'i, bundle'ı
yada provider'i varken neden laravel'de contracts yazayım ? (yoksa)
<br/>
<br/>
Ben composer ile çekip $repo = new repoClass(); diye her yerden ulaşabileceğim bir aracı, neden sadece laravel
içerisinde çalışacak bir hale sokmak isteyeyim ?
<br/>
<br/>
"Kırk Küp Kırkınında Kulpu Kırık Küp" gibi bir metni, "kirk-kup-kirkininda-kulpu-kirik-kup" şeklinde url formatına
çevirecek bir araç kullanmak için, composer.json'a tek bir satır ekleyerek istediğim yerden çağırıp kullanmak yerine
neden sadece laravel'de çalışan bir şeye dönüştüreyim ?
<br/>
<br/>
Hızlı sonuç alma fikri nerede kaldı ?
<br/>
<br/>
Yine aynı şekilde, $nesne = new Nesne(); demek varken, neden make gibi bir metod ile ide dostu olmayan bir yöntem
kullanayım ?
<br/>
<br/>
**6- Kalıplara sokarken özgünlüğünü yitirme.**
<br/>
<br/>
Projeyi parçalara ayırarak oluşturmayı legolara benzetmiştim,
<br/>
<br/>
Laravel'de aslında parçalara ayrılmış repolardan oluşuyor ancak yukarıda saydığım şeylerden ötürü her bir parça kendi
özgürlüğünü bırakıp laravel'in diretmelerine maruz kalıyor.
<br/>
<br/>
Siz güncel paketleri bir araya getirdiğinizde ortaya çıkan şey şu olurken :
<br/>
<br/>
![6177_lego_builders_of_tomorrow_box](/images/blog/6177_lego_builders_of_tomorrow_box.jpg)
<br/>
<br/>
Aynı işi laravel yaptığında ise ortaya şöyle bir şey çıkıyor :
<br/>
<br/>
![lego-castle-70404-kings-castle-box](/images/blog/lego-castle-70404-kings-castle-box.png)
<br/>
<br/>
Laravel'de size lego sunuyor ama sunduğu parçalar Laravel'in baştan düşündüğü şeylerin dışına çıkamıyor. Böyle olunca da
Laravel Programcısı oluyorsunuz, Php ile alakanız kalmıyor, Laravel'in ürettiği çözümlerin dışına dahi çıkamıyorsunuz.
<br/>
<br/>
Senelerdir Visual Studio illetine mahkum kalan .net tayfası için aynı şeyleri söylemedik mi ? (kendim de visual studio
kullanıyorum, windows ce 'ye sadece VS2008 ile yazılım üretebiliyorsunuz :'( )
<br/>
<br/>
**7- Destek, Destek, Destek.**
<br/>
<br/>
[Zend Framework 1](http://framework.zend.com/downloads/latest) , ilk olarak 2007 yılında yazıldı, zamanla üzerine yeni
versiyonlar eklendi, semantik bir versiyonlama kullandığı için ilk versiyonda yazılan (2007 yılında) bir yazılım bugün
bile sorunsuz çalışabiliyor,
<br/>
<br/>
üstelik [Zend Framework 2](http://framework.zend.com/downloads/latest)   adında yep yeni bir sürüm çıkmasına rağmen hala
Zend Framework 1 için güncellemeler yapılıyor.
<br/>
<br/>
Bir diğer Framework olan  [Symfony](http://symfony.com/), bir kaç gün
önce [LTS](http://symfony.com/blog/symfony-2-3-0-the-first-lts-is-now-available) sürümünü duyurdu.
<br/>
<br/>
Ama laravel'in  [kendi sitesinde](http://laravel.com/docs/4.2) bile 4. sürümünden öncesi için dokümantasyon bile yok.
<br/>
<br/>
**8 - Taklitler aslını yaşatır.**
<br/>
<br/>
Ruby 'den esinlenerek tek bir adamın inisiyatifinde olan Ruby çakması bir yapı kullanacağınıza, aynı basitlikte ve
gerçekten topluluk tarafından geliştirilen Ruby'e geçmeniz daha faydalı olacaktır, üstelik MVC nedir sorusuna verecek az
çok cevabınız varsa Ruby'nin öğrenme süresi size çok ama çok basit gelecektir.
<br/>
<br/>
**Sonuç olarak ;**
<br/>
<br/>
Yazdığım kodun ileride de sorunsuz çalışmasını istediğim için,
<br/>
<br/>
Günü kurtarmak için kod yazmadığım için,
<br/>
<br/>
Kullandığım araçları    "Herkes bunu kullanıyor, demek ki en iyisi bu" gibi bir argüman ile seçmediğim için,
<br/>
<br/>
Benim yazacağım kodun standardını bir topluluk değil de keyfe keder kararlar alan birisinin belirmesinden rahatsız
olduğum için,
<br/>
<br/>
İstediğim zaman istediğim yeni araçları ekleyebilmek istediğim için Laravel **Kullanmıyorum**.
<br/>
<br/>
**Peki ya çözüm önerisi:**
<br/>
<br/>
Elbette var,
<br/>
<br/>
**ilk tavsiyem**, kendini ispat etmiş, bu işe yatırım yapmış frameworkleri kullanın (Yii, Zend, Symfony gibi) ,
framework seçerken "en hızlısı buymuş" diye seçmeyin, Hız değişkeni en son dikkat etmeniz gereken faktör.
<br/>
<br/>
**Diğer tavsiyem**, yine kendini ispat etmiş toplulukların desteklediği paketleri ihtiyacınıza göre birleştirin. Girin
Github'a bakın, Php'nin yüksek versiyonları ile geliştirilen projelerde neler kullanılmış inceleyin.
<br/>
<br/>
Mesela firma olarak kullandığımız yöntemden örnek vereyim,
<br/>
<br/>
Zend FW 1'in route yapısını sevmiyorum, bunun yanında view olarak Zend Framework 1'in harika olduğunu düşünüyorum,
<br/>
<br/>
Database katmanında ORM kullanma taraftarıyım, çünkü projesini yürüttüğüm firma 2 gün sonra bir şirket kararı olarak
bundan sonra "Mysql yerine Mssql" kullanmak istiyoruz dediğinde oturup tüm sorguları elden geçirmek istemiyorum,
<br/>
<br/>
hatta yıl olmuş 2015 neden hala sql kodu ile uğraşayım ki ? Bu yüzden Doctrine kullanmak istiyorum,
<br/>
<br/>
Symfony'nin Route yapısı harika, kendim route katmanı oluşturana kadar bu iş için yine symfony tayfasının yaptığı Silex
adında micro framework var onu kullanırım. Üstelik Silex için hemen hemen tüm çevre birimler için (redis, elastic
search, doctrine vs vs) provider mevcut.
<br/>
<br/>
Bu anlattığım yapı için başka bir blog yazısı yazacağım.
<br/>
<br/>
İyi kodlamalar.
<br/>
<br/>
**Ekleme 1 : (02.04.2015)**
<br/>
<br/>
Bu yazıya bir ekleme yapmak istemiyordum, İçerisinde küfür geçmeyen tüm yorumları yayınlama gibi bir kuralım vardır. Ama
artık, yazıyı okumadan sadece yazının başını ve sonunu okuyarak yorum yapan üstelik bu yorumlarında da yazı içerisinde
söylediğim şeyleri bana sanki söylememişim gibi sav olarak sunan yorumları artık onaylamayacağım. Okuma yazma bilmeyen
insanların yorumları, bu yazıya ve konuya bir şey kazandırmayacaktır.
<br/>
<br/>
Teşekkürler.
<br/>
<br/>

---