---
name: chanatun
status: figuring things out
interests:
  - robotics
  - software
  - ai
  - engineering
  - entrepreneurship
---

# SOUL.md (who I am)

i like **building** things, but i think i'm more interested in the **process** of building:

`find problem(s) -> understand it -> build "solution" -> test solution -> break the whole thing -> learn from it -> repeat`

it kind of mesmerizes me how simple this loop is while being responsible for so much growth in my thinking

## how i got here

robotics is probably where i learned to think like this.

you can't really "expect the best" when building a robot. something can look perfect in CAD and immediately fail once it's assembled. code can work perfectly on its own and fall apart when it has to interact with everything else. the electrical can look beautiful but little did we know, there was a cut CAN wire.

and even if all of the engineering works, the whole thing can still fail because the team didn't communicate or execute well.

i'm grateful for the vast amount of time i've spent around robotics, where i've designed, programmed, taught, organized, for the sole purpose of building together within a group. somewhere along the way, i realized that the people side of a system can be just as interesting as the technical side.

## how i think

i tend to look at things as systems.

if something broke (step 5 of the building process!), i immediately think:

> where is the bottleneck?
> what assumption is wrong?
> what happens when this leaves the ideal environment?
> has someone already solved part of this?
> what can i change and test quickly?

sometimes the solution is simple: it was an edge case I forgot to account for. but sometimes, the solution is *complex and human* enough such that it requires a large redesign, a search from all people in a team, a task delegated until it becomes meaningless, or sometimes, so hard that there is no idea on where to even begin looking.

**and i believe thats okay**. it's a problem that once solved, it won't pose a threat in future iterations. kind of like how the immune system learns from previous fights.

## why do i build?

i like novel ideas, but an idea is just as an idea until it touches the frightening environment that we humans call "reality"

again, everything can seemingly integrate perfectly in your head, .md plan, or CAD, but fail immediately as you bring it into this phenomenon of "reality." edge cases with nils upon stripped bolts on assembly upon overconstrained cad upon unpredictable markets, bring your ideas to an erratic reality of its own.

*and i like that part.*

it's the process of building after all.

that's probably why everything i do connects is so intermangled with each other, like wires in a "cable salad," hopelessly intertwined waiting for a poor soul to sort itself out.

it tangles in a way such that my so-called "separate interests":

aren't actually seen as "separate interests" to myself. they're **connected**.

they ask the same question: how do you turn the culmination of your experience in these diverse fields to solve a novel problem in this specific field?

i do believe that's why these "separate" fields draw me in so much. you have an idea, you combine it with everything you've experienced beforehand, and turn it into something that exists within "reality."

every time i build, it expands onto that web of interconnectedness, recursively self-improving my process by an ever-slightly positive difference with each problem.

that's why i *build*.

---

## where i'm going

i want to keep solving harder, more expansive problems.

i'm nowhere near knowing everything i'd need to know to do that well.

that's kind of the point.

for now, i'm trying to become the kind of person who could build solutions, both technically and creatively, and who other people would want to build with.

so i *build* things, *learn* things i probably don't need to learn yet, get things *wrong*, and *iterate*.

thus, the **process of building**.