De Devschuur Coffee Corner - Iteratie ⓬

[Creepy]

Niet alleen in de naam. Minstens 1 factory, een singleton, een interface met een bijbehorende abstract class etc . Voor wat inspiratie: https://github.com/Enterp...FizzBuzzEnterpriseEdition

[Giesber]

Hydra schreef op maandag 10 mei 2021 @ 12:44:
[...]


Ik mis op z'n minst Abstract, Singleton en Bean nog in die naam!

Zie zet ik al in de package naam.

[ElkeBxl]

Creepy schreef op maandag 10 mei 2021 @ 13:49:
Niet alleen in de naam. Minstens 1 factory, een singleton, een interface met een bijbehorende abstract class etc . Voor wat inspiratie: https://github.com/Enterp...FizzBuzzEnterpriseEdition

Ik weet dat het satire is, maar toch....
* ElkeBxl gaat ff bekomen met wat /r/eyebleach

[Koenvh]

Crazy D schreef op maandag 10 mei 2021 @ 11:39:
Wat voor business werken jullie in dat jullie heel de tijd bezig zijn met apen en bananen?

Integreren van APIs

Spreek uit als "aapie", niet op z'n Engels

[Woy]

Hydra schreef op maandag 10 mei 2021 @ 12:44:
[...]


Ik mis op z'n minst Abstract, Singleton en Bean nog in die naam!

En Decorator, Facade, Strategy en Visitor

[Hydra]

Woy schreef op maandag 10 mei 2021 @ 16:03:
En Decorator, Facade, Strategy en Visitor

M'n Design Patterns boek ligt helaas opgeslagen anders hadden we er ff A-Z doorheen kunnen gaan

[RagingPenguin]

bwerg schreef op zondag 9 mei 2021 @ 23:15:
[...]

Haskell:

    -- Like obscure people who don't mind checking up on precedence of obscure operators
    print $ banana <$> apes
    print $ peel . banana <$> apes

Het gehalte "het is voor de leek niet meer zo goed te lezen" neemt zo wel wat toe.

'Leesbaarheid voor de leek' is natuurlijk wel de kracht van Haskell. Al heb je minder code dan zijn er ook minder dingen die je moet weten

[ Voor 3% gewijzigd door RagingPenguin op 10-05-2021 17:47 ]

[SPee]

Woy schreef op maandag 10 mei 2021 @ 16:03:
[...]
En Decorator, Facade, Strategy en Visitor

En vergeet Proxy niet.

Hydra schreef op maandag 10 mei 2021 @ 11:56:
[...]
Nou veel van de legacy code kan niet door mensen geschreven zijn dus ik sorteer vast voor op het moment dat ik die developers ontmoet.

Ik hou rekening met de volgende gezegde:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

En over proxy gesproken: wij moeten in onze nieuwe dev omgeving nu via een proxy naar buiten. De authenticatie foutmeldingen vliegen je om de oren. Ligt het nou aan de authenticatie op Nexus, het https certificaat dat Java niet kent of toch wat anders?
Ik zou bijna een nieuwe hype willen beginnen, met de bijbehorende rellen: DLM

[Woy]

SPee schreef op maandag 10 mei 2021 @ 21:17:
[...]
En over proxy gesproken: wij moeten in onze nieuwe dev omgeving nu via een proxy naar buiten. De authenticatie foutmeldingen vliegen je om de oren. Ligt het nou aan de authenticatie op Nexus, het https certificaat dat Java niet kent of toch wat anders?
Ik zou bijna een nieuwe hype willen beginnen, met de bijbehorende rellen: DLM

Oh, the horror. Ik heb ook ooit bij een security Toko gewerkt die dat nodig vond. Het gezeur met SSL inspection en software die gebruik maakte van certificate pinning, of niet de Windows certificate store gebruikte.

Dat was echt een ramp

[roeleboel]

Woy schreef op maandag 10 mei 2021 @ 21:27:
[...]

Oh, the horror. Ik heb ook ooit bij een security Toko gewerkt die dat nodig vond. Het gezeur met SSL inspection en software die gebruik maakte van certificate pinning, of niet de Windows certificate store gebruikte.

Dat was echt een ramp

Maar dat is dan nog consequent gedrag!
Wij deden aan proxy-roulette: ongeveer 1 op 4 requests werd gedropped omdat de proxy overbelast was...
Das pas tof om te gaan debuggen

[Lethalis]

SPee schreef op maandag 10 mei 2021 @ 21:17:
[...]
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

Ik werk al 14 jaar bij dezelfde werkgever... ik haat mezelf inmiddels

"Waarom heb ik dat in vredesnaam zo gedaan?!?"
"Ik had framework X voor dat project moeten kiezen ipv Y"
"Ik weet niet wat ik dacht toen ik dit ooit gemaakt heb, maar goed was het niet"
"Waar is de documentatie?"
"Wat doet dit in vredesnaam?!"
"Heb ik dit gemaakt?"

Enzovoorts.

[PrisonerOfPain]

Lethalis schreef op dinsdag 11 mei 2021 @ 09:06:
[...]

Ik werk al 14 jaar bij dezelfde werkgever... ik haat mezelf inmiddels

"Waarom heb ik dat in vredesnaam zo gedaan?!?"
"Ik had framework X voor dat project moeten kiezen ipv Y"
"Ik weet niet wat ik dacht toen ik dit ooit gemaakt heb, maar goed was het niet"
"Waar is de documentatie?"
"Wat doet dit in vredesnaam?!"
"Heb ik dit gemaakt?"

Enzovoorts.

Dit soort dingen fix je toch gewoon als je ze tegen komt? Als je dat niet doet deteriorate je codebase zo mega snel dat dit een constante spiraal word. Misschien dat een framework vervangen niet altijd de beste optie is, maar de rest sowieso wel.

[PrisonerOfPain]

Ik vraag me dit af en toe nog wel af (en had er laatst een gesprek met een collega over), toen ik - 10 jaar terug nog wat webdev deed heerste er altijd een idee van "code esthetics" in die wereld. Code moest "mooi" of "clean" zijn, of code kon "lelijk" zijn en dat kon afhangen van de meest uiteenlopende zaken. Tegenwoordig ben ik vooral van mening dat als code doet wat 't moet doen dat 't dan goede code is. En dat die esthetische argument 99% BS zijn - dingen om een code review inhoud te geven zonder daadwerkelijk op de code in te gaan bijvoorbeeld. Gebeurt dit nog veel, of zijn mensen inmiddels tot de conclusie gekomen dat 't allemaal niet zo interessant is allemaal, dat subjectieve idee van mooi/lelijk in code?

[Kalentum]

PrisonerOfPain schreef op dinsdag 11 mei 2021 @ 09:26:
Ik vraag me dit af en toe nog wel af (en had er laatst een gesprek met een collega over), toen ik - 10 jaar terug nog wat webdev deed heerste er altijd een idee van "code esthetics" in die wereld. Code moest "mooi" of "clean" zijn, of code kon "lelijk" zijn en dat kon afhangen van de meest uiteenlopende zaken. Tegenwoordig ben ik vooral van mening dat als code doet wat 't moet doen dat 't dan goede code is. En dat die esthetische argument 99% BS zijn - dingen om een code review inhoud te geven zonder daadwerkelijk op de code in te gaan bijvoorbeeld. Gebeurt dit nog veel, of zijn mensen inmiddels tot de conclusie gekomen dat 't allemaal niet zo interessant is allemaal, dat subjectieve idee van mooi/lelijk in code?

Het hangt natuurlijk van je definitie van lelijk en mooi af. Er zijn mensen die onleesbare oneliners mooi vinden.

Maar over het algemeen vind ik code die onze linter geaccepteerd wordt goed genoeg. En die kijkt niet alleen naar de juiste whitespace enzo maar ook naar complexe code paths enzo. In combinatie met TDD kom je dan een heel eind.

Moet opeens ook aan 1 van de maintainers van Redis denken. Die stopte daarmee om deze reden:

quote: http://antirez.com/news/133

I write code in order to express myself, and I consider what I code an artifact, rather than just something useful to get things done. I would say that what I write is useful just as a side effect, but my first goal is to make something that is, in some way, beautiful. In essence, I would rather be remembered as a bad artist than a good programmer. Now I’m asked more and more, by the circumstances created by a project that became so important, to express myself less and to maintain the project more. And this is indeed exactly what Redis needs right now. But this is not what I want to do, and I stretched myself enough during the past years.

[ Voor 25% gewijzigd door Kalentum op 11-05-2021 09:37 ]

[DevWouter]

PrisonerOfPain schreef op dinsdag 11 mei 2021 @ 09:26:
Ik vraag me dit af en toe nog wel af (en had er laatst een gesprek met een collega over), toen ik - 10 jaar terug nog wat webdev deed heerste er altijd een idee van "code esthetics" in die wereld. Code moest "mooi" of "clean" zijn, of code kon "lelijk" zijn en dat kon afhangen van de meest uiteenlopende zaken. Tegenwoordig ben ik vooral van mening dat als code doet wat 't moet doen dat 't dan goede code is. En dat die esthetische argument 99% BS zijn - dingen om een code review inhoud te geven zonder daadwerkelijk op de code in te gaan bijvoorbeeld. Gebeurt dit nog veel, of zijn mensen inmiddels tot de conclusie gekomen dat 't allemaal niet zo interessant is allemaal, dat subjectieve idee van mooi/lelijk in code?

Ik denk dat het vooral komt omdat toen wij jong waren heleboel zaken verkeerd begrepen. De SRP van SOLID is één die ik mijn juniors (en mediors) wel eens hoor roepen als argument terwijl ik zeker weet dat ze het niet weten wat het betekent.

Ik denk dat veel ontwikkelaars denken dat hun doel is om code te schrijven, iets waar ik fel tegenstander van ben. Wel wil ik dat ze minimaal een "format document" draaien bij het inchecken. Heb ooit bij één ontwikkelaar achter zijn laptop gekropen om te zorgen dat het automatisch gebeurde bij het opslaan.

Verder is de hoeveelheid cargo cult in onze beroepsgroep echt groot en de helft van de tijd ben ik bezig om simpelere oplossingen te tonen of ze aan het overtuigen dat die 3 lagen van indirectie allemaal weg kunnen.

