Have you ever had to explain something extremely complex in a language that isn't your own, while crossing your fingers that the server doesn't crash?

If you use JD Edwards and develop in Orchestrator, you know what I mean.

That little knot in your stomach.

Testing new logic in front of an audience is a mix of adrenaline and pure frustration.

A few days ago, I faced that exact challenge: my first advanced technical training 100% in English. The goal was ambitious. We wanted to master Tool Release 26.

We started with Groovy and AI. Then we moved to Connectors to handle external APIs and FTPs, set up Custom Monitoring, and built robust Error Handling. We even designed Workflows and Widgets with Statefuls.

But the reality of being "in the trenches" is different.

There were moments when things simply broke.

External APIs wouldn't communicate with our Connectors. Workflows refused to trigger the Orchestrators. And configuring the charts in our Widgets became a real puzzle.

Far from being a disaster, those glitches were a gift.

We eventually solved every single one of them live. Seeing senior professionals collaborate to fix these issues confirmed something for me: teaching is the most brutal way to learn.

But this isn't just about tech. It's about business agility.

Automating these processes reduces human error. It allows companies to scale without relying on endless, expensive "hard-coded" developments.

This is just the beginning. On the 20th, I’m back at it with another client, raising the bar even higher.

Seeing this demand, I'm working on something specific. A proposal for those who want to stop being reactive technical support and start architecting real solutions.

I'll share more details in the coming days. Stay tuned.

Mario Garcia