/u/53007/DustPuppy.png?f=community)
Signatures zijn voor boomers.
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
/u/86654/crop68d4ff30987a8.png?f=community)
Je moet niet dronken dat ik denken ben.
What seems to be the officer, problem?
Waar is de brand, meester?
:strip_icc():strip_exif()/u/437778/crop684040f89be83_cropped.jpg?f=community)
Ik was voor 1 april weer eens bezig met een projectje: ircns, een brug tussen IRC en DNS, zodat je je IRC-berichten in de DNS kunt lezen (en kunt posten). Het heeft absoluut geen nadelen 
Helaas doet de video-embed op Tweakers het niet met een directe MP4
Helaas doet de video-embed op Tweakers het niet met een directe MP4
🠕 This side up
:strip_icc():strip_exif()/u/53213/crop56ee8579a466b.jpeg?f=community)
"Je kan met alle ziel en zaligheid ergens aan werken, maar soms is de uitkomst een zaal vol zieligheid." - Ariën
:strip_icc():strip_exif()/u/734655/crop69fb2d19b907a_cropped.jpg?f=community)
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- David Blankenhorn
/u/1219196/crop6324b2e35d04c_cropped.png?f=community)
"Je kan met alle ziel en zaligheid ergens aan werken, maar soms is de uitkomst een zaal vol zieligheid." - Ariën
:strip_exif()/u/52746/eric-cartman_small.gif?f=community)
Als het een junior lukt om jou er uit te werken, loop je inderdaad een risico om werkloos thuis te zitten. Het is jou dan namelijk niet gelukt om de meerwaarde van jouw domeinkennis te laten gelden.
Ik werk al bijna 20 jaar aan ERP systemen. Een junior kan met nog zoveel leuke trucjes aankomen, maar als hij niet begrijpt wat de klant bedoelt dan houdt het heel gauw op. Maar goed, uiteindelijk is dus mijn kennis van de producten van mijn werkgever belangrijker dan mijn programmeerkennis an sich.
Een gast van 20 kan supergetalenteerd zijn en mij er misschien wel uitprogrammeren inmiddels. Maar als hij iets moet aanpassen aan een superkritische kortingsroutine die overal wordt toegepast en waar elk klein foutje betekent dat er honderden klanten aan de telefoon hangen, wens ik hem veel succes lol.
Dus de kennis van hoe de kortingsroutine werkt en wat onze klanten ermee proberen te bereiken, is veel belangrijker dan hoe hij geprogrammeerd is. En dat is in mijn werk eigenlijk met alles.
Dat is natuurlijk ook het trieste van de AI revolutie. Omdat het de business eigenlijk niet kan schelen hoe het geïmplementeerd is - als het maar werkt - maakt het relatief weinig uit hoe netjes jij programmeert en hoeveel programmeerkennis jij hebt opgedaan.
Mijn werkervaring als programmeur helpt mij wel om AI te beteugelen, en het helpt mij ook om de juiste vragen te stellen aan AI, omdat ik weet waar ik naar zoek en wat ik wil. Dat zal voor een junior ook een stuk lastiger zijn, waardoor zijn resultaat meer op vibe coding zal lijken, terwijl ik AI werk laat doen dat ik anders zelf had gedaan (cyclus van vragen met beperkte scope en resultaat checken, next).
Ik ben inmiddels 45 jaar oud en programmeer al sinds mijn 10e trouwens
Sinds mijn 15e semi professioneel (toen deed ik al projecten voor het bedrijf van mijn vader, mijn eerste project leverde 8000 gulden op toen ik 15 was... ik heb toen een DOS programma van mijn vader herschreven naar een Windows tool in de zomervakantie).Maar goed, ik deed van alles... toen ik 13 was, werkte ik ook al mee als CAD tekenaar in AutoCAD en MicroStation
En had ik meer wiskundekennis dan collega's die op dat moment in de 20 waren.Toch voel ik mij soms een enorme loser, omdat ik uiteindelijk niet hele bijzondere dingen heb bereikt. Ik ben uiteindelijk maar een standaard developer geworden eigenlijk. Deels toch mijn autisme / mensenschuwheid die mij parten speelt.
Ook druk ik mij vaak voorzichtig uit in discussies, waardoor iemand die meer zelfverzekerd overkomt, een positief halo effect weet te bereiken (mensen zullen dan ook meer vertrouwen in zijn kennis en andere eigenschappen hebben), terwijl ik overal over nadenk en alles dubbelcheck en dan kom ik wellicht onzeker over en dan denken mensen juist dat ik iets niet goed weet.
Jezelf goed presenteren is en blijft een lastig iets.
Mijn vader was hier een stuk beter in en had dus niet voor niets een eigen bedrijf etc.
[ Voor 11% gewijzigd door Lethalis op 10-06-2026 16:50 ]
Ask yourself if you are happy and then you cease to be.
Ik moet zeggen dat ik ook totaal niet 'weggeconcurreerd wordt' door juniors / mediors met een AI hulpje. Nou zit ik ook wel in complexe systemen domeinen waar AI vaak maar heel matig resultaat levert tenzij je het heel gericht inzet.
Sowieso valt het me vaak genoeg tegen hoe beroerd agents / AI in het algemeen zijn in wat op zich vrij heldere taakjes zouden moeten zijn zoals bijvoorbeeld een major versie upgrade van een bepaalde dependency.
Vaak genoeg vraag ik iets dat redelijk afgebakend is en dan produceert AI een oplossing die wel werkt, maar 100 regels code is ofzo. Handig als basis, want dan zie je hoe je iets kunt doen en herschrijf je het vervolgens zelf in 3 regels.
En ik probeer echt wel met agents.md files, skills en ga zo maar door te werken, maar het valt me elke keer na wat initieel optimisme uiteindelijk toch weer tegen.
Sowieso valt het me vaak genoeg tegen hoe beroerd agents / AI in het algemeen zijn in wat op zich vrij heldere taakjes zouden moeten zijn zoals bijvoorbeeld een major versie upgrade van een bepaalde dependency.
Vaak genoeg vraag ik iets dat redelijk afgebakend is en dan produceert AI een oplossing die wel werkt, maar 100 regels code is ofzo. Handig als basis, want dan zie je hoe je iets kunt doen en herschrijf je het vervolgens zelf in 3 regels.
En ik probeer echt wel met agents.md files, skills en ga zo maar door te werken, maar het valt me elke keer na wat initieel optimisme uiteindelijk toch weer tegen.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
/u/373849/cowava2.png?f=community)
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
:strip_icc():strip_exif()/u/148671/skyaero_small_tweakers.jpg?f=community)
/u/56000/neuken.png?f=community)
"te duur" zal erg afhangen van hoe nuttig het is voor jouw toepassing.
Oud collega van mij verkoopt zich als "AI engineer" en zelfs hij geeft aan dat het vooral nuttig is wanneer je wil prototypen of vooral snel nieuwe projecten wil opzetten. Kijk ik naar mijn werk - waarin ik 90% van mijn tijd spendeer aan het onderhouden en verfijnen van bestaande code - dan haal ik er relatief gezien veel minder uit.
De tijd zit hem namelijk niet in het programmeren zelf, maar in het uitzoeken / reproduceren van het probleem, en het bedenken van een oplossing.
Tuurlijk soms helpt AI mij hier ook bij. Zo hadden we laatst een null reference exception ergens in een routine, en toen heb ik de code simpelweg aan Gemini gegeven en gevraagd wat het kon veroorzaken, en die kwam netjes terug met de regel waarop het probleem zich voordeed. Daar bespaar je wel veel tijd mee, want daar kon ik dan zelf rustig mee verder. Vroeger had ik eerst een paar uurtjes de betreffende regel moeten zoeken
Maar er zijn ook genoeg dingen waar AI helemaal niks mee kan, omdat ze zich simpelweg niet in code afspelen, maar puur in het business domein. Als je met collega's (en klanten) aan het bespreken bent hoe een programma in de toekomst anders moet gaan werken bijvoorbeeld. Tsja, dat is tijd die je sowieso kwijt bent.
Hoe groter de impact van AI op jouw workflow, hoe duurder het mag zijn. En andersom natuurlijk
Haal je er relatief weinig uit, tsja... dan mag het eigenlijk ook niks kosten.
Ask yourself if you are happy and then you cease to be.
:strip_exif()/u/1807884/crop6a3ac5fbf39e1_cropped.webp?f=community)
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Omdat ik toch niets te doen had...:
Gisteren verkozen tot lid van de bestuurscommissie van Python New Zealand
Dat wordt een hoop extra werk...
Nu ook maar Director of PyCon 2027...
Ik moet misschiens eens leren eerst de gevolgen in te schatten voor ik een nominatie accepteer...
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
:strip_icc():strip_exif()/u/284419/Mexican%2520Wolf%2520Klein.jpg?f=community)
Ik heb hier nog een nominatie voor je: director of dingendoen. Accepteer je?:
[...]
Omdat ik toch niets te doen had...
Nu ook maar Director of PyCon 2027...
Ik moet misschiens eens leren eerst de gevolgen in te schatten voor ik een nominatie accepteer...
Wel een vette rol, lijkt me ook altijd leuk om extra dingen op te pakken maar de paar keer dat ik gevraagd ben heb ik vriendelijk bedankt want kinderen en werk en gezondheid en het leven enzo
Sure, klinkt vaag genoeg om te werken:
[...]
Ik heb hier nog een nominatie voor je: director of dingendoen. Accepteer je?
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
:strip_icc():strip_exif()/u/123739/crop5f9ddcde3b3f4_cropped.jpeg?f=community)
Inventory | Instagram: @sequenzpounder | http://www.zdaemon.org | ZDaemon! Client/Server port for DOOM!
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- David Blankenhorn
:strip_icc():strip_exif()/u/206968/325134.jpg?f=community)
Bij mij gebeurt dat als ik mijn MX Master S3 via Bluetooth of de Logitech Unifying receiver aansluit. Dan zijn alle scrollwieltjes ook omgedraaid
If money talks then I'm a mime
If time is money then I'm out of time
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- David Blankenhorn
:strip_icc():strip_exif()/u/79949/crop5f5993df06c68_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/492949/crop627d0c893ea0e_cropped.jpg?f=community)
https://github.com/openai/codex/issues/28224
ik kan me niet herinneren dat ik ooit in het wild een applicatie heb gezien die op een modern OS in userspace draait welke daadwerkelijk hardware kan slopen
ik kan me niet herinneren dat ik ooit in het wild een applicatie heb gezien die op een modern OS in userspace draait welke daadwerkelijk hardware kan slopen
Waar een wil is... 
Een klein ervaringsbericht: ik heb meerdere pipelines die data verwerken. Dit bestaat vaak uit meerdere stappen, deels Python, maar ook veel (meestal in Rust geschreven) binaries die het zware werk doen. In het begin heb ik daarvoor vooral batch files gebruikt, maar dat is best wel foutgevoelig en je kunt niet heel makkelijk checks inbouwen of een stap goed is gegaan voordat je de volgende aftrapt.
Een tijd geleden ben ik daarom Dagster gaan gebruiken, maar dat sluit niet helemaal aan bij mijn behoeftes. Aan de ene kant biedt het meer dan ik nodig heb (web UI, database van alle runs), aan de andere kant is het vooral gemaakt voor scheduled jobs of op basis van bepaalde triggers, niet zozeer voor mijn toepassing - een enkele keer een lange job op een dataset draaien. Er is geen heel makkelijke manier om een configuratie voor een run in te stellen en via de web UI krijg je de console output niet te zien. Wel handig vond ik hoe makkelijk je afhankelijkheden vast kunt leggen en checks kunt inbouwen die evt. de verdere processing onderbreken.
Ik ben daarom op zoek gegaan naar een andere tool/framework die met minder ballast iets dichter bij mijn behoeftes komt. Claude heeft eerst een heel basic Python script voor me geschreven waarin je een pipeline bestaand uit meerdere stappen en checks voor elke stap kunt definiëren. Daarin heb ik een simpele pipeline (twee stappen, eentje uitvoeren van een Rust programma, eentje verwerken van de uitvoer in Python) gebouwd en deze als basis gebruikt voor het testen van vier andere opties:
Een klein ervaringsbericht: ik heb meerdere pipelines die data verwerken. Dit bestaat vaak uit meerdere stappen, deels Python, maar ook veel (meestal in Rust geschreven) binaries die het zware werk doen. In het begin heb ik daarvoor vooral batch files gebruikt, maar dat is best wel foutgevoelig en je kunt niet heel makkelijk checks inbouwen of een stap goed is gegaan voordat je de volgende aftrapt.
Een tijd geleden ben ik daarom Dagster gaan gebruiken, maar dat sluit niet helemaal aan bij mijn behoeftes. Aan de ene kant biedt het meer dan ik nodig heb (web UI, database van alle runs), aan de andere kant is het vooral gemaakt voor scheduled jobs of op basis van bepaalde triggers, niet zozeer voor mijn toepassing - een enkele keer een lange job op een dataset draaien. Er is geen heel makkelijke manier om een configuratie voor een run in te stellen en via de web UI krijg je de console output niet te zien. Wel handig vond ik hoe makkelijk je afhankelijkheden vast kunt leggen en checks kunt inbouwen die evt. de verdere processing onderbreken.
Ik ben daarom op zoek gegaan naar een andere tool/framework die met minder ballast iets dichter bij mijn behoeftes komt. Claude heeft eerst een heel basic Python script voor me geschreven waarin je een pipeline bestaand uit meerdere stappen en checks voor elke stap kunt definiëren. Daarin heb ik een simpele pipeline (twee stappen, eentje uitvoeren van een Rust programma, eentje verwerken van de uitvoer in Python) gebouwd en deze als basis gebruikt voor het testen van vier andere opties:
- Marimo: dit is een Python notebook framework (vergelijkbaar met Jupyter) die anders dan Jupyter afhankelijkheden tussen cellen kent en bij wijzigingen alles (waar nodig) opnieuw berekend. Dat is dan weer niet ideaal als je lang lopende processen hebt, waarvoor je dan weer startknoppen toe kunt voegen. Het werkte soort van, maar je zit uiteindelijk wel weer in een webinterface te werken die sommige dingen niet zichtbaar maakt en toch net iets minder functionaliteit heeft dan een echte IDE.
- Hamilton: dit is een dataflow framework dat eigenlijk alleen met functies werkt, met de parameters als afhankelijkheden. Ook dit werkte soort van, maar het leent zich eigenlijk minder voor een pipeline die vooral met bestanden werkt en daarvoor externe programma's oproept.
- Snakemake: ook in Python geschreven, je definieert op make-manier (maar in Python) een recept voor het verwerken van bestanden. Zoals bij make kijkt 'ie daarbij naar de wijzigingstimestamp van bestanden om te bepalen welke stappen van de pipeline mogelijk gedraaid moeten worden. Dit komt vrij dicht bij mijn gewenste functionaliteit, maar leunt sterk op bash en draait daarop niet onder Windows - niet handig voor mij, want support van Windows, Linux en macOS is voor mij een must.
- doit: dit lijkt qua filosofie op Snakemake, maar zonder de bash afhankelijkheid. Standaard checkt het wijzigingen op basis van een md5 hash (niet timestamp) waardoor het geschikt is voor git, maar je kunt hem ook op basis van timestamp laten checken zodat geen hashing van grote bestanden vereist is. Ook hier kun je afhankelijkheden en checks voor elke stap toevoegen.
Ik heb vandaag ook meerdere gespeeld met allerlei AI's en het blijft toch teleurstellend. Het toevoegen van een website titel nadat ik npx sv create app gedaan heb (een minimale template) kost 1 minuut en 13 secondes omdat hij allerlei dingen ging dubbelchecken die niet nodig waren, de "eerste gedachte" die het had was ook de juiste maar blijkbaar vertrouwde het niks. Een opdracht om de bestanden structuur aan te maken deed een poging om ook een directory in mijn home directory te maken. Een simpele calculator moest de knoppen in javascript defineren waardoor het moest loopen en het fout ging maken. En toen ik vroeg of het op de homepage te plaatsen had hij meerdere minuten nodig omdat het vergat te importeren.:
https://github.com/openai/codex/issues/28224
Ik had ook nog wat credits voor een online platform (Jetbrains), maar daar was ik binnen vijf minuten door heen. Waarom? Omdat het voor de "zekerheid" elke bestand handmatig ging inspecteren (dit was een ander project die veel groter was). De richting die het op ging was wel redelijk.
En wat mij het meest dwars zit? Het heeft wel een paar bugs en typos gevonden. Maar een statische analyse tool had die ook gevonden in waarschijnlijk een honderste van de tijd. Which reminds me... Ik moet toch echt tijd maken om een serieuze OTAP straat in te richten.
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- David Blankenhorn
/u/3813/100_8985_ICON2.JPG?f=community)
:strip_exif()/f/image/odyp9Y98OIEO1xYyhz1ElKVw.png?f=user_large)
AI sucks
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Oh die kan ik verklaren. De quote komt in dit artikel voor: https://www.the-american-interest.com/2016/02/17/the-seven-habits-of-highly-depolarizing-people/. Het is ook letterlijk waar ik de quote vandaan heb gehaald. (Tip: Het is een geweldig artikel voor als je handvaten zoekt voor gepolariseerde discussies).
Daar in staat duidelijk dat het van Václav Havel komt. Maar de auteur van het artikel is... Drum roll please... David Blankenhorn.
Zie opmerking van Kalentum in "De Devschuur Coffee Corner - Iteratie ⑬"
[ Voor 5% gewijzigd door DevWouter op 30-06-2026 11:26 ]
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- David Blankenhorn
:strip_icc():strip_exif()/u/116726/crop5e3ee297a8a03_cropped.jpeg?f=community)
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- David Blankenhorn
Actually...
Anyho ... het artikel ga ik lezen. Ik hoop dat ik op een mooie dag ga leren hoe om te gaan met polariserende discussiepartners.
Anyho ... het artikel ga ik lezen. Ik hoop dat ik op een mooie dag ga leren hoe om te gaan met polariserende discussiepartners.
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Het hele artikel is bullshit, er staat letterlijk geen waar woord in, en iedereen die erin gelooft moet dood.:
Anyho ... het artikel ga ik lezen. Ik hoop dat ik op een mooie dag ga leren hoe om te gaan met polariserende discussiepartners.
Dus.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
/u/224026/crop5a1c1a6fcf1b1.png?f=community)
* DevWouter leest heel snel nog een keer het artikel... Yep, yep... Duidelijk...:
[...]
Het hele artikel is bullshit, er staat letterlijk geen waar woord in, en iedereen die erin gelooft moet dood.
Dus.
Ik betwijfel of je er echt zo over denkt, maar misschien dat ik verkeerd zit. Ik laat me dan graag overtuigen. Kan je aangeven waar je moeite mee hebt en beschrijven wat in jouw beleving beter werkt?
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- David Blankenhorn
Polarisatie is best handig met deze zon, ik ben best blij met m'n zonnebril:
Actually...
Anyho ... het artikel ga ik lezen. Ik hoop dat ik op een mooie dag ga leren hoe om te gaan met polariserende discussiepartners.
🠕 This side up
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Heb je 't niet meegekregen? ICT staat tegenwoordig voor Informatie- en Claudetechnologie, niet meer voor Informatie- en Communicatietechnologie
Vroeger was het Informatie- en Cloudtechnologie
🠕 This side up
Ik heb eigenlijk nog steeds veel moeite dat ICT hernoemd is naar IT. Sure, de C ging meer over de technische kant (kabels aanleggen, telefoons, etc), maar ik ben ook overtuigd dat daardoor ITers niet meer in staat zijn om te communiceren.:
[...]
Heb je 't niet meegekregen? ICT staat tegenwoordig voor Informatie- en Claudetechnologie, niet meer voor Informatie- en Communicatietechnologie
Vroeger was het Informatie- en Cloudtechnologie
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- David Blankenhorn
/u/81985/crop566b00b43645a.png?f=community)
Je HUD is waarschijnlijk een LCD-scherm?
Kwestie van meer polarisatiefilters toevoegen.
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
/u/243953/crop56f55a7bcf291.png?f=community)
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Ja, maar ik vind het dus nogal lomp dat ze daar niet al rekening mee houden. Polariserende glazen tijdens het rijden is niet echt bijzonder oid:
[...]
Je HUD is waarschijnlijk een LCD-scherm?
[...]
Kwestie van meer polarisatiefilters toevoegen.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Sowieso vind ik de kwaliteit van de schermen in auto's vaak teleurstellend. Mijn Opel Corsa uit 2020 heeft een LCD die gevoelsmatig eerder uit 2010 komt.:
[...]
Ja, maar ik vind het dus nogal lomp dat ze daar niet al rekening mee houden. Polariserende glazen tijdens het rijden is niet echt bijzonder oid
🠕 This side up
Maar wat stel je dan voor?:
[...]
Ja, maar ik vind het dus nogal lomp dat ze daar niet al rekening mee houden. Polariserende glazen tijdens het rijden is niet echt bijzonder oid
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Ik heb een Kia EV6 uit 2026. De dashboardschermen zijn allemaal OLED volgens mij. De HUD weet ik niet, hij is best scherp en ik zie geen lichtgevend vlak waar geen pixels zijn, dus misschien ook OLED?
Een verticaal polarisatiefilter ipv diagonaal? Een waveplate eroverheen?:
[...]
Maar wat stel je dan voor?
Ik ga kijken of ik het hiermee kan oplossen: https://www.edmundoptics.com/p/100-x-100mm-lambda2-retarder-film/30513/
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- David Blankenhorn
OLED is al een stuk beter... helaas hier nog gewoon een LCD (en een stuk kleiner dan de EV6).
Verder kan ik niet klagen, hij doet 't goed zonder in de weg te zitten, maar een beter (en dus niet alleen groter, Stellantis) scherm had ik geen nee tegen gezegd. De nieuwe variant heeft ook ChatGPT-integratie
🠕 This side up
Toch best lastig, als je niet even diep zucht en nadenkt na zo'n opmerking.:
[...]
Het hele artikel is bullshit, er staat letterlijk geen waar woord in, en iedereen die erin gelooft moet dood.
Dus.
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
/u/363743/crop61aa1329d36b8_cropped.png?f=community)
/u/36698/avatar.png?f=community){kind=avatar}
Ik denk dat het helpt als je het probleem terugbrengt naar een organisatorisch probleem. Simpel gezegd: Je hebt een persoon in jouw team die ondanks meerdere verzoeken afwijkend gedrag vertoont en niet bereid is om zich aan te passen. Daardoor veroorzaakt die overlast waar die persoon geen verantwoordelijkheid voor neemt. Immers zou die dat wel doen dan had hij eerst campagne gevoerd voor zijn werkwijze voordat(!) en gezorgd dat er binnen de organisatie men bereid is om te veranderen voordat hij ging afwijken.
De hele discussie over PRs kan je achterwegen laten, dat is in dit soort discussies alleen maar een voorbeeld. Het probleem is dat de persoon geen teamspeler is ondanks het verzoek van het team dat wel te doen. De vervolgvraag over hoe je dat gaat oplossen zou ik overlaten aan de teammanager (icm HR).
Het feit dat je kijkt naar de PR is trouwens omdat ontwikkelaars vooral kijken naar de technische problemen/oplossingen, maar zoals gezegd is dit puur organisatorisch.
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- David Blankenhorn
:strip_icc():strip_exif()/u/269054/crop6064049cee9ab_cropped.jpg?f=community)
/u/105842/Homer_60x60.png?f=community)
/u/102105/crop56f481fe1f74f.png?f=community)
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- David Blankenhorn
Ligt er natuurlijk aan welke tool je gebruikt, maar in GitLab kun je expliciet aangeven of je review changes behoeft, en kun je óók gewoon een comment achterlaten. Daarnaast kun je afdwingen dat alle threads gesloten moeten zijn voordat een PR verder kan, maar dat staat daar los van.:
[...]
Ik vind het wel fijn om beide opties te hebben, maar het maakt vragen als dit meteen onduidelijk zonder expliciete bevestiging van welke manier van werken gebruikt wordt.
Ja vooral dat. Helaas zit ik best wel vaak bij klanten waar men heel erg van 'cover your ass' is. Risico en onvoorspelbaarheid zijn dan vieze woorden, maar in plaats van dat het gaat om realistisch kijken naar hoe het risico echt ingedamd kan worden is het vooral zaak om alles dicht te timmeren met procedures zodat de accountant kan auditen dat de procedures zijn gevolgd en een vinkje gezet kan worden. Vervolgens kan het management dan bij problemen verwijzen naar het vinkje van de accountant en hun lucratieve baantjes behouden.
Dat betekent onder andere dat zaken als hoe je omgaat met PRs geen kwestie zijn van afspraken binnen een team die worden bedacht op basis van nut en noodzaak, maar van centraal afgedwongen policies. Dat betreft dan niet enkel zaken als verplichte reviewvinkjes, maar ook koppeling met JIRA, want stel je voor dat je een spelfout corrigeert in docs zonder een JIRA ticket. Bovendien is dat ook niet simpelweg een kwestie van een oneliner ticket maken en klaar, maar een heel adminstratief proces waarbij 324 veldjes moeten worden gevuld (waarvan het gros gewoon voorgevuld had kunnen zijn, maar waarom makkelijk maken als het ook bureaucratisch kan). Want ja, stel je voor dat die 3 seconden werk die je eigenlijk had aan het daadwerkelijke werk ongeadministreerd blijven. Het administratieve kwartiertje dat je hebt gespendeerd staat nu in ieder geval aan de juiste kostenposten toegewezen!
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Als het slechts een spelfout is, is het niet heel belangrijk om direct op te lossen en kun je het bundelen onder meerdere subtaken en een keer een opschoon ticket maken voor dit soort taakjes. Ik denk dat dit erg bezien is als uitvoerder en dat je daarbij het overzicht vanuit de organisatie breed een beetje kleiner maakt dan het zou moeten zijn. Zelfs een kleine wijziging in documentatie kan soms grote gevolgen hebben over de interpretatie en daarmee over hoe iets geimplementeerd wordt. dan wil je dit juist wel heel duidelijk gelogd hebben wie wanneer en waarom zodat je weer kan zorgen dat alles rechtgetrokken wordt. En qua kosten is dat ene beetje werk van 3 seconden (bij wijze van, want 3 seconden is wel heel weinig tijd) misschien niet veel, maar hoe groter het team, hoe vaker die 3 seconden en hoe duurder het personeel, dan gaat het behoorlijk oplopen. En bedenk dan ook dat als er inderdaad een verschil in interpretatie ontstaat daarna, de gevolgen qua kostenpost nog veel groter kunnen uitvallen. Dus hoewel je in het begin m.i. het juiste zegt, lijk je dat naar mijn idee aan het einde juist weer wat tegen te spreken door zelf die risico's niet te zien:
[...]
Ja vooral dat. Helaas zit ik best wel vaak bij klanten waar men heel erg van 'cover your ass' is. Risico en onvoorspelbaarheid zijn dan vieze woorden, maar in plaats van dat het gaat om realistisch kijken naar hoe het risico echt ingedamd kan worden is het vooral zaak om alles dicht te timmeren met procedures zodat de accountant kan auditen dat de procedures zijn gevolgd en een vinkje gezet kan worden. Vervolgens kan het management dan bij problemen verwijzen naar het vinkje van de accountant en hun lucratieve baantjes behouden.
Dat betekent onder andere dat zaken als hoe je omgaat met PRs geen kwestie zijn van afspraken binnen een team die worden bedacht op basis van nut en noodzaak, maar van centraal afgedwongen policies. Dat betreft dan niet enkel zaken als verplichte reviewvinkjes, maar ook koppeling met JIRA, want stel je voor dat je een spelfout corrigeert in docs zonder een JIRA ticket. Bovendien is dat ook niet simpelweg een kwestie van een oneliner ticket maken en klaar, maar een heel adminstratief proces waarbij 324 veldjes moeten worden gevuld (waarvan het gros gewoon voorgevuld had kunnen zijn, maar waarom makkelijk maken als het ook bureaucratisch kan). Want ja, stel je voor dat die 3 seconden werk die je eigenlijk had aan het daadwerkelijke werk ongeadministreerd blijven. Het administratieve kwartiertje dat je hebt gespendeerd staat nu in ieder geval aan de juiste kostenposten toegewezen!
?
Ik denk dat je me verkeerd begrijpt. Ik heb het niet over een spelfout in documentatie voor afnemers, maar gewoon documentatie in de codebase. (Publieke) API specs worden bij m'n huidige klant sowieso door een team beheerd dat ze afstemt in overlegorganen met formele processen waar maanden overheen gaat.:
[...]
Als het slechts een spelfout is, is het niet heel belangrijk om direct op te lossen en kun je het bundelen onder meerdere subtaken en een keer een opschoon ticket maken voor dit soort taakjes. Ik denk dat dit erg bezien is als uitvoerder en dat je daarbij het overzicht vanuit de organisatie breed een beetje kleiner maakt dan het zou moeten zijn. Zelfs een kleine wijziging in documentatie kan soms grote gevolgen hebben over de interpretatie en daarmee over hoe iets geimplementeerd wordt. dan wil je dit juist wel heel duidelijk gelogd hebben wie wanneer en waarom zodat je weer kan zorgen dat alles rechtgetrokken wordt. En qua kosten is dat ene beetje werk van 3 seconden (bij wijze van, want 3 seconden is wel heel weinig tijd) misschien niet veel, maar hoe groter het team, hoe vaker die 3 seconden en hoe duurder het personeel, dan gaat het behoorlijk oplopen. En bedenk dan ook dat als er inderdaad een verschil in interpretatie ontstaat daarna, de gevolgen qua kostenpost nog veel groter kunnen uitvallen. Dus hoewel je in het begin m.i. het juiste zegt, lijk je dat naar mijn idee aan het einde juist weer wat tegen te spreken door zelf die risico's niet te zien
En ja, je gaat van alles onder andere PRs prakken op deze manier en hoe meer bloated de PRs hoe minder scherp je die weer functioneel reviewt. Het zijn juist dit soort averechtse effecten die vaak onderschat worden.
Overigens draaien er dan wel weer automatische dependency upgrades die gewoon door kunnen zonder door al die administratieve hoepels te moeten en die brengen een veel groter risico met zich mee dan zo'n correcte in documentatie van de codebase.
En het gaat veel verder dan dit soort zaken. Neem iets als de administratieve bewijslast van het feit dat processen wordt gevolgd. Er zijn vaak audittrails van jaren, alles is in te zien, maar nee, risk managers zijn kennelijk zo digibeet dat alle 350 procedures met wekelijkse of maandelijkse screenshotjes moet worden bevestigd. Wordt daar iets beter van? Nee, natuurlijk niet.
De enige wijze waarop dit soort procedurezucht bijdraagt aan het reduceren van risico is dat het de snelheid waarmee je werkende software op kunt leveren drastisch reduceert. En hoe minder werkende software je oplevert, des te minder risico je loopt op onvoorziene problemen.
Ik denk dat ik met inmiddels ruim 20 jaar ervaring in de softwarewereld bij een breed scala aan bedrijven toch echt prima in staat ben om te beoordelen wat zinvolle checks & balances zijn en wat vooral window dressing is.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
En als iemand anders met vergelijkbare achtergrond ga ik je tegenspreken
Elke bedrijf/project/team is anders. De eerste maand dat ik ergens bij betrokken ben stap ik vaak de ruimte in terwijl ik me zelf nogmaals actief herinner dat ik mijn ego thuis moet laten. En dan ben ik vaak de persoon die juist binnen gehaald word om proces verbeteringen door te voeren
En ik zeg dit omdat mijn eerste oordeel/conclusie zelden in het rapport aan management verschijnt. Dus mogelijk zegt dit meer over mij dan over jou
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- David Blankenhorn
100% mee eens. Ik heb ooit een uren registratie ingeleverd waar een kopje was "uren invullen" die ik getimed had op een ongeveer 50 minuten. De week daarop kon ik een uren registratie inleveren met een kopje "discussie over uren registratie" waar ik 5 uur op kon boeken. De week daarop heb ik met HR afgesproken dat we in het vervolg een willekeurige taak kiezen en die gewoon aandikken.:
[...]
Ja vooral dat. Helaas zit ik best wel vaak bij klanten waar men heel erg van 'cover your ass' is. Risico en onvoorspelbaarheid zijn dan vieze woorden, maar in plaats van dat het gaat om realistisch kijken naar hoe het risico echt ingedamd kan worden is het vooral zaak om alles dicht te timmeren met procedures zodat de accountant kan auditen dat de procedures zijn gevolgd en een vinkje gezet kan worden. Vervolgens kan het management dan bij problemen verwijzen naar het vinkje van de accountant en hun lucratieve baantjes behouden.
Dat betekent onder andere dat zaken als hoe je omgaat met PRs geen kwestie zijn van afspraken binnen een team die worden bedacht op basis van nut en noodzaak, maar van centraal afgedwongen policies. Dat betreft dan niet enkel zaken als verplichte reviewvinkjes, maar ook koppeling met JIRA, want stel je voor dat je een spelfout corrigeert in docs zonder een JIRA ticket. Bovendien is dat ook niet simpelweg een kwestie van een oneliner ticket maken en klaar, maar een heel adminstratief proces waarbij 324 veldjes moeten worden gevuld (waarvan het gros gewoon voorgevuld had kunnen zijn, maar waarom makkelijk maken als het ook bureaucratisch kan). Want ja, stel je voor dat die 3 seconden werk die je eigenlijk had aan het daadwerkelijke werk ongeadministreerd blijven. Het administratieve kwartiertje dat je hebt gespendeerd staat nu in ieder geval aan de juiste kostenposten toegewezen!
Ps: Dit was toen ik nog heel jong (en dom en arrogant) was.
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- David Blankenhorn
Je zet hier wel de deur open zeg... maar ik houd me in
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Geen zorgen, ik ben al lang niet meer jong:
[...]
Je zet hier wel de deur open zeg... maar ik houd me in
...De andere dingen mag jezelf beoordelen...
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- David Blankenhorn
Goed, laat ik het anders formuleren.:
[...]
En als iemand anders met vergelijkbare achtergrond ga ik je tegenspreken
Elke bedrijf/project/team is anders. De eerste maand dat ik ergens bij betrokken ben stap ik vaak de ruimte in terwijl ik me zelf nogmaals actief herinner dat ik mijn ego thuis moet laten. En dan ben ik vaak de persoon die juist binnen gehaald word om proces verbeteringen door te voeren
En ik zeg dit omdat mijn eerste oordeel/conclusie zelden in het rapport aan management verschijnt. Dus mogelijk zegt dit meer over mij dan over jou
Ik ben echt niet iemand die hangt in universele waarheden over wat werkt en wat niet werkt in de IT, integendeel ik ben daar vrij postmodernistisch in.
Als ik op een lopend project kom, dan ben ik ook open in mijn analyse. Het is vrij makkelijk om naar processen of code te kijken en te zeggen "jullie doen dit helemaal verkeerd", maar vaak ben je op een bepaald punt gekomen vanwege een lange voorgeschiedenis.
Hoewel ik een pesthekel heb aan het keihard afdwingen van allerlei zaken als reviews, kan het best nodig zijn in situaties waar je zit met onverschrokken juniors die zonder enige vrees voor de 15e keer productie omver trekken met een ongereviewde PR.
Maar qua organisatisch ken ik zo langzamerhand mijn Pappenheimers ook wel. Ik heb al best wat klantorganisaties waar men heeft besloten om niet langer een regie-organisatie te zijn, maar juist een engineering organisatie met eigen engineers. Wat ik in dat type organisatie gewoon heel erg zie is het vasthouden aan de illusie van de controle. In een regie-organisatie kun je gewoon lekker schoppen naar je leverancier, die veelal gepokt en gemazeld is in het succesvol leveren van IT projecten en ook weet hoe men die moet managen. Dan halen ze vervolgens een managementconsultancyclubje binnen die een analyse gaat doen en om de een of andere onverklaarbare reden altijd uitkomt op SAfE als methodiek. Want dan kun je Agile roepen, maar nog steeds net doen alsof IT projecten met loopduren van jaren volkomen planbaar zijn.
Daarbij moet natuurlijk nog steeds wel over alles en nog wat continu verantwoording afgelegd worden, want we moeten wel kunnen sturen natuurlijk en het kan niet zo zijn dat 'we' (lees: MT) verantwoordelijk worden gehouden voor falen zonder dat we kunnen verwijzen naar procedures, normen en certificeringen die allemaal braaf gevolgd zijn.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra