Hands-On History: A Solid Foundation
A chance encounter at the 1994 Dade County Youth Fair forestry exhibit introduced me to a remarkable vehicle, and cemented a core principle that would help define my approach to software development. The exhibit allowed for an unusually detailed hands on inspection of an AM General H1's architecture. As a fourteen-year-old I was giddy, and already acquainted with the challenges of maintaining consumer vehicles like the Ford Bronco and I was immediately captivated by the stark contrast in its robust, mission-critical design. For the next hour my father and I poked and prodded, asked questions and commented, in awe of its rugged, purpose-built design. He then remarked, "You know, this would be the last truck you ever had to buy." He saw a solid foundation where everything else was just a serviceable component. I now had a new dream car.
My father, a veteran, and I were amateur mechanics out of necessity. We learned to fix what was broken, identify weak points, and extend the life of our equipment. By the time I was fourteen, we had already pulled, rebuilt, and replaced two V8 engines in our family's daily drivers—cars that served us for many years after. This hands-on experience taught me that even complex systems can be understood and maintained.
These lessons are directly transferable to how I approach system design and component architecture. Maintainable systems can be broken down into their core components, each individually testable and only as complex as necessary.
I moved to Boynton Beach in 2013, and while getting to know the new neighbors I found the opportunity to test drive and purchase an actual H1. I sold my jeep, and motorcycle and bought it 1998 AM General H1. It wasn't perfect, but this was civilian model with creature comforts like airconditioning and cruise control, and had the bones to last. A long-term lesson in mechanical engineering, patience, and the joy of working on a system designed for longevity, and an excuse to buy more tools.
Foundations in Understanding
As a lifelong student, my approach to technology is grounded in a deep curiosity for the "why" behind the "how." I believe that true mastery comes not just from using a tool, but from understanding its design, its limitations, and its place in the broader ecosystem. This philosophy guides how I learn, how I build, and how I solve problems.
A Solid Foundation
- Fundamentals First: I prioritize understanding core concepts—data
structures, network protocols, OS fundamentals—before committing to a framework. This
"measure twice, cut once" approach avoids costly migrations and ensures the chosen solution
is genuinely the best fit. It’s about replacing the broken mirror, not buying a new car.
VHT yellow coat, and ARP 2000 head studs, essential for handling the increased cylinder pressure expected from the new turbo. 
Upgraded HK 1.6 roller rockers from Quadstar for improved valve train stability and performance. - Deliberate Practice: I'm currently exploring Advanced AI/ML techniques in Google Cloud to understand how to build more intelligent, data-driven applications.
- Intellectual Honesty (The Value of Failure): Not every experiment succeeds.
The most valuable lessons come from experience, turning failures into a durable
understanding of what to avoid or what data was missing from the initial equation.
Learning to weld, while fitting an exhaust for a better flow. 
Welding in sandals is a mistake, An attempt at a stainless exhaust. 
The first, less-than-perfect attempt at exhaust and welding. Ultimately scrapped. 
Final turbo header fitment (right/passenger side) after design iterations. 
Final turbo header fitment (left/driver side) completing the build.
The AI Integration Journey
As someone skilled in areas most affected by AI, I've embraced it as a powerful augmentation to my workflow, not a replacement. My focus is on using AI strategically to enhance productivity and solve more complex problems.
Experiments & Augmentation
- Google Cloud Platform: I am actively experimenting with GCP's Products and services at the moment.
- GitHub Copilot Learning Curve: I have used Copilot as a "pair programmer" to assist and accelerate development. While it takes time to learn its nuances, it's incredibly powerful for generating boilerplate code, creating unit tests, and exploring alternative implementations. But like any resource there are costs to not setting constraints exactly correct. Components of this site itself was built with significant assistance from Copilot.
Tech Stories: Impact-Driven Solutions
Technology is most valuable when it solves a real-world problem. Here are a few stories where a deep understanding of fundamentals led to significant business impact.
The Emergency REPL: From Hours to Minutes
Problem: We had months to plan for a hosting provider change on a production system that cannot be down for longer than our timebox and rollbacks were not possible. The potential need for debugging critical, time-sensitive issues in a proper locked-down new foreign production environment was immenent and experience whispered of a incoming nightmare.
Solution: I proactively built a highly logged custom, secure Python-like REPL (Read-Eval-Print Loop) that could be safely injected into any of the live python environments. This was used a powerful diagnostic and repair tool, reducing emergency response time from hours or minutes to seconds. Used for years for pre-release and post-release steps and built to authenticate and target individual nodes fooling the HAProxy load balancer, ensuring patches could be applied with surgical precision, and sometimes as cron jobs.
AThe $40/Day Personal Website
Problem: Excited by a generous $1500 credit, I set up this personal site on GCP using "best practices": a separate Cloud SQL instance and a dedicated app server. While quick to configure, I soon discovered this overkill architecture was burning through credits at a projected rate of $40/day.
Solution: I quickly refactored. By consolidating services and installing PostgreSQL directly on the app server instance and downgrading the virtual hardware, I reduced the daily cost to about $0.18. It was a practical lesson in right-sizing infrastructure to the problem at hand, not just following abstract best practices.
Build it, prototypes are cheap.
In an industry that often favors off-the-shelf solutions, I've always found immense value in building and deeply understanding my own development environment, usually a flavor of linux in vmware as a clone of production. Where i would shell to an emacs session to develop, no local sharing, or software license issues, just brass tax whats needed. It's not about being different, its about knowing and not guessing and it's about being more effective with more options.
The Emacs Ecosystem
Historically, I have used Emacs for 99% of my programming and still today prefer it, however impossible today with all the AI advantages and services available. This isn't about nostalgia; it's about creating a fully integrated, distraction-free environment tailored to my exact workflow, without the bells and whistles auto-complete or syntax highlighting. There is something pure about writing things from scratch, where no surprises are introduced externally. Having the same environment as production is just a disaster preparation that has prevented countless issues, and having emacs installed is something small enough devops does not complain, we can debate node, or vi later. But gone are the days where I can spend 100% of my time in the terminal with current pace of AI tools development.
Building from Scratch
When faced with the need for point-and-click functionality in a legacy system, I chose to build it from the ground up rather than integrating a heavy, modern framework. These decisions result in lightweight, zero-dependency solutions that are easier to maintain and more perfectly suited to the problem, demonstrating that the "right" tool is sometimes the one you build yourself.
Project Gallery & Milestones
A collection of photos documenting the work, repairs, and upgrades I've performed over the years.