[Mugwump]

PrisonerOfPain schreef op dinsdag 11 mei 2021 @ 09:26:
Ik vraag me dit af en toe nog wel af (en had er laatst een gesprek met een collega over), toen ik - 10 jaar terug nog wat webdev deed heerste er altijd een idee van "code esthetics" in die wereld. Code moest "mooi" of "clean" zijn, of code kon "lelijk" zijn en dat kon afhangen van de meest uiteenlopende zaken. Tegenwoordig ben ik vooral van mening dat als code doet wat 't moet doen dat 't dan goede code is. En dat die esthetische argument 99% BS zijn - dingen om een code review inhoud te geven zonder daadwerkelijk op de code in te gaan bijvoorbeeld. Gebeurt dit nog veel, of zijn mensen inmiddels tot de conclusie gekomen dat 't allemaal niet zo interessant is allemaal, dat subjectieve idee van mooi/lelijk in code?

"Doet wat het moet doen" lijkt me nogal een beperkte definitie.
Ik bedoel code met myvar1 t/m myvar391 in 25 geneste ifjes met wat loops er tussendoor kan best doen wat er moet gebeuren door veel trial and error (en meestal de nodige hotfixes omdat er in productie allerlei onvoorziene situaties ontstaan), maar succes als je daar een wijziging op moet doen.

[Hydra]

PrisonerOfPain schreef op dinsdag 11 mei 2021 @ 09:26:
Ik vraag me dit af en toe nog wel af (en had er laatst een gesprek met een collega over), toen ik - 10 jaar terug nog wat webdev deed heerste er altijd een idee van "code esthetics" in die wereld. Code moest "mooi" of "clean" zijn, of code kon "lelijk" zijn en dat kon afhangen van de meest uiteenlopende zaken. Tegenwoordig ben ik vooral van mening dat als code doet wat 't moet doen dat 't dan goede code is.

Code moet niet alleen doen wat het moet doen, het moet ook onderhoudbaar zijn. En het belangrijkste aspect in onderhoudbaarheid is leesbaarheid. Dan is het dus belangrijk dat code zo simpel mogelijk gehouden wordt, geen dingen doet die niet nodig zijn, niet afwijkt van teams standaarden, etc.

En dat is meestal waar die discussies over 'esthetics' om gaan; code die 'clean' of 'elegant' is, is meestal gewoon simpel. En code die simpel is om te lezen is over het algemeen ook simpel om aan te passen.

M.i. is de kunst om simpele code te schrijven wat 'senior' developers definieert. Als je overengineered zut produceert ben je m.i. geen 'senior', hoe 'slim' je code ook is. De kans is namelijk groot dat als je je code zo slim mogelijk maakt, je niet slim genoeg bent 'em te debuggen.

[Hydra]

DevWouter schreef op dinsdag 11 mei 2021 @ 09:45:
Ik denk dat veel ontwikkelaars denken dat hun doel is om code te schrijven, iets waar ik fel tegenstander van ben. Wel wil ik dat ze minimaal een "format document" draaien bij het inchecken. Heb ooit bij één ontwikkelaar achter zijn laptop gekropen om te zorgen dat het automatisch gebeurde bij het opslaan.

Precies. Code is risico. Je wil er zo min mogelijk van hebben.

Verder is de hoeveelheid cargo cult in onze beroepsgroep echt groot en de helft van de tijd ben ik bezig om simpelere oplossingen te tonen of ze aan het overtuigen dat die 3 lagen van indirectie allemaal weg kunnen.

Absoluut. Aan de andere kant zie je mensen ook naar de andere kant doorslaan dat alle abstracties slecht zijn, en dat is ook complete onzin. Je wil abstracties over het algemeen niet 3 lagen diep hebben, maar abstracties kunnen code ook heel veel simpeler maken. Een simpel voorbeeld van een abstractie is iets dat vaak gebruikt wordt in een herbruikbare library stoppen. Sommige mensen zijn daar tegen (zie je veel bij Go developers); die vinden het 'beter' die zut overal naar toe te copy-pasten. Maf hoe de geschiedenis daar ook weer een cirkel blijkt te zijn.

[PrisonerOfPain]

Hydra schreef op dinsdag 11 mei 2021 @ 10:01:
[...]


Code moet niet alleen doen wat het moet doen, het moet ook onderhoudbaar zijn. En het belangrijkste aspect in onderhoudbaarheid is leesbaarheid. Dan is het dus belangrijk dat code zo simpel mogelijk gehouden wordt, geen dingen doet die niet nodig zijn, niet afwijkt van teams standaarden, etc.

Ik zou die nuance anders leggen denk ik - code moet onderhouden worden. Alle code is onderhoudbaar - het is immers code, die kun je verplaatsen, verwijderen, opschonen, veranderen etc.

[Hydra]

PrisonerOfPain schreef op dinsdag 11 mei 2021 @ 10:09:
Ik zou die nuance anders leggen denk ik - code moet onderhouden worden. Alle code is onderhoudbaar - het is immers code, die kun je verplaatsen, verwijderen, opschonen, veranderen etc.

Da's nogal een rare niet standaard definitie van onderhoudbaar IMHO.

[PrisonerOfPain]

Hydra schreef op dinsdag 11 mei 2021 @ 10:17:
[...]


Da's nogal een rare niet standaard definitie van onderhoudbaar IMHO.

Misschien het is voor mij over de jaren een stuk nuttiger gebleken om zo naar code te kijken en code te zien als een kneedbaar veranderbaar ding, dan om "onderhoudbaarheid" te proberen te front-loaden, je weet immers niet wat de toekomst kan brengen.

[InTheDisorder]

PrisonerOfPain schreef op dinsdag 11 mei 2021 @ 10:09:
[...]


Ik zou die nuance anders leggen denk ik - code moet onderhouden worden. Alle code is onderhoudbaar - het is immers code, die kun je verplaatsen, verwijderen, opschonen, veranderen etc.

Alle code is onderhoudbaar, maar als code compleet onlogisch in elkaar zit en het een uur duurt voordat je uberhaupt doorhebt wat er nou precies allemaal gebeurd is het de code die 'clean' en simpel te lezen is die toch meer onderhoudbaar is imo.

[armageddon_2k1]

PrisonerOfPain schreef op dinsdag 11 mei 2021 @ 10:23:
[...]


Misschien het is voor mij over de jaren een stuk nuttiger gebleken om zo naar code te kijken en code te zien als een kneedbaar veranderbaar ding, dan om "onderhoudbaarheid" te proberen te front-loaden, je weet immers niet wat de toekomst kan brengen.

Juist omdat je niet weet wat de toekomst brengt is het handig als het onderhoudbaar is lijkt me zo. Ligt er een beetje aan hoe je onderhoudbaar definieert. Maar als ik voor een simpele kleurwijziging van een knopje 8 uur bezig ben, dan vind ik het niet onderhoudbaar.

[ Voor 14% gewijzigd door armageddon_2k1 op 11-05-2021 10:37 ]

[KabouterSuper]

PrisonerOfPain schreef op dinsdag 11 mei 2021 @ 10:09:
[...]
Ik zou die nuance anders leggen denk ik - code moet onderhouden worden. Alle code is onderhoudbaar - het is immers code, die kun je verplaatsen, verwijderen, opschonen, veranderen etc.

Dan kan ik ook zeggen dat alle code gedocumenteerd is: lees de code, dan snap je vanzelf wat de bedoeling is. Overigens is documentatie fijn, maar alleen als het wat toevoegt. Het meest briljante commentaar dat ik ooit gelezen heb was "Bugfix: fixed a bug, because it was wrong". En bedankt!

[wackmaniac]

Lethalis schreef op dinsdag 11 mei 2021 @ 09:06:
[...]

Ik werk al 14 jaar bij dezelfde werkgever... ik haat mezelf inmiddels

"Waarom heb ik dat in vredesnaam zo gedaan?!?"
"Ik had framework X voor dat project moeten kiezen ipv Y"
"Ik weet niet wat ik dacht toen ik dit ooit gemaakt heb, maar goed was het niet"
"Waar is de documentatie?"
"Wat doet dit in vredesnaam?!"
"Heb ik dit gemaakt?"

Enzovoorts.

Ik ben een tijdje geleden begonnen met het toevoegen van ADR's aan mijn (persoonlijke) projecten en ik ben een poging aan het doen collega's over te halen dit ook te introduceren in onze corporate codebases. Juist om dit soort dingen te voorkomen.

Doorgaans maak je een beslissing met de kennis die je op dat moment hebt. Soms blijkt zo'n beslissing niet de juiste, soms is er een verborgen reden waarom de gekozen oplossing juist de beste is.

[armageddon_2k1]

Ik moest opzoeken wat een ADR is. Maar een Architecture Design Record dus. Mooie term weer voor iets wat in andere engineering bedrijfstakken al lang gemeengoed is.

Na aardig wat jaren als ingenieur gewerkt te hebben verbaasd het me altijd weer hoe de software wereld bepaalde dingen elke keer weer opnieuw uitvind die in medical, automotive, aerospace al 30 jaar gemeengoed zijn.

Na mijn overstap in software hebben wij dus in onze repositories of onze knowledge base al vrij rap Architectuur documenten staan die beschrijven waarom iets gedaan is, en wat de consequenties zijn. Dat hoeven echt geen epistels te zijn hoor.

[ Voor 7% gewijzigd door armageddon_2k1 op 11-05-2021 10:57 ]

[Hydra]

wackmaniac schreef op dinsdag 11 mei 2021 @ 10:47:
Ik ben een tijdje geleden begonnen met het toevoegen van ADR's aan mijn (persoonlijke) projecten en ik ben een poging aan het doen collega's over te halen dit ook te introduceren in onze corporate codebases. Juist om dit soort dingen te voorkomen.

FF m'n blogje pimpen: https://niels.nu/blog/201...itecture-decision-records

[armageddon_2k1]

Hydra schreef op dinsdag 11 mei 2021 @ 11:12:
[...]


FF m'n blogje pimpen: https://niels.nu/blog/201...itecture-decision-records

Mooi. Ik was architect in medical devices en herken me goed in je verhaal.

[Mugwump]

