Changing code until it became mine

I did not begin with a blank file and a perfect idea. I began by opening something that already worked, changing a small piece, and watching what happened. At 13, that project was MyBot.run. I was not trying to pretend the whole engine was mine. I wanted to understand why it behaved the way it did, where one decision led, and which pieces I could change without losing the thread.

That process made code feel less like an assignment and more like a place I could explore. A name in one file would appear again in another. A setting in the interface would eventually become a branch in the runtime. When a change broke something, the break was often more useful than the success because it showed me a connection I had not noticed. I kept returning to the same project, and that repetition mattered more than any single feature.

There is a difference between changing a project and claiming it. The inherited engine, its history, and the work of the people before me still matter. What gradually became mine was the layer of questions I brought to it: how should a session be planned, what should stop it, what should be visible before it runs, and how can a person supervise the automation instead of guessing what it is doing? Those questions became the beginning of my own Control Center and orchestration work.

I still learn this way. I read the existing structure, make one bounded change, test the result, and keep the parts I can explain. Starting from someone else’s code did not make the learning less real. It taught me that understanding is built through careful contact with a system, not through the performance of starting from nothing. The code felt like mine only when I could describe both what I changed and what I deliberately left alone.