De Devschuur Coffee Corner - Iteratie ⓫

[Mugwump]

armageddon_2k1 schreef op dinsdag 15 mei 2018 @ 08:05:
[...]


Nee, want ik heb zelden meegemaakt dat dat iets toevoegt...Een goede recruiter, een goede manager en HR persoon en je hebt al die peperdure assessments niet nodig :-) (okee, die mensen zijn ook duur). Daarnaast, mijn vrouw is psycholoog en kan me vertellen dat zelfs aan de meest ingewikkelde IQ en persoonlijkheids-tests zoveel haken en ogen zitten dat je bijna een PhD moet hebben om het een beetje te interpreteren

Zo kan ik me herinneren dat er iemand was bij ons die supergoed aansloot, maar z'n karakter was te 'geel' (insight kleurtjes voor de bekenden) en we hadden een roder persoon nodig..... tja

Ik ben ook geen voorstander van dat soort tests, maar dat was het punt natuurlijk niet. De vraag was of je tests per se zelf moet bedenken of dat je wat meer gestandaardiseerde varianten wilt pakken.
Wij hebben die discussies met HR over kleurtjes ook vaak genoeg afgekapt nadat we in onze ogen de perfecte kandidaat hadden, maar HR begon te miepen over kleurtjes. Die luxe heb je in de software-ontwikkeling helemaal niet doorgaans.

[Mugwump]

Hydra schreef op dinsdag 15 mei 2018 @ 08:29:
[...]


Die hebben wij ook gebruikt en kan ik afraden. Er is een erg beperkte set opdrachten, de site is outdated en ze opdrachten die er zijn, zijn simpel te vinden op internet. Die better programmer is meer een filter om te voorkomen dat je mensen interviewt die liegen op hun CV maar daar faalt het dus in.

Anyway; ik heb een tijdje terug zelf een test gemaakt die eigenlijk gewoon aansluit bij je 'dagelijks' werk. Zit wel wat algoritmisch werk in maar is primair gewoon het bouwen van een service. Ik vind of je dependency injection en testing snapt belangrijker dan dat je een string kunt reversen.

Ik moet ook zeggen dat het inderdaad alweer een tijdje geleden was dat ik zelf eens het verzoek kreeg om daar wat opdrachten te doen en mee te nemen om te bediscussiëren en het inmiddels wat verouderd is zoals jij en iemand anders terecht opmerken.

Of algoritmisch werk of design patterns toepassen / goed kunnen opzetten van tests of nog weer iets anders belangrijker is, hangt ook wel af van het soort werk dat je doet.

[armageddon_2k1]

Hydra schreef op dinsdag 15 mei 2018 @ 08:29:
Er zijn eigenlijk 2 test fases: eentje waarin je mensen uit wil filteren die je uberhaupt niet op interview wil hebben, en een tweede waarin je beoordeelt hoe goed iemand nu is. Voor die eerste fase zijn dat soort tests prima.

Ja, daar kan ik wel inkomen

[downtime]

Lethalis schreef op dinsdag 15 mei 2018 @ 06:57:
[...]

Ik zou liever niet bij een bedrijf willen werken die per se wil dat ik een persoonlijkheids- of IQ test moet doen.

Zeker niet in mijn rol als programmeur. Het is niet alsof ik nou verantwoordelijk ben voor mensenlevens ofzo.

Bovendien vind ik IQ ook privacy gevoelig. Het schept verwachtingen die je misschien helemaal niet waar kunt maken (een hoog IQ betekent niet meteen dat je ook beter presteert, je kan er ook sneller afgeleid door zijn of chaotischer).

Of juist dat je niet aangenomen wordt, omdat de werkgever vreest dat je je teveel gaat vervelen. Terwijl dat niet zo hoeft te zijn.

Daarnaast is het een moment opname. Een slechte score op een IQ test betekent ook niet meteen dat je te dom voor een functie zou zijn.

Kortom, ik vind het helemaal niks.

Ik wil best een paar programmeeropdrachten doen, want daar kom ik immers voor, maar that's it.

Ik snap jouw bezwaren niet echt. Een sollicitatiegesprek is per definitie een momentopname én een inbreuk op de privacy. Ook een programmeeropdracht is een momentopname. Ook daarop kun je door stress de mist ingaan.

[Hydra]

downtime schreef op dinsdag 15 mei 2018 @ 09:09:
Ik snap jouw bezwaren niet echt.

Ik wil. Hij scoort slecht op IQ tests

Ben het er overigens helemaal mee eens dat goed scoren op IQ tests niet zegt dat je het goed als developer doet.

[ Voor 23% gewijzigd door Hydra op 15-05-2018 09:44 ]

[Lethalis]

downtime schreef op dinsdag 15 mei 2018 @ 09:09:
[...]
Ik snap jouw bezwaren niet echt. Een sollicitatiegesprek is per definitie een momentopname én een inbreuk op de privacy. Ook een programmeeropdracht is een momentopname. Ook daarop kun je door stress de mist ingaan.

Dat ben ik dus niet met jou eens.

Een sollicitatiegesprek is niet per definitie een inbreuk op de privacy en kan gewoon een zakelijk gesprek zijn dat puur gaat over wat jij eventueel voor een werkgever kunt betekenen. Een gesprek waarbij je dus in principe alleen relevante informatie voor het functioneren deelt.

Hetzij voor het programmeren, hetzij voor het voeren van gesprekken met klanten, enzovoorts. Dingen die bepalen of jij geschikt voor een bepaalde functie bent.

IQ is daarbij niet relevant. Het zou niet uit mogen maken of iemand een IQ van 100 of 150 heeft.

Als jij met een IQ van 150 taxichauffeur wil worden, omdat je dat gewoon een leuke baan vindt, dan moet dat gewoon kunnen. In de praktijk zie je echter dat mensen dan worden afgewezen, omdat ze "zich zouden vervelen".

Dat is gewoon jammer, want je wijst dan iemand af die verdorie zelf ervoor kiest om die baan te doen omdat het hem leuk lijkt.

[bwerg]

Voor degenen die aan de kant van de interviewers zitten: maak je een goede of juist een slechte indruk, als je wordt gevraagd wat voor patronen je ziet in een aantal cijferreeksen, en je zegt dat je in elke reeks een polynoom ziet van graad n-1, met n de lengte van de reeks?

Lethalis schreef op dinsdag 15 mei 2018 @ 09:44:
... wat jij eventueel voor een werkgever kunt betekenen. Een gesprek waarbij je dus in principe alleen relevante informatie voor het functioneren deelt.

Hetzij voor het programmeren, hetzij voor het voeren van gesprekken met klanten, enzovoorts. Dingen die bepalen of jij geschikt voor een bepaalde functie bent.

IQ is daarbij niet relevant. Het zou niet uit mogen maken of iemand een IQ van 100 of 150 heeft.

En een bepaald denkniveau heeft volgens jouw geen toegevoegde waarde voor een werkgever, en geen correlatie met programmeervaardigheden?

[ Voor 54% gewijzigd door bwerg op 15-05-2018 09:48 ]

[DevWouter]

Marcj schreef op maandag 14 mei 2018 @ 16:40:
[...]


Dank voor deze opdracht. Ik heb het net geprobeerd bij een sollicitant en het uitvoeren van deze opdracht gaf me inderdaad veel inzicht! In dit geval helaas niet positief, maar dan zijn we er wel snel achter.

Graag gedaan.

---

armageddon_2k1 schreef op dinsdag 15 mei 2018 @ 08:05:
...SNIP... Wat je zelf al zegt, het ligt eraan hoe iemand tot het resultaat komt. En het denkproces krijg je niet te zien door iemand even een uurtje een online assessment te laten doen.

Had het zelf niet beter kunnen zeggen

[Lethalis]

bwerg schreef op dinsdag 15 mei 2018 @ 09:46:
En een bepaald denkniveau heeft volgens jouw geen toegevoegde waarde voor een werkgever, en geen correlatie met programmeervaardigheden?

Ik ben van mening dat IQ weinig zegt over een bepaald denkniveau.

IQ geeft alleen de potentie om een bepaald denkniveau te bereiken, maar zegt niets over het uiteindelijk behaalde denkniveau.

Vind ik dan

Dus ik vind dat iemand met een IQ van 110 een hoger denkniveau kan hebben bereikt dan iemand met een IQ van 140, als deze persoon simpelweg veel tijd en aandacht heeft besteed aan het nadenken over een bepaald onderwerp. Bijvoorbeeld door werkervaring, of relevante boeken erover te lezen.

Als de persoon met een IQ van 140 een ongeduldig type is die niet verder kijkt dan zijn neus lang is, dan kan hij nog zo goed scoren op IQ tests, maar daar heb je als werkgever dus geen fluit aan.

Kortom, wat is jouw definitie van "een bepaald denkniveau" ?

Hydra schreef op dinsdag 15 mei 2018 @ 09:43:
[...]
Ik wel. Hij scoort slecht op IQ tests

Heel slecht

[ Voor 7% gewijzigd door Lethalis op 15-05-2018 10:00 ]

[bwerg]

Lethalis schreef op dinsdag 15 mei 2018 @ 09:57:
IQ geeft alleen de potentie om een bepaald denkniveau te bereiken, maar zegt niets over het uiteindelijk behaalde denkniveau.

Helemaal niets? Iemand met een IQ van 60 heeft net zo veel kans om een goed programmeur te worden als iemand met een IQ van 120?

Kortom, wat is jouw definitie van "een bepaald denkniveau" ?

Dat is harstikke abstract en situatie-afhankelijk, en dus nooit perfect te meten. Een IQ-test kan wel een indicatie geven, als het maar met het denkniveau correleert. En al is de test nog zo slecht, correlatie is er echt wel.