armageddon_2k1 schreef op dinsdag 11 mei 2021 @ 10:53:
Ik moest opzoeken wat een ADR is. Maar een Architecture Design Record dus. Mooie term weer voor iets wat in andere engineering bedrijfstakken al lang gemeengoed is.

Na aardig wat jaren als ingenieur gewerkt te hebben verbaasd het me altijd weer hoe de software wereld bepaalde dingen elke keer weer opnieuw uitvind die in medical, automotive, aerospace al 30 jaar gemeengoed zijn.

Na mijn overstap in software hebben wij dus in onze repositories of onze knowledge base al vrij rap Architectuur documenten staan die beschrijven waarom iets gedaan is, en wat de consequenties zijn. Dat hoeven echt geen epistels te zijn hoor.

Als je het de gemiddelde ingenieur (uit een andere discipline) vraagt, dan is software-ontwikkeling ook geen echt ingenieursvak, maar meer een beetje hobbywerk.

[Lethalis]

wackmaniac schreef op dinsdag 11 mei 2021 @ 10:47:
[...]
Ik ben een tijdje geleden begonnen met het toevoegen van ADR's aan mijn (persoonlijke) projecten en ik ben een poging aan het doen collega's over te halen dit ook te introduceren in onze corporate codebases. Juist om dit soort dingen te voorkomen.

Tegenwoordig zet ik meestal een markdown bestandje erbij (readme.md). Met daarin een korte omschrijving wat het doet, waar het gedeployed is en welke belangrijke keuzes er gemaakt zijn. Maar ja, de oude meuk heeft dat nog niet.

Het mooie van oplossingen als github / gitea vind ik ook dat je die documentatie meteen bij het project kunt zetten en het direct zichtbaar is zodra iemand naar een repository kijkt.

Vroeger werd documentatie vaak met Word (en Visio) geschreven en de verschillende versies ervan als PDF geëxporteerd.

Maar dat werd dan dus niet bij het project opgeslagen, maar in een documentatie map op een server.

Dus ik zoek mij soms een ongeluk om die oude documenten te vinden.

[roeleboel]

Mugwump schreef op dinsdag 11 mei 2021 @ 11:39:
[...]
Als je het de gemiddelde ingenieur (uit een andere discipline) vraagt, dan is software-ontwikkeling ook geen echt ingenieursvak, maar meer een beetje hobbywerk.

In alle eerlijkheid is een heel groot deel ook gewoon de zoveelste variant op crud waarbij er een tikkeltje maatwerk gevraagd wordt maar zeker niks spannends.
En ja, ik besef me ten volle dat er genoeg 'professionals' rondlopen die dat naar iets totaal on-onderhoudbaar vertalen.

[Lethalis]

Mugwump schreef op dinsdag 11 mei 2021 @ 11:39:
[...]


Als je het de gemiddelde ingenieur (uit een andere discipline) vraagt, dan is software-ontwikkeling ook geen echt ingenieursvak, maar meer een beetje hobbywerk.

Ik heb 5 jaar bij het ingenieursbureau van mijn pa gewerkt als technisch tekenaar en we hebben destijds ook een hoop rommel gezien hoor

Van roldeuren die naar beneden kwamen zeilen, stalen constructies en hele daken die instorten, tot en met dingen die gewoon helemaal niet klopten en / of onmogelijk waren om te monteren

Dus ik vind het wat oneerbiedig om zo over software ontwikkeling te praten. Bij andere disciplines gaat ook veel mis.

[armageddon_2k1]

Naarmate ik ouder wordt (en ik ben niet echt oud ofzo) kom ik erachter dat 99% van de mensen maar gewoon wat aankloot. En daar reken ik mezelf natuurlijk ook af en toe bij.

EDIT: Mooie quote van de historicus Rutger Bregman in z'n podcast:
"Mensen die heel erg geloven in complottheorieen raad ik toch aan om historicus te worden. Dan kom je erachter dat iedereen maar wat aankloot en dat zelfs de grootste complotten, zoals Watergate, aan elkaar hangen van knulligheden en toevalligheden."

[ Voor 48% gewijzigd door armageddon_2k1 op 11-05-2021 12:18 ]

[PrisonerOfPain]

DevWouter schreef op dinsdag 11 mei 2021 @ 09:45:
Ik denk dat veel ontwikkelaars denken dat hun doel is om code te schrijven, iets waar ik fel tegenstander van ben.

Hier ben ik 't trouwens helemaal mee eens @DevWouter, ik vind goed kunnen communiceren met je klant / team een van de meest belangrijke skills van een goede programmeur en heb ook bijvoorbeeld liever iemand in 't team die misschien technisch iets minder onderlegd is maar wel sterk kan communiceren dan andersom. Technische skills zijn meestal vrij makkelijk aan te leren, communicatie niet.

[armageddon_2k1]

PrisonerOfPain schreef op dinsdag 11 mei 2021 @ 12:08:
[...]
Technische skills zijn meestal vrij makkelijk aan te leren, communicatie niet.

Niet helemaal mee eens. Technische skills zijn goed aan te leren omdat er duidelijke curricula (? -lums?) voor bestaan, maar voor communicatie is gewoon niet een heel duidelijk leerpad. Daarnaast is communiceren in een team en met klanten juist iets dat je moet leren, en wat prima te leren is, en sommigen zullen daar meer aanleg voor hebben dan anderen. Ik heb best wel wat mensen zien veranderen van lompe onhandige beginnende stagiairs tot goed communicerende team-leden. Dus iemand afschrijven op communicatie is zonde.

Daarnaast, 'technische skills' aanleren is nogal breed. Als iemand geen lineaire algebra kan dan is het best lastig deze dat nog snel aan te leren. Een basis React app daarentegen is weer wat makkelijker. Een differentiaal-vergelijking numeriek oplossen dan weer niet....

Overigens, over de incompententie van ingenieurs gesproken. Tijdens mijn werk hadden we nogal veel te maken met statistiek (lekker six sigma doen enzo, je weet toch) en toen kwam ik erachter dat sommige Delftsche werktuigbouwers geen standaard deviatie uit konden rekenen. Zelfs na het zien van de formule. Daar viel ik wel stijl van achterover.

[ Voor 4% gewijzigd door armageddon_2k1 op 11-05-2021 12:22 ]

[Mugwump]

armageddon_2k1 schreef op dinsdag 11 mei 2021 @ 12:06:
Naarmate ik ouder wordt (en ik ben niet echt oud ofzo) kom ik erachter dat 99% van de mensen maar gewoon wat aankloot. En daar reken ik mezelf natuurlijk ook af en toe bij.

EDIT: Mooie quote van de historicus Rutger Bregman in z'n podcast:
"Mensen die heel erg geloven in complottheorieen raad ik toch aan om historicus te worden. Dan kom je erachter dat iedereen maar wat aankloot en dat zelfs de grootste complotten, zoals Watergate, aan elkaar hangen van knulligheden en toevalligheden."

Het verschil zit hem meer in de mate van aanklooien.
Als ik een code review doe en ik vraag waarom bepaalde keuzes zijn gemaakt (die een flinke impact hebben) en het antwoord is 'oh dat heb ik gewoon ergens vandaan gecopy-paste', dan word ik niet heel vrolijk.

En je kunt toch moeilijk beweren dat elke hersenchirurg maar wat aanklooit en het een godswonder is dat niet 95% van de patiënten overlijdt.

[PrisonerOfPain]

Mugwump schreef op dinsdag 11 mei 2021 @ 12:25:
Als ik een code review doe en ik vraag waarom bepaalde keuzes zijn gemaakt (die een flinke impact hebben) en het antwoord is 'oh dat heb ik gewoon ergens vandaan gecopy-paste', dan word ik niet heel vrolijk.

Als dit daadwerkelijk het soort collega's is wat mensen hebben dan snap ik een deel van de reacties hierboven een stuk beter

[Lethalis]

Mugwump schreef op dinsdag 11 mei 2021 @ 12:25:
[...]
Het verschil zit hem meer in de mate van aanklooien.
Als ik een code review doe en ik vraag waarom bepaalde keuzes zijn gemaakt (die een flinke impact hebben) en het antwoord is 'oh dat heb ik gewoon ergens vandaan gecopy-paste', dan word ik niet heel vrolijk.

En je kunt toch moeilijk beweren dat elke hersenchirurg maar wat aanklooit en het een godswonder is dat niet 95% van de patiënten overlijdt.

Een hersenchirurg heeft doorgaans ook een ander salaris en is een stuk zeldzamer dan de gemiddelde ingenieur, programmeur, whatever. You get what you pay for.

Er zijn natuurlijk ook hele goede software engineers, maar die zijn net zo zeldzaam als die chirurg. Ik reken mezelf daar ook niet toe trouwens Ik zie dan echt iemand voor me met een CS master die tig jaar ervaring heeft bij grote bedrijven en complexe architecturen.

En niet de gemiddelde Google-fu meester

[DevWouter]

armageddon_2k1 schreef op dinsdag 11 mei 2021 @ 12:22:
[...]


Niet helemaal mee eens. Technische skills zijn goed aan te leren omdat er duidelijke curricula (? -lums?) voor bestaan, maar voor communicatie is gewoon niet een heel duidelijk leerpad. Daarnaast is communiceren in een team en met klanten juist iets dat je moet leren, en wat prima te leren is, en sommigen zullen daar meer aanleg voor hebben dan anderen. Ik heb best wel wat mensen zien veranderen van lompe onhandige beginnende stagiairs tot goed communicerende team-leden. Dus iemand afschrijven op communicatie is zonde.

Software ontwikkelen is ook een communicatief vak. Je vertaalt de eisen van de klant naar code die uitgevoerd wordt door de gebruiker. De technische vaardigheid is eerder een noodzaak voor je sociale vaardigheid.

Dat is ook de reden waarom dat sommige developers niet in contact mogen komen met de stakeholder/klant/gebruiker. Zij begrijpen die persoon letterlijk niet. En een ontwikkelaar die niet maakt waar om gevraagd wordt levert een negatief rendament op.

Mugwump schreef op dinsdag 11 mei 2021 @ 12:25:
Als ik een code review doe en ik vraag waarom bepaalde keuzes zijn gemaakt (die een flinke impact hebben) en het antwoord is 'oh dat heb ik gewoon ergens vandaan gecopy-paste', dan word ik niet heel vrolijk.

