Day in the Life of a Backend Developer

Dein Bild vom Backend-Job ist vermutlich falsch, und zwar in beide Richtungen. Manche denken, man schreibt acht Stunden am Tag Code. Andere glauben, man sitze nur in Meetings und habe die Technik abgegeben. Die Wahrheit ist ein drittes, unordentlicheres Ding.

Ich beschreibe hier einen typischen Werktag eines Backend Developers mit etwa drei bis fünf Jahren Erfahrung. Kein Ausnahmetag, kein Karriere-Märchen. Ein normaler Dienstag, an dem wenig Spektakuläres passiert, genau darum geht es.

Der Morgen: Posteingang, Pull Requests, Prioritäten#

8:45 Uhr. Rechner an, Kaffee, Slack und E-Mail auf. Die erste halbe Stunde gehört dem, was über Nacht passiert ist. CI-Pipelines sind durchgelaufen, ein Kollege aus einem anderen Zeitfenster hat zwei Pull Requests kommentiert, ein Monitoring-Alert ist einmal aufgetaucht und wieder verschwunden.

Das ist kein Nebenjob. Wer hier schlampig arbeitet, verliert den Überblick über den eigenen Code. Wer zu gründlich arbeitet, verschwendet die beste Konzentrationszeit des Tages. Der Kompromiss: Alerts ansehen, Pull Requests kurz scannen, alles andere liegen lassen.

9:15 Uhr, Standup. Fünfzehn Minuten, die fast immer fünfzehn bleiben. Drei Sätze pro Person: gestern, heute, Blocker. Der Wert liegt weniger in den Statusupdates als in den zwei, drei Nebensätzen, aus denen man mitbekommt, dass ein anderes Team gerade eine Abhängigkeit anfasst, die auch einen selbst betrifft.

Danach entsteht der erste Druckpunkt. Standup endet, aber die Leute bleiben hängen. Zehn Minuten Smalltalk, fünfzehn Minuten "kurze Rückfrage", und plötzlich ist es zehn Uhr, bevor die erste Zeile Code entsteht. Wer das nicht aktiv abblockt, verliert jeden Vormittag.

Vormittag: die einzige echte Deep-Work-Phase#

Zwischen 10 und 12:30 liegt der produktivste Block des Tages. Für mittlere Backend-Arbeit braucht man zusammenhängende Zeit. Eine API umzubauen, eine Race Condition im Queue-Consumer zu finden oder eine Datenbankmigration sauber zu entwerfen, das geht nicht in 25-Minuten-Scheiben.

Die meisten Teams schützen diese Phase nicht von allein. Man muss selbst blocken: Kalenderblock "fokussiert" setzen, Slack auf stumm, E-Mail zu. Das wirkt auf manche Kollegen unfreundlich. Es ist trotzdem richtig.

Konkret sieht der Block so aus: Feature-Ticket aufmachen, betroffene Services im Repo suchen, bestehende Tests lesen, dann entwerfen, dann schreiben. Erfahrene Entwickler investieren hier vielleicht eine Stunde ins Lesen und Verstehen, bevor die erste Änderung entsteht. Juniors tippen oft früher los und bauen etwas, das lokal läuft, aber an der falschen Stelle sitzt.

Werkzeuge, die wirklich im Alltag landen: die IDE, meist IntelliJ oder VS Code, ein Terminal, Git mit dem jeweiligen CI-System, Docker für die lokale Umgebung, Postman oder curl für API-Tests, dazu Logging- und Tracing-Oberflächen wie Kibana oder Grafana, wenn etwas schiefgeht. Tickets laufen in Jira oder Linear. Wichtiger als die genaue Auswahl ist, dass man die Tools tief kennt, statt alle zwei Monate zu wechseln.

Mittagspause und der Nachmittagsknick#

12:30 bis 13:30 Pause. Danach sinkt die Konzentrationsqualität spürbar, selbst wenn man das nicht wahrhaben will. Der Nachmittag gehört deshalb Dingen, die weniger Tiefe brauchen: Code Reviews, kleinere Bugfixes, Dokumentation, Antworten auf Fragen aus anderen Teams.

Code Review ist der unterschätzte Teil der Rolle. Ein mittlerer Entwickler verbringt vielleicht eine Stunde am Tag damit, fremden Code zu lesen. Das ist unbequem und frisst Zeit, die für das eigene Ticket fehlt. Aber wer Reviews auslässt, produziert später dreimal so viele eigene Fehler.

Ein Beispiel für eine typische Review-Notiz, wie sie wirklich klingt:

