Wat ik heb geleerd bij federaal webwerk

Volgende week is mijn laatste week van het contract. Ik heb besloten te vertrekken en voordat ik verder ga, wilde ik opschrijven wat ik dagelijks deed.

Ik was geen directe werknemer van het bureau. Ik werkte voor een aannemer, toegewezen aan het programma van het bureau als tech lead / architect. Dat is de regeling achter veel federaal webwerk. Je zit dagelijks in het team, maar je salaris komt ergens anders vandaan.

Er was een veiligheidsproces voordat ik kon beginnen. Achtergrondonderzoek, formulieren, referenties, een wachttijd. Het is standaard voor federaal contractwerk en het vormt de onboarding meer dan de meeste banen in de private sector.

Wat ik daadwerkelijk deed

Het grootste deel van mijn tijd ging naar publieke contentwebsites. Duizenden pagina's, miljoenen bezoekers, content in verschillende talen. De meeste vertalingen werden afgehandeld door een externe service, MotionPoint. Een paar sites gebruikten de ingebouwde vertaling van Drupal, voor de Spaanse, Chinese en Koreaanse varianten. Elk had zijn eigen eigenaardigheden rond gelokaliseerde URL's en verschillende schrijfsystemen.

Veel van het werk bestond uit het gezond houden van een portfolio van bestaande Drupal-sites. Versie-upgrades, module-updates, fixes en feature-werk. Ik was ook onderdeel van een groter project om meer dan 400 Drupal-sites te consolideren tot 8 hubs. Dat is nog steeds in uitvoering.

Ik voerde audits uit. Inventarisatie van duizenden PDF's. Toegankelijkheid controleren. Kapotte links en verouderde content vinden. Het meeste van dat handmatige werk werd omgezet in Python-scripts. PDF-audits, analytics-pulls, scrapers, redirect-controles, rapportgeneratoren. Het team gebruikt er nog steeds een paar.

Ik ondersteunde ook het data-analyseteam. GA4, Google Search Console en GTM. Rapporten ophalen, tagging-problemen oplossen, discrepanties onderzoeken en de tracking synchroon houden met site-wijzigingen. Ik heb ook een deel van de rapportgeneratie geautomatiseerd in Python.

Het eerste wat ik oppakte, was het implementatieproces. Het meeste draaide al op Jenkins, maar een cruciale stap vereiste nog steeds dat iemand een shell-script vanaf zijn laptop draaide. Het verplaatsen van dat laatste stuk naar Jenkins was mijn eerste overwinning.

Later voegde ik CodeDeploy toe voor de lagere omgevingen om de implementaties daar te versnellen. Tegen het einde draaide een implementatie die vroeger meer dan een uur duurde in een paar minuten.

On-call was onderdeel van de baan. Productieproblemen wachten niet op kantooruren.

Ik besteedde ook tijd aan een content-syndicatieplatform buiten onze hoofdstack. Grails-gebaseerd, ouder, iets waar ik nog niet eerder mee had gewerkt. De Groovy die ik had geschreven voor de Jenkins-pipelines droeg bij, waardoor het oppakken van het platform sneller ging dan anders het geval zou zijn geweest. Ik heb het goed genoeg geleerd om het te troubleshooten en hielp met een server-upgrade naar Ubuntu 22.04.

Een paar andere dingen waar ik aan werkte.

• Twee React-apps, kleinere front-end onderdelen bovenop de CMS en gekoppeld aan het federale ontwerp systeem.
• AWS dagelijks. Load balancers, target groups, CodeDeploy en een flinke dosis debugging van productieproblemen die alleen bij echt verkeer verschijnen.
• Testen met Playwright en Cypress, pytest voor Python. Tegen het einde experimenteerde ik met Playwright plus een LLM om visuele regressies te vangen die normale diffs missen.
• AI-demo's en proof-of-concepts, waarbij leiderschap werd getoond wat moderne tools konden doen en hoe ze zouden kunnen passen zonder een beveiligingsreview te blazen.

De stack omvatte Drupal, PHP, Python, JavaScript, React, Groovy, Jenkins, Docker, AWS, Splunk en USWDS (het US Web Design System). Tegen het einde ook veel AI-tools (Gemini, OpenAI, vector databases, MCP servers).

Een paar dingen die ik opmerkte

Proces is echt. Veiligheidsbeoordelingen, toegankelijkheidsaudits, content-freezes, sprintplanning over pods heen. De eerste maand voelde het traag. Dan begrijp je waarom het er is.

Jira, Confluence en Bitbucket waren allemaal self-hosted voor FedRAMP-compliance. Cloudversies waren geen optie.

Er zijn veel vergaderingen. Stand-ups, sprintplanning, architectuurbeoordelingen, contentbeoordelingen, pod-syncs, één-op-één gesprekken, demo's, statusgesprekken. Sommige waren essentieel. Sommige niet.

Toegankelijkheid is geen vinkje. Het verandert hoe je dingen benoemt, pagina's structureert en test.

Editors en programmaleiders waren een groot deel van de mensen met wie ik dagelijks werkte, niet alleen andere engineers.

Je werkt met veel externe leveranciers. Akamai voor CDN en edge-beveiliging, een AWS-partner voor infrastructuur, GSA voor search.gov-integratie, en diverse audit- en reviewleveranciers onderweg. Een reëel deel van de baan is het achterhalen van antwoorden over bedrijfsgrenzen heen, niet alleen binnen je team.

Communicatie is een groot deel van de baan. Waarschijnlijk meer dan ik van tevoren had verwacht.

Ik schreef veel. Statusupdates, runbooks, overdrachtsdocumenten, tickets. Ik schrijf letterlijk een overdrachtsmail terwijl ik dit typ.

Veel tijd ging naar het uitleggen van technische afwegingen aan mensen die niet technisch zijn.

Tegen het einde deed ik wat AI-werk. AI-ondersteunde contentworkflows, LLM-classificatoren voor PDF's en MCP-servers. We begonnen ook gesprekken over het introduceren van codeeragenten zoals Codex en Claude Code als onderdeel van onze workflow. Die goedkeuringen zijn nog steeds in behandeling aan de overheidszijde.

Debugging in de cloud is een apart iets. AWS-productie ziet er niet uit als je laptop. Je brengt veel tijd door in Splunk, CloudWatch en implementatiegeschiedenissen.

Ik had het geluk om met slimme mensen te werken en voor een manager die me vertrouwde om de klus te klaren. Dat maakte het meeste van de rest makkelijker.

Dat is het. Op naar wat hierna komt.