About
My work is easier to understand as a progression: scripts, machines, memory, hardware, runtimes. Each step made the next one more concrete.
Starting with automation
My first useful programs were small Bash scripts on Linux and Minecraft server experiments around age 12. That beginning still matters because it set a habit: write software to remove repeated manual work, then keep refining it when the first version becomes too fragile.
Learning that code touches material
At 15, I entered a three-year technical course in CNC machining and production program optimization for complex metal parts. Internships and factory work around Renault, Disney, Clerc and Barrio moved programming away from screens and into toolpaths, machine cycles, tolerances, wear and wasted stock.
That experience explains a lot of my later engineering taste. I tend to ask what happens when an assumption fails, what the machine or operator sees, and which failure can be recovered without improvisation.
C, C++ and the cost of abstraction
École 42 pushed my work toward low-level programming: C, C++, memory management, algorithms, data structures and projects where a missing boundary becomes a bug you can feel. Work for corporate contexts such as Roche, BNP Paribas and La Poste added a second constraint: software must fit into organizations that already have workflows, data and operational habits.
Hardware as a design discipline
Building and calibrating 3D printers made another lesson visible: the system is not only the firmware. It is the electronics, the chassis, the motor driver, the surface, the material, the operator and the recovery process. Labalek, a custom MSLA printer project, is the clearest artifact from that phase.
Why Rust became central
Rust fits the direction my work had already taken. It keeps explicit control over memory, file formats, process boundaries and performance while making many classes of mistakes harder to ship. In AppCore, Rust is used less as a badge and more as a way to enforce contracts: manifests, bounded runtime services, authenticated storage containers, peer envelopes, update authenticity and testable boundaries.
What I look for now
The problems that keep coming back are local-first systems, operational desktop software, secure storage, runtime architecture, industrial tooling, hardware interfaces and developer tools that are small enough to understand and stable enough to trust.
The question is rarely "which technology should be used?" The better question is: what must remain true when the network fails, the filesystem is shared, two users edit the same object, a release needs rollback, or a machine has already started doing physical work?
2026 © Daniel Netto. Todos os direitos reservados.