Jij ervaart meerdere problemen:
1. De gekozen oplossing voldoet niet aan jouw eisen.
2. De maker heeft onvoldoende nagedacht over de gevolgen van diens keuze
3. De maker probeert de schuld af te schuiven naar waar de code vandaan komt.

Mocht je het nog een keer meemaken vraag die persoon dan: "Begrijp jij waarom ik zo ongelukkig ben van deze code?" en volg die ongeacht diens antwoord op met "Wat zouden we kunnen doen om te zorgen dat we beide gelukkig worden wanneer ik [review/whatever] moet doen?"

De eerste vraag zorgt dat je ze laat focussen op de negatieve impact die zij veroorzaakt hebben. En de tweede vraag zorgt ervoor dat zij een plan maken waarbij het positief voor beide is.

En mocht die persoon zo stom zijn door te zeggen: "Ik vraag eerst een ander" dan mag je hem duidelijk maken dat je die persoon ongelukkig maakt en dat jij daardoor ook ongelukkig wordt. En als die echt oliedom is en zegt "ik ga niemand wat vragen" dan mag je die er direct uit werken. Dat soort personen zijn giftig voor je team en je product.

[DevWouter]

Lethalis schreef op dinsdag 11 mei 2021 @ 13:19:
Er zijn natuurlijk ook hele goede software engineers, maar die zijn net zo zeldzaam als die chirurg. Ik reken mezelf daar ook niet toe trouwens

Het stomme is dat mijn collega's vaak denken dat ik die hele goede ontwikkelaar ben (leuk voor je ego, slecht voor je vaardigheden).

Maar voor mijn voelt het gewoon aan alsof ik dezelfde fouten maak als hun maar met iets meer structuur en op een stuk hoger tempo. Zo gooi ik vaker en sneller mijn eigen code weg en lijkt het alsof mijn eerste oplevering van een hogere standaard is. Verder laat ik ze vaak feedback geven en neem ik het mee, maar voor die aanpassing geven zij mij vaak ook de eer.

Het enige echt verschil is dat ik veel meer overzicht heb en daardoor beter begrijp welke impact mijn code heeft. Maar dat ligt ook aan mijn positie binnen de teams.

Ik snap nu wel steeds meer waar het argument/smoes "onvoldoende ervaring" vandaan komt.

[Mugwump]

Lethalis schreef op dinsdag 11 mei 2021 @ 13:19:
[...]

Een hersenchirurg heeft doorgaans ook een ander salaris en is een stuk zeldzamer dan de gemiddelde ingenieur, programmeur, whatever. You get what you pay for.

Er zijn natuurlijk ook hele goede software engineers, maar die zijn net zo zeldzaam als die chirurg. Ik reken mezelf daar ook niet toe trouwens Ik zie dan echt iemand voor me met een CS master die tig jaar ervaring heeft bij grote bedrijven en complexe architecturen.

En niet de gemiddelde Google-fu meester

Nou ja, het ging me ook meer om 'iedereen klooit maar wat aan'. En dat was nou ook juist mijn punt. In de IT kun je vaak ook prima aanklooien zonder consequenties. Als arts ligt dat toch wat problematischer en daarom wordt er aan de voorkant veel harder geselecteerd. "We kijken het wel even een maandje aan en als het niets wordt nemen we weer afscheid" kan net wat makkelijker als je software bouwt dan wanneer je

Het is op zich ook wel mooi dat er in de IT wat minder formele toelatingseisen zijn, want of je een afgeronde master hebt zegt niet altijd wat over je kwaliteiten. Kan er zelf over meepraten aangezien ik in een ver verleden tegelijk aan mijn doctoraalscriptie ben begonnen en gaan werken en vervolgens nooit meer de motivatie heb gehad om die scriptie af te ronden. De kennis van een CS master heb ik dus wel, het officiële papiertje niet.

[Mugwump]

DevWouter schreef op dinsdag 11 mei 2021 @ 13:24:

[...]

Jij ervaart meerdere problemen:
1. De gekozen oplossing voldoet niet aan jouw eisen.
2. De maker heeft onvoldoende nagedacht over de gevolgen van diens keuze
3. De maker probeert de schuld af te schuiven naar waar de code vandaan komt.

Mocht je het nog een keer meemaken vraag die persoon dan: "Begrijp jij waarom ik zo ongelukkig ben van deze code?" en volg die ongeacht diens antwoord op met "Wat zouden we kunnen doen om te zorgen dat we beide gelukkig worden wanneer ik [review/whatever] moet doen?"

De eerste vraag zorgt dat je ze laat focussen op de negatieve impact die zij veroorzaakt hebben. En de tweede vraag zorgt ervoor dat zij een plan maken waarbij het positief voor beide is.

En mocht die persoon zo stom zijn door te zeggen: "Ik vraag eerst een ander" dan mag je hem duidelijk maken dat je die persoon ongelukkig maakt en dat jij daardoor ook ongelukkig wordt. En als die echt oliedom is en zegt "ik ga niemand wat vragen" dan mag je die er direct uit werken. Dat soort personen zijn giftig voor je team en je product.

Ik geloof niet zo in de one-size-fits-all aanpak voor dit soort zaken. Hoe ik daar op reageer is persoonsafhankelijk. Bij de een is luiheid de oorzaak of een drang om maar zo snel mogelijk zaken af te krijgen, bij de ander is het gewoon pure incompetentie. De incompetente collega's zijn ook niet zelden mensen met 15-20 jaar 'ervaring' die er eigenlijk altijd mee weg zijn gekomen vanwege het tekort in de sector en daar ook mee weg blijven komen.

En dan is het ook nog weer de vraag wat de onderliggende oorzaak is. Wil iemand iets maar zo snel mogelijk afronden omdat het zijn werkwijze is die je moet zien te doorbreken, is het een kwestie van druk die ze (vaak ten onrechte) ervaren en ga zo maar door.

Bovendien hangt het allemaal erg af van hoe en wat je specificeert. Het project waar ik nu op zit is een compleet herontwerp van een vrij complex systeem waarbij een deel van de mensen het bestaande systeem heel goed kent, een deel wat minder en er grote verschillen in kennis en kunde zijn. Gevolg daarvan is dat je weer een beetje moet schipperen met de mate van detail en uitwerking van specificaties. Het is voor mij ook altijd de vraag of ik dan juist weer van te voren heel diep moet gaan doorvragen of iedereen echt snapt wat er moet gebeuren, of de boel wat meer op z'n beloop moet laten en mensen keuzes laten maken waardoor ze uiteindelijk 2x zo lang bezig zijn, maar er wel weer wat meer van opsteken wellicht.

[RagingPenguin]

Lethalis schreef op dinsdag 11 mei 2021 @ 12:02:
[...]

Van roldeuren die naar beneden kwamen zeilen, stalen constructies en hele daken die instorten, tot en met dingen die gewoon helemaal niet klopten en / of onmogelijk waren om te monteren

Verschil is alleen wel dat dat direct zichtbaar is. Bij software ontwikkeling komt het geklooi vaak pas een jaar later boven tafel.

[DevWouter]

RagingPenguin schreef op dinsdag 11 mei 2021 @ 17:03:
[...]


Verschil is alleen wel dat dat direct zichtbaar is. Bij software ontwikkeling komt het geklooi vaak pas een jaar later boven tafel.

Nou... Het is vaak al meerdere jaren boven tafel, maar het moment dat het pand instort dat kan je uitstellen door te stutten.

[RagingPenguin]

DevWouter schreef op dinsdag 11 mei 2021 @ 17:06:
[...]


Nou... Het is vaak al meerdere jaren boven tafel, maar het moment dat het pand instort dat kan je uitstellen door te stutten.

Maar bij digitale bouwwerken hoeft de klant en management geen slalom te doen om de schroefstempels die midden in de gang staan

[R4gnax]

DevWouter schreef op dinsdag 11 mei 2021 @ 13:24:
Dat is ook de reden waarom dat sommige developers niet in contact mogen komen met de stakeholder/klant/gebruiker. Zij begrijpen die persoon letterlijk niet. En een ontwikkelaar die niet maakt waar om gevraagd wordt levert een negatief rendament op.

Ter verdediging van software developers alom: soms -- waarschijnlijk meestal zelfs -- ligt het werkelijke probleem niet bij hen, maar heb je te maken met een gevalletje: "wij willen graag een rode lijn getekend met groene inkt."


Trouwens: even hand opsteken als die sketch pijnlijk persoonlijk herkenbaar is?
:: steekt hand op ::

[ Voor 8% gewijzigd door R4gnax op 11-05-2021 17:17 ]

[Lethalis]

RagingPenguin schreef op dinsdag 11 mei 2021 @ 17:03:
[...]
Verschil is alleen wel dat dat direct zichtbaar is. Bij software ontwikkeling komt het geklooi vaak pas een jaar later boven tafel.

Was dat maar zo

Een dak van een gebouw kan ook pas instorten op het moment dat er zich een bepaalde conditie voordoet, zoals dat er sneeuw op ligt. Of een brug die gaat trillen als het gaat waaien, om maar een bekend voorbeeld te noemen (Erasmusbrug).

Of zoals in ons nieuwe kantoorpand, dat de airco's bevriezen die helaas ook gebruikt worden om het kantoor te verwarmen Ik blij dat we tegenwoordig veel thuiswerken

Natuurlijk heb je precies hetzelfde bij software ontwikkeling. Vaak in verband met de schaalbaarheid. Dus dat de problemen pas gaan opvallen zodra er meer gebruik van wordt gemaakt.

Ja, en soms heb je die ene bizarre bug die aan je gemeld wordt en waar je aan de code comments kan zien dat hij er al sinds 2009 inzit. Ach ja, kleinigheden hou je altijd

[thlst]

De software ontwikkeling aanpak voor een brug

Imagine joining an engineering team. You’re excited and full of ideas, probably just out of school and a world of clean, beautiful designs, awe-inspiring in their aesthetic unity of purpose, economy, and strength. You start by meeting Mary, project leader for a bridge in a major metropolitan area. Mary introduces you to Fred, after you get through the fifteen security checks installed by Dave because Dave had his sweater stolen off his desk once and Never Again. Fred only works with wood, so you ask why he’s involved because this bridge is supposed to allow rush-hour traffic full of cars full of mortal humans to cross a 200-foot drop over rapids. Don’t worry, says Mary, Fred’s going to handle the walkways. What walkways? Well Fred made a good case for walkways and they’re going to add to the bridge’s appeal. Of course, they’ll have to be built without railings, because there’s a strict no railings rule enforced by Phil, who’s not an engineer.

https://www.stilldrinking.org/programming-sucks

[armageddon_2k1]

R4gnax schreef op dinsdag 11 mei 2021 @ 17:15:
[...]


Ter verdediging van software developers alom: soms -- waarschijnlijk meestal zelfs -- ligt het werkelijke probleem niet bij hen, maar heb je te maken met een gevalletje: "wij willen graag een rode lijn getekend met groene inkt."


Trouwens: even hand opsteken als die sketch pijnlijk persoonlijk herkenbaar is?
:: steekt hand op ::

Maak daar maar gewoon alle beroepen van die iets moeten maken in opdracht. Nondeju ik heb wat meegemaakt met die minkukels van marketing bij m’n vorige werk

- “We willen graag dat het product smartness heeft”
- “Ok, en wat is smartness?”
- “Iets met Bluetooth”
- “Wat dan?”
- “Iets met een app”
- “Maar moeten ze hun telefoon dat vasthouden tijdens gebruik?”
- “Ja zodat we real-time data kunnen laten zien in de app en wij data kunnen verzamelen”
- “Dat gaat de FDA niet zo leuk vinden enneh.... je hebt twee handen nodig om het apparaat vast te houden”
- “Dan leveren we een telefoon standaard mee”
- “uh... voor alle soorten telefoons? En een beetje raar niet?”
- “Gewoon voor iPhones. Onze target demographic zijn affluente hoogopgeleide Europeanen en Amerikanen”
- “Kostprijs gaat met Bluetooth wel al zo’n 15 dollar omhoog”
- “Nee, het moet goedkoper zijn dat de huidige best in class van de concurrentie”

Dit is geen grap. Wel wat samengevat want het was een meeting van een uur maar dan nog...

Geen wonder dat ik schreeuwend in de auto zat soms.

Of die ene keer dat zo’n marketing genie een apparaat wilde dat te steriliseren was maar dan op kamertemperatuur. Godverdomme ik word er weer boos van als ik bedenk dat ik heb moeten uitleggen dat sterilisatie een nogal beschermd geheel is om te claimen dat je steriliseert en toch echt minstens 100 graden en eventueel druk nodig heeft. Kwamen ze met infrarood als tip. Infrarood!!

Of die ene keer dat er BPA vrij op de verpakking MOEST. Maar ik gaf aan dat het nonsens is want, hij is BPA vrij maar het doet niet terzake, want het product komt niet in de mond. Nou het moest erop! Het MOEST! Toen hebben we gevraagd waarom er niet asbest vrij op kon dan. Nee, dat sloeg nergens op. Enfin erop gezet en ja hoor, 3 maanden later een instantie op ons dak dat dat niet mocht.

Of die ene keer dat de Senior Category Marketing Lead verkondigde aan alle 300 medewerkers dat DECT niet meer mocht als draadloos commmunicatie medium tussen producten want digitale straling was niet gezond had ze gelezen ergens. Nu alles Bluetooth. Maakt niet uit dat DECT veeeeel verder reikt dan Bluetooth overigens.....

Of die ene keer dat we erachter kwamen dat alle project deadlines gebaseerd waren op een leveringswindow van een heeeeele grote Amerikaanse retailer. Toen een collega in Amerika was bleek dat we helemaal niet in de winkel stonden. Al vijf jaar werden we daar niet meer verkocht!!!

Ik ga even mediteren ik word weer boos.

Er werkten veel goede mensen maar die marketeers.... godverdetering. Er was er eentje die was echt goed en die deed 95% van al het werk. De rest waren echt waardeloze types. Echt waardeloos. En dan kan je nog zo goed communiceren, en in een professionele setting kan ik dat volgens mij wel, maar op gegeven moment heb je gewoon zin hun banden lek te prikken.

[ Voor 35% gewijzigd door armageddon_2k1 op 11-05-2021 20:02 ]

[Skyaero]

armageddon_2k1 schreef op dinsdag 11 mei 2021 @ 19:50:
[...]

Maak daar maar gewoon alle beroepen van die iets moeten maken in opdracht. Nondeju ik heb wat
meegemaakt met die minkukels van marketing bij m’n vorige werk

Je geeft een technisch/rationeel antwoord naar iemand die niet technisch/rationeel is. Communicatie is de sleutel.

- “We willen graag dat het product smartness heeft”

Tuurlijk kan dat. We kunnen met machine learning de gebruiker persoonlijke suggesties doen.
<insert onzinnige feature die pretendeerd ML te gebruiken>

- "Gaaf! Tof!"

Of die ene keer dat er BPA vrij op de verpakking MOEST. Maar ik gaf aan dat het nonsens is want, hij is BPA vrij maar het doet niet terzake, want het product komt niet in de mond. Nou het moest erop! Het MOEST!

"Tuurlijk kunnen we BPA vrij op de verpakking zetten. Het staat mij bij dat hier strenge wetgeving over is. Zodra Legal akkoord is staat het erop.


Ik heb zelf ooit een klant gehad die er op stond dat er een app moest komen. Ik heb een student tegen een schappelijk bedrag een app laten maken en aan de klant gedemonstreerd. Klant was superblij en kon overal roepen dat ze ook een app hadden.

De enige twee smart phones waar de app ooit op geïnstalleerd was, was die van de student en die van de software engineer die het aan de klant heeft gedemonstreerd.

Klant blij, wij blij.


Ik kan met een groene marker zeven rode parallelle lijnen tekenen. Geen probleem.

[ Voor 20% gewijzigd door Skyaero op 11-05-2021 22:53 ]

[gekkie]

Skyaero schreef op dinsdag 11 mei 2021 @ 22:50:
[...]
Je geeft een technisch/rationeel antwoord naar iemand die niet technisch/rationeel is. Communicatie is de sleutel.
[...]
Tuurlijk kan dat. We kunnen met machine learning de gebruiker persoonlijke suggesties doen.
<insert onzinnige feature die pretendeerd ML te gebruiken>

- "Gaaf! Tof!"
[...]
"Tuurlijk kunnen we BPA vrij op de verpakking zetten. Het staat mij bij dat hier strenge wetgeving over is. Zodra Legal akkoord is staat het erop.

Vooral een sleutel om er zelf (tijdelijk) vanaf te zijn, maar vaak hebben dat soort lui alle gaven van een boomerang.

[armageddon_2k1]

@Skyaero jij hebt duidelijk alle antwoorden. Ik ken nog wel een leuk bedrijf waar je kan gaan werken.

[Mugwump]

Skyaero schreef op dinsdag 11 mei 2021 @ 22:50:
Ik kan met een groene marker zeven rode parallelle lijnen tekenen. Geen probleem.

Parallel is de uitdaging ook niet hè? Ze moeten loodrecht zijn. Parallel kunnen we allemaal wel.

[Douweegbertje]

Skyaero schreef op dinsdag 11 mei 2021 @ 22:50:
[...]

Ik heb zelf ooit een klant gehad die er op stond dat er een app moest komen. Ik heb een student tegen een schappelijk bedrag een app laten maken en aan de klant gedemonstreerd. Klant was superblij en kon overal roepen dat ze ook een app hadden.

De enige twee smart phones waar de app ooit op geïnstalleerd was, was die van de student en die van de software engineer die het aan de klant heeft gedemonstreerd.

Klant blij, wij blij.


Ik kan met een groene marker zeven rode parallelle lijnen tekenen. Geen probleem.

Ik word zelf niet blij om lucht te verplaatsen. Als ik het kostbaarste in mijn leven (lees: tijd) gebruik, dan wil ik toegevoegde waarde bieden voor een persoon, bedrijf, wereld, whatever.

Misschien is dit heel zweverig, maar ik word er dus niet gelukkig van om zoiets te doen. Er valt ook nog iets te zeggen onder dat mom van communicatie, dat je de klant dit ook uitlegt.

Moet je iedereen dan blij maken? Stel dat iemand met een lekkere sliert spinazie tussen z'n tanden loopt. "Hoe zie ik er uit?" - Oh, ja geweldig, helemaal top. Dan is die gene blij. Die gene staat alleen wel voor lul. Mooi, klant blij.

Anyhow, dat is mijn mening

[DevWouter]

Skyaero schreef op dinsdag 11 mei 2021 @ 22:50:
Ik heb zelf ooit een klant gehad die er op stond dat er een app moest komen. Ik heb een student tegen een schappelijk bedrag een app laten maken en aan de klant gedemonstreerd. Klant was superblij en kon overal roepen dat ze ook een app hadden.

De enige twee smart phones waar de app ooit op geïnstalleerd was, was die van de student en die van de software engineer die het aan de klant heeft gedemonstreerd.

Klant blij, wij blij.

In die categorie ken ik ook een mooie.

Mijn collega en ik zitten bij de klant waar we aanpassingen gedaan hadden en we waar het lijstje aan het afvinken. Een lijntje was aangepast van 3 pixels breed naar 1 pixel, maar desondanks werd er gevraagd of het nog dunner kan. Halverwege de uitleg van mijn collega dat je van 1 alleen nog maar 0 kan gaan draai ik me laptop op en vroeg of de lijn in mijn aanpassing dun genoeg was. Klant blij, wij blij.

spoiler: hoe het probleem was opgelost

Het probleem was NIET dat de lijn te dik was. Het probleem was dat lijn te prominent aanwezig was. Door het contrast te verminderen van wit-op-zwart naar een grijs-op-zwart lijkt de lijn minder dik.

Ik kan met een alleen rechte lijnen een cirkel tekenen. Geen probleem.

[Skyaero]

gekkie schreef op dinsdag 11 mei 2021 @ 22:55:
[...]
Vooral een sleutel om er zelf (tijdelijk) vanaf te zijn, maar vaak hebben dat soort lui alle gaven van een boomerang.

Nee, niet om er tijdelijk van af te zijn. Lees de voorbeelden nog eens door. Het is elke keer de engineer/softwareontwikkelaar die de hakken in het zand zet. Dat werkt gewoon niet. Je moet meegaan met de klant en de 'vraag achter de vraag' achterhalen. Waarom wil de klant een rode lijn met een groene marker tekenen?

Zie ook het prachtige voorbeeld van @DevWouter van de klant die een lijn van een halve pixel wilt hebben (de vraag), terwijl het ze eigenlijk ging om de aanwezigheid van de lijn (de vraag achter de vraag). De klant weet niets van UI/UX en dat je naast de dikte van de lijn nog 20 parameters hebt om daar mee te spelen. DAT is jouw werk.

Idem dito met het verhaal van de marketing afdeling. Marketing (maar ook alle andere aspecten binnen een business) is gewoon een serieuze zaak. Ik snap prima dat een marketing iets 'smart' wilt hebben. Dat adverteert namelijk uitstekend. Kijk eens om je heen, bijna alles is tegenwoordig 'smart'.

Er wordt hier geregeld verweten dat managers, marketeers en klanten niets snappen van IT/techniek. Toch zie ik ook veelvuldig het omgekeerde in dit topic (en daarbuiten): IT-ers/ingenieurs die eigenlijk maar weinig begrijpen wat andere onderdelen in de business doen en waarom zij bepaalde vragen stellen. Soms moet je gewoon even zelf in de spiegel kijken in plaats van wijzen naar anderen.

Douweegbertje schreef op woensdag 12 mei 2021 @ 13:56:
[...]
Misschien is dit heel zweverig, maar ik word er dus niet gelukkig van om zoiets te doen. Er valt ook nog iets te zeggen onder dat mom van communicatie, dat je de klant dit ook uitlegt.

Ik val nu een beetje in herhaling. Communicatie met de klant of businessafdeling start niet met de hakken in het zand als zij een verzoek doen. "Het kan niet", "het is nonense", "maar wat is dat dan?" als antwoord op een vraag levert geen oplossing en wel frustratie op.

Douweegbertje schreef op woensdag 12 mei 2021 @ 13:56:
[...]
Ik word zelf niet blij om lucht te verplaatsen. Als ik het kostbaarste in mijn leven (lees: tijd) gebruik, dan wil ik toegevoegde waarde bieden voor een persoon, bedrijf, wereld, whatever.

Toegevoegde waarde vanuit welk perspectief? Dat wat jij niets vind toevoegen kan voor een ander heel waardevol zijn.

[ Voor 9% gewijzigd door Skyaero op 12-05-2021 14:50 ]

[Woy]

Skyaero schreef op woensdag 12 mei 2021 @ 14:48:
[...]
Er wordt hier geregeld verweten dat managers, marketeers en klanten niets snappen van IT/techniek. Toch zie ik ook veelvuldig het omgekeerde in dit topic (en daarbuiten): IT-ers/ingenieurs die eigenlijk maar weinig begrijpen wat andere onderdelen in de business doen en waarom zij bepaalde vragen stellen. Soms moet je gewoon even zelf in de spiegel kijken in plaats van wijzen naar anderen.

Exact, juist door de dialoog te openen, en alternatieven aan te dragen die mogelijk makkelijker/beter zijn, en te valideren of dat ook aan de wensen voldoet schiet je een hoop op. Overigens is die hakken in het zand niet alleen vanaf de kant van IT'ers, maar als je aan die kant zit kan je hooguit proberen om in gesprek te gaan.

Ik heb vaak dat een klant X vraagt, waarop ik dan antwoord: Is Y ook goed, dat is in 50% van de tijd te bewerkstelligen, en ik heb het vermoeden dat dat ook je probleem oplost. Dan kan de klant ja of nee zeggen, maar in het geval van nee is het ook weer makkelijker te verkopen dat het meer tijd/geld kost.

[DevWouter]

Skyaero schreef op woensdag 12 mei 2021 @ 14:48:
Er wordt hier geregeld verweten dat managers, marketeers en klanten niets snappen van IT/techniek. Toch zie ik ook veelvuldig het omgekeerde in dit topic (en daarbuiten): IT-ers/ingenieurs die eigenlijk maar weinig begrijpen wat andere onderdelen in de business doen en waarom zij bepaalde vragen stellen. Soms moet je gewoon even zelf in de spiegel kijken in plaats van wijzen naar anderen.

[...]

Ik val nu een beetje in herhaling. Communicatie met de klant of businessafdeling start niet met de hakken in het zand als zij een verzoek doen. "Het kan niet", "het is nonense", "maar wat is dat dan?" als antwoord op een vraag levert geen oplossing en wel frustratie op.

[...]

Toegevoegde waarde vanuit welk perspectief? Dat wat jij niets vind toevoegen kan voor een ander heel waardevol zijn.

Inderdaad. Heb nu al vaak genoeg meegemaakt dat een ontwikkelaar roept dat iets niet om vervolgens die persoon een paar uur later zijn woorden terug te laten nemen omdat ik heb bewezen dat het wel kan.

Het is inmiddels zo erg dat ik soms nieuwe klanten moet overtuigen dat het wel kan en dat ontwikkelaars dat zeggen wanneer het onmogelijk is, maar dat het waarschijnlijker is dat ze geen zin hebben.

[Jory]

Skyaero schreef op woensdag 12 mei 2021 @ 14:48:
[...]
De klant weet niets van UI/UX

Ach de gemiddelde software ontwikkelaar ook niet hoor.

[gekkie]

Skyaero schreef op woensdag 12 mei 2021 @ 14:48:
[...]
Nee, niet om er tijdelijk van af te zijn. Lees de voorbeelden nog eens door. Het is elke keer de engineer/softwareontwikkelaar die de hakken in het zand zet. Dat werkt gewoon niet. Je moet meegaan met de klant en de 'vraag achter de vraag' achterhalen. Waarom wil de klant een rode lijn met een groene marker tekenen?

Daar matchen je gegeven "oplossingen" bij die voorbeelden dan weer niet bij wat mij betreft, meegaan in eventueel onbegrip en marketingsaus van je collega's. Ik zag daar totaal niets in van doorvragen en een "vraag achter de vraag".
Dat zie ik eerder als erg tijdelijk en als een boomerang weer een keertje terug komen, maar goed smaken verschillen.

[Douweegbertje]

Skyaero schreef op woensdag 12 mei 2021 @ 14:48:
[...]

[...]


Ik val nu een beetje in herhaling. Communicatie met de klant of businessafdeling start niet met de hakken in het zand als zij een verzoek doen. "Het kan niet", "het is nonense", "maar wat is dat dan?" als antwoord op een vraag levert geen oplossing en wel frustratie op.


[...]

Toegevoegde waarde vanuit welk perspectief? Dat wat jij niets vind toevoegen kan voor een ander heel waardevol zijn.

Je geeft dit toch zelf aan:

De enige twee smart phones waar de app ooit op geïnstalleerd was, was die van de student en die van de software engineer die het aan de klant heeft gedemonstreerd.

Moet ik hier nu echt extra context bij geven?

[RagingPenguin]

Woy schreef op woensdag 12 mei 2021 @ 15:07:
[...]

Exact, juist door de dialoog te openen, en alternatieven aan te dragen die mogelijk makkelijker/beter zijn, en te valideren of dat ook aan de wensen voldoet schiet je een hoop op. Overigens is die hakken in het zand niet alleen vanaf de kant van IT'ers, maar als je aan die kant zit kan je hooguit proberen om in gesprek te gaan.

Ik heb vaak dat een klant X vraagt, waarop ik dan antwoord: Is Y ook goed, dat is in 50% van de tijd te bewerkstelligen, en ik heb het vermoeden dat dat ook je probleem oplost. Dan kan de klant ja of nee zeggen, maar in het geval van nee is het ook weer makkelijker te verkopen dat het meer tijd/geld kost.

Nu vraagt dit natuurlijk ook wel om een gezonde relatie en houding aan de andere kant van de tafel. Ik kan mij prima voorstellen dat er bedrijven en culturen zijn waar communicatie tussen verschillende afdelingen ongeveer hetzelfde verloopt als de volgende Noord-Korea top

Toevoeging: ik zie dit zelf nog wel eens fout gaan als we met een klant werken waar de PO net promotie heeft gemaakt naar een 'management-rol' en aan zijn baas wil laten zien hoe goed die wel niet kan onderhandelen met leveranciers (of bang is om de controle over de scope te verliezen). Vaak krijg je dan ergens een escalatie waarin het dan wel weer goed komt (maar leuk is anders).

[ Voor 15% gewijzigd door RagingPenguin op 12-05-2021 17:04 ]

[Hydra]

armageddon_2k1 schreef op woensdag 12 mei 2021 @ 06:54:
@Skyaero jij hebt duidelijk alle antwoorden. Ik ken nog wel een leuk bedrijf waar je kan gaan werken.

Volgens mij hebben jullie beiden gewoon gelijk maar kijken jullie er vanuit compleet andere standpunten naar. Natuurlijk zijn sommige dingen gewoon onmogelijk. Je kunt wel beweren dat je 7 rode lijnen kunt tekenen met een groene marker, maar ben je dan niet gewoon een klant aan het oplichten? Ik heb ook wel eens te maken gehad met een klant die software wou laten bouwen, maar die ik er uiteindelijk op gewezen heb dat er al een SaaS oplossing was die 95% van wat 'ie wou al kon. Toch weer blij dat 'ie een halve ton geld bespaard had. Account manager was minder blij, maargoed, niet mijn probleem.

Aan de andere kant komt het ook wel erg vaak voor dat "dat kan niet" gewoon een gevalletje "ik weet niet hoe" is. Daar betrap ik developers wel vaak op dat als ze niet weten hoe dat het dus niet kan. Of dat ze niet doorvragen naar wat een gebruiker nu precies wil. Heel vaak blijkt wat gebruikers willen gebaseerd te zijn op wat ze denken dat kan, vanuit ervaringen met vroeger (vaak met inflexibele partijen). Ik neem dan graag een stap terug en ga met ze kijken hoe voor hen het optimale proces eruit zou zien, en of en hoe we daar kunnen komen.

[DevWouter]

gekkie schreef op woensdag 12 mei 2021 @ 15:45:
[...]

Daar matchen je gegeven "oplossingen" bij die voorbeelden dan weer niet bij wat mij betreft, meegaan in eventueel onbegrip en marketingsaus van je collega's. Ik zag daar totaal niets in van doorvragen en een "vraag achter de vraag".
Dat zie ik eerder als erg tijdelijk en als een boomerang weer een keertje terug komen, maar goed smaken verschillen.

De klant heeft dan een bedrijfsrisico genomen die verkeerd uitpakt, maar dat is zijn taak en verantwoordelijkheid. Het alternatief scenario was dat de ontwikkelaars de keuze voor het bedrijf bepaalt en die hebben de taak en verantwoording niet. Overigens had de klant het wel gemotiveerd en dat is namelijk dat zonder app het product onwaarschijnlijk verkocht wordt.

De keren dat ik het als ontwikkelaar beter wist dan bedrijfsvoerend personeel is net zo laag of zelfs lager dan dat een klant een technische oplossing voor een bug aanlevert.

[armageddon_2k1]

@Hydra Oh je hebt gelijk hoor en het was waarschijnlijk ook een stuk onervarenheid van mijn kant en de wisselwerking met de marketeers. Nadeel was alleen dat de marketeers een stuk hoger in de organisatie stonden.

Maar ik reageerde er een beetje op Skyaero omdat die deed blijken of het allemaal zo simpel is. Soms is dat gewoon niet zo en is het gewoon slikken geblazen.

Een groot probleem was dat opdrachtgevers (marketing) in oplossingen dachten ipv een vraag vanuit de markt. Bluetooth is een oplossing. “Smartness” is een oplossing.

[gekkie]

DevWouter schreef op woensdag 12 mei 2021 @ 17:33:
[...]
De klant heeft dan een bedrijfsrisico genomen die verkeerd uitpakt, maar dat is zijn taak en verantwoordelijkheid. Het alternatief scenario was dat de ontwikkelaars de keuze voor het bedrijf bepaalt en die hebben de taak en verantwoording niet. Overigens had de klant het wel gemotiveerd en dat is namelijk dat zonder app het product onwaarschijnlijk verkocht wordt.

De keren dat ik het als ontwikkelaar beter wist dan bedrijfsvoerend personeel is net zo laag of zelfs lager dan dat een klant een technische oplossing voor een bug aanlevert.

Ik vind het best joh, vooral doen en doorgaan !

[Koenvh]

Daarvoor kun je natuurlijk ook een extra clausule opnemen, iets als:

Koen heeft het recht om tegen de Opdrachtgever te zeggen "zie je nou wel?" als de Voorspelling uitkomt.

(Overigens vind ik het wel bijzonder hoe veel direct klantcontact jullie klaarblijkelijk hebben)

[DevWouter]

Koenvh schreef op woensdag 12 mei 2021 @ 18:39:
(Overigens vind ik het wel bijzonder hoe veel direct klantcontact jullie klaarblijkelijk hebben)

Helaas nog steeds minder dan je verwacht, maar nummer 4 op het agile manifesto is "Business people and developers must work together daily throughout the project" en nummer 6 is "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation".

Ik vind het opvallend hoeveel agile-coaches niet de inhoud kennen van het manifest terwijl ze beweren dat hun methode "agile" is. Het is vaak het eerste wat ik moet fixen.

[Hydra]

Koenvh schreef op woensdag 12 mei 2021 @ 18:39:
Daarvoor kun je natuurlijk ook een extra clausule opnemen, iets als:

Ik doe dat toch wel, clausule of niet

[Hydra]

DevWouter schreef op woensdag 12 mei 2021 @ 19:05:
Helaas nog steeds minder dan je verwacht, maar nummer 4 op het agile manifesto is "Business people and developers must work together daily throughout the project" en nummer 6 is "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation".

Ik vind het opvallend hoeveel agile-coaches niet de inhoud kennen van het manifest terwijl ze beweren dat hun methode "agile" is. Het is vaak het eerste wat ik moet fixen.

Veel mensen zijn vanuit opgeheven rollen als project manager "dan maar" agile coach geworden. Even een certficaatje halen (soms dat al niet eens) en gewoon doorgaan op dezelfde voet. Die mensen zijn vaak ook helemaal dol op SAFe (braak) omdat ze dan weer lekker met regeltjes en procesjes aan de slag kunnen.

[PrisonerOfPain]

Koenvh schreef op woensdag 12 mei 2021 @ 18:39:
(Overigens vind ik het wel bijzonder hoe veel direct klantcontact jullie klaarblijkelijk hebben)

De klanten zit bij ons rechtstreeks in Slack (het zijn ook developers), maar goed, een kort lijntje naar de klant is voor ons de enige manier om effectief te bouwen.

[.oisyn]

Heh, een spammailtje dat door de Google filters heen komt. Blijkbaar gebruiken de spammers het contactformulier van het Rivermill Event Centre, die je een bevestiging stuurt van je emailtje met daarin het bericht wat je hebt verstuurd.

[Mugwump]

PrisonerOfPain schreef op woensdag 12 mei 2021 @ 19:24:
[...]


De klanten zit bij ons rechtstreeks in Slack (het zijn ook developers), maar goed, een kort lijntje naar de klant is voor ons de enige manier om effectief te bouwen.

Ja ik had vorige week weer een mooi voorbeeldje van het tegenovergestelde. Klant waar ze denken dat een logge architectuurclub die vanuit hun ivoren toren van alles bedenkt in combinatie met wat eigen 'tech leads' die eigenlijk ook totaal losgezongen zijn van de inhoud hadden voor een ander project even bedacht hoe de nieuwe architectuur eruit moest komen te zien. Andere team had daar ook al een jaar aan gebouwd ofzo. Na een overlegje met mij en nog een andere dev uit ons team bleek dat ze de helft van de functionele scope over het hoofd hadden gezien en daardoor bovendien ook met de huidige bedachte oplossing totaal niet konden voldoen aan de daadwerkelijke non-functionals. Terug naar de tekentafel.

[Koenvh]

.oisyn schreef op vrijdag 14 mei 2021 @ 12:17:
Heh, een spammailtje dat door de Google filters heen komt. Blijkbaar gebruiken de spammers het contactformulier van het Rivermill Event Centre, die je een bevestiging stuurt van je emailtje met daarin het bericht wat je hebt verstuurd.

Wel creatief bedacht. Ik krijg vooral spam via Google Docs, waar ik dan getagd ben, en dus een e-mail krijg. Vond het leuk bedacht, maar niet erg overtuigend

[Neverwinterx]

Skyaero schreef op dinsdag 11 mei 2021 @ 22:50:
[...]


Je geeft een technisch/rationeel antwoord naar iemand die niet technisch/rationeel is. Communicatie is de sleutel.


[...]

Tuurlijk kan dat. We kunnen met machine learning de gebruiker persoonlijke suggesties doen.
<insert onzinnige feature die pretendeerd ML te gebruiken>

- "Gaaf! Tof!"


[...]

Communicatie is de sleutel? Blijkbaar bedoel je met communicatie leugens?

[AW_Bos]

Tijd voor een nieuw project: Verbeteren van het adminpaneel van mijn site.

Huidige pijnpunten:
Obsolete code, slecht onderhoud, geen consistentie in acties, niet responsive....

Tijd voor actie .
En dat allemaal gebaseerd op AdminLTE3

[ Voor 9% gewijzigd door AW_Bos op 17-05-2021 00:28 ]

[Hydra]

AW_Bos schreef op maandag 17 mei 2021 @ 00:27:
Huidige pijnpunten:
Obsolete code, slecht onderhoud, geen consistentie in acties, niet responsive....

Ik zou eerst de verantwoordelijke developer ontslaan.

[AW_Bos]

Hydra schreef op maandag 17 mei 2021 @ 11:10:
[...]


Ik zou eerst de verantwoordelijke developer ontslaan.

Maak je mij nu werkloos?

_{Gelukkig kan ik nu betere dingen bouwen dan 12 jaar geleden i.p.v. door de tijd heen enkel te patchen....}

[ Voor 23% gewijzigd door AW_Bos op 17-05-2021 11:56 ]

[ElkeBxl]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Koenvh]

AW_Bos schreef op maandag 17 mei 2021 @ 11:54:
[...]

Maak je mij nu werkloos?

_{Gelukkig kan ik nu betere dingen bouwen dan 12 jaar geleden i.p.v. door de tijd heen enkel te patchen....}

Moet je natuurlijk ook de tijd voor hebben (en krijgen). Ik heb ook nog een paar projecten waar ik delen van wil herstructureren, simpelweg omdat de scope in de tussentijd zo veranderd is dat de keuzes uit het verleden niet meer zo goed aansluiten... Maar ja, tijd.

[Voutloos]

ElkeBxl schreef op donderdag 20 mei 2021 @ 16:45:
***members only***

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[gekkie]

ElkeBxl schreef op donderdag 20 mei 2021 @ 16:45:
***members only***

Poeh lang verhaal. Is er de mogelijkheid om even langs een terrasje te zeilen voor een flinke tas Dokkumer-koffie met een Frysk dúmke ?

[Koenvh]

gekkie schreef op donderdag 20 mei 2021 @ 18:34:
[...]

Poeh lang verhaal. Is er de mogelijkheid om even langs een terrasje te zeilen voor een flinke tas Dokkumer-koffie met een Frysk dúmke ?

Je dacht, het reilen is er al, dus nu alleen nog het zeilen?

[gekkie]

Koenvh schreef op donderdag 20 mei 2021 @ 19:54:
[...]
Je dacht, het reilen is er al, dus nu alleen nog het zeilen?

Ze hees zelf de zeilen , dus ik was al wel in de stemming .

[bwerg]

ElkeBxl schreef op donderdag 20 mei 2021 @ 16:45:
***members only***

Oke, en wat doen ze als je op een camping zonder internetverbinding zit?

Kijk, als er nou onvoorziene problemen zijn waarbij jij de persoon bent die dat het beste kan oplossen...

[ Voor 19% gewijzigd door bwerg op 20-05-2021 21:12 ]

[Motrax]

Sharepoint. Sterf een langzame dood. 26k files in een lijst. Max 5k is tegelijk te bereiken en dan moet je gaan filteren.

Ik dacht even met een Azure Logic App de bestanden te downloaden (low code heh), maar de connector ondersteunt geen queries.

500 bestanden moet er maar gedownload worden. Maar... dat kak sharepoint staat maar toe om max 100 bestanden te selecteren en dan kan je ze ook niet in 1x download. Wat een brakke hack is dat toch.

Sterfffffffff

[ Voor 27% gewijzigd door Motrax op 20-05-2021 22:06 ]

[mcDavid]

bwerg schreef op donderdag 20 mei 2021 @ 21:12:
[...]

Oke, en wat doen ze als je op een camping zonder internetverbinding zit?

Kijk, als er nou onvoorziene problemen zijn waarbij jij de persoon bent die dat het beste kan oplossen...

Als mensen mijn werk deployen zonder dat met mij te overleggen en zonder ik erbij ben?

Geen idee maar dat zoeken ze dan maar lekker zelf uit

[Evilbee]

Motrax schreef op donderdag 20 mei 2021 @ 21:55:
Sharepoint. Sterf een langzame dood. 26k files in een lijst. Max 5k is tegelijk te bereiken en dan moet je gaan filteren.

Ik dacht even met een Azure Logic App de bestanden te downloaden (low code heh), maar de connector ondersteunt geen queries.

500 bestanden moet er maar gedownload worden. Maar... dat kak sharepoint staat maar toe om max 100 bestanden te selecteren en dan kan je ze ook niet in 1x download. Wat een brakke hack is dat toch.

Sterfffffffff

Sync die map met OneDrive naar server/pc/laptop. Heb je het inclusief mappen structuur lokaal staan.

[Motrax]

Evilbee schreef op donderdag 20 mei 2021 @ 22:25:
[...]

Sync die map met OneDrive naar server/pc/laptop. Heb je het inclusief mappen structuur lokaal staan.

Wat. Die had ik niet aan zien komen. Hij is nu 40k files aan het syncen naar mijn laptop, die laat ik even een nachtje doorratelen. Morgen alle bestanden terug jenken naar Azure blob storage waar ze sowieso hadden moeten staan en niet alleen in Sharepoint...

Held. Zo kan ik mijn avond nog goed afsluiten

En het was echt alleen maar als rant bedoeld tegen Sharepoint

[Koenvh]

Motrax schreef op donderdag 20 mei 2021 @ 22:41:
[...]
Wat. Die had ik niet aan zien komen. Hij is nu 40k files aan het syncen naar mijn laptop, die laat ik even een nachtje doorratelen. Morgen alle bestanden terug jenken naar Azure blob storage waar ze sowieso hadden moeten staan en niet alleen in Sharepoint...

Held. Zo kan ik mijn avond nog goed afsluiten

En het was echt alleen maar als rant bedoeld tegen Sharepoint

Zo werkt dat toch? "Software X is echt %@$!, want <reden>" "Da's niet waar, want je kunt namelijk Y".

Overigens ondersteunt SharePoint volgens mij ook WebDAV

[Motrax]

Koenvh schreef op vrijdag 21 mei 2021 @ 02:01:
[...]

Zo werkt dat toch? "Software X is echt %@$!, want <reden>" "Da's niet waar, want je kunt namelijk Y".

Overigens ondersteunt SharePoint volgens mij ook WebDAV

Mjaaaa... Sharepoint is wel een klasse apart. Traag. Werkt altijd ruk in de GUI, maar er is geen beter alternatief.

Gelukkig weet ik nu ook weer waarom ik Onedrive een klasse apart vind... 10k wijzigingen nu gesynchroniseerd in een nacht, nog 30k te gaan en het is een partij traag... gelukkig kan mijn laptop het weekend door ratelen.

Online blijkt alles er al te staan, dus wat mijn laptop client aan het doen is? Joost mag het weten.

En Online is dan ook weer een warboel in de GUI. In de link naar Sharepoint kan je wel downloaden, maar reageert niet na selectie van 1600 bestanden. Maar als je dan eerst de link aanmaakt in MyFiles en dan download, lukt het wel. Dan in de zip staan de bestanden met een wijzigingsdatum op GMT ipv CEST.

Brakke spullenboel.

Ik snap wel dat gebruikers helemaal de weg kwijt zijn in de digitale wereld.

[ Voor 28% gewijzigd door Motrax op 21-05-2021 06:19 ]

[ElkeBxl]

Voutloos schreef op donderdag 20 mei 2021 @ 17:17:
[...]

***members only***

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

gekkie schreef op donderdag 20 mei 2021 @ 18:34:
[...]

Poeh lang verhaal. Is er de mogelijkheid om even langs een terrasje te zeilen voor een flinke tas Dokkumer-koffie met een Frysk dúmke ?

Nog nooit gehoord van een Dokkumer-koffie of een Frysk dúmke... Maar als het koffie of bier is, count me in
Net eens opgezocht wat die Frysk dúmke is, ik zou het proberen maar ik verwacht er niet veel van omdat ik echt geen affiniteit heb met anijs.

mcDavid schreef op donderdag 20 mei 2021 @ 22:08:
[...]


Als mensen mijn werk deployen zonder dat met mij te overleggen en zonder ik erbij ben?

Geen idee maar dat zoeken ze dan maar lekker zelf uit

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Hydra]

mcDavid schreef op donderdag 20 mei 2021 @ 22:08:
Als mensen mijn werk deployen zonder dat met mij te overleggen en zonder ik erbij ben?

Is dat niet een stukje proces wat je vrij simpel aan kunt leggen? Bij ons kan alles wat 'klaar' is gewoon gedeployed worden, ongeacht wie het gemaakt hebt. De 'lanes' zijn To do > In process > In review > In test > Ready > Deployed.

[DevWouter]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[DevWouter]

Hydra schreef op vrijdag 21 mei 2021 @ 08:58:
[...]


Is dat niet een stukje proces wat je vrij simpel aan kunt leggen? Bij ons kan alles wat 'klaar' is gewoon gedeployed worden, ongeacht wie het gemaakt hebt. De 'lanes' zijn To do > In process > In review > In test > Ready > Deployed.

Inderdaad, continue waarde "opleveren" ipv "maken".

Eén van de dingen die ik tegenwoordig (bijna) eis is dat iedereen de build-scripts en deploy-scripts begrijpt en kan uitvoeren. Het is een relatief kleine barriere en je merkt hoe het denken van een ontwikkelaar verandert als die begrijpt dat zijn product ook online staat en wat de impact is.

[mcDavid]

Hydra schreef op vrijdag 21 mei 2021 @ 08:58:
[...]


Is dat niet een stukje proces wat je vrij simpel aan kunt leggen? Bij ons kan alles wat 'klaar' is gewoon gedeployed worden, ongeacht wie het gemaakt hebt. De 'lanes' zijn To do > In process > In review > In test > Ready > Deployed.

Sure. Bij ons ziet de "straat" er iets anders uit maar als een MR klaar en approved is, mag die in principe live ja. Als het een grote change is zou ik dat alsnog wel het liefste zelf doen (of iig zelf bij zijn) maar als iemand anders er ownership voor wilt nemen, is dat natuurlijk prima. Maar dan verwacht ik dus wel dat die persoon dat ownership ook neemt, en niet mij gaat terugbellen van vakantie omdat'ie eigenwijs was

Daarnaast lees ik een beetje dat in dit geval de oplevering nog lang niet in het stadium "ready" stond.

[ElkeBxl]

Hydra schreef op vrijdag 21 mei 2021 @ 08:58:
[...]


Is dat niet een stukje proces wat je vrij simpel aan kunt leggen? Bij ons kan alles wat 'klaar' is gewoon gedeployed worden, ongeacht wie het gemaakt hebt. De 'lanes' zijn To do > In process > In review > In test > Ready > Deployed.

Dat is er, maar daar is ergens een miscommunicatie door iemand gebeurd waardoor het onterecht van In Test naar Ready is gegaan. Dan heb je weinig aan 'lanes' natuurlijk.

DevWouter schreef op vrijdag 21 mei 2021 @ 09:05:
***members only***

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

mcDavid schreef op vrijdag 21 mei 2021 @ 09:18:
[...]
Daarnaast lees ik een beetje dat in dit geval de oplevering nog lang niet in het stadium "ready" stond.

Klopt. Het was niet eens assigned aan het deploymentteam...

[ Voor 7% gewijzigd door ElkeBxl op 21-05-2021 09:25 ]

[Hydra]

mcDavid schreef op vrijdag 21 mei 2021 @ 09:18:
Daarnaast lees ik een beetje dat in dit geval de oplevering nog lang niet in het stadium "ready" stond.

Ik had het ook niet over dat specifieke geval hoor, meer in general. Dat was idd gewoon een fuckup waar "proces" je ook niet tegen beschermt. Gaat me er vooral om dat het wat mij betreft zo is dat in principe alle devs 'ready' dingen moeten kunnen deployen.

[DevWouter]

ElkeBxl schreef op vrijdag 21 mei 2021 @ 09:24:
[...]

***members only***

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

In ander nieuws: Als externe consult (en daar zit nog een bedrijf tussen) heb ik afgelopen week de "Senior IT Administrator" rol gekregen bij een grote klant terwijl ik half jaar geleden nog als "backend developer" aan hun geintroduceerd ben.

En ik maar continue roepen dat je software ontwikkelaars nooit admin rechten moet geven omdat het een stel idioten zijn die zonder te blozen je Active Directory weggooien.

Heb er even over nagedacht om de BOFH te worden

[gekkie]

ElkeBxl schreef op vrijdag 21 mei 2021 @ 08:11:
Nog nooit gehoord van een Dokkumer-koffie of een Frysk dúmke... Maar als het koffie of bier is, count me in
Net eens opgezocht wat die Frysk dúmke is, ik zou het proberen maar ik verwacht er niet veel van omdat ik echt geen affiniteit heb met anijs.

Neem een Ierse koffie, maar dan op z'n Fries, dus Berenburg ipv Whisky.
Hmm plak suikerbrood dan maar ipv een dúmke, daar kun je wel een dag op varen calorietechnisch, wel een mooi windje nu met 5 a 6 beaufort