Als je boeken leest gaat je IQ trouwens omhoog, dus je uitleg dat een geinteresseerd en goed ingelezen persoon benadeeld wordt klopt niet. Je lijkt aan te nemen dat IQ is aangeboren.

[Harrie_]

bwerg schreef op dinsdag 15 mei 2018 @ 10:06:
[...]
Als je boeken leest gaat je IQ trouwens omhoog, dus je uitleg dat een geinteresseerd en goed ingelezen persoon benadeeld wordt klopt niet. Je lijkt aan te nemen dat IQ is aangeboren.

Als je boeken leest gaat je IQ omhoog?
Wie heeft er hier weleens een IQ-test gedaan? En dan bedoel ik een èchte; niet die nationale TV-quiz die jaarlijks wordt uitgezonden of een ander slap aftreksel van. Het meten/testen van feitenkennis (ofwel boekenkennis) is maar een héél klein onderdeel van een IQ-test. Verder worden in een IQ-test bij uitstek de zaken gemeten die voor een beetje programmeur juist van belang zijn (conceptueel en analytisch denkvermogen om maar wat te noemen).

[ Voor 19% gewijzigd door Harrie_ op 15-05-2018 10:12 ]

[Lethalis]

bwerg schreef op dinsdag 15 mei 2018 @ 10:06:
[...]
Helemaal niets? Iemand met een IQ van 60 heeft net zo veel kans om een goed programmeur te worden als iemand met een IQ van 120?

Het zegt wel iets, maar is naar mijn mening - in de meeste gevallen - niet relevant voor een werkgever.

Die zoekt een programmeur, niet "iemand met een IQ van tenminste 120".

Als je boeken leest gaat je IQ trouwens omhoog, dus je uitleg dat een geïnteresseerd en goed ingelezen persoon benadeeld wordt klopt niet. Je lijkt aan te nemen dat IQ is aangeboren.

Wanneer heb jij voor het laatst een IQ test gedaan?

Want als ik boeken over software architectuur lees, dan heeft dat bar weinig te maken met een paar puzzeltjes oplossen op een IQ test (ook de ingewikkeldere, waarbij ruimtelijk inzicht wordt gemeten). Maar het verandert wellicht wel mijn kijk op hoe software wordt ontwikkeld en is dus van invloed op mijn manier van denken daarover.

PS
Ik scoorde hoger op IQ testen toen ik nog op het ingenieursbureau werkte van mijn vader. Ik deed destijds veel 3D CAD ontwerpen en berekeningen. Hierdoor fietste ik ook wat makkelijker door zo'n test heen.

Sindsdien ik alleen nog maar programmeer, scoor ik juist minder goed op zo'n test Ik heb namelijk nooit meer ruimtelijk inzicht nodig en berekeningen doe ik al bijna helemaal niet meer.

Dus hoe relevant is die test dan nog?

[ Voor 21% gewijzigd door Lethalis op 15-05-2018 10:17 ]

[bwerg]

Lethalis schreef op dinsdag 15 mei 2018 @ 10:12:
Die zoekt een programmeur, niet "iemand met een IQ van tenminste 120".

En hoe meet hij of iemand 'een programmeur' is?

Met een test, die een grove simplificatie is van de vaardigheden die je nodig hebt voor programmeren, zoals in een IQ-test.

Ik zeg niet dat een IQ test een goede of de beste manier is. Maar het is flauwekul om te zeggen dat het niets zegt.

Want als ik boeken over software architectuur lees, dan heeft dat bar weinig te maken met een paar puzzeltjes oplossen op een IQ test (ook de ingewikkeldere, waarbij ruimtelijk inzicht wordt gemeten). Maar het verandert wellicht wel mijn kijk op hoe software wordt ontwikkeld en is dus van invloed op mijn manier van denken daarover.

Alleen boeken lezen geeft je ook helemaal geen programmeerervaring, dus de analogie lijkt me nog steeds prima op te gaan.

[Lethalis]

bwerg schreef op dinsdag 15 mei 2018 @ 10:16:
[...]
En hoe meet hij of iemand 'een programmeur' is?

Door iemand te laten programmeren?

Als ik iemand zoek die goed kan fietsen, ga ik hem ook niet laten koorddansen om te kijken of hij goed zijn evenwicht kan houden.

[bwerg]

Lethalis schreef op dinsdag 15 mei 2018 @ 10:19:
Door iemand te laten programmeren?

Oke, iemand laten programmeren (wat ook niet alles zegt, zoals besproken) is een betere test. Prima. Dat wil niet zeggen dat de uitkomst voor een IQ-test compleet irrelevant is, of dat al je andere bezwaren tegen IQ-tests ergens op slaan.

[ThomasG]

bwerg schreef op dinsdag 15 mei 2018 @ 10:24:
[...]

Oke, iemand laten programmeren (wat ook niet alles zegt, zoals besproken) is een betere test. Prima. Dat wil niet zeggen dat de uitkomst voor een IQ-test compleet irrelevant is, of dat al je andere bezwaren tegen IQ-tests ergens op slaan.

Maar een IQ-test is ook niet doorslaggevend. Het is enkel een indicatie dat iemand theoretisch gezien een grotere kans heeft een beter programmeur te zijn. Maar dat betekend niet dat het in de praktijk ook het geval zal zijn. Het is een combinatie van verschillende factoren wat er toe leid of iemand een goede programmeur is of niet. Omdat veel goede programmeurs een gemiddeld hoger IQ hebben betekend niet dat mensen met een gemiddeld hoger IQ dus goede programmeurs zullen zijn.

[Hydra]

Ik geloof in ieder geval wel dat een IQ test en iemands kwaliteiten als programmeur een hoge correlatie hebben. Er is dan geen direct causaal verband maar er is echt wel een reden dat dit soort IQ tests gegeven worden. Neemt niet weg dat er m.i. betere tests zijn om iemand's kwaliteiten te testen.

[mcDavid]

ThomasG schreef op dinsdag 15 mei 2018 @ 10:39:
[...]
Maar een IQ-test is ook niet doorslaggevend. Het is enkel een indicatie dat iemand theoretisch gezien een grotere kans heeft een beter programmeur te zijn. Maar dat betekend niet dat het in de praktijk ook het geval zal zijn. Het is een combinatie van verschillende factoren wat er toe leid of iemand een goede programmeur is of niet. Omdat veel goede programmeurs een gemiddeld hoger IQ hebben betekend niet dat mensen met een gemiddeld hoger IQ dus goede programmeurs zullen zijn.

Hoezo zou zo'n test doorslaggevend moeten zijn? Een recruiter/werkgever probeert gewoon een beeld te vormen van een kandidaad. En als hij dat een beetje serieus doet, gebruikt'ie daarvoor meerdere verschillende invalshoeken. Dat je een goed CV hebt betekent ook niet dat je een goeie programmeur bent. Dat je een goed sollicitatiegesprek kunt houden evenmin. En een programmeertest is ook maar een momentopname. Het zal altijd een totaalplaatje zijn vanuit meerdere invalshoeken.

[.oisyn]

Harrie_ schreef op dinsdag 15 mei 2018 @ 10:12:
[...]


Als je boeken leest gaat je IQ omhoog?

Ja. "Boeken" moet je hierbij in het algemeen zien. Het prikkelt je taalvaardigheid en analytisch denkvermogen. Het gaat dus niet zozeer om feitenkennis die je eventueel opdoet door het lezen van non-fictie.

[Marcj]

Harrie_ schreef op maandag 14 mei 2018 @ 16:52:
@Marcj Mag ik misschien vragen:
- Om wat voor functie het dan gaat
- Wie daarop af komt en wat deze persoon op zijn/haar CV heeft staan?
- Met wat voor oplossing deze persoon op de proppen kwam (had hij/zij überhaupt een oplossing?)

Het heeft nogal wat discussie los gemaakt, maar ik heb het toch eens uitgeprobeerd. Ik ben blij deze test uitgevoerd te hebben, want het brengt in ieder geval wat discussie los en je ziet hoe hij zo'n probleem aanpakt.

- Het ging om een junior PHP'er
- Hij was net klaar met het MBO (afstuderen aan het afronden), heeft 2 stages gehad
- Hij kwam wel met een oplossing, maar met een aantal PHP warnings en nogal slordig

Vooral het proces hoe hij er toe kwam maakte me wel duidelijk dat hij veel moeite gaat hebben met complexere software bouwen. Ik denk dat hij prima geschikt is bij een websitebouwer die wat aan een CMS sleutelt, zolang het recht-toe-recht-aan is. Maar we bouwen hier inmiddels een best groot complex systeem, waar al verschillende mensen in verzopen zijn. We willen nu dus wat kritischer worden wie we aannemen, want blijkbaar kan niet iedere programmeur dit aan.

En ik snap nog niet helemaal wat er op tegen is om een standaard testje te hebben, ook al is dit een idee van iemand anders. Dit is gewoon een eerste test om enigszins een beeld te krijgen wat voor programmeerkennis iemand heeft.

Ik verwacht ook van een junior programmeur dat hij/zij vrij snel hier met een zinnige oplossing komt. Ik heb de test hier ook aan wat collega's laten zien en die kwamen allemaal binnen enkele minuten met een goede oplossing, ook de jongste collega's.

Ps. Als iemand nog een mooie uitdaging in Noord-Nederland zoekt, we hebben meerdere vacatures open staan, van front-end (React, PHP) tot back-end (Java 10 / MariaDB / Redis)

[ Voor 4% gewijzigd door Marcj op 15-05-2018 12:08 ]

[Ryada]

Marcj schreef op dinsdag 15 mei 2018 @ 12:05:
[...]


Het heeft nogal wat discussie los gemaakt, maar ik heb het toch eens uitgeprobeerd. Ik ben blij deze test uitgevoerd te hebben, want het brengt in ieder geval wat discussie los en je ziet hoe hij zo'n probleem aanpakt.

- Het ging om een junior PHP'er
- Hij was net klaar met het MBO (afstuderen aan het afronden), heeft 2 stages gehad
- Hij kwam wel met een oplossing, maar met een aantal PHP warnings en nogal slordig

Vooral het proces hoe hij er toe kwam maakte me wel duidelijk dat hij veel moeite gaat hebben met complexere software bouwen. Ik denk dat hij prima geschikt is bij een websitebouwer die wat aan een CMS sleutelt, zolang het recht-toe-recht-aan is. Maar we bouwen hier inmiddels een best groot complex systeem, waar al verschillende mensen in verzopen zijn. We willen nu dus wat kritischer worden wie we aannemen, want blijkbaar kan niet iedere programmeur dit aan.

En ik snap nog niet helemaal wat er op tegen is om een standaard testje te hebben, ook al is dit een idee van iemand anders. Dit is gewoon een eerste test om enigszins een beeld te krijgen wat voor programmeerkennis iemand heeft.

Ik verwacht ook van een junior programmeur dat hij/zij vrij snel hier met een zinnige oplossing komt. Ik heb de test hier ook aan wat collega's laten zien en die kwamen allemaal binnen enkele minuten met een goede oplossing, ook de jongste collega's.

Ps. Als iemand nog een mooie uitdaging in Noord-Nederland zoekt, we hebben meerdere vacatures open staan, van front-end (React, PHP) tot back-end (Java 10 / MariaDB / Redis)

Wat ik een belangrijk punt vind is wat bepaald of iets een goede oplossing is voor jullie?
dat het snel is? Of het mooie code is? Of dat er super fancy features van de language gebruikt worden?
Of gewoon zo simpel als compilable code die doet wat het doel was ongeacht de input?

(Java? 0.0 helaas geen C# )

[Marcj]

Ryada schreef op dinsdag 15 mei 2018 @ 12:11:
[...]

Wat ik een belangrijk punt vind is wat bepaald of iets een goede oplossing is voor jullie?
dat het snel is? Of het mooie code is? Of dat er super fancy features van de language gebruikt worden?
Of gewoon zo simpel als compilable code die doet wat het doel was ongeacht de input?

(Java? 0.0 helaas geen C# )

Ik zie graag hoe zijn denkproces verloopt, kan hij zo'n probleem opknippen in logische stukken en daarbij de edge-cases herkennen. Vooral dit laatste ging behoorlijk fout toen ik de input iets ging veranderen.

De exacte oplossing en zelfs de taal interesseert mij niet. En ook al zit er een bug in, dat maakt me niet uit. Maar het gaat erom hoe je ermee om gaat. Daarom wil ik er ook naast zitten tijdens zo'n test.

Ps. Ervaring met een bepaalde taal vind ik ook niet zo belangrijk, een goede programmeur kan makkelijk schakelen wanneer het nodig is. Ik heb hier naast me een goede collega zitten die uit de .NET wereld kwam, maar was na een maandje al vloeiend bezig in zowel PHP als Java.

[ Voor 14% gewijzigd door Marcj op 15-05-2018 12:17 ]

[Ryada]

Marcj schreef op dinsdag 15 mei 2018 @ 12:14:
[...]


Ik zie graag hoe zijn denkproces verloopt, kan hij zo'n probleem opknippen in logische stukken en daarbij de edge-cases herkennen. Vooral dit laatste ging behoorlijk fout toen ik de input iets ging veranderen.

De exacte oplossing en zelf taal interesseert mij niet. En ook al zit er een bug in, dat maakt me niet uit. Maar het gaat erom hoe je ermee om gaat. Daarom wil ik er ook naast zitten tijdens zo'n test.

Fair enough.
Dat klinkt een stuk logischer dan wat ik in eerste instantie begreep vanuit het verhaal.

[ZaZ]

Harrie_ schreef op dinsdag 15 mei 2018 @ 10:12:
[...]
Wie heeft er hier weleens een IQ-test gedaan? En dan bedoel ik een èchte; niet die nationale TV-quiz die jaarlijks wordt uitgezonden of een ander slap aftreksel van.

Hackerhater geloof ik.
Uitkomst was iets van 438

[Harrie_]

Marcj schreef op dinsdag 15 mei 2018 @ 12:14:
[...]
Ps. Ervaring met een bepaalde taal vind ik ook niet zo belangrijk, een goede programmeur kan makkelijk schakelen wanneer het nodig is. Ik heb hier naast me een goede collega zitten die uit de .NET wereld kwam, maar was na een maandje al vloeiend bezig in zowel PHP als Java.

Moet ook een verademing voor 'm geweest zijn

[Matis]

ZaZ schreef op dinsdag 15 mei 2018 @ 12:27:
Hackerhater geloof ik.
Uitkomst was iets van 438

It's over 9000!

[Mugwump]

Harrie_ schreef op dinsdag 15 mei 2018 @ 12:28:
[...]


Moet ook een verademing voor 'm geweest zijn

Kan me niet voorstellen dat iemand met een .Net of Java achtergrond vrolijk wordt van PHP. C# en Java hebben in mijn ogen beiden hun voor- en nadelen, maar bij PHP wil ik echt nooit meer in de buurt komen.

[bwerg]

ZaZ schreef op dinsdag 15 mei 2018 @ 12:27:
[...]

Hackerhater geloof ik.
Uitkomst was iets van 438

Ben je niet in de war met een cito-score?

Oh nee, dat is in het bereik 500-550, niet 400-450.

[Matis]

bwerg schreef op dinsdag 15 mei 2018 @ 13:03:

Ben je niet in de war met een cito-score?

Oh nee, dat is in het bereik 500-550, niet 400-450.

Daarvoor had ik 549

[Tjolk]

Wat doen wij fout dat jullie blijkbaar de luxe hebben om kandidaten te selecteren? We zijn hier al tijden op zoek naar versterking, maar vinden niet veel.

[Woy]

Tjolk schreef op dinsdag 15 mei 2018 @ 13:10:
Wat doen wij fout dat jullie blijkbaar de luxe hebben om kandidaten te selecteren? We zijn hier al tijden op zoek naar versterking, maar vinden niet veel.

Het feit dat je altijd versterking zoekt maakt het niet dat je niet alsnog de slechte mensen eruit wil filteren. Een slecht teamlid richt meer schade aan dan het wat toevoegt.

[Marcj]

Mugwump schreef op dinsdag 15 mei 2018 @ 13:03:
[...]


Kan me niet voorstellen dat iemand met een .Net of Java achtergrond vrolijk wordt van PHP. C# en Java hebben in mijn ogen beiden hun voor- en nadelen, maar bij PHP wil ik echt nooit meer in de buurt komen.

Ach, met PHP 7.2 is het wel mogelijk om net object georienteerd te werken, maar het kost wat extra inzet. Er is helaas ooit begonnen met PHP en dat zomaar omzetten is ook geen oplossing. We zijn in ieder geval stappen aan het zetten om het wat stricter te maken, en daarbij is veel ervaring in c# of java erg handig.

[Harrie_]

Tjolk schreef op dinsdag 15 mei 2018 @ 13:10:
Wat doen wij fout dat jullie blijkbaar de luxe hebben om kandidaten te selecteren? We zijn hier al tijden op zoek naar versterking, maar vinden niet veel.

Zonder te weten wie/wat jullie zoeken en wat jullie te bieden hebben is daar natuurlijk geen antwoord op te geven.

[Marcj]

Woy schreef op dinsdag 15 mei 2018 @ 13:15:
[...]

Het feit dat je altijd versterking zoekt maakt het niet dat je niet alsnog de slechte mensen eruit wil filteren. Een slecht teamlid richt meer schade aan dan het wat toevoegt.

Absoluut waar. Zo hebben wij ook al een paar keer afscheid moeten nemen achteraf, omdat iemand meer tijd kost dan oplevert. Daarom moeten we ook wel wat kritischer worden en beter gaan selecteren. Maar goed: ik heb zo weer een gesprek, hopelijk is dit wel wat!

[Mugwump]

Marcj schreef op dinsdag 15 mei 2018 @ 13:15:
[...]


Ach, met PHP 7.2 is het wel mogelijk om net object georienteerd te werken, maar het kost wat extra inzet. Er is helaas ooit begonnen met PHP en dat zomaar omzetten is ook geen oplossing. We zijn in ieder geval stappen aan het zetten om het wat stricter te maken, en daarbij is veel ervaring in c# of java erg handig.

Je kon al wel eerder redelijk object oriented werken in PHP, maar het probleem tussen wat er in theorie kan en wat praktijk gebeurt zit nogal eens een heel groot gat. Nog afgezien van het feit dat PHP in de basis gewoon nog steeds een brakke taal is. Niet dat er in C# of Java niet genoeg bagger wordt geproduceerd, maar mijn persoonlijk ervaring is dat dat in PHP vaak nog eens een tandje erger.
PHP was natuurlijk ook altijd bij uitstek geschikt om 'even snel wat in elkaar te klooien dat werkt'. Dat is soms een kracht, maar zeker bij software die flink groeit is dat al snel niet voldoende meer.

[Tjolk]

@Woy nee logisch natuurlijk. Maar er komt gewoon bijna geen reactie.

We zoeken een PHP developer, in eerste instantie Senior/HBO niveau, inmiddels is de eis iets verlaagd naar medior en iemand die in elk de juiste manier van werken heeft (e.g.: MBO is ook prima). Vorig jaar is de boel wel via een aantal recruitmentbureaus uitgezet, maar dat leverde niets zinnigs op. Die spammen gewoon iedere CV waar het woord PHP in staat door.

Wel enkele serieuze sollicitanten gehad, maar dan blijkt bijvoorbeeld iemand volledig blij te kunnen vertellen dat hij Game Developer wil worden (kwam net van school) en puntje bij paaltje geen interesse had in de eigenlijke functie. Gewoon verkeerd geselecteerd. Andere junior die zichzelf na anderhalf jaar ervaring wel medior vond en een salariseis had vlak onder mijn salaris als senior.*

Afgelopen jaar heeft hier wel iemand gewerkt, maar zijn contract is niet verlengd omdat hij qua manier van werken niet paste (is medetweaker, dus ga ik niet verder op in). Al die tijd hadden we nog steeds versterking nodig, inmiddels nog steeds maar gewoon geen (zinnige) reacties.

Dus dan vraag ik me af: wat is nou een goede tactiek om aan nieuwe devs te komen? We hebben een broertje dood aan recruitmentbureaus en hun praktijken, maar op eigen kracht blijkt ook verdomd lastig.

*) Volgens mij zit ik best prima qua salaris

[XWB]

Marcj schreef op dinsdag 15 mei 2018 @ 13:15:
[...]


Ach, met PHP 7.2 is het wel mogelijk om net object georienteerd te werken, maar het kost wat extra inzet.

Definieer "net" ?

[armageddon_2k1]

A ) Het lukt maar net...
B ) Het is netjes

Wereld van verschil ;-)

[ThomasG]

armageddon_2k1 schreef op dinsdag 15 mei 2018 @ 13:34:
A ) Het lukt maar net...
B ) Het is netjes

Wereld van verschil ;-)

It ken net

[Mugwump]

Tjolk schreef op dinsdag 15 mei 2018 @ 13:31:
Dus dan vraag ik me af: wat is nou een goede tactiek om aan nieuwe devs te komen? We hebben een broertje dood aan recruitmentbureaus en hun praktijken, maar op eigen kracht blijkt ook verdomd lastig.

Wij hebben het ook heel lastig om mensen te vinden. Software-ontwikkeling is bij ons een beetje een spin-off / aanhangsel met een klein groepje pure software developers. We hebben nog wel de nodige mensen rondlopen die best prima kunnen scripten of wat hele basale programmeerdingetjes zouden kunnen, maar die kun je niet echt heel makkelijk even aanschakelen. Het gros bij ons doet BI en daarin gaat het vinden van mensen ons wel vrij goed af. 80-90% van de nieuwe mensen ook gewoon binnen van het 'netwerk' van collega's. Dat is bij ons softwareclubje wat lastiger. Mijn eigen netwerk kan zo ongeveer gelijk de prullenbak in omdat vloeiend Nederlands spreken hier een harde eis is en het overgrote deel van de developers die ik ken het Nederlands onvoldoende beheerst.

Er wordt wel heel veel geprobeerd om intern de werving ook wat minder afhankelijk te maken van het via-via binnenhalen van mensen, maar dat blijft toch steeds erg lastig. Is ook niet zo gek natuurlijk. Ik heb ook meer vertrouwen in iemand die ik ken en waarvan ik weet dat hij of zij het vak verstaat en prettig is om mee te werken dan in een willekeurige hyperenthousiaste recruiter.

[Harrie_]

Marcj schreef op dinsdag 15 mei 2018 @ 13:15:
[...]
Ach, met PHP 7.2 is het wel mogelijk om net object georienteerd te werken, maar het kost wat extra inzet.

Volgens mij kun je in PHP prima OO uit de voeten, dat gezegd hebbende hangt het meeste van wat ik zelf maak van functioneleprocedurele syntax aan elkaar. Ik begrijp ook nooit zo goed die drang om altijd alles OO te willen vangen.

Wat is er mis met:

PHP:

if (isset($object){
    // iets doen
} else {
    // iets anders doen
}

[ Voor 25% gewijzigd door Harrie_ op 15-05-2018 14:15 ]

[TheNephilim]

Harrie_ schreef op dinsdag 15 mei 2018 @ 13:55:
[...]


Volgens mij kun je in PHP prima OO uit de voeten, dat gezegd hebbende hangt het meeste van wat ik zelf maak van functionele syntax aan elkaar. Ik begrijp ook nooit zo goed die drang om altijd alles OO te willen vangen.

Wat is er mis met:

PHP:

if (isset($object){
    // iets doen
} else {
    // iets anders doen
}

In principe niks, het hangt er net af wat (en hoeveel) je allemaal doet bij "iets doen" en "iets anders doen".

[ThomasG]

TheNephilim schreef op dinsdag 15 mei 2018 @ 13:59:
[...]


In principe niks, het hangt er net af wat (en hoeveel) je allemaal doet bij "iets doen" en "iets anders doen".

Het probleem is natuurlijk wel dat je de verantwoordelijkheid verplaatst, vooral als zo'n constructie vaak gebruikt wordt (op meerdere plaatsen). Dan kun je beter een null/no-op variant hebben, want dat scheelt (op langer termijn) een hoop qua onderhoud.

[armageddon_2k1]

Harrie_ schreef op dinsdag 15 mei 2018 @ 13:55:
[...]


Volgens mij kun je in PHP prima OO uit de voeten, dat gezegd hebbende hangt het meeste van wat ik zelf maak van functionele syntax aan elkaar. Ik begrijp ook nooit zo goed die drang om altijd alles OO te willen vangen.

Wat is er mis met:

PHP:

if (isset($object){
    // iets doen
} else {
    // iets anders doen
}

Mij ontgaat wat dit met OO te maken heeft?

[Mugwump]

Harrie_ schreef op dinsdag 15 mei 2018 @ 13:55:
[...]


Volgens mij kun je in PHP prima OO uit de voeten, dat gezegd hebbende hangt het meeste van wat ik zelf maak van functionele syntax aan elkaar. Ik begrijp ook nooit zo goed die drang om altijd alles OO te willen vangen.

Wat is er mis met:

PHP:

if (isset($object){
    // iets doen
} else {
    // iets anders doen
}

Dit is procedureel, niet zo zeer functioneel. Het heeft zoals @armageddon_2k1 zegt weinig te maken met wel of geen OO-code schrijven. Wat je altijd miste was de mogelijkheid om bijvoorbeeld een fatsoenlijk contract te schrijven in de vorm van een interface met methods die parameters én return types hebben. Dat kan geloof ik in PHP 7 wel, maar dat heeft dan wel verdomd lang geduurd. Iets meer geavanceerde zaken als generics zijn dan nog weer heel ver weg in PHP volgens mij.

[Harrie_]

Mugwump schreef op dinsdag 15 mei 2018 @ 14:13:
[...]


Dit is procedureel, niet zo zeer functioneel. Het heeft zoals @armageddon_2k1 zegt weinig te maken met wel of geen OO-code schrijven. Wat je altijd miste was de mogelijkheid om bijvoorbeeld een fatsoenlijk contract te schrijven in de vorm van een interface met methods die parameters én return types hebben. Dat kan geloof ik in PHP 7 wel, maar dat heeft dan wel verdomd lang geduurd. Iets meer geavanceerde zaken als generics zijn dan nog weer heel ver weg in PHP volgens mij.

Sorry ik bedoelde ook procedureel

[Hydra]

Tjolk schreef op dinsdag 15 mei 2018 @ 13:10:
Wat doen wij fout dat jullie blijkbaar de luxe hebben om kandidaten te selecteren? We zijn hier al tijden op zoek naar versterking, maar vinden niet veel.

Je onderschat de schade die een slechte developer kan doen. Ik heb met developers gewerkt (en er 2 uitgewerkt) die een netto negatieve bijdrage leverden, dus nog buiten de vraag of ze hun geld waard waren. En dan heb je het nog niet eens over het sneeuwbaleffect dat je krijgt met te veel slechte developers.

Harrie_ schreef op dinsdag 15 mei 2018 @ 13:55:
Volgens mij kun je in PHP prima OO uit de voeten, dat gezegd hebbende hangt het meeste van wat ik zelf maak van functioneleprocedurele syntax aan elkaar. Ik begrijp ook nooit zo goed die drang om altijd alles OO te willen vangen.

OO werken gaat niet om een paar regeltjes code op manier A of manier B doen. Het gaat om dingen netjes bij elkaar zetten als ze bij elkaar horen en dat dan af te schermen voor de buitenwereld. Je hebt geen OO taal nodig om OO te werken (het helpt wel enorm natuurlijk), dat kun je ook in C doen. Check de SOLID basisprinciepes van OO programmeren.

Daarbovenop komen ook nog eens een hoop Design Patterns. De meeste zijn toch vrij lastig puur procedureel te implementeren.

[ Voor 46% gewijzigd door Hydra op 15-05-2018 14:37 ]

[Tjolk]

Hydra schreef op dinsdag 15 mei 2018 @ 14:33:
[...]


Je onderschat de schade die een slechte developer kan doen. Ik heb met developers gewerkt (en er 2 uitgewerkt) die een netto negatieve bijdrage leverden, dus nog buiten de vraag of ze hun geld waard waren. En dan heb je het nog niet eens over het sneeuwbaleffect dat je krijgt met te veel slechte developers.

Volgens mij onderschat ik niets, maar lees jij niet

Mijn opmerking (zie ook vorige bericht) ging erom dat wij nauwelijks een populatie hebben om op te selecteren. Niet of selectie nuttig is, want dat staat buiten kijf.

[Hydra]

Tjolk schreef op dinsdag 15 mei 2018 @ 14:54:
Volgens mij onderschat ik niets, maar lees jij niet

Je kunt je bericht makkelijk interpreteren alsof je weinig aanbod hebt en dus je drempel flink verlaagd hebt. Je daaropvolgende reactie had ik nog niet gelezen Sorry

Tjolk schreef op dinsdag 15 mei 2018 @ 13:31:
Dus dan vraag ik me af: wat is nou een goede tactiek om aan nieuwe devs te komen? We hebben een broertje dood aan recruitmentbureaus en hun praktijken, maar op eigen kracht blijkt ook verdomd lastig.

Je neemt als bedrijf zelf iemand aan die de hele dag bezig is het internet af te struinen of je laat dat een extern bedrijf doen. Een vacature online zetten levert je vrijwel niks op, tenzij je een enorm hot bedrijf zijn. En dat zijn jullie niet.

[ Voor 45% gewijzigd door Hydra op 15-05-2018 15:01 ]

[Douweegbertje]

Harrie_ schreef op dinsdag 15 mei 2018 @ 13:55:
[...]


Volgens mij kun je in PHP prima OO uit de voeten, dat gezegd hebbende hangt het meeste van wat ik zelf maak van functioneleprocedurele syntax aan elkaar. Ik begrijp ook nooit zo goed die drang om altijd alles OO te willen vangen.

Wat is er mis met:

PHP:

if (isset($object){
    // iets doen
} else {
    // iets anders doen
}

Dat ik eerder "instanceof" verwacht en dan iets met zn members doet

------

Ik ben zelf hier wel tevreden over de kwaliteit van onze PHP programmatuur. Als ik het ook vergelijk met menig ander opensource applicatie / code dan zit het op de plek waar we willen zijn (bovenaan ).

We zien nu ook binnen de organisatie die mensen elkaar steeds meer wijzen op tips m.b.t. architectuur van de code ipv mierenneuken over "dingetjes". Simpel voorbeeld kan zijn; "Waarom niet een factory gebruiken voor dit". Dat heeft door de tijden heen ons kwaliteit sterk verbetert.

[Hydra]

Douweegbertje schreef op dinsdag 15 mei 2018 @ 15:33:
We zien nu ook binnen de organisatie die mensen elkaar steeds meer wijzen op tips m.b.t. architectuur van de code ipv mierenneuken over "dingetjes". Simpel voorbeeld kan zijn; "Waarom niet een factory gebruiken voor dit". Dat heeft door de tijden heen ons kwaliteit sterk verbetert.

Pas maar op, voor 't weet heb je Java code. AbstractSingletonProxyFactoryBean FTW!

[XWB]

Mugwump schreef op dinsdag 15 mei 2018 @ 14:13:
[...]


Dit is procedureel, niet zo zeer functioneel. Het heeft zoals @armageddon_2k1 zegt weinig te maken met wel of geen OO-code schrijven. Wat je altijd miste was de mogelijkheid om bijvoorbeeld een fatsoenlijk contract te schrijven in de vorm van een interface met methods die parameters én return types hebben. Dat kan geloof ik in PHP 7 wel, maar dat heeft dan wel verdomd lang geduurd. Iets meer geavanceerde zaken als generics zijn dan nog weer heel ver weg in PHP volgens mij.

Ja, de return types zijn er inmiddels. En in PHP 7.1 zijn nog nullable en void return types toegevoegd.

Maar is er nog steeds geen method overloading, en het staat ook niet op de planning voor de nabije toekomst.

Met betrekking tot generics, daar staat enkele RFC's voor open, maar is verder niks met gedaan. Inderdaad allemaal ver weg dus.

[Harrie_]

Hydra schreef op dinsdag 15 mei 2018 @ 14:33:
[...]
OO werken gaat niet om een paar regeltjes code op manier A of manier B doen. Het gaat om dingen netjes bij elkaar zetten als ze bij elkaar horen en dat dan af te schermen voor de buitenwereld.
[...]

En daar sla je de spijker op z'n kop! Mijn voorbeeldje pseudo-code was ook bedoeld ter illustratie dat zoiets niet per definitie fout is, terwijl er wel vaak met een vinger wordt gewezen want niet 100% OO.

Daarmee wil ik verder niet zeggen dat ik het lichtend voorbeeld ben van hoe het wel en niet moet; ik ben ook maar een doorgegroeide hobbyist van het kaliber "als het werkt niet meer aanraken"

[Mugwump]

Harrie_ schreef op dinsdag 15 mei 2018 @ 17:17:
[...]


En daar sla je de spijker op z'n kop! Mijn voorbeeldje pseudo-code was ook bedoeld ter illustratie dat zoiets niet per definitie fout is, terwijl er wel vaak met een vinger wordt gewezen want niet 100% OO.

Daarmee wil ik verder niet zeggen dat ik het lichtend voorbeeld ben van hoe het wel en niet moet; ik ben ook maar een doorgegroeide hobbyist van het kaliber "als het werkt niet meer aanraken"

En die houding kan prima als je kleinschalige scripts maakt die verder niet continu veranderen, maar op het moment dat je met applicaties van serieuze omvang te maken krijgt, dan helpt dat de productiviteit van je hele team om zeep.

[Hydra]

Harrie_ schreef op dinsdag 15 mei 2018 @ 17:17:
Daarmee wil ik verder niet zeggen dat ik het lichtend voorbeeld ben van hoe het wel en niet moet; ik ben ook maar een doorgegroeide hobbyist van het kaliber "als het werkt niet meer aanraken"

Wat is je doel verder in je carriere? Als je een beetje aan PHP webshops wil knutselen is dat 'prima'. In andere teams. Tja. Een stuk minder prima.

[Harrie_]

@Mugwump @Hydra Ik zou haast zeggen vanzelfsprekend bedoel ik "als het werkt niet meer aanraken" als grap en zet ik het neer als een stukje zelfspot, wetende dat ik nog een hoop te leren heb. Heeft geen verdere uitleg nodig denk ik.

[Mugwump]

Harrie_ schreef op dinsdag 15 mei 2018 @ 19:43:
@Mugwump @Hydra Ik zou haast zeggen vanzelfsprekend bedoel ik "als het werkt niet meer aanraken" als grap en zet ik het neer als een stukje zelfspot, wetende dat ik nog een hoop te leren heb. Heeft geen verdere uitleg nodig denk ik.

Ik heb helaas inmiddels te veel ervaring in de IT om dit als grap op te vatten.
Ik sta echt altijd weer te kijken van het feit dat er zoveel mensen in de IT werken die totaal niet geïnteresseerd zijn in hoe iets nou precies werkt en gewoon lekker aanklooien tot iets werkt en er een strik omheen gooien.

[DirkZzZ]

Tjolk schreef op dinsdag 15 mei 2018 @ 13:31:
@Woy nee logisch natuurlijk. Maar er komt gewoon bijna geen reactie.

We zoeken een PHP developer, in eerste instantie Senior/HBO niveau, inmiddels is de eis iets verlaagd naar medior en iemand die in elk de juiste manier van werken heeft (e.g.: MBO is ook prima). Vorig jaar is de boel wel via een aantal recruitmentbureaus uitgezet, maar dat leverde niets zinnigs op. Die spammen gewoon iedere CV waar het woord PHP in staat door.

Wel enkele serieuze sollicitanten gehad, maar dan blijkt bijvoorbeeld iemand volledig blij te kunnen vertellen dat hij Game Developer wil worden (kwam net van school) en puntje bij paaltje geen interesse had in de eigenlijke functie. Gewoon verkeerd geselecteerd. Andere junior die zichzelf na anderhalf jaar ervaring wel medior vond en een salariseis had vlak onder mijn salaris als senior.*

Afgelopen jaar heeft hier wel iemand gewerkt, maar zijn contract is niet verlengd omdat hij qua manier van werken niet paste (is medetweaker, dus ga ik niet verder op in). Al die tijd hadden we nog steeds versterking nodig, inmiddels nog steeds maar gewoon geen (zinnige) reacties.

Dus dan vraag ik me af: wat is nou een goede tactiek om aan nieuwe devs te komen? We hebben een broertje dood aan recruitmentbureaus en hun praktijken, maar op eigen kracht blijkt ook verdomd lastig.

*) Volgens mij zit ik best prima qua salaris

In welke regio?

[Lethalis]

Tjolk schreef op dinsdag 15 mei 2018 @ 13:31:
Dus dan vraag ik me af: wat is nou een goede tactiek om aan nieuwe devs te komen? We hebben een broertje dood aan recruitmentbureaus en hun praktijken, maar op eigen kracht blijkt ook verdomd lastig.

*) Volgens mij zit ik best prima qua salaris

Wat is "best prima" ?

Meestal is de conclusie toch dat je te weinig betaalt...

Of je zit in een krimpregio. Meeste developers trekken richting de randstad omdat daar het meeste werk is.

[Lethalis]

bwerg schreef op dinsdag 15 mei 2018 @ 10:24:
[...]

Oke, iemand laten programmeren (wat ook niet alles zegt, zoals besproken) is een betere test. Prima. Dat wil niet zeggen dat de uitkomst voor een IQ-test compleet irrelevant is, of dat al je andere bezwaren tegen IQ-tests ergens op slaan.

Laat ik het anders stellen...

Als ik een collega zou zoeken voor mijn werk dan kijk ik niet naar een IQ score, maar naar het denkproces dat iemand heeft bij het ontwikkelen van een oplossing. En dan ligt de nadruk niet eens op zijn algoritmische vaardigheden, maar of hij rekening houdt met de juiste factoren ten aanzien van onderhoudbaarheid, schaalbaarheid, veiligheid, enzovoorts.

Want daar zitten namelijk de grote risico's van software ontwikkeling mijns inziens.

Ook al is er een correlatie met IQ, dan nog vind ik dat meer een gegeven dan echte informatie.

Toen ik ruim 15 jaar geleden nog een jonge gast van in de 20 was, dacht ik overigens wel dat IQ belangrijk was om goed te kunnen programmeren.

Maar 15 jaar werkervaring en tig cursussen en boeken verder, hecht ik veel meer waarde aan de kennis en ervaring die ik heb opgedaan.

Dat is dan ook wat ik in een collega zou zoeken.

Iemand die ik niks hoef te vertellen over de GoF, of SOLID principes. Iemand die rekening houdt met de coupling en cohesie van onderlinge classes. Iemand die ik niks hoef te vertellen over SQL injection en XSS attacks. Iemand die snapt hoe semantic versioning werkt en hoe hij transitieve dependencies kan beheren. Iemand die in staat is componenten los te ontwikkelen en daarvoor op zijn minst integration tests kan schrijven.

Iemand die niet de makkelijkste weg kiest als hij een andere interne library gebruikt, maar goed nadenkt over de architecturele consequenties daarvan (spinnenweb dll hell ).

Iemand die het inversion of control principe snapt en kan toepassen.

Iemand die begrijpt wanneer iets stateless moet zijn.

Liefst ook nog iemand die voor relationele databases een indexing strategie kan ontwerpen en snapt hoe hij een query execution plan moet analyseren.

Iemand die verscheidene concurrency strategieën kan toepassen. Die bij ACID niet aan drugs denkt

Iemand die het motto release early and release often snapt in het kader van iteratieve ontwikkeling. Iemand die de kritieke succesfactoren van een project kan identificeren en daar zijn aandacht op richt.

And the list goes on and on...

Als je al die dingen kan zal je IQ wel okee zijn, en vind ik het dus niet meer relevant. En andersom: als een werkgever die IQ test belangrijk vindt, dan selecteert hij wat mij betreft niet goed en ga ik mij serieus zorgen maken over het niveau van de functie.

[ Voor 13% gewijzigd door Lethalis op 16-05-2018 00:21 ]

[Hydra]

Harrie_ schreef op dinsdag 15 mei 2018 @ 19:43:
@Mugwump @Hydra Ik zou haast zeggen vanzelfsprekend bedoel ik "als het werkt niet meer aanraken" als grap en zet ik het neer als een stukje zelfspot, wetende dat ik nog een hoop te leren heb. Heeft geen verdere uitleg nodig denk ik.

Dat kan ik van afstand niet ruiken. Er zijn hordes slechte developers in NL die precies die instelling hebben; een beetje shit in elkaar knutselen tot het 'werkt' en er dan niet meer aankomen. En zich dan later afvragen waarom het hele systeem een grote teringzooi geworden is.

Dat jij het als grap bedoelt weet ik niet. Ik krijg hier meteen jeuk, rode uitslag en hoofdpijn van (grap)

[Tjolk]

DirkZzZ schreef op dinsdag 15 mei 2018 @ 20:27:
[...]


In welke regio?

Als de wind de goede kant op staat horen we soms het treintje van de Efteling.

Lethalis schreef op dinsdag 15 mei 2018 @ 23:20:
[...]

Wat is "best prima" ?

Meestal is de conclusie toch dat je te weinig betaalt...

Of je zit in een krimpregio. Meeste developers trekken richting de randstad omdat daar het meeste werk is.

Midden Brabant dus. Niet echt een krimpregio. Categorie 45-50k per jaar.

Ik ken geen enkele junior die dat waard is.

[Jantje2000]

Logisch, want als die het wel waard is, is het geen junior meer.

[Sandor_Clegane]

Jantje2000 schreef op woensdag 16 mei 2018 @ 09:01:
Logisch, want als die het wel waard is, is het geen junior meer.

heh

[Ryur]

Hydra schreef op woensdag 16 mei 2018 @ 08:21:
[...]


Dat kan ik van afstand niet ruiken. Er zijn hordes slechte developers in NL die precies die instelling hebben; een beetje shit in elkaar knutselen tot het 'werkt' en er dan niet meer aankomen. En zich dan later afvragen waarom het hele systeem een grote teringzooi geworden is.

Jep. Ik heb er veel mee te maken gehad. Wordt zo moe van 'dat soort' programmeurs.

[bwerg]

Hydra schreef op dinsdag 15 mei 2018 @ 14:33:
OO werken gaat niet om een paar regeltjes code op manier A of manier B doen. Het gaat om dingen netjes bij elkaar zetten als ze bij elkaar horen en dat dan af te schermen voor de buitenwereld. Je hebt geen OO taal nodig om OO te werken (het helpt wel enorm natuurlijk), dat kun je ook in C doen. Check de SOLID basisprinciepes van OO programmeren.

SOLID gaat om te beginnen al uit van classes en inheritance, dus hoewel uiteindelijk dezelfde principes belangrijk zijn als in imperatief en FP, gaat het toch wat ver om dat OO te noemen. In FP bereik je die principes op een andere manier dan met classes. Ja, je kan SOLID wel gemakkelijk vertalen naar het niveau van modules in Haskell, maar dat is dan wel een vrije interpretatie. Ik zou net zo gemakkelijk kunnen zeggen dat alle code functioneel is.

Misschien is een betere stelling 'OO, FP of imperatief maakt geen drol uit, zolang je code maar netjes (onderhoudbaar, modulair, verzin maar...) is'.

[ Voor 16% gewijzigd door bwerg op 16-05-2018 09:31 ]

[Hydra]

bwerg schreef op woensdag 16 mei 2018 @ 09:23:
SOLID gaat om te beginnen al uit van classes en inheritance, dus hoewel uiteindelijk dezelfde principes belangrijk zijn als in imperatief en FP, gaat het toch wat ver om dat OO te noemen.

Ik snap niet helemaal wat je hiermee bedoelt? Ik "noem" SOLID geen OO. Ik zeg dat OO niet om syntax draait maar om hoe je je code ontwerpt. De SOLID 'regels' en de GoF design patterns zijn slechts een paar voorbeelden.

Misschien is een betere stelling 'OO, FP of imperatief maakt geen drol uit, zolang je code maar netjes (onderhoudbaar, modulair, verzin maar...) is'.

Dat sowieso! Heb genoeg rotzooi Java gezien om te weten dat een OO taal absoluut geen garantie is

[ Voor 21% gewijzigd door Hydra op 16-05-2018 09:38 ]

[Harrie_]

Hydra schreef op woensdag 16 mei 2018 @ 09:37:
[...]
Ik zeg dat OO niet om syntax draait maar om hoe je je code ontwerpt.
[...]

Dit

[Mugwump]

bwerg schreef op woensdag 16 mei 2018 @ 09:23:
[...]

SOLID gaat om te beginnen al uit van classes en inheritance, dus hoewel uiteindelijk dezelfde principes belangrijk zijn als in imperatief en FP, gaat het toch wat ver om dat OO te noemen. In FP bereik je die principes op een andere manier dan met classes. Ja, je kan SOLID wel gemakkelijk vertalen naar het niveau van modules in Haskell, maar dat is dan wel een vrije interpretatie. Ik zou net zo gemakkelijk kunnen zeggen dat alle code functioneel is.

Ik zou dat zeker niet willen zeggen, het is wel een vrij strak afgebakend paradigma. Je kunt wel stellen dat je vrijwel alle problemen op functionele wijze kunt oplossen, maar dat is een ander verhaal.

Misschien is een betere stelling 'OO, FP of imperatief maakt geen drol uit, zolang je code maar netjes (onderhoudbaar, modulair, verzin maar...) is'.

Dat geldt natuurlijk altijd, maar feit is in mijn ogen wel dat FP en OO je een stuk meer dwingen om over dat soort zaken na te denken dan bijvoorbeeld in PHP. Er zit bovendien ook nog wel een verschil tussen PHP en C. Beiden zijn imperatief, maar in de basis is PHP geen gecompileerde taal terwijl C dat wel is.

[RayNbow]

Mugwump schreef op woensdag 16 mei 2018 @ 11:47:
maar in de basis is PHP geen gecompileerde taal terwijl C dat wel is.

Of er wel of geen compiler bestaat staat toch los van de kwaliteiten van een taal?

[bwerg]

Mugwump schreef op woensdag 16 mei 2018 @ 11:47:
Ik zou dat zeker niet willen zeggen, het is wel een vrij strak afgebakend paradigma. Je kunt wel stellen dat je vrijwel alle problemen op functionele wijze kunt oplossen, maar dat is een ander verhaal.

Precies, en mijn punt was vooral dat OO ook wel afgebakend is. Dat je OO kunt doen zonder OO-taal zou ik dus óók niet willen zeggen.

Ja, je kan structs maken in C en doen alsof het objecten zijn, net zoals dat je function pointers kunt rondgeven alsof het functionele expressies zijn. Maar of je dan OO of functioneel aan het programmeren bent...

[ThomasG]

RayNbow schreef op woensdag 16 mei 2018 @ 12:08:
[...]

Of er wel of geen compiler bestaat staat toch los van de kwaliteiten van een taal?

Ja. Het 'probleem' van PHP is eerder dat het loosely typed is, en als je abacadabra troep schrijft dat gewoon geslikt wordt en vaak ook gewoon werkt.

[Matis]

Ik kan prima strong typed bullshit typen dat de compiler slikt, maar op z'n bek gaat tijdens het uitvoeren.

[ZaZ]

Matis schreef op woensdag 16 mei 2018 @ 12:18:
Ik kan prima strong typed bullshit typen dat de compiler slikt, maar op z'n bek gaat tijdens het uitvoeren.

Toch heb ik in talen die niet strong typed zijn altijd gelazer dat er bijvoorbeeld ergens een variabele ooit eens als "recieved" is gedeclareerd en ik "received" ga gebruiken.
Duurt dan altijd veel te lang voordat het mij opvalt.

[Lethalis]

Tjolk schreef op woensdag 16 mei 2018 @ 08:56:
[...]
Als de wind de goede kant op staat horen we soms het treintje van de Efteling.

Midden Brabant dus. Niet echt een krimpregio. Categorie 45-50k per jaar.

Ik ken geen enkele junior die dat waard is.

Heb je ook gelijk in. 45-50k is een prima salaris voor een ervaren developer.

Maar midden Brabant is misschien toch lastiger dan hartje Utrecht of Rotterdam.

[Mugwump]

RayNbow schreef op woensdag 16 mei 2018 @ 12:08:
[...]

Of er wel of geen compiler bestaat staat toch los van de kwaliteiten van een taal?

Het zegt niet zozeer wat over de kwaliteit van een taal, maar wel over de kwaliteit van de output. Een compiler vangt uiteraard lang niet alle problemen voor je af, maar het zorgt wel dat je in ieder geval nog iets van basale controle hebt. Natuurlijk heeft dat ook deels te maken met bijvoorbeeld het type system, maar zaken die door een compiler compile-time afgevangen worden kunnen in een geïnterpreteerde taal doodleuk in je productiecode terechtkomen omdat ze in de praktijk eigenlijk niet of nooit worden geraakt. Totdat er opeens wat omstandigheden veranderen waardoor dat wel het geval is.

[bauke1994]

ZaZ schreef op woensdag 16 mei 2018 @ 12:25:
[...]

Toch heb ik in talen die niet strong typed zijn altijd gelazer dat er bijvoorbeeld ergens een variabele ooit eens als "recieved" is gedeclareerd en ik "received" ga gebruiken.
Duurt dan altijd veel te lang voordat het mij opvalt.

Dat heeft niks te maken met strongly of weakly typed talen maar of het een geïnterpreteerde of gecompileerde taal is.

[Lethalis]

Mugwump schreef op woensdag 16 mei 2018 @ 12:54:
[...]
Het zegt niet zozeer wat over de kwaliteit van een taal, maar wel over de kwaliteit van de output. Een compiler vangt uiteraard lang niet alle problemen voor je af, maar het zorgt wel dat je in ieder geval nog iets van basale controle hebt.

Helemaal mee eens.

Dit is ook de reden dat ik TypeScript gebruik. Het vangt voor mij een hoop ellende af die ik normaal gesproken met JavaScript tegenkom.

[Stemis]

ZaZ schreef op woensdag 16 mei 2018 @ 12:25:
[...]

Toch heb ik in talen die niet strong typed zijn altijd gelazer dat er bijvoorbeeld ergens een variabele ooit eens als "recieved" is gedeclareerd en ik "received" ga gebruiken.
Duurt dan altijd veel te lang voordat het mij opvalt.

Met welke talen heb je deze problemen ?
Je IDE vangt autocompletion en undeclared var's gewoon af.

Voor javascript gebruik ik altijd Typescript

Voor PHP kan je in je docblocks de properties definieren als deze door je ORM via __set en __get gaan. Je IDE geeft dat aan als er een veld niet bestaat. Je kan ook vars typehinten via docblocks ie:

code:

/**
 * @property string $name
**/
class User extends Model {
    __get($varName) {
        if($varName == 'name') {
            return 'The user his name';
        }
    }
}

$user = new User();
echo $user->name; // <-- autocompleted

/** @var Router */
$router = app(Router::class);

Zo werkt je autocompletion ook een stuk beter en hoef je niet te onthouden hoe alles heet.

Het ligt er ook maar net aan hoe je dingen gebruikt.

De vraag is dan ook: Is het een gebrek van de taal of je eigen keuze om tijd te besparen op korte termijn en dingen niet goed te definieren.

Andere talen zoals C# dwingen het af om je types te definieren en daardoor heb je wel meer controle, maar autocompletion en undefined property checks kunnen dus gewoon via je IDE voor bepaalde talen.

[ Voor 21% gewijzigd door Stemis op 16-05-2018 13:25 ]

[Mugwump]

Stemis schreef op woensdag 16 mei 2018 @ 13:14:
[...]


Met welke talen heb je deze problemen ?
Je IDE vangt autocompletion en undeclared var's gewoon af.

In mijn ervaring valt het nog wel tegen met de wijze waarop IDEs in staat zijn om in JavaScript en PHP te bepalen wat de juiste zaken zijn waarnaar gerefereerd wordt. In je voorbeeldje heb je alles in één file en dan is het niet zo'n punt, maar als je meerdere classes met dezelfde namen hebt met dynamische loads / includes, dan wordt het al snel lastig voor de IDE. Soms is er aardige frameworksupport waardoor het redelijk werkt, maar het zit echt niet op het niveau van Java (en afgeleiden) of C# in bijvoorbeeld IntelliJ of VS.

[Harrie_]

ThomasG schreef op woensdag 16 mei 2018 @ 12:14:
[...]
Ja. Het 'probleem' van PHP is eerder dat het loosely typed is, en als je abacadabra troep schrijft dat gewoon geslikt wordt en vaak ook gewoon werkt.

Daar komt iedereen altijd mee maar ik snap nog steeds niet wat het probleem dan precies is. Je bent er als dev toch zelf bij? Op het moment dat er abracadabra troep wordt geschreven dan ligt het probleem bij de dev.

[ThomasG]

Harrie_ schreef op woensdag 16 mei 2018 @ 14:00:
[...]


Daar komt iedereen altijd mee maar ik snap nog steeds niet wat het probleem dan precies is. Je bent er als dev toch zelf bij? Op het moment dat er abracadabra troep wordt geschreven dan ligt het probleem bij de dev.

Ja, je bent daar als dev bij. Maar het probleem is dat PHP dat gewoon slikt. En als je een beginnende dev hebt die questionable code schrijft en een taal die dat gewoon zonder problemen slikt, dan krijg je situaties: het 'werkt', dus zal het wel goed zijn. Met alle gevolgen van dien op langer termijn. Zowel voor de code als die developer.

[Matis]

ThomasG schreef op woensdag 16 mei 2018 @ 14:07:
Ja, je bent daar als dev bij. Maar het probleem is dat PHP dat gewoon slikt. En als je een beginnende dev hebt die questionable code schrijft en een taal die dat gewoon zonder problemen slikt, dan krijg je situaties: het 'werkt', dus zal het wel goed zijn. Met alle gevolgen van dien op langer termijn. Zowel voor de code als die developer.

Wel eens van (code)reviews gehoord?

[Tjolk]

ThomasG schreef op woensdag 16 mei 2018 @ 14:07:
[...]
Ja, je bent daar als dev bij. Maar het probleem is dat PHP dat gewoon slikt. En als je een beginnende dev hebt die questionable code schrijft en een taal die dat gewoon zonder problemen slikt, dan krijg je situaties: het 'werkt', dus zal het wel goed zijn. Met alle gevolgen van dien op langer termijn. Zowel voor de code als die developer.

Meestal leidt dat wel tot volgelopen logs met een shitload aan notices. Je kunt PHP verwijten dat het alsnog uitgevoerd wordt, maar het is de dev te verwijten dat het niet ook in productie genomen wordt. Ik weet nog bij mijn vorige werkgever dat dit dus het geval was; onze voorganger had er dermate een bende van gemaakt dat mijn collega (iets voor mij begonnen) een statistiek tooltje gemaakt had om alle notices, warnings, etc. uit te lezen en onze primaire focus was in eerste instantie alle troep op te lossen en die logs schoon te krijgen en zo die grafiek naar de x-as te brengen.

Bak ellende, maar n.m.m. lag dat niet aan PHP maar aan onze voorganger: die had inderdaad de insteek: als het werkt dan is het prima (en kan ik rustig boven mijn toetsenbord in slaap vallen).
Vaak getuigt zo'n insteek van een bepaalde werkhouding, en kun je ook op je klompen aanvoelen dat er ook veel mis is wat niet in de logs verschijnt. Ook dat ligt niet aan PHP maar gewoon aan de dev.

Het excuus 'beginner' vind ik een zwaktebod: leuk als je voor Ome Henk zijn tatoo shop een websiteje bouwt, maar als je als professional aan de slag gaat moet je gewoon weten waar je mee bezig bent.

[ThomasG]

Tjolk schreef op woensdag 16 mei 2018 @ 14:23:
[...]

Meestal leidt dat wel tot volgelopen logs met een shitload aan notices. Je kunt PHP verwijten dat het alsnog uitgevoerd wordt, maar het is de dev te verwijten dat het niet ook in productie genomen wordt. Ik weet nog bij mijn vorige werkgever dat dit dus het geval was; onze voorganger had er dermate een bende van gemaakt dat mijn collega (iets voor mij begonnen) een statistiek tooltje gemaakt had om alle notices, warnings, etc. uit te lezen en onze primaire focus was in eerste instantie alle troep op te lossen en die logs schoon te krijgen en zo die grafiek naar de x-as te brengen.

Bak ellende, maar n.m.m. lag dat niet aan PHP maar aan onze voorganger: die had inderdaad de insteek: als het werkt dan is het prima (en kan ik rustig boven mijn toetsenbord in slaap vallen).
Vaak getuigt zo'n insteek van een bepaalde werkhouding, en kun je ook op je klompen aanvoelen dat er ook veel mis is wat niet in de logs verschijnt. Ook dat ligt niet aan PHP maar gewoon aan de dev.

Het excuus 'beginner' vind ik een zwaktebod: leuk als je voor Ome Henk zijn tatoo shop een websiteje bouwt, maar als je als professional aan de slag gaat moet je gewoon weten waar je mee bezig bent.

Het ligt ook aan de dev. En ja, anzich is er niets is met PHP (als je weet wat je doet). Het probleem ontstaat als je dat niet weet. Het internet staat bijvoorbeeld vol met slechte PHP code. En PHP slikt dat gewoon. Als je als, bijvoorbeeld, beginnende programmeur met PHP begint en tegen een probleem aanloopt, dan zoeken ze op internet naar oplossingen. En dan is de kans groot dat ze een dat dan overnemen, en dat aannemen als juist; want zo doen andere het ook, en het werkt toch? Mijn probleem is dan ook niet PHP anzich, maar dat PHP het zo ontzettend makkelijk maakt om troep te schrijven. Dat probleem speelt bij andere talen ook, maar dan is het omdat ze bijvoorbeeld strong typed zijn en/of compiled zijn een kleiner probleem, omdat de programmeur vanuit de taal feedback krijgt dat ze 'fout' bezig zijn.

Matis schreef op woensdag 16 mei 2018 @ 14:14:
[...]

Wel eens van (code)reviews gehoord?

Waar je dus niets aan hebt als niemand van die programmeurs zich ervan bewust is dat ze iets fout doen, omdat de taal het zonder morrelen slikt. Maar goed, jullie gaan er allemaal vanuit dat er ervaren programmeur bij zitten die weten wat ze doen. Wat ik bedoel zijn de problemen als die er niet bij zijn.

[ Voor 9% gewijzigd door ThomasG op 16-05-2018 14:37 ]

[Lethalis]

ThomasG schreef op woensdag 16 mei 2018 @ 14:35:
[...]
Maar goed, jullie gaan er allemaal vanuit dat er ervaren programmeur bij zitten die weten wat ze doen. Wat ik bedoel zijn de problemen als die er niet bij zijn.

Nou jongens, hier is jullie piloot voor vandaag. Hans vliegt vandaag voor het eerst in een Boeing 747. Voor de veiligheid zal de autopiloot zoveel mogelijk alles in goede banen leiden.

Succes allemaal!

[Hydra]

Harrie_ schreef op woensdag 16 mei 2018 @ 14:00:
Daar komt iedereen altijd mee maar ik snap nog steeds niet wat het probleem dan precies is. Je bent er als dev toch zelf bij? Op het moment dat er abracadabra troep wordt geschreven dan ligt het probleem bij de dev.

We zijn allemaal mensen en dynamisch talen zijn een beetje als communisme: in theory werkt 't perfect maar in de praktijk zijn wel allemaal mensen met allemaal problemen die ook maar hun shit proberen af te krijgen. Als je tooling je daarbij kan helpen; top.

M.i. zijn dynamische talen waardeloos en m'n tijd niet waard. Ze schelen je alleen tijd in het begin of hele simpele scriptjes. Als je niet triviale shit moet schrijven is het gewoon beter domme trivialiteiten aan de tooling over te kunnen laten zodat je je kan focussen op de zaken die wel echt belangrijk zijn.

Ik vind het wel grappig dat er gesproken wordt over 'ervaren' programmeurs. Alsof mensen hier geen fouten maken. Ik ben zelf 'ervaren' maar geef graag toe dat ik regelmatig fouten maak. Dat toegeven is een eerste stap je te verbeteren. Ervaren developers (en ik heb het hier niet over jullie) die denken geen fouten te maken zijn in mijn ogen gewoon juniors en nog wel de ergste soort.

[ Voor 17% gewijzigd door Hydra op 16-05-2018 14:50 ]

[Lethalis]

Hydra schreef op woensdag 16 mei 2018 @ 14:48:
[...]
Ik vind het wel grappig dat er gesproken wordt over 'ervaren' programmeurs. Alsof mensen hier geen fouten maken. Ik ben zelf 'ervaren' maar geef graag toe dat ik regelmatig fouten maak. Dat toegeven is een eerste stap je te verbeteren. Ervaren developers (en ik heb het hier niet over jullie) die denken geen fouten te maken zijn in mijn ogen gewoon juniors en nog wel de ergste soort.

"The more I learn, the more I realize how much I don't know." - Albert Einstein

Ik ervaar dat ook echt zo.

En wat mijn vader altijd zei: "In het land der blinden is de éénoog koning".

Maar goed, een team zonder ook maar 1 "ervaren" persoon is in mijn ogen al gauw een ongeleid projectiel. Er moet op zijn minst 1 iemand bij zitten die al vaker op zijn bek is gegaan en daardoor - in grote lijnen - weet waar de valkuilen liggen.

[farlane]

Daarbij komt dat (veel?) ervaren programmeurs ook crap maken. Ik heb veel liever goede programmeurs...

[Hydra]

farlane schreef op woensdag 16 mei 2018 @ 15:05:
Daarbij komt dat (veel?) ervaren programmeurs ook crap maken. Ik heb veel liever goede programmeurs...

We hebben hier een "ervaren" programmeur die er ook een behoorlijke zooi van maakt. Probleem is dat dat dan vaak op architectuur niveau is. Zie dat dan maar eens recht te trekken.

[armageddon_2k1]

Hebben jullie ook vaak dat als je een unit test schrijft en hij faalt je erachter komt dat de functie z'n werk eigenlijk prima doet, maar jouw expected result foutief was?

[Lethalis]

Hydra schreef op woensdag 16 mei 2018 @ 15:10:
[...]


We hebben hier een "ervaren" programmeur die er ook een behoorlijke zooi van maakt. Probleem is dat dat dan vaak op architectuur niveau is. Zie dat dan maar eens recht te trekken.

Maar wat gebeurt er dan als hij daarop wordt aangesproken?

[ThomasG]

armageddon_2k1 schreef op woensdag 16 mei 2018 @ 15:13:
Hebben jullie ook vaak dat als je een unit test schrijft en hij faalt je erachter komt dat de functie z'n werk eigenlijk prima doet, maar jouw expected result foutief was?

Ik heb wel eens gehad dat ik door een specifieke bug (per ongeluk) een datum met hardcoded jaartal in m'n unit test had gezet. En dat werkte prima, tot we in een nieuw jaar aankwamen en op 1 januari de unit test niet meer werkte waardoor de builds faalde

[Matis]

ThomasG schreef op woensdag 16 mei 2018 @ 15:30:
Ik heb wel eens gehad dat ik door een specifieke bug (per ongeluk) een datum met hardcoded jaartal in m'n unit test had gezet. En dat werkte prima, tot we in een nieuw jaar aankwamen en op 1 januari de unit test niet meer werkte waardoor de builds faalde

Ja herkenbaar.

Of unit tests die in een andere localization een ander test resultaat opleverde

Wij draaien hier up en-US, collega's in het VK draaien dus en-GB.

[ Voor 6% gewijzigd door Matis op 16-05-2018 15:33 . Reden: GB ]

[DevWouter]

armageddon_2k1 schreef op woensdag 16 mei 2018 @ 15:13:
Hebben jullie ook vaak dat als je een unit test schrijft en hij faalt je erachter komt dat de functie z'n werk eigenlijk prima doet, maar jouw expected result foutief was?

Ik heb het erger. Ik draai expected en actual continue om

[Mugwump]

armageddon_2k1 schreef op woensdag 16 mei 2018 @ 15:13:
Hebben jullie ook vaak dat als je een unit test schrijft en hij faalt je erachter komt dat de functie z'n werk eigenlijk prima doet, maar jouw expected result foutief was?

Ik heb daar nogal eens copy-paste cases inzitten waarbij ik dan wel de input aanpas, maar vergeet om de assertion ook even te inverten.

[Hydra]

Lethalis schreef op woensdag 16 mei 2018 @ 15:20:
Maar wat gebeurt er dan als hij daarop wordt aangesproken?

Niks. Hij's ouder dus heeft z'n gelijk ingebouwd. Erg frustrerend.

[bwerg]

bauke1994 schreef op woensdag 16 mei 2018 @ 13:06:
[...]


Dat heeft niks te maken met strongly of weakly typed talen maar of het een geïnterpreteerde of gecompileerde taal is.

Nee, daar heeft het ook niets mee te maken.

Ook een interpreter kan prima statische checks doen (veel talen die standaard gecompileerd worden hebben ook gewoon een interactieve interpreter), en ook een compiler kan gewoon flauwekul-statements slikken (en code genereren die onvermijdelijk fouten gooit). Er bestaan bijvoorbeeld gewoon python-compilers, die (als ze standaard python slikken, geen idee - nooit geprobeerd) onvermijdelijk variable-not-defined-fouten moeten gooien tijdens runtime.

Compiled of interpreted is niets anders dan het direct uitvoeren ofwel wegschrijven van een low-level representatie (machine, java bytecode, etc) en heeft niets met wel of geen foutmeldingen te maken, behalve dat het wat handiger is om voor compilen zoveel mogelijk statische checks te doen.

[ Voor 5% gewijzigd door bwerg op 16-05-2018 16:52 ]

[whoami]

ThomasG schreef op woensdag 16 mei 2018 @ 14:35:
[...]
[...]
Waar je dus niets aan hebt als niemand van die programmeurs zich ervan bewust is dat ze iets fout doen, omdat de taal het zonder morrelen slikt. Maar goed, jullie gaan er allemaal vanuit dat er ervaren programmeur bij zitten die weten wat ze doen. Wat ik bedoel zijn de problemen als die er niet bij zijn.

Dan is er imo iets fout aan de samenstelling van het team
Bij ons wordt een team samengesteld uit x aantal juniors met minstens één sr die wel weet hoe het moet.

Voordat code kan gemerged worden naar develop of master (afhankelijk hoe de opzet is), moet de PullRequest eerst geapproved worden door 2 team-members.

[Hydra]

bwerg schreef op woensdag 16 mei 2018 @ 16:48:
Compiled of interpreted is niets anders dan het direct uitvoeren ofwel wegschrijven van een low-level representatie (machine, java bytecode, etc) en heeft niets met wel of geen foutmeldingen te maken, behalve dat het wat handiger is om voor compilen zoveel mogelijk statische checks te doen.

Sowieso is een taal zelf nooit "compiled" of "interpreted". Kijk maar naar JavaScript; hoe het afgehandeld wordt ligt compleet aan de engine die gebruikt wordt. Daarnaast is het onderscheid ook nog eens vrij zinloos aangezien vrijwel alles tegenwoordig op z'n minst JIT compiled wordt.