
code:
symbols that drive
images move
change pushed to arrive
idea so complex, cannot be grasped in whole
only pieces can held,
trail of focus, looking for a bend in the road
so salvation? but only the compiler knows
Yes rearrange how it goes
(0) errors (0) warnings
- Jared Bruni
Explanation
When I wrote this poem I was trying to express what it feels like to learn programming from the inside out.
In the poem I use the words mov and push which are real low level instructions used
inside a computer. mov means move a value from one place to another.
push means place something onto the stack so it can be used later.
These instructions control everything a program does. Every animation, every effect, every image on the screen
ultimately comes down to tiny symbolic steps like this.
The line symbols that drive images move is about how the symbols are the instructions and the images are the result. When I learned software development I had to understand that what I saw on the screen came from these tiny machine steps. At first it felt overwhelming. The idea is so complex that you cannot take it all in at once. You can only hold pieces of it until your understanding builds enough to see the bigger structure.
A trail of focus looking for a bend in the road describes the mental process of learning to think like a programmer. You follow one idea to the next. You find small clues in the logic that tell you where the program is going. You try to predict what it will do and why. The path is not always clear so you look for the bend in the road that reveals the next step.
So salvation? but only the compiler knows reflects the moment when you run your code and the compiler tells you
if you understood the system well enough. A compiler checks your work. It tells you if your logic holds together.
When you finally get that message at the end that says (0) errors (0) warnings it feels like the poem describes.
Everything clicked. The idea settled. You shaped something complex into something that works.
The poem is really about how I had to conceptualize programming in small steps and how I had to accept that you do not grasp the whole thing at once. You build it piece by piece until the logic finally reveals itself.
This is a short example of my artwork. It blends traditional pencil drawing with effects generated in C++ and GLSL. I have been experimenting with combining hand-drawn elements and shader based transformations to create a hybrid style that feels both organic and computational.
The fragment love = get(give()); looks like a small piece of source code, but in a spiritual sense it describes a pattern people often fall into. Someone can have everything in a material sense and still feel empty because they never initiate the one function that matters. If give() is never called, then it returns nothing. And if it returns nothing, get() has nothing to work with. The variable love stays uninitialized inside the system.
Spiritually this is a reminder that love is not a resource you acquire by possession, status, or accumulation. It is generated by what you are willing to give away. When you offer compassion, generosity, presence, or kindness, the internal call to give() returns something meaningful. Only then can get() process that action into a feeling of real connection.
A person who holds on to everything but gives nothing is essentially running empty function calls. They are expecting fulfillment without any input data. The result is predictable: emotional null values. Nothing changes. Nothing fills the internal variable that is waiting to be assigned. This is why someone can look complete from the outside and still feel hollow on the inside.
In this context the code becomes a quiet instruction: if you want to receive love, create it first. If you want life to feel full, contribute something to it. Even small acts of giving feed back into the system and generate emotional returns. The equation only works when the first function is called. Love flows when you give it a path to return.
This morning I wanted to document something that influences my day to day workflow in a more technical and scientific way. In my late teens I experienced a psychotic break that resulted in hospitalization. A formal diagnosis did not come until age twenty three after another two week psychiatric hold. The condition I was diagnosed with is chronic and produces symptoms that I manage every single day. These symptoms impact cognitive load, task switching, motivation, and overall throughput. They are variable in intensity and they interact directly with the kind of work I do.
From a technical standpoint I treat this condition as a persistent system constraint. It is similar to having hardware with known faults that require constant monitoring and adjustment. I adapt my routines, my project structures, and my development environments to work with this constraint rather than against it. Over time I have learned that creativity, focus, and productivity can still be achieved by designing around the limitations and by acknowledging them instead of ignoring them.
I have dedicated my software projects to people who experience similar conditions. My goal is to demonstrate that cognitive or perceptual differences do not eliminate capability. Instead they require a different engineering approach. The tools I build are meant to show that creative output can come from minds that do not operate within typical ranges. I want to bring awareness to this and create space for others who might be dealing with similar issues but still have strong technical or artistic potential.
None of this is the result of personal failure or misconduct. It is a medical condition with measurable symptoms and known patterns. Sometimes people misunderstand that, so part of my work is being open about the science behind it and how it integrates into my daily process. By documenting it here I hope to make the mechanics of it clearer and to continue using this log as a place to track how I work with the condition rather than be defined by it.

This morning I spent some time thinking about how my interest in programming originally developed. When I was in school I noticed early that a lot of what they were teaching felt more about shaping behavior than teaching useful knowledge. Instead of following along with ideas that did not make sense to me, I redirected my focus into computers. I started teaching myself how to code in the nineties and it became the foundation of everything I work on today.
People from my past often misunderstood the reasons for the path I took. They assumed it was about rebellion or a lack of discipline, but it was actually a deliberate choice to pursue something real and logical. This morning it was clearer to me how much that decision shaped my life. Coding has always been the one area where things make sense, where effort leads to results, and where I can build something of my own.