{
"$type": "site.standard.document",
"content": {
"$type": "pub.leaflet.content",
"pages": [
{
"$type": "pub.leaflet.pages.linearDocument",
"blocks": [
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"description": "S2 · Afl. 15 · 49 min · 21 maart 2022",
"previewImage": {
"$type": "blob",
"ref": {
"$link": "bafkreihiqfpqf7uk3l543lyjirgcttjbiy5zi66urqlcvb755x3nejzjji"
},
"mimeType": "image/jpeg",
"size": 63832
},
"src": "https://codeklets.nl/episodes/381",
"title": "▶ Beluister deze aflevering"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.text",
"facets": [],
"plaintext": "We hebben het samen met Dennis, Redmar en Johnny over de Staat van Programmeren in 2022"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "http://www.creativecode.nl"
}
],
"index": {
"byteEnd": 24,
"byteStart": 9
}
},
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#didMention",
"did": "did:plc:25iypiijjfwrpnm4k5bcudyq"
}
],
"index": {
"byteEnd": 39,
"byteStart": 26
}
},
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#didMention",
"did": "did:plc:n5zdxzzelmg7g22ebweczura"
}
],
"index": {
"byteEnd": 69,
"byteStart": 56
}
},
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://kishenpanday.medium.com"
}
],
"index": {
"byteEnd": 94,
"byteStart": 71
}
}
],
"plaintext": "Te gast: Redmar Kerkhoff, Dennis Doomen · Presentatie: Saber Karmous, Kishen Simbhoedatpanday, Johnny Dongelmans"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.header",
"facets": [],
"level": 2,
"plaintext": "Hoofdstukken"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.unorderedList",
"children": [
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/381?t=11"
}
],
"index": {
"byteEnd": 11,
"byteStart": 0
}
}
],
"plaintext": "0:11 Intro"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/381?t=88"
}
],
"index": {
"byteEnd": 60,
"byteStart": 0
}
}
],
"plaintext": "1:28 Nieuwe ontwikkelaars kunnen het beste beginnen met …"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/381?t=302"
}
],
"index": {
"byteEnd": 67,
"byteStart": 0
}
}
],
"plaintext": "5:02 Programmeren van een moderne applicatie in 2022 is te complex"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/381?t=644"
}
],
"index": {
"byteEnd": 82,
"byteStart": 0
}
}
],
"plaintext": "10:44 Welke principes pas je toe in je toolstack om de situatie simpel te houden?"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/381?t=992"
}
],
"index": {
"byteEnd": 74,
"byteStart": 0
}
}
],
"plaintext": "16:32 De enige manier om oplossingen te bouwen is middels “the cloud”"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/381?t=1284"
}
],
"index": {
"byteEnd": 73,
"byteStart": 0
}
}
],
"plaintext": "21:24 Over welke technologie zijn jullie op dit moment heel enthousiast?"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/381?t=1612"
}
],
"index": {
"byteEnd": 103,
"byteStart": 0
}
}
],
"plaintext": "26:52 We zijn over de piek heen van de hype cycle als het aankomt op nieuwe programmeertalen/platforms"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/381?t=1814"
}
],
"index": {
"byteEnd": 81,
"byteStart": 0
}
}
],
"plaintext": "30:14 Wat zou je willen weten over de taal/platform van degene die naast je zit?"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/381?t=2142"
}
],
"index": {
"byteEnd": 32,
"byteStart": 0
}
}
],
"plaintext": "35:42 Vragen vanuit het publiek"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/381?t=2178"
}
],
"index": {
"byteEnd": 24,
"byteStart": 0
}
}
],
"plaintext": "36:18 Vraag van Wim The"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/381?t=2428"
}
],
"index": {
"byteEnd": 29,
"byteStart": 0
}
}
],
"plaintext": "40:28 Vraag van Frank Bakker"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/381?t=2723"
}
],
"index": {
"byteEnd": 32,
"byteStart": 0
}
}
],
"plaintext": "45:23 Vraag van Peter Hesseling"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/381?t=2887"
}
],
"index": {
"byteEnd": 12,
"byteStart": 0
}
}
],
"plaintext": "48:07 Outro"
}
}
]
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.header",
"facets": [],
"level": 2,
"plaintext": "Fragmenten"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.blockquote",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/381?t=384"
}
],
"index": {
"byteEnd": 67,
"byteStart": 0
}
}
],
"plaintext": "Is modern programmeren te complex? Het Kubernetes-landschap duizelt\n\nRedmar ziet 500 projecten op de Kubernetes landscape en pleit voor meer 'minder' in de branche."
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.header",
"facets": [],
"level": 2,
"plaintext": "Shownotes"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.text",
"facets": [],
"plaintext": "Dit is een speciale aflevering. De eerste CodeKlets \"live\" opname met publiek erbij. We houden een panel discussie over de \"Staat van Programmeren\". Het panel bestaat uit, als je onze podcast trouw hebt geluisterd, 3 bekende gezichten: Redmar Kerkhoff, Dennis Doomen & Johnny Dongelmans. Het panel leggen we een aantal stellingen en vragen voor, om een beetje een beeld te krijgen hoe het staat met de \"Staat van Programmeren\" in 2022."
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://www.avivasolutions.nl/"
}
],
"index": {
"byteEnd": 55,
"byteStart": 40
}
}
],
"plaintext": "Dit panel is mede mogelijk gemaakt door Aviva Solutions. We mochten daar te gast zijn op het Aviva Impulse event."
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.header",
"facets": [],
"level": 3,
"plaintext": "Random notes"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.unorderedList",
"children": [
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://dutchangular.org/talks"
}
],
"index": {
"byteEnd": 44,
"byteStart": 0
}
}
],
"plaintext": "Dutch Angular Group en Angular lunch sessies"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://jamstack.org/"
}
],
"index": {
"byteEnd": 8,
"byteStart": 0
}
}
],
"plaintext": "Jamstack"
}
}
]
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.header",
"facets": [],
"level": 2,
"plaintext": "Links"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"src": "https://www.bol.com/nl/nl/p/accelerate-the-science-of-lean-software-and-devops/9200000080652224/",
"title": "Accelerate: The Science of Lean Software and Devops"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"src": "https://teamtopologies.com/",
"title": "Team Topologies"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.horizontalRule"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/381"
}
],
"index": {
"byteEnd": 72,
"byteStart": 60
}
}
],
"plaintext": "Beluister de aflevering en lees het volledige transcript op codeklets.nl."
}
}
],
"id": "372dc256-8d48-493b-8e3d-d08a92a56c08"
}
]
},
"contributors": [
{
"did": "did:plc:n5zdxzzelmg7g22ebweczura",
"displayName": "Saber Karmous",
"role": "host"
},
{
"did": "did:plc:25iypiijjfwrpnm4k5bcudyq",
"displayName": "Dennis Doomen",
"role": "guest"
}
],
"coverImage": {
"$type": "blob",
"ref": {
"$link": "bafkreihiqfpqf7uk3l543lyjirgcttjbiy5zi66urqlcvb755x3nejzjji"
},
"mimeType": "image/jpeg",
"size": 63832
},
"description": "We hebben het samen met Dennis, Redmar en Johnny over de Staat van Programmeren in 2022",
"path": "/episodes/381",
"publishedAt": "2022-03-21T15:19:20.000Z",
"site": "at://did:plc:flhrheaiuteqoy65yixudwsv/site.standard.publication/self",
"tags": [
"Clean code",
"Panel"
],
"textContent": "Nou, welkom bij een nieuwe aflevering van de CodeKlets podcast. Het is een heel speciale. De eerste aflevering die live is, de eerste aflevering met publiek, hebben we nog nooit gedaan. Het format is ook nieuw. We hebben een panel met drie panelleden. De eerste die voor mij zit, dat kun je niet zien via de luisteraar zeg maar, is Johnny. Dat heb ik zelfs nog niet gezegd, we hebben teams, een aantal, hoe zeg je dat, teams die vertegenwoordig, een vertegenwoordig C-Sharp, de andere Ruby, de andere Rust en Elixir. Johnny is degene die team Ruby is in dit geval, Redmay gaat Rust en Elixir doen en Dennis mag C-Sharp en .NET vertegenwoordigen, dus ik hoop dat je daar goed mee voelt, niet halverwege gaan switchen. We hebben een aantal stellingen, de vragen en stellingen, de vragen zijn steeds in het lichtblauw, de stellingen zijn in het zalmroos gekleurd, dus dat zie je zo meteen op, het publiek ziet dat op het scherm en jullie moeten ook maar op het scherm kijken, succes ermee. Oké, de eerste vraag, als jullie nieuwe ontwikkelaars, zeg maar, een advies wat je aan de nieuwe ontwikkelaars zou willen geven, waarom zou je mee moeten beginnen, Dennis, wat zou jij adviseren? Dat je heel goed leert zoeken op Google, dat is mijn mening serieus. Dat is het ook? Nee, nee. Nee, best te beginnen, naar andermans code kijken, dat is denk ik wel een hele goeie. Open source project, Stackoverflow is natuurlijk een belangrijke bron, maar kijk gewoon eens wat andere mensen doen, kijk wat je daarvan kan leren. Is het niet een specifiek platform of taal, dat is een soort van een goeie om mee te beginnen of is dat... Nee, ik denk dat hij zijn eigen voorkeur heeft natuurlijk. Oké. Nee, geen mening over. Redmo, wat vind jij ervan? Daar ga ik eigenlijk wel aan mee, de meeste junioren of jongens die beginnen met programmeren, die vergeten eigenlijk dat je inderdaad ook hoort te googlen, dat is iets dat het mag, zeg maar. Soms zie je ze heel lang hun best doen en dan struggelen en dan, ja maar je mag ook googlen, zo van doen wij ook. Maar qua platform dacht ik eigenlijk aan Scratch, maar dat is meer voor als kinderen ermee willen beginnen en als je er net mee in aankomt. Swift Playgrounds is wel een eentje die heel leuk is, als je gewoon een iPad hebt dan kan je dat installeren en dat is al iets voor iets oudere kinderen en volwassenen. Ja, en ik zou zeggen van als je er net mee begint ook aan die schroom om no-code-tools te gebruiken, dus gewoon veel meer, dus dingen aan elkaar kunnen klikken, gewoon begin er gewoon mee, zeg maar, en vooral zoeken waar je plezier uit haalt. Ja, oké. Niet jezelf erg verplichten van ik moet dit doen, ga gewoon iets doen waar je op dat moment gewoon plezier uit haalt. Ik denk dat het wel uitmaakt voor advies of je waar je voor begint, dus nu je echt professioneel wilt doen of dat je er kennis mee wilt maken. Oké. Johnny? Nou, ik heb hier niet zo heel veel meer aan toe te voren, het laatste inderdaad was dat ik dacht ja als je gaat programmeren, ja je moet er wel plezier uit halen, of het moet iets oplossen of je moet er met name plezier uit halen voor jezelf, iets oplossen waarvan je denkt dat lijkt me nou leuk om te kunnen doen, dat vond ik vroeger in ieder geval toen ik begon het meest magische van programmeren, ja je gaat ineens iets automatiseren, je gaat iets echt oplossen wat je vroeger met de hand moest doen bijvoorbeeld, dat vond ik mijn eerste stap was echt iets automatiseren en dat vond ik gewoon heel erg leuk om te zien, om te zien werken. Ja, je hoort ook, dat is ook bij heel veel gasten zeg maar die we hebben gehad, dat ze zijn begonnen met bouwen van games, omdat dat dan, ja dat spreekt meteen heel erg aan. Dus dat... Ik niet, nee. Jij niet? Nee. Oké. Als ik nog mag reageren, ik zou het me denken, ik had laatst ook een ontwikkelaar die eigenlijk net van de universiteit afkwam en even los van de technieken, is misschien een beetje afgezaagd maar er is een boek dat heet Clean Coder, niet te verwarren met het andere boek, wat eigenlijk heel erg gaat over wat betekent het nou eigenlijk om professional te zijn. Dus wat betekent het nou om te werken in een bedrijf, want het is bijvoorbeeld niet altijd zo dat als een manager iets zegt dat je ja moet zeggen, daar gaat hij heel erg over, dus dat boek focust zich heel erg op de soft skills die natuurlijk ook superbelangrijk zijn. En programmeren kan iedereen. Dus ik denk dat iedereen wel kan leren programmeren, tot een zekere mate, maar om te acteren als een programmeur, als een professieel ontwikkelaar, daar komt veel meer mee kei in, communicatie en omgang met mensen. Ja, dat is waar. Ik ben zelf heel slecht in trouwens. Dat is ook heel erg belangrijk. Oké. Schopen in een keer te binnen. Ja, goeie toevoeging. Dan komen we bij de eerste stelling, hopen dat er wat discussie loskomt. Programmeren van moderne applicaties in 2022 is eigenlijk te complex. Johnny? Ja, dat hangt er vanaf. It depends. Is het over het algemeen te complex? Ja, ik denk dat het met name vaak gewoon de bedrijfscultuur reflecteert. Dat is een beetje hoe ik er altijd tegen nakijk tegen applicaties. Het is een reflectie in afspiering van je bedrijfscultuur. Dus hoe ingewikkelder de bedrijfscultuur, hoe ingewikkelder de applicatie, zou ik dan kunnen zeggen. Maar ja, het hangt er vanaf. Natuurlijk zijn er complexe applicaties. Natuurlijk zijn er applicaties die heel ingewikkeld in elkaar zitten, al dan niet de bedoeld of al dan niet nodig soms ook. Maar ja, op elk potje past een dekseltje, denk ik. Als het het doel dient, en er zijn programmeurs die die code aankunnen en ook willen beheren en ook willen programmeren, en er zullen ook genoeg applicaties zijn die niet makkelijk zijn. Maar ik zou niet durven zeggen dat het overal te complex is, eerlijk gezegd. Ik denk dat er zoveel tooling en dingen tegenwoordig ook bij zijn gekomen, dat een hele hoop programmeerwerk van tegenwoordig makkelijker is dan vroeger. Maar maakt dat niet nog complexer, want er komen nog veel meer stuk dan dat er voorheen kon. Ja, dat is waar. Dat is ook wel een ding. Ja, Redmoor? Ik denk het wel. In de zin dat er steeds meer, er is meer van alles. Ja, onder de noemer van toen ik begon, was het gewoon redelijk PAP en gewoon iets in een pagina gooien, een paar regels, en je kon refreshen en je zag het, zeg maar. En in die zin denk ik dat het complex is geworden als je net begint en dat je dan eigenlijk best wel guidance nodig hebt van mensen om je een beetje wegwijs te maken, wat je het beste kan leren en ook om focus te houden. Het is een beetje gegeven hoeveel desktop apps er zijn die in elektron zijn gebouwd. Op basis daarvan denk ik dat je bijna wel conclusie kunt trekken dat het gewoon te complex is. Ook de drang naar dingen als React Native op mobiel, ook al maar weer om gewoon weer twee hele complexe eigen ecosysteem te kunnen overbruggen. Voor mij is dat niet nog wel te complex. Gegeven dat je nog weer doorgaat naar infra, dat hele Kubernetes-verhaal, dat duizelt gewoon. Als je naar de Kubernetes landscape kijkt, er staan echt volgens mij 500 bedrijven, 500 projecten op. Ja, dat gaat volgens mij reis dat een beetje te pan uit. Dus volgens mij zou het niet erg zijn om als branche meer te streven naar minder. Hetzelfde als bij programmeertalen. Blijf maar bouwen, bouwen, bouwen, nieuwe dingen erbij bouwen. Ik denk dat het helemaal niet erg is om soms gewoon daarin juist te zeggen van hier stoppen we. En je maakt hetgene waar je mee bezig bent beter in de zin van bugs fixen, maar niet per se alleen maar features blijven doorbouwen. Oké. Dennis? Ja, ik denk zeker dat het antwoord ja is en wat jij zegt is zeker waar. We hebben gewoon te veel keuzes, te veel platformen, te veel talen, te veel opties. Zeker als je in de JavaScript-wereld kijkt, het vliegt te pan uit met alle frameworks. Maar wat ook belangrijk is, is dat 20 jaar, 25 jaar geleden bouwden we vooral desktop-applicaties, dingen die op een pc leven. Nu zijn het allemaal websites en op het moment dat je iets op het internet zet, krijg je aan een keer te maken met beveiliging, schaalbaarheid, weet je, allemaal van complexiteiten, wat gewoon zo enorm complex maakt. En infrastructuur, die zei jij ook al, Redmar, dat is ook wel een super belangrijke, komt allemaal bij kijken. Er zijn natuurlijk zat platformen waar je vrij snel een websiteje op kan zetten en dan wordt het ergens gehost. Maar op het moment dat het een beetje, hoe zeg je dat, massa krijgt of het publiek aantrekt, ja, dan moet je gaan nadenken over security en cross-site scripting en cores en dat soort zaken. Dat kan je nu te bevatten tegenwoordig en infrastructuur is een hele mooie. Tegenwoordig moet je ook dingen weten van Terraform en AWS en cloud en Google, wat allemaal weer net anders in een andere manier werkt. Het komt zoveel bij kijken. Ik denk dat het ook veel waarde geeft aan tools zoals Webflow of Shopify, om dat juist te gaan gebruiken. Omdat het alternatief is zoveel complexer en daarmee ook zoveel duurder om het te bouwen, want je hebt nog veel meer nodig. Oké, ja. Ja, ik zit een beetje te denken, is dat niet altijd zo geweest tot op zeker, kijk we hebben nu meer keuze, dat ben ik helemaal met je eens, maar het is, kijk vroeger kon je ook kiezen om het in Assembly te gaan schrijven, dat kan nu nog steeds overigens, er is bijna niemand meer, maar vroeger was dat nog meer mainstream, om even zo te zeggen, en waren daar ook al talen die daarop verder borduurden om bepaalde dingen uit handen te nemen en bepaalde dingen voor je over te nemen. Maar misschien is het wel zo dat de applicatie die we tegenwoordig bouwen, dus de eisen door dat het op het internet staat, dat we daar meer eisen aan hebben gesteld. Ja, maar er is ook om die eisen weer te vergemakkelijken zijn, is er natuurlijk gewoon een heel hoop toeling meegebaan. Ja, ik denk dat het dieper en breder is gegaan. Ja, precies, ja. Dus het is wel complexer geworden, maar niet per se makkelijker of moeilijker, maar dan is dat het. Maar je moet het wel eens zien te vinden. Dat is het, welke keuze maak je? Er zijn tegenwoordig hele studies binnen bedrijven, uit of uit gaan we nou voor React of U of Svelte, wat dan ook, terwijl het misschien helemaal niet zo'n belangrijke keuze is, maar dat is gewoon zoveel. En vroeger, als je op het Windows machine zat, dan bouwde je iets met MFC en C++, je had niet zoveel keuzes. En als je cross-platform wilde doen, dan pakte je Java, want dat was cross-platform. Ja, maar dan zat je wel weer ook vast gelijk daarin, dus je moest dan gelijk ook het curslijf in van die specifieke taal, terwijl je nu dan wel de keuze hebt. Maar dat is niet complexer, dat maakt het misschien simpeler. Ja. Alleen totdat je een bepaalde schaalgrote bereikt, dan wordt het in één keer weer een probleem, maar dan kun je niet meer. Dus ja. Ik denk ook niet dat er een echt een ja of nee antwoord is. Ik had wel een ja, dat had ik wel verwacht. Dat is een antwoord op alles. Dat is de stelling, hè. Soms een tweede keer. Oké, nou goed. Dan gaan we naar een vraag. Welke principes pas je toe in je toolstek om de situatie simpel te houden? Sluit een beetje aan op wat we hiervoor qua stelling hadden. Redmar? Wat wij doen is onder andere echt religieus bijna kiss toepassen. Kan het nog makkelijker? Kan je er nog meer van afhalen? Kan het nog makkelijker? Met name als je een soort greenfield dingen doet, maar dat geldt eigenlijk ook voor als je features toevoegt. Van ja, maak het nou zo klein en zo simpel mogelijk. Het is zelfs eigenlijk dat als je een nieuwe feature deploit, kan het ook met je feature flag en kan je hem zeg maar over tien minuten live hebben. Er zit niks in, maar we hebben wel een feature flag. Kan je dan daarna iets erbij bouwen wat achter die feature flag zit en door itereren op productie? Dat is inderdaad hoe wij het zo maar doen. Met name de houding van dat je het zo simpel mogelijk moet houden. Dat dat altijd de beste uithangspositie is. In die zin is het ook design upfront natuurlijk. Big design upfront en dan dat willen bouwen. Ja, het is gewoon itereren, klein houden en vooruit zeg maar. Dennis? Ja, wat moet ik hier nou op zeggen? Het is bijna mijn werk om dit soort dingen in kaart te brengen. Nou, dan heb je hopelijk. Ja, toolstack. Ik bedoel, er zijn zoveel methodieke principes die moeten helpen om het simpel te maken. Maar vaak heb je complexiteit nodig. Dat is het voor anderen. Je kunt dingen wel simpel willen houden. Maar je requirements, je non-functions, die eisen geven met die complexiteit, die heb je gewoon nodig. Dat kun je niet voorkomen. Maar ja, ik heb net een hele dikke sessie gedaan over clean code en over testbaarheid en over interne kwaliteit. Dat is allemaal onderdeel van dat proces om het simpeler te houden. Nou ja, ik kan al mijn principes gaan noemen die ik toepas. Ja, je mag er voor mij een paar noemen. Toen er eens drie. Solid, om maar iets te noemen. Test driven development, infrastructures, code. Die maken trouwens in die zin wel complexer. Maar nogmaals, je hebt het nodig, want je moet dingen uit kunnen rollen. En met de hand naar een cloud provider ga je je virtual machine uitrollen. Dat maakt het niet simpeler. Om het te automatiseren, dat maakt het natuurlijk simpeler, makkelijker, sneller, betrouwbarer. Maar het hangt er vanaf over hoe vaak ga je het doen. Ik ga het niet automatiseren als ik het maar één keer hoef te doen. En ik span ergens een VM met je. En daar draait een dingetje, een service shop, die vervolgens de komende vijf jaar er niet aangeraakt wordt. Dan raak ik er geen hele automatisering omheen bouwen. Dat is je non-functional. Ja, non-functional is dat je waarschijnlijk niks nieuws gaat uitrollen. Maar elk serieus systeem heeft natuurlijk... Je krijgt altijd nieuwe requirements, nieuwe inzichten. Dus er komt een punt dat het update, het uitrollen met de hand zo complex wordt en zo foutgevoelig dat je geen keuze hebt om te automatiseren. Maar ook dat is een proces. Je begint met een MVP en dat ontwikkelt zich door. Dat wordt succesvol, hopelijk. En dan moet je in één keer andere dingen gaan doen. Dat is inderdaad iets wat ik in ieder geval bij mijn werkgever wel vaak zie. Wat ik wel vaak zie is dat er heel vaak al van tevoren veel te complex wordt gedaan. Dus altijd kritische vragen blijven stellen. Dat is dan voor mij het antwoord op deze vragen. Dus gewoon kritisch blijven. Hey, oké, ja, je zegt nu dat je dit wil, maar is dat ook echt daadwerkelijk wat je wil? Of wat wil je bereiken? Heel vaak komt er bijvoorbeeld een opdrachtgever of iemand anders binnen het bedrijf komt dan met een oplossing naar je toe. Iemand van sales komt met een oplossing naar je toe als developer. En dan zeg je, ja, hallo, maar wat wil de klant nou precies? Kunnen we dat dan niet oplossen met iets wat we willen hebben? Dus gewoon continu die vraag blijven stellen. Ik denk dat dat voor mij de meest. Ik heb precies de situatie meegemaakt dat er twee applicaties moesten gesynchroniseerd worden. En mijn vraag was uiteindelijk van, er moeten gebruikers gesynchroniseerd worden. Maar hoe vaak moet het dan gebeuren? Want de ontwikkelaars zei gelijk, oh, we moeten een service bussen. We moeten dit en dat introduceren. Wat blijkt nou? Het hoeft maar één keer in de vijf tot tien minuten een beetje bijgewerkt worden. Was het helemaal niet nodig om al die complexiteit toe te voegen? Mas, mas, database replicatie. Misschien. Misschien, zelfs als er een optie is. Het kan, weet je. Het ligt aan de requirements uiteindelijk. Maar niet elk probleem is een technisch probleem. Het kan ook functioneel opgelost worden. En dat vergeten heel veel ontwikkelaars. Of met bestaande tooling die er al is. Ja, bijvoorbeeld. Jij wil natuurlijk alles tien keer zelf opnieuw uitvinden. Dat is toch veel leuker. Ik had ook nog een beetje gekeken wat de industrie hierover zegt. We hebben de vraag van tevoren gekregen. Dus een beetje uitzoeken daar maar. En hetgeen wat op dit moment heel erg leeft in de industrie... ...is de vier key factors. Vier key... En dat is eigenlijk die... Je hebt het bekende Accelerate-boek. En die hebben zes jaar onderzoek daarnaar gedaan. Een soort DevOps-researchteam. En die zeggen eigenlijk andersom. Dus die hebben zes jaar onderzoek gedaan naar succesvolle projecten. Nou ja, succesvol is waar je kunt zeggen. Die weten het nog simpel genoeg te houden... ...om nog te begrijpen wat aan het doen zijn. En daar hebben ze vier key factors gehad. Hoe snel kan je deployen? Hoe snel kan je recoveren van een fouten deploy? En nog twee. Maar in dezelfde richting. Nee, lead time totdat er een change in productie kan komen. Dat is drie. En nog eentje die er heel dicht naast schuurt. Maar die vier komt overal terug. En dat is wel interessant om te zien. Sowieso is dat boek wel interessant, Accelerate. Het is wel een beetje droog. In de zin van het is heel erg een opschomming. We hebben allemaal enquêtes gehouden en onderzoek gedaan. En dan lees je die droogstof in die zin. Conclusie is wel heel mooi. En in die zin een goed streven wil je het simpel houden. Daar hoort het automatiseren alweer bij. Want dat is het deel van hoe snel je iets in productie krijgt. Dat is ook het idee achter continuous deployment. Dat is een ideaal streven. Maar patten naartoe eist zoveel volwassenheid in je organisatie. En alleen dat al voor elkaar krijgen. Ieder stukje wat je daar voor elkaar krijgt helpt je als organisatie. Dat je het eindelijk continuous delivery kan doen. Perfect. Er moet zoveel gebeuren. Ik denk dat de relatie weer terug slaat over waar Johnny volgens mij net mee begon. Dat het inderdaad iets aangeeft hoe je organisatie in elkaar steekt. Dat dat weer terug slaat op of je dit aankomt. De link naar dat boek dat delen we straks. Ja, daar komen de show notes. De fysieke show notes. De fysieke show notes, ja. Oké, dan gaan we naar de volgende stelling. De enige manier om oplossingen te bouwen is middels de cloud. Dat is de man. Ja, tuurlijk. Ik heb een aandeel in AWS en Azure. Ja, ik weet het niet. Misschien zijn er mensen die geloven dat alles nog cloud based moet zijn. Ja, ik weet het niet. Ik heb er altijd wel moeite mee. Ja, dat hangt. Het depends. Het depends. Het depends. Uiteraard ja. In de zin van wat je onder de cloud voor staat. Maar als je gewoon VM's ook onder de cloud voor staat dan zou ik niet heel snel meer Zou ik niet heel snel meer weten wat je eigenlijk op metaal doet. Ook al gebruiken wij wel metalen bakken in onze infrastructuur. En daar hebben we dan dus ook goede reden voor. Ja, oké. Dat is de vraag, ja. Dus zodra je dat er onder verstaat dan zou ik echt niet meer weten waar je de service zou gaan slepen. Nou, dat is wel dat we die dus niet erbij rekenen. Voor mij brengt gewoon letterlijk de cloud in de zin wat het nu is en wat nu als gehyped is eigenlijk heel veel complexiteit met zich mee. Het zijn met name allemaal eigen interpretaties van de cloud providers. En zodra je ook voor een cloud kiest is het heel lastig om alle concepten en alles weer even heel makkelijk over te brengen naar iets anders. Dan vind je het wel zulke giganten dat je het ook niet snel zal wisselen, denk ik. Dus wisselen van Azure naar Google of naar Amazon, zeg maar. Dat is lastig. Tenzij je het heel, kijk IA's natuurlijk, of dat is gewoon alleen maar VM'tjes opspinnen. Ja, dat zal niet lastig zijn. Maar zodra je wat complexer of wat rijker. Ja precies. Het lijkt me dat als je weer gewoon alle Kubernetes dingen gebruikt. Dus als je aan die interface uit van Kubernetes. Dan hebben ze alle grote giganten hebben gewoon in die zin gewoon. Ja, de hoogste Kubernetes. Dus is het eigenlijk wel weer makkelijk over te zetten. Het is weer hoe diep je gaat, zeg maar. Dan gebruik je minder de functies van de cloud zelf. Ja, precies. Maar dat wordt wel weer complexer, zeg maar. Want dan ben jij bezig om als het ware Kubernetes weer te babysitten, zeg maar. En dan wordt het weer complexer, zeg maar, voor jezelf. Dus als je het makkelijker wil. En ja, weet ik veel. Als je een functie bijvoorbeeld wilt gebruiken of Lambda's in AWS. Ja, dat is makkelijker, zeg maar. Maar het is niet zo makkelijk om over te zetten naar een andere cloud, als ik dat zo begrijp. Ja. Ja, oké. Nou, ik geloof er wel in dat er echt wel heel veel onderdelen inmiddels al zijn die je echt niet zelf moet doen. Zoals bijvoorbeeld de mailserver hosten zelf. Waar je vroeger gewoon heel snel iets van de mailserver en de mailtjes uitstuurde. Dat doe je gewoon niet meer. En dat doe je echt alleen maar in de cloud. Maar een oplossing bouwen, want daar is eigenlijk natuurlijk waar het om gaat. Nee, ik zou het... Nee. Denk ik niet. Want ik zou het gewoon lekker zelf bouwen. Het maakt het ook heel veel makkelijker als je het gewoon lokaal gewoon nog steeds aan kan raken en kan runnen en kan hosten, zeg maar. Ja, oké, zo. Ja. Wat vind jij ervan, Dennis? Nou, ik kan er twee dingen over zeggen. In eerste instantie, ik zit bij een klant die in de industrie zit waarin het internetverkeer niet altijd beschikbaar is. Dus dan heb je het over olieplatformen. Dan is cloud helemaal geen optie. Het tweede is, ik zie cloud meer als een grote bak met tools en dingen die je kan gebruiken. En dan moet je keuzes maken. Ik heb de laatste weken toevallig aan de Pox gedraaid om gewoon containers te kunnen draaien. Even niet met Kubernetes, maar gewoon met AWS Fargate en Amazon. Dat is het container interface. Die werelden zijn al zo verschillend dat je niet eens kan praten over de cloud. Als je Amazon wil gaan draaien, dan moet je gigantisch veel stappen doordat het ding überhaupt bereikbaar is op het internet. Je moet elk subnetje, elk elementje moet je helemaal instellen. En dat probeer ik dan te automatiseren met Pullimi. Terwijl als je naar Azure gaat, dat is bijna één commando, dan staat het ding in de cloud en compleet beschikbaar. Geen beperking, niks. Die werelden zijn zo verschillend. Mijn grootste probleem zit, wat jij net ook zei, is op het moment dat je alles in de cloud kunt draaien, kun je dus niks meer testen lokaal. Ik vind het prettig dat ik iets lokaal kan starten. Dat ik lokaal mijn build skip kan draaien. Kan zien dat end-to-end testen draaien. Op het moment dat alles in de cloud draait, ben je zo vanafhankelijk. Dat is een dingetje. Maar uiteindelijk is het gewoon een box met tools. En als je jouw non-functionals of jouw specifiek situatie toelaat dat je het in de cloud kan draaien. Nou bij alweer eens, doe het. Ga je niet zelf je eigen hardware draaien. Maar als je dat niet hebt, dan is het toch geen oplossing. Dat is gewoon een oplossingsrichting weer. Ja. Sonny, wil je daar nog iets aan toevoegen? Nee, niet echt per se toevoegen. Ik denk inderdaad dat het gewoon een beetje gegroeid is. De laatste, wat zal het zijn, tien jaar of zo, dat het nu echt een beetje... Nou, niet zo lang denk ik. Nee, wel. Ik denk de laatste vijf jaar. Ja, de laatste vijf jaar met name. Ik kom juist met Kubernetes, denk ik. Ja, en kijk, gewoon een service als een Digital Ocean of zo. Ja, het is natuurlijk zo makkelijk om iets op te spinnen daar en dan gewoon te deployen en te gebruiken. Ja, dan heeft het z'n plek en dan heeft het z'n functie. Ja, dan is het misschien handig om het daar wel te draaien en dan ga je het niet zelf oosten. Ja, zoals we begonnen, it depends, denk ik. Ja, precies. Ja, absoluut. Overal is het it depends. Dat we de conclusie maken van elke stelling. Ja, dat wordt de titel van de aflevering. It depends. Misschien komt er nog iets wat is het beste programme je hebt gehaald of zo, dan klaar. Wat ben je zo bezig? Oké, over welke technologie zijn jullie op dit moment heel enthousiast? Johnny. Jeetje, ik heb me slecht voorbereid. Dat komt nu naar boven. Redman, je mag ook, dan mag je nog even nadenken. Ik heb helemaal geen slides gezien, ik wist helemaal niet wat we vragen hadden. Oh, dat was een beetje, ja. Mijn fout of jouw? Nee, nee, waarschijnlijk mijn fout, maar ja, knippen eruit. Oh gek, oh, kijk, ik ga me voorbereiden. Wat ik had staan was Wasm, WebAssembly. Dat is eigenlijk het verhaal dat alles naar de browser toe gaat en dat we dat ook nu zijn we daarmee aan het ontwikkelen. En dan is, ja, dat vult gewoon op dit moment een gat wat gewoon heel interessant is om te zien. Dat zijn toevallig projecten die ik dan heel erg van dichtbij volg. Dat is een soort code editor. Ik weet niet, Cloudline als editor. Dat is in ieder geval, AWS heeft dat ooit opgekocht. Dus ja, script editor in de browser. Een beetje hetzelfde verhaal dat je naar github kan gaan, op puntje kan drukken en dan krijg je hele VS code achter de omgeving. Zoiets is het. Alleen, dat heeft hij dus helemaal gebouwd met zijn team. Volgens mij maar twee of drie man ofzo. En ik kom er eigenlijk steeds achter dat die browser heel vaak een beetje de, ja, factor is die het allemaal beperkt, zeg maar. Je zit hele tijd vast aan die dom en het gaat zoals dat die browser doet, zeg maar. En WebAssembly in combinatie met WebGL geeft eigenlijk een nieuw soort van kamp vast. Een omgeving waar je vrijwel eigenlijk alles in kan doen. Je kan gewoon compilen. Als het eenmaal een soort van compile naar bottom, dan kan je erin runnen, zeg maar. En die heeft nu ook na volgens mij twee jaar, heeft hij iets, ja. Hij is even ver na twee jaar als hij vijf jaar in JavaScript was. En bij JavaScript liep hij eigenlijk gewoon vast. Want het kon gewoon niet meer verder. De browser piepte en kraakte en het kon gewoon niet meer. En nu heeft het in de rust zitten. En je ziet nu ook wel meer bedrijven die het oppakken. Natuurlijk ook zo'n tool als Figma ofzo, wat volledig gewoon. Een van de eerste was die daar soort van commercieel dan ook nog heel veel succes mee had. Dat is volgens mij trouwens in C++ geprogrammeerd. En toen, zeg maar, gecompiled. Maar goed, dat kan je op de achtergrond nu zelf weten wat je wilt. Dat als technologie. En een ander die ik had, volgens mij is hij ook één keer bij de podcast langsgekomen. Dat is OpenAI Codecs. Dus zeg maar die GPT-3 Artificial Intelligence die voor je programmeert. En nu was volgens mij op het moment dat jullie hem bespraken was hij nog redelijk, zeg maar gewoon kansloos. Maar die blijft maar bezig aan evalueren. En die maakt nu wel af en toe. Je hebt er wat demos van die je gewoon kan opzoeken. Van OpenAI. Die worden nu wel echt interessant. Om te zien wat de AI aan het programmeren is. En dan zou het maar straks gebruikt worden als sidekick. Net alsof je mag googlen. Dat je straks ook gewoon mag zeggen. Je mag ook gewoon zeggen wat je wilt hebben. En dan programmeert hij voor jou je eerste klatje, om het zo maar te zeggen. En als je dan een goede test hebt erbij waarbij je kan valideren dat dat ding heeft gemaakt voor jou. Dat het nog steeds doet wat het moet doen. Waarom niet zo? Ja, ik bedacht me net iets toevallig wat ik voor mijn eigen werk heb moeten doen afgelopen tijd. WebAuthentication. Dat is WebAuthentication, nieuwe standaard van W3C. Is al een aantal jaren in de maak. En dat is eigenlijk een standaard die ze aan het ontwikkelen zijn. Ter vervanging van wachtwoorden eigenlijk. Want wachtwoorden het zwakte bot zijn van het internet. Ja, iedereen heeft wachtwoorden. Tegenwoordig lossen we het op met een password manager. En zij zeggen eigenlijk, ja weet je, je kan er veel beter een soort... Ja, ze hebben het gestandardiseerd. Op basis, het is eigenlijk een voortborduring op U2F. Dat was een standaard voor cryptografische sleuteluitwisseling. Bijvoorbeeld in Ubiqui. Ik weet niet of mensen dat wel eens gezien hebben. Maar een USB stickje in je laptop. En dan is dat je second factor in dit geval. En nu hebben ze dat eigenlijk doorgeëvolueerd tot een standaard... die gewoon inmiddels door alle browsers ondersteund wordt. En eigenlijk is dat gewoon best wel een hele toffe nieuwe implementatie... om een wachtwoord te vervangen. Dus je voert je gebruikersnaam in. En dan bijvoorbeeld krijg je een pop-up in je browser... met leg je vinger op je MacBook fingerprint reader. En dan hop, is dat je wachtwoord. En dan is het eigenlijk gewoon direct een second factor en een wachtwoord ineen. En dan ben je gelijk ingelogd op de website. Het bestaat dus al een aantal jaar. Twee en een half jaar geleden heb ik een keer Proof of Concept al gemaakt... ook om het bij ons in de platform te gebruiken. Het was toen nog niet nodig. Maar nu hebben ze de U2F-standaard uitgefaceerd. In ieder geval bij Google sinds 1 februari. Dus moesten we wel over. En toen heb ik het weer gebouwd. En ja, elke keer blijf ik toch wel... Ja, dat is wel heel erg tof. Je hebt ook een website, webauthent.io. En dan kun je het gewoon echt even snel proberen. Je kan allerlei variabelen opgeven. Of er bijvoorbeeld ook echt user authentication achter moet zitten. Dus dat die ook jou als user moet identificeren. Dus je fingerprint is uniek. Dus dan kunnen ze daar aan de hand van ook weer allerlei dingen filteren. Nou, dat is wel een technologie waarvan ik denk... ja, dat krijgt hopelijk ooit wel een keer ergens een plekje. Dennis? Ik ben niet zo van de technologie. Ik vind technologie toch altijd wel een dingetje. Een means to an end. Ja, oké. Als ik dingen moet noemen die ik nu... Ik vind dotnet nog steeds fantastisch. Zeker in de huidige vorm. Ik vind typeskip fantastisch als taal. Dingen die ik wel interessant vind is Pulumi. Om je hele infrastructuur te automatiseren. Gewoon het feit dat je een enkele repository hebt. Waarin zowel je productiecode zit als de code die je hele infrastructuur uitrolt. En dat ook mee involueert. Dat vind ik wel gaaf voor dingen. Maar voor de rest ben ik niet zo... Oké. Nee. Dat is te veel. Nou, dan gaan we snel naar de voorne. We hebben nog even tijd om vragen straks te beantwoorden. Dan gaan we deze proberen kort te houden. We zijn over de piek heen van de hype cycle als het aankomt op nieuwe programmeertalen en platforms. Als het stil blijft dan is het gewoon niet zo. Oneent. Dat is het verhaal waar ik net al als ik over WebAssembly heb. Dat is pas vier jaar oud of zo. De meeste mensen hebben er volgens mij nog nooit van gehoord. Dus in die zin zijn we nog volop bezig. Ik had al eens een soort lijstje gemaakt hoe oud de programmeertalen zijn voor mezelf. Hoe oud zijn ze nou eigenlijk? Nou, C-Sharp... 20 jaar. Ja, 20 jaar. Maar eigenlijk... Ja, Ruby is ook al aan de leeftijd. Maar Rust is 7 jaar oud. De 1.0 versie. Swift is ook pas 6, 7 jaar oud. Ja, Elixir 2011. TypeScript. 8, 9 jaar. Dat is al zo oud, joh. Oh, wauw. En Kotlin, dat is ook eigenlijk best wel kort pas. Ja, oké. En pas 2019 als Preferred Language op het platform gekomen. Dus in die zin zijn we eigenlijk de grootste platform die we hebben. De mobiele platform, zeg maar. Die hebben eigenlijk hele jonge talen. Oké, ja. Ja, en dan heb je nog bij jullie Blazer. Blazer, geloof ik. Ja, maar dat is WebAssembly implementatie. Ja, in die zin is het ook allemaal een soort... Eigenlijk dikke hype, zeg maar. Overal wordt het zeg maar genoemd. Dus volgens mij zit het nog volop in de hype. Ja, oké, oké. Zijn jullie het ook mee eens? Nee. Ik voel dat niet zo. Maar goed. Nee, oké, dat kan. Maar goed. Ja, nou ja, ik... Voor mijn gevoel... Maar dat is gevoelsmatig. Dat is... Ook met front-end, zeg maar. Dat je daar een beetje over die hype heen bent. Want kijk, iedereen die niet front-end die veld zal zeggen... Ja, er zijn iedere week eens een nieuwe taal die zeg maar heel erg hip is. Dat is redelijk over. De Vue, Angular, React en misschien... Nee, op zich krijg je nu weer Swelte. Die soort van... Wat aan Swelte. Ja, die is ook altijd. Maar dat zijn een beetje de grote. Je hebt heel vaak gezegd, zoek degene op waar de meeste community... Het is wel zo dat ze nu boring technology geworden zijn. Weet je wat GitLab gebruikte? Ik weet niet of zij de starter daarvan of van die term waren. Maar in ieder geval zo oud dat het gewoon goed is geworden, zeg maar, inmiddels. Mainstream. Gewoon mainstream. Ja. Dus in front-end is op zich, denk ik, die hype... Er gebeuren zeker nog wat dingen. Swelte is relatief jong. Maar het is niet meer zo dat iedere... Toen is het voor mijn gevoel dat ik echt iedere half jaar weer een nieuwe taal, weer een nieuwe community. Dus dat ging echt heel hard. Ja, maar die libraries, dat zal nog steeds wel zo zijn, denk ik. Ja. Alleen ja, je ziet nu gewoon een aantal grote die steeds terugkomen. Ja. Nou, ik denk dat als je hebt dat teams zijn gewoon geïnvesteerd. Dus op een gegeven moment heb je geïnvesteerd. Ja, precies. Je gaat ook niet... Als je het view leuker vindt, maar het is allemaal al in React gebouwd, dan ga je ook niet opeens omschrijven, zeg maar. Jawel, want daarom doen we microservices, hè. Elke service kan zijn eigen platform gebruiken. Eigen taal, eigen database, eigen front-end. Ja, micro-front-end. Dan kunnen we lekker wisselen. Ja. Ja, en dat hele Kubernetes, denk ik, dat je daar ook al bent van dat daar zijn we nog niet klaar. Dat is gewoon niet het eind antwoord. Nee, dat klopt. Dat is waar. Want het gaat er eigenlijk nergens over. Ja. Qua complexiteit dan in ieder geval. Ja. Van het is goed dat je het doet, maar... Het is nog niet... Als je ziet wat je vroeger nodig had en wat je nu nodig hebt, als je gewoon een groot platform gewoon z'n gang laat gaan en Kubernetes in je bedrijf haalt, dan heb je opeens heel veel meer nodig, zeg maar. Dus ik denk dat we daar nog niet klaar zijn. Maar dat zal ook wel langzaam een boring technology, mainstream technology worden. Oké. Mainstream klinkt positiever dan boring. Nee, ik heb niks te vertellen. Ja, oké. Ik snap ook niet waarom ze die term voor marketing, do I know code? Goed. De laatste vraag. Wat zou je willen weten over taal of platform van degene die naast je zit? Ik doe niet mee. Je mag het ook aan hem en je mag het ook zoeken. Ja. Welke taal gebruik je ook weer? Ja, precies. Niks? Nee. Nee, ja. Ik heb er zelf voor gekozen om binnen dat vakgebied te blijven. Omdat er al zoveel informatie, zoveel dingen over te leren valt en zoveel mogelijkheden. Ja, ik word af en toe al eens via Twitter bestoken. Je moet AFsharp doen. Ja. Waarom dan? Alles simpeler. Sorry, maar ik zit lang genoeg in het vak, dat het allemaal niet zo makkelijk is. Nee, jij maakt een keuze. Ik heb dat niet zo met talen. Nooit gehad. Op een gegeven moment ben je geïnvesteerd, net als wat Redmar net zei over een bedrijf, dus op een bepaald moment geïnvesteerd in bepaalde keuzes van frameworks en dergelijke, maar ook van inderdaad totaal op een gegeven moment. Ja, het is veel breder dan dat. En je kunt het googlen, hè? Maar goed, geen voorstanders van oké, af en toe eens kijken bij de buren van oké, hoe zit dat met Java? Ik vroeg een beetje. Ja, dat is wel het gegeven wat ik mezelf in herken wat ik constant doe. Ja. Gegeven dat ik nu kinderen heb, is dat iets minder, iets rustiger geworden, dus iets meer focus. Maar ik vind het nog steeds heel interessant om te zien wat er in een andere ecosysteem, andere werelden en programmeerde frameworks gebeurt. Zeker omdat soms zijn werelden zo anders, zeg maar. Dat is ook überhaupt de reden, want ik sta daar op met rust én elixer. Ik kom eigenlijk uit de Ruby-hoek en die elixer kan, zeg maar, dat is eigenlijk lijkt heel erg op Ruby, maar hoe dieper je duikt, hoe meer je eigenlijk gaat zien dat het heel anders is dan Ruby. In de zin van dat lijkt een beetje qua syntax, terwijl het wel functioneel is, en zo blijft het doorgaan. En in die zin denk ik dat het wel kan helpen qua verbreding, alleen je moet er tijd voor zijn, want je kan het niet, want uiteindelijk verdient het niks. En wat Jay ook zegt van binnen bedrijven zijn ze gewoon geïnvesteerd. Alleen tegelijkertijd ben ik ook wel weer mee eens dat als jij niet aankomt met een andere oplossing, kijk je kan met diezelfde hammerdaten gaan lopen slaan, maar er zijn een paar gevallen geweest die praktisch gezien gewoon letterlijk in die andere talen niet mogelijk waren. Dus juist toen rond gaan kijken was het, letterlijk de oplossing was dat andere ecosysteem. En want het huidige ecosysteem kon het gewoon weg niet oplossen. Dus soms is het ook wel weer... Dus het is disruptivist eigenlijk. Het verandert de manier hoe je software gaat bouwen. Ja, en dat heb ik net nog niet genoemd, volgens mij, van technologie die interessant zijn. Maar bijvoorbeeld zoiets als Darklang, dat is ook zoiets van die... Ja, het is op dit moment een beetje een soort startup-achtig verhaal, maar wat hij eigenlijk zegt, en ik denk dat hij een goed verhaal heeft, is dat Kubernetes zo complex en de hele pipeline opzet, alles is zo complex. En hij biedt eigenlijk een framework of een platform aan, waarbij het gewoon klikkerdeklik en dan heb je gewoon je rest endpoint enzovoort. Je gaat weer kijken wat lichter, en hoe kunnen we dat weer in feite helemaal weghalen, gewoon wegslopen, en dat is wel disruptif. Als je naast iemand zit in een team zit, die dat voor elkaar weet te krijgen. Ik weet ook wel, er zijn ook toolingen die dat eigenlijk hetzelfde doen, maar dan met serverless, dus dan zit je niet zozeer op de taal dark, maar dan doe je het gewoon binnen Azure of AWS. Ik denk dat als er iemand naast je zit, terwijl jij laat een heel team eerst een Kubernetes cluster bouwen, want zo zijn we het gewend, kan je inderdaad volgens mij af en toe gewoon wel zwaar disruptif zijn. Eigenlijk is dat het voorbeeld van hoe Rails op het toneel kwam. Het was letterlijk dat er kwamen daar gewoon mensen in Rails-conferenties van grote bedrijven en die hadden eigenlijk een soort stealth. Niemand mag zeggen, je moet niet zeggen dat wij Rails doen, maar die waren gewoon aan het kijken van wat kunnen we daar halen, omdat Rails toch wel zo hard ging. Mag ik een wedervraag stellen? Op het moment dat jij of Johnny komt iemand tegen, een CTO, en die heeft geld, een investor, en die zegt, wij willen een of andere nieuw product bouwen. Ik heb geld en ik ga jou aannemen, want jij klinkt als een slimme gozer. Wat voor een platform ga je dan toepassen? It depends. Maar bas van? Want ik weet niks van, Ruby ken ik een beetje, maar Rust en Elixir weet ik niks van. Dus op het moment, bas waarvan kies je dan dat platform? Dat doe je toch denk ik vanuit je eigen ervaring. Ja, maar als je eigen ervaring dus beperkt is, met all respect, en het zal na 25 jaar best wel genoeg zijn, dan heeft iemand gewoon vertrouwen in jou dat jij het daarin goed doet. Maar iemand anders die zich verbreed heeft, die kan op dat moment die keuze maken om bijvoorbeeld juist wel net even die andere kant op te gaan. Maar je denkt dus dat door de keuze van een andere taal, zou je als organisatie efficiënter of sneller bepaalde functionaliteit kunnen bouwen? En mensen vinden om dat te kunnen... Het is letterlijk wat er gebeurt. Als je het zomaar hebt over startups, hackersnews, of even Y Combinator die investering doet, daar zie je ook gewoon letterlijk dat het gaat puur om stek. Ze beoordelen ook zelfs basis van stek. Een nog groter team, waar het team uit bestaat, maar ze kijken ook echt naar stek en hoe snel het gaat. Dus er zijn onderzoeken teruggevinden naar hoe groot zijn bedrijven, hoe snel kunnen ze bewegen. En als dat er echt toe doet, want dat is nog wel iets... Dus we zoeken een patroon eigenlijk. Is bepaalde stek een garantie dat we daardoor, of is de kans groter dat we daardoor sneller succesvol zijn, sneller een MVP in productie kunnen zetten? Precies, ja. En daar zijn letterlijk de cijfers van bij Y Combinator dat dat dan ook zo is. Dus die zijn zoveel jaar in de running nu, dat ze dat achteraf kunnen zien. Maar goed, dat is niet hetzelfde als... Dat is een momentopname, meneer McCana. Want al die platformen, als ik dan bijvoorbeeld even puur kijk naar mijn eigen wereldje Microsoft, die komt ook nu alle dingetjes om het makkelijker te maken, om sneller iets in productie te zetten. Maar ja. Oké, oké, kijk. Ik ga jullie afkappen. Oh, sorry. Ik wilde net even een debat starten. Ja, ik wil dat het eerder afkomt, want ik denk, het is nog best interessant. Vragen vanuit publiek misschien. Yes. Zullen we dat... Ja, een paar... Heeft iemand nog een leuke vraag voor deze heren? Zal ik hem gooien, de microfoon? Of gewoon hem even proberen? Ik sta al de hele dag hier een beetje te kijken. Ik ga hem gewoon proberen. Die ga je raken. Nou, die man daarachter. Komt hij hoor. Komt hij aan. Drie, twee, één. Zo! De lampen, die zijn wel stil. Collateral damage. Maar mijn vraag is, je bouwt iets voor een bedrijf. Het is wat de bedrijf wil. Zijn eigenlijk bedrijven beter slimmer geworden in de dingen die ze vragen? Of willen ze nog steeds heel snel die troep hebben die we even snel uit onze mouw kunnen schudden en dan later kijken of het mooi of beter kan? Of willen bedrijven nu echt kwaliteit, intern, extern? Ja, dat is een goede vraag. Dat ligt ook aan de fase van het bedrijf. Als het een start-up is, willen ze natuurlijk snel mogelijk iets in de markt zetten. Maar als een bedrijf een tijdje meedraait, gaan ze tegen alle groeipijnen aanlopen, alle problemen. Dan willen ze misschien weer kwaliteiten. Dan gaan ze weer op zoek naar bijvoorbeeld ons, om te kijken wat kunnen we doen. Het is maar net waar ze zitten. Als het een heel groot bedrijf is, hebben ze alle keuzes al gemaakt. Is dat beter in 2022 dan? Tien jaar geleden? Ja, dat is wel… Ik denk wel dat er gewoon meer kennis is, zeg maar. Omdat het alles gewoon al langer bestaat, is er meer algemene kennis, zeg maar. Dat denk ik wel. Er is meer te vinden over oplossingen. Er wordt heel veel gepubliceerd over wat is nou beter als ik een API GT nodig heb. Ga ik dat zelf bouwen? Kan ik een off-the-shelf-product kopen? Is het niet zo dat we nu, zeg maar, architectuur hebben, bijvoorbeeld microservices, microphone, whatever, dat we de keuze makkelijker kunnen maken dat we switchen van platform? Is dat niet iets wat anders is dan, weet ik veel, 10, 15 jaar geleden? Of is dat nog steeds gewoon… Je kiest voor een architectuur, is dat toevallig microservices? Dan is het… Ja, maar waarom kies je voor microservices? Waarschijnlijk omdat je ergens een presentatie hebt gezien en denkt dat het al je huidige problemen oplost. Nee, nee, nee. Dat zie je heel veel, hè? Maar is de bijvang, zeg maar, van microservices dat je mogelijk makkelijker zou kunnen switchen? Stel dat een bedrijf dat heeft gedaan, dan… Nou, je hebt een soort vervolg van dat Accelerate-boek, of in ieder geval zij refereren heel veel naar dat Accelerate-boek. Dat is Team Topologies. Decelerate of zo? Dat is Team Topologies. En die draaien het eigenlijk helemaal op z'n kop. En het is ook al wat jaartjes nu oud. En ik denk dat dat op zich een hele goeie is. Die zegt dus niet je begint niet met de Microsoft-architectuur, wat dan ook. microservices. Ja, microservices. Ik begin ook niet met Microsoft-architectuur. Maar je begint met de mensen. En dat is eigenlijk hetgeen wat ik net ook zei, aanrefereren met die VC's, zeg maar. Dus waar geld wordt besteed. Die hebben ook al lang door. Dat gaat om een team. Het gaat helemaal niet om een technologie. En dan ben je misschien ook weer terug met je vraag net eigenlijk, als je naar iemand toe gaat. Eigenlijk hebben ze nu pas door, ook weer heel veel onderzoek, zeg maar, research, dat je bij team moet beginnen. En het team bepaalt uiteindelijk weer de architectuur. Oké. Op basis van hun eigen ervaring natuurlijk. Ja, maar het is ook wel, dat onderzoek gaat wel echt over van duizenden projecten bekeken. En dan komt er eigenlijk op neer dat je dus ook een soort van toxic communicatestructuren hebt en toxic teams hebt, die gewoon niet succesvol zijn naar hun maatstaven. Dus ze geven ook echt op van, er zijn zo'n drie types manieren van communiceren. Vier types, tien types, zeg maar. En die kan je met elkaar combineren. En eigenlijk zodra je daar eentje invoegt die niet daaraan voldoet, zeg maar, dan loopt de boel spraak. Alleen, ja, dat vind ik eigenlijk ook wel interessant in het verhaal. Volgens mij hebben we dus nu meer door uit onderzoek, uit ervaring. Ja, ervaring. Hoe we het moeten aanpakken. En dat het dus eigenlijk veel meer vanuit het menselijk deel voortkomt. Ja. Want wij doen dat vooral als technologen, doen we graag direct uit architectuur of techniek denken. Ik denk dat dat een hele vooruitgang is. Het ligt ook heel dichtbij Conway's Law. Ja, ze noemen het letterlijk de Reverse Conway Law. Oh, de Reverse Conway Maneuver. Ja. Ja, dat is hem. Maar dan vraag ik me af of Wim nu een goed antwoord heeft gekregen. Ja. Ja. Ik heb altijd zo'n beeld van ja, bedrijven willen eigenlijk troep omdat ze zo snel mogelijk iets willen. Zoveel mogelijk willen. Oh zo. Ja, dat het voor ons moeilijk is om weerwoord te bieden. Maar ik heb ook wel het gevoel dat het nu beter lijkt. Oké. Oké. Vast houden zo. Nog een vraag misschien uit het publiek? Het publiek is heel stil vandaag. Ze durven gewoon niet. Ze kunnen gewoon beroemd worden. Ze zitten gewoon te wachten op het bier. Oké. Wim? Ah, kijk eens. Er komt nog een hand. Ik ga niet gooien. Voor dat de bieter naar beneden komt. Ja. Frank. Dan stelde net die vraag over hoe kom je nu tot de keuze voor een platform. Als iemand je vraagt voor een oplossing en ik kies een platform en de suggestie achter de vraag is een beetje wat ik ook wel in mijn hoofd had. Of ja, je kiest toch heel snel voor hetgeen waar je zelf kennis en ervaring van hebt. En het is natuurlijk heel mooi om te zeggen ja, ik weet wat van alles en ik kan de juiste keuze maken. Maar is het niet ook zo dat je dat een bepaald platform ook meer bepaald type ontwikkelaars aantrekt en dat dat vervolgens ook meer bepaalt of dat de platform succesvol is? Hmm. Goed punt. Inception. Dat vind ik wel, ja. Ja, ik denk zeker dat dat er mee te maken heeft. Nou, front en talen. Het is niet voor niks dat ze heel populair zijn, omdat heel makkelijk begin je ermee. Er zijn heel veel ontwikkelaars die denken, oh ja, ik begin gewoon met JavaScript, TypeScript in een browser en ik heb heel snel resultaat. Dus dat zijn heel toegankelijke talen. En je ziet ook dat die communities ook echt enorm groot zijn. Ik denk dat .net nu niet meer wint, zeg maar van de gemiddelde front-end library. Het is wel vroeger Java, .net, het is in Nederland een beetje 50-50, zeg maar. Ja, dat is nu gewoon niet meer zo. C-Sharp is gewoon een klein, ja niet de kleinere speler, nog steeds doet hij heel erg goed mee, maar het is een klein community. Dus ik denk dat het wel waar is dat je een bepaalde groep mensen aantrekt en dat creëert een bepaalde community trouwens, ook over toxiciteit. Toxie, ik krijg het niet aan m'n mond. Gift geëind. Dat het in bepaalde communities ook weer in kan sluipen, zeg maar. Dat de ene veel vrolijke yippie en de andere een beetje chagrijnig. Dat is ook naar de mensen die langs zijn gekomen in onze podcast. Je merkt echt wel verschillende communities. Dat doet net als we er heel chagrijnig van alle JavaScript ontwikkelaars. Ja. Omdat we elkaar op ons zijn. Ja, klopt. Ja, waar het mij aan doet denken nu ik er is, ik kom zelf uit de database wereld in het begin. Het is het begin van SQL Server, over 2000. Toen in die tijd had je met SQL Server versus Oracle heel erg sterk. En SQL dat was slecht en Oracle was goed. Vooral bij de grote organisaties. En wat mij daar altijd is opgevallen is dat het een heel groot verschil was. Is dat Oracle daar werkt alleen maar mensen van die echt verstand hadden van databases. En SQL Server, dat kon iedereen. Dat kon je ook met drie klikken installeren. En het grote verschil was dat die Oracle database waren allemaal super stabiel. Maar het kwam meer door het feit dat de mensen die daarmee werkten, die hadden er ook echt verstand van. Want je moest er ook verstand van hebben om ermee te werken. Met SQL Server wereld was dat veel minder. Ja, ik denk dat je daar wel een goed punt hebt. Zeker in de entry is nu veel lager. Je kan veel makkelijker, wat Sabo ook al zei, je kan veel makkelijker beginnen tegenwoordig met één random programmeertal. Ik zeg af en toe tegen mijn collega's en ook tegen Redmar, die ik met één regelmaat wel zie. Soms is het ook echt een soort van verloedering van ons vakgebied, vind ik. Heel grof gezegd. Maar dan zie je af en toe code voorbijkomen van mensen die zichzelf dan programmeur noemen of zo. Dan denk ik, ja, je hebt het niet begrepen. Je hebt duidelijk, zeg maar, niet... Ja, je hebt vanaf de basis... Zo aardig zeg je dat helemaal niet. Nee, dat klopt. Ik ben normaal wat grover. Je ziet dan echt duidelijk aan mensen dat ze vanaf een andere hoek binnen zijn komen wandelen. En dan toch een bepaalde basiskennis of basisidee of gedachteganger er achter de code, die zie je dan dat dat gewoon ontbreekt. Aan de ene kant is het een positief iets natuurlijk, dat er veel meer mee, dat iedereen mee kan doen. Ik denk ook, zeker in het begin, front-end developers kregen bijvoorbeeld minder betaald van back-end developers. Waarom was dat? Ja, oké. Nog een... Zo grappig. Hoe lang hebben we nog? We hebben min 5 minuten. Oké, dus we hebben alle tijd. Oneindig. Ja, ik zat even terug te denken 20 jaar geleden. Dat er gewoon een hele groep mensen waren, dat waren official basic ontwikkelaars. Die gingen toen C-sharp en tot net doen. Nee, dat was ik ook. En dat zag je gewoon. Je zag gewoon het hele secreciele programmeren. In plaats van objectorienteerd. Maar ik denk nu zelf, als ik nu naar mezelf kijk, dat er nu een generatie komt die op de universiteit al alle functiële talen heeft gezien, die eigenlijk naar mij toe kijken, van dan heb je nog zo'n oude zak die alles nog in objectorienteerd doet. En ik sta er misschien niet van open omdat ik zoiets heb van ja, wat brengt het mij? En dat zie je hetzelfde ook gewoon weer. Generatie-dingetje, weet je. Is er nog een vraag? De laatste vraag? Ja, dat was de laatste. We hebben toch min 5 minuten. Ik ga nu wel even kippen. Hopelijk dat ik de lampen niet raak. Jawel. Als je kijkt naar technologische ontwikkeling, dan lijkt alles sneller te worden, beter te worden, langer mee te gaan, et cetera. Als ik kijk naar software development over de laatste 20 jaar waar ik ervaring mee heb, zeg maar, heb ik het gevoel dat dat voor software development zelf helemaal niet het geval is dat we vandaag sneller software developpen dan 20 jaar geleden, ondanks alle platformen, tools, frameworks, et cetera, dat we het onszelf moeilijker lijken te maken dan makkelijker te maken. En dat we dus niet 10 keer zo snel een stuk software bouwen vandaag als 20 jaar geleden. Hoe denken jullie daarover? Ja, ik denk wel dat meest basale dingen sneller kunnen doen dan vroeger. Ik denk dat dat wel... Vroeger, als je een mooie website wilde maken, zat je echt avondenlang, zelf in HTML, alles uit de type. Tegenwoordig is het een beetje sleuren pleuren, of je gaat naar een of andere website en je installeert WordPress en het is klaar. Dat is makkelijker geworden. Anderzijds denk ik dat, waar we het eerder over hadden, die schaling van complexiteit, dat de projecten nu complexer zijn geworden, dat de tooling die we daarbij hebben ontwikkeld, wel helpt om de snelheid, de lijn van snelheid, om iets naar productie te krijgen, dat dat een soort van gelijk is gebleven, terwijl de complexiteit veel hoger is geworden. Dus misschien dat het een soort van elkaar heeft opgeheft... Zo, moeilijk spreken. Dat het elkaar opheft. Dus dat het wel qua positiviteit gedweld, maar omdat met de huidige systemen die veel meer eisen, waar we het begin over hadden, cloud, beveiliging en performance, dat daar heel veel dingen voordoor opgelost. Ik denk dat je nu meer tijd krijgt, op uit te vogelen, welke tool, service, dingetje je gaat gebruiken om je probleem op te lossen, dan het werkelijke probleem op te lossen. Er is gewoon zoveel. Ik denk dat applicaties wel complexer zijn geworden en daardoor was het gewoon meer tijd. Als je dan heel toespitsen, precies dat stukje voor Facebook waarom ze React hebben gemaakt, dat was letterlijk die reden. Omdat ze gewoon een team van 500 man hebben zitten op diezelfde website die jij in je zolderkamer in elkaar aan het prutsen was. Dat doen zij nu met 500 man. Alleen hoe krijg je het nog voor elkaar dat je met 500 man aan dezelfde website kan werken? Daar hadden ze last van. React was in ieder geval de eerste presentatie van React, was dat de reden. Zo van, dan kunnen we dingen bij elkaar containen en we kunnen het beter van elkaar snappen en begrijpen wat we aan het doen zijn. Dus in die zin ben ik het wel allemaal eens. Oké. Want wil dat je vraag? Zeker. Ja, goed genoeg. Oké. Nou, dankjewel. Ik, bij deze, want we moeten snel afsluiten. Dankjewel voor deze panelsessie. Het publiek ook bedankt. Of in ieder geval bedankt voor het hosten. En hopelijk dat we dit nog vaker gaan doen. Yes. Doei. Ja, leuk. APPLAUS",
"title": "CodeKlets panel discussie over de Staat van Programmeren",
"updatedAt": "2026-03-12T15:54:50.094Z"
}