"Der Filter hier greift erst nach der Pagination. Dadurch sieht der Nutzer bei mehr als 100 Datensätzen falsche Ergebnisse. Bitte den Filter vor den DB-Aufruf ziehen und den Testcase auf 150 Datensätzen erweitern."

Kurz, konkret, ohne Bewertung der Person. Genau so sollte das aussehen.

Meetings: weniger als man denkt, aber schlecht verteilt#

Der Meetinganteil variiert stark. In vielen Teams liegt er für Backend Developers zwischen etwa einem und drei Stunden am Tag, in regulatorischen Umgebenden oder bei stark abhängigen Architekturen auch höher. Das ist keine feste Regel, sondern eine typische Bandbreite, die je nach Firma stark abweicht.

Das Problem ist selten die Gesamtmenge. Das Problem ist die Verteilung. Ein 30-Minuten-Meeting um 11:15 zerstört eine Deep-Work-Phase genauso zuverlässig wie ein einstündiges. Wer Einfluss auf die Teamregeln hat, sollte auf zusammenhängende Blöcke drängen, nicht auf weniger Meetings insgesamt.

Zu den Terminen, die wirklich nötig sind, gehören Architektur-Runden bei größeren Änderungen, Refinement neuer Tickets und On-Call-Übergaben. Alles andere darf hinter einer Frage in Slack sterben.

Druckpunkte, über die niemand spricht#

Der größte Stress im Backend kommt selten vom Code selbst. Er kommt aus Abhängigkeiten, die man nicht kontrolliert. Ein fremdes Team ändert eine Schnittstelle. Ein Vendor dreht ein Rate Limit zu. Eine Datenbank, die seit Monaten läuft, verhält sich plötzlich anders.

On-Call-Wochen verstärken das. Auch hier gibt es keine allgemeingültige Zahl, aber in vielen produktionsnahen Teams gehört eine Rufbereitschaft im Rhythmus dazu. Wer das nicht abkann, sollte vor dem Wechsel fragen, wie oft und wie vergütet.

Der zweite Druckpunkt ist Schätzungen. Man schätzt ein Ticket auf zwei Tage und steht am dritten Tag vor einer Migration, die niemand vorhergesehen hat. Gute Teams behandeln das als Information, nicht als Versagen. Schlechte Teams behandeln es als beides.

Was Neue überrascht#

Der häufigste Schock ist der geringe Anteil wirklich neuer Funktionen. Ein großer Teil der Arbeit besteht daraus, bestehenden Code zu verstehen, zu pflegen und behutsam zu ändern. Wer hauptsächlich Neubauen spannend findet, wird sich im Backend häufig langweilen.

Der zweite Schock: Lesen dominiert das Schreiben. Vielleicht liest man drei bis fünfmal mehr Code, als man selbst produziert. Das ist kein Zeichen für Ineffizienz. Es ist die Arbeit.

Drittens, Soft Skills sind kein Zusatz. Wer eine technische Entscheidung nicht erklären kann, bekommt sie nicht durchgesetzt. Das gilt besonders für Backend, weil die Auswirkungen meist unsichtbar für Nutzer sind und deshalb nur über Argumentation vermittelbar werden.

Junior, Mid, Senior: dieselbe Rolle, andere Tiefe#

Der Titel täuscht. Die Aufgaben sehen ähnlich aus, die Tiefe unterscheidet sich.

Ein Junior löst das Ticket, das vor ihm liegt, mit Hilfe. Ein Mid-Level-Entwickler löst das Ticket und erkennt, welche zwei Tickets dadurch später entstehen. Ein Senior erkennt zusätzlich, dass das Problem an einer falschen Systemgrenze liegt, und verhandelt mit dem Produktteam, bevor Code entsteht.

Der Senior schreibt oft weniger Code als der Mid-Level-Entwickler. Das wird von außen falsch verstanden, auch im eigenen Management. Wer Karriere über Zeilen Code definiert, wird im Backend falsch belohnt.

Ein konkreter Unterschied am Beispiel einer Fehlermeldung im Log:

Junior-Meldung: "Request failed, see logs."

Mid-Level-Meldung: "POST /orders/confirm returned 502 between 14:02 and 14:19 UTC, correlated with a timeout on the payment service. Retry logic in OrderService.confirm needs a circuit breaker."

Senior-Meldung: zusätzlich die Frage, ob Order-Confirm überhaupt synchron auf den Payment-Service warten sollte, und ein Vorschlag zur Entkopplung über Events. Das ist derselbe Arbeitstag, eine andere Ebene.

Ein ehrlicher Tagesplan#

