Zurück zum Blog

Was ich bei der Bundesbehörde im Web gelernt habe

2026-04-245 min read

Nächste Woche wird meine letzte Woche im Vertrag sein. Ich habe beschlossen zu gehen, und bevor ich weiterziehe, wollte ich aufschreiben, was ich tatsächlich Tag für Tag gemacht habe.

Ich war kein direkter Angestellter der Agentur. Ich habe für einen Auftragnehmer gearbeitet und war als Tech Lead / Architekt dem Programm der Agentur zugeteilt. Das ist die Regelung hinter vielen staatlichen Webarbeiten. Sie sind Tag für Tag im Team, aber Ihr Gehaltsscheck kommt von woanders.

Vor meinem Start gab es einen Freigabeprozess. Hintergrundüberprüfung, Formulare, Referenzen, eine Wartezeit. Das ist Standard für staatliche Vertragsarbeiten und prägt das Onboarding mehr als die meisten Jobs im privaten Sektor.

Was ich tatsächlich gemacht habe

Die meiste Zeit habe ich für öffentlich zugängliche Inhaltsseiten aufgewendet. Tausende von Seiten, Millionen von Besuchern, Inhalte in mehreren Sprachen. Die meisten Übersetzungen wurden von einem externen Dienst, MotionPoint, übernommen. Einige wenige Seiten nutzten stattdessen die integrierte Übersetzung von Drupal für die spanischen, chinesischen und koreanischen Varianten. Jede hatte ihre eigenen Besonderheiten bei lokalisierten URLs und unterschiedlichen Schriftsystemen.

Ein Großteil der Arbeit bestand darin, ein Portfolio bestehender Drupal-Sites in gutem Zustand zu halten. Versions-Upgrades, Modul-Updates, Fehlerbehebungen und Feature-Arbeiten. Ich war auch Teil eines größeren Projekts, über 400 Drupal-Sites in 8 Hubs zu konsolidieren. Dieses Projekt ist noch im Gange.

Ich habe Audits durchgeführt. Inventarisierung von Tausenden von PDFs. Überprüfung der Barrierefreiheit. Suche nach defekten Links und veralteten Inhalten. Die meiste dieser manuellen Arbeit wurde in Python-Skripte umgewandelt. PDF-Audits, Analytics-Abfragen, Scraper, Redirect-Prüfungen, Berichtsgeneratoren. Das Team nutzt einige davon immer noch.

Ich habe auch das Data-Analytics-Team unterstützt. GA4, Google Search Console und GTM. Berichte abrufen, Tagging-Probleme beheben, Diskrepanzen untersuchen und das Tracking mit Website-Änderungen synchron halten. Ich habe auch einige der Berichtsgenerierungen in Python automatisiert.

Das Erste, was ich in Angriff nahm, war der Deployment-Prozess. Der Großteil lief bereits auf Jenkins, aber ein kritischer Schritt erforderte immer noch, dass jemand ein Shell-Skript von seinem Laptop aus ausführte. Die Verlagerung dieses letzten Teils nach Jenkins war mein erster Erfolg.

Später fügte ich CodeDeploy für die unteren Umgebungen hinzu, um die Deployments dort zu beschleunigen. Am Ende dauerte ein Deployment, das früher über eine Stunde dauerte, nur wenige Minuten.

On-Call war Teil des Jobs. Produktionsprobleme warten nicht auf die Geschäftszeiten.

Ich habe auch Zeit mit einer Content-Syndication-Plattform außerhalb unseres Hauptstacks verbracht. Grails-basiert, älter, nichts, mit dem ich zuvor gearbeitet hatte. Das Groovy, das ich für die Jenkins-Pipelines geschrieben hatte, ließ sich übertragen, was die Einarbeitung in die Plattform schneller machte, als es sonst der Fall gewesen wäre. Ich habe es gut genug gelernt, um es zu beheben, und bei einem Server-Upgrade auf Ubuntu 22.04 geholfen.

