Van developer naar DevOps: het verhaal van Cel Pynenborg

Vier jaar geleden begon Cel Pynenborg als Java Developer bij Axxes. Het is een rol die hij altijd met veel plezier vervulde, en waarin hij bij verschillende klanten aan de slag kon gaan. Zo werkt hij momenteel bij een van de grootste telecomproviders van België. Het is een bedrijf met honderden experts, dat graag een gezonde mix van vaardigheden binnen teams wil hebben. Er zijn steeds een paar mensen bezig met UI en UX, terwijl anderen meer focussen op backend of CI/CD.

En Cel? Zijn rol veranderde: hij ging van een rol als developer naar een DevOps-rol. Dat was geen makkelijke transitie, maar hij heeft er wel veel door geleerd. Op een DevOps-manier werken is namelijk een pak meer dan zomaar een Docker container bouwen en die laten draaien.

Leer netwerken en doe aan InnerSource

De eerste stap, zo vertelde Cel op Haxx, is er een die sowieso voor iedere consultant belangrijk is: hij ging netwerken. Zo leerde hij wie waarvoor verantwoordelijk is, welke processen er bestaan en wat er nog ontbrak. ‘DevOps draait om het in vraag stellen van de status quo. Wanneer mensen je opmerken, kunnen deuren opengaan. Wees dus aanwezig, op een respectvolle manier’, zegt Cel.

Door DevOps contactpersoon te worden, kreeg Cel de Maintainer-rol en toegang tot meerdere repositories binnen de organisatie. Zo kreeg hij een beter zicht op wat er gebeurde, en kon hij problemen sneller oplossen. Dat zorgde voor meer credibiliteit binnen het bedrijf, waardoor nog meer deuren open gingen.

‘Als je die strategie doortrekt binnen je volledige bedrijf, dan doe je aan InnerSource. Je gebruikt dan open source methodieken om een soort open source cultuur binnen je organisatie te creëren’, legt Cel uit. Binnen een open source cultuur creëer je een software development community, waardoor het werk meer zichtbaar wordt, en contributions vanuit elke hoek kunnen komen. ‘Het is in veel bedrijven nog een utopie, maar het is wel een zeer slimme manier om software te ontwikkelen.’

Door binnen een organisatie de instellingen bij interne projecten standaard voor iedereen open te zetten, verandert er heel wat. Zo wordt het makkelijker om bepaalde componenten te hergebruiken en gaan teams nauwer samenwerken. De workflow doorheen het hele bedrijf standaardiseert en de kwaliteit van de code verbetert.

Verlaat je comfortzone

Cel kon voortaan mee bijdragen aan de gedeelde pipelines en Terraform modules. Zo leerde hij meer over de intricacies en het deployment proces - zeer waardevolle kennis. Daarnaast kwam hij in contact met een pak mensen, die samen met hem de basis voor die community vormden. Het lijkt controversieel, maar door bij te dragen aan de gedeelde code ervaarde Cel een grote productiviteitsboost. Hij droeg weliswaar minder bij aan de sprint goal, maar wanneer een bug of incident opduikt kan hij die sneller oplossen omdat hij de processen en tooling door en door kent.

Als DevOps heeft Cel zeer gevarieerde dagen. Het ene moment is hij bezig met het opzetten van end-to-end testen van een Angular applicatie in Cypress, het andere leert hij Terraform om op AWS EKS clusters te provisioneren. ‘Ik deed de voorbije maanden veel zaken voor de eerste keer, maar net door die uitdaging voel ik me gelukkig en productief. Je moet als DevOps Engineer uit je comfortzone stappen. Het is belangrijk om om te kunnen gaan met oncomfortabele situaties.’

Steek als DevOps Engineer de handen uit de mouwen

Onlangs onderging het bedrijf waar Cel voor werkt een transformatie, want de telecomprovider wil de teams voortaan meer ownership geven. 'Vroeger werkten teams op een zeer specifiek deel van een applicatie. De ene groep was bijvoorbeeld bezig met de frontend, de andere met de backend’, vertelt Cel. ‘Het probleem was dat de ene niet wist waar de andere mee bezig was. Na de transformatie is dat anders, en zijn teams meer hybride ingedeeld.’

Cross-functionele teams zijn sowieso een stap in de goede richting, maar volgens Cel is er nog meer nodig om van ownership te kunnen spreken. ‘In mijn ogen is dat pas het geval wanneer je de hele software development cycle ownt’, zegt hij. Het team van Cel is niet alleen verantwoordelijk voor de ontwikkeling van hun applicaties, maar ook voor de business analyse en de functionele analyse. Daarnaast beheren ze de tooling voor de deployment en staan ze bovendien ook in voor de databases en de infrastructuur die hun applicaties beschikbaar maken voor de eindgebruikers.

‘Uit de verantwoordelijkheid die dat met zich meebrengt volgt betrokkenheid, want mensen voelen zich deel van hetgeen ze maken’, vertelt Cel. ‘Als je aan DevOps doet, moet je niet alleen anderen helpen, maar ook zelf dingen bouwen. Je bent het aanspreekpunt voor anderen die met vragen zitten. Soms zal het gebeuren dat iemand je een vraag stelt waarop je het antwoord niet weet, maar die momenten moet je als opportuniteiten zien. In zo’n geval kan je samen op zoek gaan naar het antwoord, of diegene naar iemand doorverwijzen. Zo word je zelf ook beter, en als je het antwoord nadien neerschrijft creëer je een gedeelde knowledge base. Of, zoals Adam Savage ooit zei: the difference between screwing around and science is writing it down.’

Bekijk hieronder de volledige talk van Cel!