How Learning About EDI and CAN Systems Led Me to Understand APIs and Become a Software Engineer

Before I ever touched a line of code, I was fascinated by how machines talked to each other.

In the automotive world, systems like the CAN bus (Controller Area Network) and EDI (Electronic Data Interchange) blew my mind. These weren’t just wires or sensors—they were networks. Communication systems. Interfaces.

I didn’t realize it at the time, but I was being introduced to the core idea behind APIs—systems talking to systems through structured protocols.

---

🚗 CAN Bus: The Vehicle’s Internal API

Inside a car, the engine, transmission, ABS, and even the dashboard don’t communicate through magic—they use a protocol called CAN. Each module (ECU) sends and listens to messages on a shared network. It’s fast, reliable, and consistent.

Sound familiar? It’s just like an API.

Instead of calling GET /status, an engine control unit sends a message like ID 0x0CF00400: engine RPM = 2000. Another module listens and responds accordingly.

---

🏢 EDI: The Business World's API Before APIs

On the other hand, EDI is how businesses like warehouses and retailers communicated—well before REST or GraphQL were cool.

Want to send a purchase order? You’d send an EDI 850 document. Shipment notice? That’s an EDI 856.

It’s structured, automated, and standardized. Again—API vibes.

---

💡 The Shift: From Machines to Software

Learning how these systems communicated made something click: APIs are everywhere.

Whether it’s cars, factories, or cloud software—everything depends on structured communication between systems. Once I made that connection, diving into REST APIs, JSON, and HTTP felt familiar.

And that’s what launched me into software engineering.

---

🎯 Why This Matters

If you’re coming from a technical background that’s not traditional software—mechanics, electronics, business operations—you already understand systems.

APIs, at their core, are about interfaces and protocols. Whether it’s a CAN message, an EDI invoice, or a REST call—they’re all just conversations between machines.

Once you recognize that, learning to build software is just learning a new dialect of the same language.

---

🧰 TL;DR