Ein paar andere Dinge, die ich berührt habe.

  • Zwei React-Apps, kleinere Frontend-Teile, die auf das CMS aufgesetzt und in das föderale Designsystem integriert wurden.
  • AWS im täglichen Betrieb. Load Balancer, Target Groups, CodeDeploy und eine beträchtliche Menge an Debugging von Produktionsproblemen, die nur bei echtem Traffic auftreten.
  • Tests mit Playwright und Cypress, pytest für Python. Gegen Ende experimentierte ich mit Playwright plus einem LLM, um visuelle Regressionen zu erkennen, die normale Diffs übersehen.
  • KI-Demos und Proofs-of-Concept, die der Führung zeigten, was moderne Tools leisten können und wie sie passen könnten, ohne eine Sicherheitsprüfung zu sprengen.

Der Stack umfasste Drupal, PHP, Python, JavaScript, React, Groovy, Jenkins, Docker, AWS, Splunk und USWDS (das US Web Design System). Gegen Ende auch viele KI-Tools (Gemini, OpenAI, Vektordatenbanken, MCP-Server).

Ein paar Dinge, die mir aufgefallen sind

Prozesse sind real. Sicherheitsüberprüfungen, Barrierefreiheitsaudits, Content-Freezes, Sprint-Planung über Pods hinweg. Im ersten Monat fühlte es sich langsam an. Dann versteht man, warum es da ist.

Jira, Confluence und Bitbucket waren für die FedRAMP-Konformität selbst gehostet. Cloud-Versionen waren keine Option.

Es gibt viele Meetings. Stand-ups, Sprint-Planung, Architektur-Reviews, Content-Reviews, Pod-Syncs, One-on-Ones, Demos, Status-Calls. Einige waren unerlässlich. Einige nicht.

Barrierefreiheit ist kein Kontrollkästchen. Sie verändert, wie man Dinge benennt, Seiten strukturiert und testet.

Redakteure und Programmleiter waren ein großer Teil der Personen, mit denen ich täglich zusammengearbeitet habe, nicht nur andere Ingenieure.

Man arbeitet mit vielen externen Anbietern zusammen. Akamai für CDN und Edge-Sicherheit, ein AWS-Partner für die Infrastruktur, GSA für die Integration von search.gov und verschiedene Audit- und Review-Anbieter. Ein echter Teil der Arbeit ist es, Antworten über Unternehmensgrenzen hinweg zu finden, nicht nur innerhalb des eigenen Teams.

Kommunikation ist ein großer Teil der Arbeit. Wahrscheinlich mehr, als ich erwartet hatte.

Ich habe viel geschrieben. Status-Updates, Runbooks, Übergabedokumente, Tickets. Ich schreibe buchstäblich eine Übergabe-E-Mail, während ich das hier tippe.

Viel Zeit ging dafür drauf, technische Kompromisse an Personen zu erklären, die nicht technisch sind.

Gegen Ende habe ich einige KI-Arbeiten durchgeführt. KI-gestützte Content-Workflows, LLM-Klassifikatoren für PDFs und MCP-Server. Wir begannen auch Gespräche über die Einführung von Coding Agents wie Codex und Claude Code als Teil unseres Workflows. Diese Genehmigungen sind auf Regierungsseite noch ausstehend.

Debugging in der Cloud ist eine eigene Sache. AWS-Produktion sieht nicht aus wie Ihr Laptop. Man verbringt viel Zeit in Splunk, CloudWatch und Deployment-Historien.

Ich hatte das Glück, kluge Leute zu leiten und für einen Manager zu arbeiten, der mir vertraute, die Arbeit zu erledigen. Das hat den Rest erleichtert.

Das war's. Auf zum nächsten.

Auf dem Laufenden bleiben

Erhalten Sie die neuesten Beiträge und Einblicke direkt in Ihren Posteingang.

Unsubscribe anytime. No spam, ever.