Der echte Alltag bei erminas
In vielen Unternehmen gibt es diese Azubi-Porträts, in denen alles perfekt läuft. Der Azubi kommt um Punkt acht ins Büro, arbeitet an spannenden Projekten, lernt nebenbei fünf neue Technologien und geht abends erfüllt nach Hause. Die Realität sieht meistens anders aus – und bei uns sowieso, weil schon die Grundannahme nicht stimmt. Um Punkt acht ist bei erminas nämlich meistens noch niemand da.
Dieser Text beschreibt einen normalen Tag in der Ausbildung bei uns. Nicht den besten Tag und nicht den schlechtesten. Einen Mittwoch im März, der zeigt, wie es wirklich läuft – mit den produktiven Phasen und den zähen, mit den Momenten, in denen alles klappt, und denen, in denen der Code macht, was er will, nur nicht das Richtige.
08:30 Uhr – Ankommen, wenn es passt
Max steigt aus dem Bus und geht auf die „Hallig Hanken“ zu, eine große Halle, in der lauter umgebaute Container als Büros dienen. Hinter den Fenstern sieht man schon Bildschirme leuchten, Whiteboards mit Skizzen, ein 3D-Drucker rattert irgendwo im Hintergrund. Zwischen den Containern sitzen kleine Start-ups, jede Firma mit ihrem eigenen Stil, aber alle teilen sich dieselbe Halle.
Auf dem Weg zu seinem Container kommt Max an den anderen Teams vorbei, nickt hier und da ein kurzes „Moin“ zu und bleibt vielleicht einen Moment an der gemeinsamen Küche stehen, wo schon jemand Kaffee aufsetzt. Dann steht er vor der Tür von erminas, schließt auf und tritt ins Büro.
Ein paar Kollegen sind schon da, andere kommen erst später. Bei erminas gibt es echte Gleitzeit – nicht die Variante, bei der offiziell Flexibilität gilt, aber inoffiziell alle um acht Uhr erwartet werden. Hier startet jede und jeder wirklich dann, wenn es passt. Die einzige Bedingung: Die Stunden müssen am Ende stimmen, und wer für ein Meeting eingeplant ist, ist dann auch vor Ort.
10:00 Uhr – Dailies: Kurz, aber wichtig
Um zehn beginnen die Dailies. Je nach Projekt hat Max an manchen Tagen ein Daily, an anderen zwei oder drei. Heute sind es zwei – eines für das IoT-Projekt, an dem er gerade hauptsächlich arbeitet, und eines für ein kleineres Nebenprojekt, bei dem er unterstützt.
Jedes Daily dauert etwa fünfzehn Minuten. Das Format ist simpel: Was habe ich gestern gemacht? Was mache ich heute? Gibt es Hindernisse? Keine ausufernden Diskussionen, keine Statusberichte fürs Management, kein Rechtfertigungsdruck. Einfach ein kurzer Abgleich im Team, damit alle wissen, was heute läuft.
Im ersten Daily berichtet Max, dass er gestern an der Sensoranbindung weitergearbeitet hat. Die Daten kommen jetzt zuverlässig an, aber die Darstellung im Dashboard macht noch Probleme. Heute will er das angehen. Ein Kollege erwähnt, dass er ein ähnliches Problem letzte Woche hatte, und bietet an, später kurz drüberzuschauen, falls Max nicht weiterkommt.
Das zweite Daily ist noch kürzer. Das Nebenprojekt läuft gerade ruhig, Max’ Teil ist größtenteils erledigt, er wartet auf Feedback vom Kunden. Nichts Neues, weiter geht’s.
Um halb elf sind beide Dailies durch, und Max hat den Rest des Vormittags zum Arbeiten.
10:35 Uhr – Coden, endlich
Die nächsten anderthalb Stunden gehören dem Code. Keine Meetings, keine Unterbrechungen, nur Max und das Dashboard-Problem.
Das Problem ist eines dieser Dinge, die auf den ersten Blick trivial wirken und sich dann als hartnäckig erweisen. Die Sensordaten kommen korrekt an, das hat er gestern verifiziert. Aber im Dashboard werden manche Werte falsch dargestellt – nicht alle, nur manche, und scheinbar ohne Muster.
Max fängt an, systematisch zu debuggen. Er prüft die Daten an verschiedenen Stellen im System. Am Sensor: korrekt. Nach der Übertragung: korrekt. In der Datenbank: korrekt. Im Backend: korrekt. Im Frontend… da wird es merkwürdig.
Zu diesem systematischen Debuggen gehört bei erminas auch, dass Softwaretests ganz selbstverständlich Teil der Arbeit sind – egal, ob jemand Senior-Entwickler oder Azubi ist. Jede*r schreibt Unit-Tests für den eigenen Code, dazu kommen automatisierte Checks in den Build-Pipelines und später Code Reviews im Team. Viele Fehler werden dadurch schon abgefangen, bevor sie überhaupt jemand im Browser sieht. Aber manchmal rutscht ein Bug eben trotzdem durch und versteckt sich in einer Ecke, die bisher niemand getestet hat – so wie heute.
Er schaut sich den Frontend-Code genauer an. Irgendwo zwischen Datenbank und Darstellung passiert etwas, das nicht passieren sollte. Er fügt Logging hinzu, lässt das System laufen, schaut sich die Ausgaben an. Langsam kristallisiert sich ein Muster heraus: Das Problem tritt nur bei bestimmten Zeitstempeln auf.
12:15 Uhr – Mittagspause mit Kollegen
Bei erminas heißt Mittagspause wirklich Pause. Meist bringt jede*r etwas von zu Hause oder vom Bäcker mit und setzt sich an die Tische direkt vor den Containern. Das Team ist klein, die Altersgruppen sind gemischt. An manchen Tagen wird es etwas gemeinschaftlicher: Dann wird zusammen Pizza oder Döner bestellt und alle sitzen in lockerer, familiärer Runde zusammen.
Sie reden über alles Mögliche. Ein neues Restaurant, das aufgemacht hat. Die absurde Verkehrssituation an der Baustelle vor dem Büro. Jemand erzählt von einem Podcast, den er gehört hat. Die Arbeit kommt nur am Rande vor, und das ist auch gut so.
13:30 Uhr – Azubi Weekly
Nach der Mittagspause steht das Azubi Weekly an. Das ist ein fester Termin jede Woche, an dem der Ausbilder und alle Azubis zusammenkommen – aktuell sind das drei, in verschiedenen Lehrjahren und mit verschiedenen Schwerpunkten.
Das Format ist locker, aber strukturiert. Jeder berichtet kurz, woran er gerade arbeitet und wie es läuft. Nicht nur grob wie im Daily, sondern mit mehr Detail. Was sind die aktuellen Projekte? Wo gibt es Herausforderungen? Was hat man in letzter Zeit gelernt?
Heute erzählt Max von seinem Zeitzonenproblem. Ein Azubi aus dem dritten Lehrjahr nickt wissend – er hatte mal etwas Ähnliches und gibt einen Tipp, wo Max noch schauen könnte. Eine Azubi-Kollegin aus dem ersten Jahr hört zu und macht sich Notizen. Irgendwann wird sie vor ähnlichen Problemen stehen, und dann hilft es, schon mal davon gehört zu haben.
Ein Teil des Meetings dreht sich auch um die Berufsschule. Nächste Woche steht eine Prüfung an, und jemand hat Fragen zum Stoff. Das Schöne am Azubi Weekly: Die verschiedenen Lehrjahre lernen voneinander. Wer ein Jahr weiter ist, kennt die Prüfung schon und kann Tipps geben. Wer ein Jahr zurück ist, sieht, was auf ihn zukommt.
14:20 Uhr – Zurück zum Bug
Der Zeitzonenbug wartet noch. Mit dem Tipp aus dem Azubi Weekly hat Max jetzt eine neue Idee, wo er suchen könnte.
Er findet die Stelle schneller als erwartet. Eine JavaScript-Bibliothek, die Zeitstempel verarbeitet, interpretiert bestimmte Formate anders als erwartet. Die Dokumentation ist unklar, was zu dem Problem geführt hat. Die Lösung ist am Ende nur ein paar Zeilen Code, aber der Weg dahin hat Stunden gedauert.
Das ist Softwareentwicklung. Manchmal verbringt man einen halben Tag damit, ein Problem zu finden, das sich in dreißig Sekunden beheben lässt. Das Frustrierende daran hat Max inzwischen akzeptiert. Es gehört dazu. Und das Gefühl, wenn der Bug endlich gefunden ist, macht einiges davon wett.
Er schreibt einen kurzen Eintrag im internen Wiki: Problem, Ursache, Lösung. Falls jemand anderes mal vor demselben Problem steht, muss er nicht denselben Weg gehen.
15:30 Uhr – Tests und Aufräumen
Der Bug ist gefixt, aber die Arbeit ist noch nicht fertig. Bevor der Code ins Hauptprojekt fließen kann, braucht er Tests. Max schreibt ein paar Unit-Tests, die sicherstellen, dass die Zeitstempelkonvertierung jetzt korrekt funktioniert – nicht nur für den aktuellen Fall, sondern auch für Sonderfälle, die später einmal auftreten könnten.
Von außen wirkt das oft wie unnötiger Extra-Aufwand: Der Bug ist behoben, die Funktion läuft, warum jetzt noch Zeit mit Tests verbringen? In der Praxis sorgen genau solche Tests dafür, dass der Code auch in ein paar Monaten noch funktioniert, wenn jemand anders etwas ändert oder neue Features dazukommen. Gerade in größeren Projekten mit vielen Entwickler*innen, externen Partnern und mehreren parallelen Branches braucht es mehrere Sicherheitsinstanzen, damit nichts durcheinandergerät: sauberen Code, verständliche Commits, automatisierte Tests und später auch Code Reviews.
Tests sind also nicht „nice to have“, sondern ein wichtiger Teil von Professionalität. Sie fangen Probleme früh ab, bevor sie beim Kunden oder in der Produktion landen – auch wenn es sich im Moment manchmal einfach nur nach „nerviger Mehrarbeit“ anfühlt.
16:30 Uhr – Code Review
Max’ Änderungen sind fertig und getestet. Er erstellt einen Pull Request – eine Anfrage, den Code ins Hauptprojekt zu übernehmen – und beschreibt kurz, was er gemacht hat und warum. Im Hintergrund laufen automatisierte Checks: Die Tests springen an, Linter prüfen Code-Stil und Formatierung. Erst wenn diese Schutzschicht grün ist, geht es an den nächsten Schritt.
Jetzt kommt jemand anderes ins Spiel. Bei erminas reviewed man seine eigenen Pull Requests nicht selbst – das übernimmt immer ein Kollege oder eine Kollegin. Je nach Projekt schauen manchmal sogar zwei Personen drauf. Das ist nicht, weil man sich gegenseitig misstraut, sondern weil ein zweites Paar Augen fast immer Details sieht, die dem ersten entgangen sind: ein Randfall, eine unverständliche Variable, ein Kommentar, der präziser sein könnte.
Natürlich kann sich das manchmal nach zusätzlichem Aufwand anfühlen: warten auf Feedback, Kommentare beantworten, noch einmal umbauen. Aber genau diese Schleifen sorgen dafür, dass das Projekt auch dann stabil bleibt, wenn viele Leute gleichzeitig daran arbeiten – intern, extern, über mehrere Standorte und Zeitzonen hinweg.
Während er auf das Review seines eigenen Pull Requests wartet, schaut Max sich selbst einen Pull Request an, den ein Kollege heute Morgen erstellt hat. Code Review ist keine Einbahnstraße. Auch als Azubi soll und darf er den Code anderer begutachten. Beim Lesen fremden Codes lernt man mindestens so viel wie beim Schreiben des eigenen.
An einer Stelle versteht Max nicht, was der Code tut. Er schreibt einen Kommentar mit einer Frage. Keine Kritik, nur Neugier. Vielleicht gibt es einen guten Grund, den er nicht sieht. Vielleicht ist die Stelle aber auch tatsächlich verwirrend und sollte klarer geschrieben werden. Das Gespräch wird es zeigen – und wenn am Ende der Code besser und verständlicher ist, hat sich der Aufwand gelohnt.
17:15 Uhr – Feierabend
Max macht sich Notizen für morgen: Was ist noch offen? Wo will er weitermachen? Das Pull-Request-Review steht noch aus, wahrscheinlich kommt das morgen früh. Danach könnte er anfangen, das nächste Feature zu bauen.
Er fährt den Rechner runter, verabschiedet sich von den Kollegen, die noch da sind. Manche werden noch eine Weile bleiben, andere sind schon weg. Bei erminas gibt es keinen sozialen Druck, als Letzter zu gehen, und keinen misstrauischen Blick, wenn man als Erster aufbricht. Die Arbeit ist geschafft, die Stunden stimmen, morgen geht es weiter.
Und was heißt das jetzt für dich?
Das war ein Mittwoch im März bei erminas – keiner, an dem alles perfekt läuft, aber auch keiner, an dem alles schiefgeht. Viel davon ist ganz normaler Alltag: Bugs suchen, Meetings, Tests schreiben, Code reviewen. Manchmal ist es frustrierend, manchmal macht es richtig Spaß, oft ist es einfach ehrliche, konzentrierte Arbeit im Team.
Wenn du dir eine Ausbildung wünschst, in der du nicht nur „beschäftigt“ wirst, sondern wirklich Teil eines Projekts bist – mit Verantwortung, echten Kunden, echten Problemen und echten Lösungen –, dann könnte das hier gut zu dir passen. Du musst bereit sein, dich durch zähe Bugs zu kämpfen, Unit-Tests zu schreiben, Pull Requests von anderen zu lesen und deinen eigenen Code von jemand anderem hinterfragen zu lassen. Kurz: Du musst Lust auf Professionalität haben, auch an den Tagen, an denen sie sich eher nach „nervig, aber notwendig“ anfühlt.
Wenn du dich darin wiederfindest und dir vorstellen kannst, deinen eigenen Mittwoch im März bei uns zu verbringen, schau auf unserer Karriereseite vorbei und bewirb dich:
