Ich lernte Programmieren auf einer SPS in einer Fabrikhalle, nicht auf einem MacBook in einem Startup.
Bei Ranpak programmierte ich Beckhoff-Steuerungen für Industriemaschinen. Kein Hot Reload, kein console.log, kein „das fixen wir in Produktion". Wenn eine SPS einen Fehler machte, bewegte sich ein 200-Kilo-Arm in die falsche Richtung.
Dieser Unterschied — zwischen einem Bug, der einen Retry kostet, und einem Bug, der Material kostet — prägt noch heute, wie ich Code schreibe.
Was ich auf dem Fabrikboden lernte
Bevor ich zu Ranpak kam, arbeitete ich bei Nedcar und O-I Manufacturing. Kein Code, aber die beste Lektion, die ich je hatte: Wenn ein Prozess nicht funktioniert, liegt es am System, nicht an den Menschen.
Auf dem Fabrikboden siehst du haarscharf, wo es klemmt. Menschen, die Workarounds erfinden, weil Software im Weg steht. Prozesse, die existieren, „weil wir es schon immer so gemacht haben". Teure Maschinen, die stillstehen, weil niemand Zeit hat, sie zu bedienen.
Als ich später bei Boogaard Textiles eine 100.000-€-Schneidemaschine wieder zum Laufen brachte — nicht durch Hantieren an der Maschine, sondern durch die Software darum herum — war das genau das, was ich auf dem Fabrikboden gelernt hatte: Schau auf den Prozess, nicht auf das Problem.
Die Brücke in die Cloud
Bei Agron lernte ich die Enterprise-Seite kennen: Datenqualität in großem Maßstab. Ein BI-Dashboard, das über 30.000 Fehler in bestehenden ERP-Daten erkannte. Auch hier: keine kaputte Software, sondern ein Prozess, der nie richtig eingerichtet worden war.
Inzwischen baue ich Full-Stack-Webplattformen, KI-gesteuerte Tools und API-Integrationen. Die Technologie ist anders, aber der Ansatz ist derselbe:
- Verstehe, wie die Arbeit wirklich fließt — nicht wie sie auf dem Papier steht
- Finde die Reibung — wo erfinden Menschen Workarounds?
- Entferne diese Reibung — mit der einfachstmöglichen Lösung
Nicht jeder Entwickler kann eine SPS programmieren. Aber jeder Entwickler sollte verstehen, was passiert, wenn sein Code die reale Welt berührt.
Was es bringt
Genau diese Kombination macht Kerris ICT einzigartig. Ich weiß, wie eine Fabrik funktioniert und wie eine API funktioniert. Ich verstehe, warum eine teure Maschine stillsteht — und kann sie mit einer Laravel-API und einem Dashboard fixen.
Die meisten Entwickler bauen Features. Ich finde gebrochene Prozesse und löse sie auf.