Wer sich das konkret vorstellen will, findet eine typische Aufteilung so:

• 30 Minuten Mails, Alerts, Pull Requests
• 15 Minuten Standup
• 2 bis 2,5 Stunden Deep Work am eigenen Ticket
• 1 Stunde Code Review für andere
• 1 bis 2 Stunden Meetings, je nach Team
• 1 Stunde kleinere Fixes, Dokumentation, Antworten
• Rest für Kontextwechsel, Gespräche, Aufräumen

Das ergibt selten acht volle produktive Stunden. Wer das nicht glaubt, sollte eine Woche lang mit einer einfachen Notiz tracken, woran die Zeit tatsächlich geht. Die Ernüchterung ist Teil des Lernens.

Was du vor dem Wechsel prüfen solltest#

Bevor du dich auf Backend-Stellen bewirbst, hilft eine kurze Ehrlichkeitsrunde mit dir selbst:

• Wie gehst du damit um, stundenlang fremden Code zu lesen, bevor du etwas änderst?
• Bist du bereit, eine Rufbereitschaft zu übernehmen, wenn das Team sie hat?
• Wie reagierst du auf Schätzungen, die danebengehen?
• Kommst du mit Arbeit klar, deren Nutzer niemand sehen?
• Kannst du eine technische Entscheidung jemandem erklären, der nicht technisch ist?

Wenn mehr als zwei Antworten negativ ausfallen, ist Backend vielleicht nicht die richtige Wahl. Das ist keine Schwäche, sondern eine nützliche Information vor dem nächsten Schritt.

Für die konkrete Stellensuche hilft ein Blick in aktuelle Backend-Ausschreibungen, um Anforderungen und Tech-Stacks realistisch zu sehen. Wer die ausgeschriebenen Stellenprofile besser verstehen will, findet dafür einen Decoder für Stellenanzeigen nützlich. Vor der Bewerbung lohnt ein Blick, ob der eigene Lebenslauf überhaupt durch die automatisierte Vorauswahl kommt, dafür gibt es einen kostenlosen ATS-Check. Tieferes zu Bewerbung, Gehalt und Rollenwechsel steht regelmäßig im Karrierebereich des Blogs.

Kostenlose Tools#

• jobrise.io/de/free-ats-checker/
• jobrise.io/de/free-jd-decoder/
• jobrise.io/de/jobs/
• jobrise.io/de/blog/

Häufige Fragen#

Wie viel Prozent der Arbeitszeit geht wirklich für Coding drauf?

Für mittlere Backend-Entwickler liegt der Anteil oft deutlich unter der Hälfte, typischerweise irgendwo zwischen einem Viertel und der Hälfte der Zeit. Der Rest verteilt sich auf Reviews, Meetings, Debugging, Dokumentation und Abstimmung. Wer eine exakte Zahl will, muss in der konkreten Firma nachfragen, weil Teamkultur den Wert stark verschiebt.

Muss man im Backend viel Mathematik können?

Für die meisten Backend-Rollen brauchst du keine höhere Mathematik. Wichtiger sind Logik, Datenmodellierung, ein gutes Gefühl für Zustände und Nebenläufigkeit sowie solides Verständnis von Algorithmen im üblichen Rahmen. Spezielle Domänen wie Machine-Learning-Backends oder quantitative Systeme sind die Ausnahme.

Wie oft wird man nachts aus der Rufbereitschaft gerufen?

Das hängt stark an Reifegrad und Größe der Systeme. In manchen Teams passiert es fast nie, in anderen mehrmals im Monat. Vor dem Vertragsunterzeichnen solltest du direkt fragen, wie oft das im Schnitt vorkommt und wie Bereitschaft vergütet wird.

Braucht man einen Informatikabschluss für den Einstieg?

Nein, viele Quereinsteiger schaffen den Weg über praktische Projekte, Bootcamps oder verwandte Rollen wie Support oder QA. Der Abschluss öffnet Türen bei großen Unternehmen mit formalen Einstiegsprogrammen. Ohne ihn brauchst du einen überzeugenden Portfolio-Code und die Bereitschaft, länger zu suchen.

Wird Backend-Arbeit durch KI in den nächsten Jahren überflüssig?

Code-Assistenten beschleunigen schon heute einzelne Aufgaben, vor allem Boilerplate und Tests. Die eigentliche Backend-Arbeit, Systemgrenzen zu setzen, Datenmodelle zu entwerfen und Fehler in verteilten Systemen zu finden, ist davon weniger betroffen. Wer KI als Werkzeug einsetzt statt als Bedrohung, hat die bessere Ausgangsposition.