ICT en de framework madness, begrijpen we elkaar nog? Zoektocht 100% match

Door Erwines op donderdag 8 juni 2017 07:00 - Reacties (29)
Categorie: -, Views: 4.617

Onderstaand vacature (zie link onderaan) doet mij heel erg denken aan huidige staat van de I(C)T met haar excessieve framework gebruik, voor elke programmeertaal, dat juist in toenemende mate groepen mensen uit elkaar drijft ipv verbind, welke in basis dezelfde (programmeer-) taal zouden moeten of kunnen 'spreken' zonder specifiek dialect (=framework).

Mensen, HRM people in de I(C)T branche, onderstaande lijkt wat banaal voor u maar dat is een exacte beschrijving van de banale situatie in vraag en aanbod, vraag de vereiste taal en geen dialect, het komt nogal unfair over (zoals onderstaande vacature KLM duidelijk laat zien). Elk weldenkend mens vind dit een rare vacature en zal nooit leiden tot het vinden van kwalitatief goed personeel, het stoot de juist de juiste mensen af omdat de omschrijving een afstotend effect heeft als het niet bekend in de oren klinkt, met 'vage' terminologie smijten.

Vraag de taal die gewenst is en spreek onderling af wat het dialect moet zijn, maar stel dat niet als een vereiste als we in basis dezelfde taal moeten beheersen.

Stop met het proberen te vinden van de 100% match, kwalitatieve mensen worden buitengesloten door het vereisen van een dialect, het is idioot, banaal en tevens oneerlijk. Iemand die taal goed beheerst is niets meer waard als deze het dialect niet beheerst, sorry maar dat is écht niet goed. Geef mensen de kans het dialect te leren als er bereidheid is om het te leren.

Link wat mij triggerde om dit te posten:
http://www.geenstijl.nl/m...7/05/nee_nee_nee_klm.html

"Framework hell". een artikel geschreven door iemand anders maar beschrijft precies wat ik ook denk en voel:
https://medium.com/@garyw...amework-hell-aa54a9b5d4fd

Volgende: Javascript templating, waarom niet? 19-06 Javascript templating, waarom niet?
Volgende: Domeinnaam verkopen 11-'16 Domeinnaam verkopen

Reacties


Door Tweakers user Brandts, donderdag 8 juni 2017 07:49

Heb je ook een voorbeeld van zo'n vacature in de I(C)T?

Door Tweakers user Pantagruel, donderdag 8 juni 2017 08:48

Niet mekkeren, tegenwoordig krijg je een auto-reply binnen 20 sec met de afwijzing.

Geen mensen oog kijkt of de brief/ 't cv voldoet, de 'smart' software scant je gegevens en als er te weinig overlap/match is lig je al in de bit bucket.

Door Tweakers user fvdberg, donderdag 8 juni 2017 09:33

zo reageerde ik ooit op een vacature als ict-inkoper bij een scholengemeenschap, maar ik werdt afgewezen met als reden dat ik te veel ict kennis had.

Door Tweakers user DjentPirate, donderdag 8 juni 2017 10:39

fvdberg schreef op donderdag 8 juni 2017 @ 09:33:
zo reageerde ik ooit op een vacature als ict-inkoper bij een scholengemeenschap, maar ik werdt afgewezen met als reden dat ik te veel ict kennis had.
Afgewezen bij een scholengemeenschap vanwege je ict kennis? Ik denk dat het daar niet aan lag.. :p

Door Tweakers user xFeverr, donderdag 8 juni 2017 11:05

fvdberg schreef op donderdag 8 juni 2017 @ 09:33:
zo reageerde ik ooit op een vacature als ict-inkoper bij een scholengemeenschap, maar ik werdt afgewezen met als reden dat ik te veel ict kennis had.
Tsja... Het kan ook niet anders dan dat ze op veel scholen juist expres de slechtste mensen uitkiezen. Ongelooflijk wat daar soms rond loopt

Door Tweakers user johnkeates, donderdag 8 juni 2017 15:18

Als ik in een team een extra FTE nodig heb die na een week inwerken 100% productief kan zijn moet ik wel iemand hebben die de gebruikte technologie al begrijpt. Ik heb niks aan iemand die 'OOP' en "functioneel" en "SCM/VCS" in het algemeen kent. Sure, je kan de specifieke implementatie van wat er gebruikt wordt waarschijnlijk prima leren en na een maandje opstarten vast heel productief zijn, maar dat kan iemand uit Roemenië ook, en die is 10x goedkoper.

Als je ergens wil werken maar niks te bieden hebt t.o.v. iemand die de gebruikte talen, frameworks en workflow wel kent, dan solliciteer je dus al met een achterstand.

[Reactie gewijzigd op donderdag 8 juni 2017 15:19]


Door Tweakers user Erwines, donderdag 8 juni 2017 15:24

Brandts schreef op donderdag 8 juni 2017 @ 07:49:
Heb je ook een voorbeeld van zo'n vacature in de I(C)T?
Niet bij zo 1,2,3 bij de hand maar misschien kan ik je verbeelding aanspreken, bijvoorbeeld jQuery versus AngularJs bijvoorbeeld. AngularJs is bijvoorbeeld geen tool, dat is een herdefinitie van de taal, manier van oplossen, een model, op de basis waarop het leunt, in dit geval javascript. Lees anders even het tweede artikel dat precies aangeeft wat er mis is:
"Framework hell" https://medium.com/@garyw...amework-hell-aa54a9b5d4fd

Er zijn zelfs programmeurs die leren het framework als taal leren met het gevolg dat ze helemaal vastgebakken zitten aan dat framework. Een framework is in feite een gedachtegang van één of meerdere programmeurs (zoals vroeger, de eigenwijze programmeur met eigen oplossing) alleen dan groter uitgemeten omdat het idee gepubliceerd is op het net en opgepikt door een grote groep mensen, die daar een hype van maken. Zo krijg je dus steeds meer eilandjes met verschillende dialecten. Sterker nog, de taal waarop het leunt verdwijnt naar de achtergrond. Het is geen programmeren meer, het is modelleren, een geforceerde denkwijze om tot een oplossing te komen.

Bijvoorbeeld in een vacature van Philips werd AngularJs vereist (terwijl dat nog niet eens zo lang bestaat), het woord javascript kwam niet voor. Dus als ik solliciteer met javascript op mijn CV, ondersteunend met verschillende frameworks maar niet AngularJs, dan word je het niet.

Dus als het woord AngularJs niet voorkomt op mijn CV, dan val ik in het bakje "ongeschikt" terwijl ik jaren lang ervaring heb met de programmeertaal zelf (ken alle in en outs) en ken ook nog eens verschillende andere frameworks. Dat is dan niet voldoende? Vind dat nogal een belediging (en onbegrijpelijk) eigenlijk, ze zoeken dus programmeurs die een trucje kunnen, dat is dat framework dus.

Dit is nog maar een voorbeeld, er zijn onnoemelijk veel frameworks dat script/programmeertalen fragmenteert in allerlei eilandjes, smaakjes. Moet echt een halt worden toegeroepen een framework te behandelen als programmeertaal.

[Reactie gewijzigd op donderdag 8 juni 2017 16:17]


Door Tweakers user Erwines, donderdag 8 juni 2017 15:33

johnkeates schreef op donderdag 8 juni 2017 @ 15:18:
Als ik in een team een extra FTE nodig heb die na een week inwerken 100% productief kan zijn moet ik wel iemand hebben die de gebruikte technologie al begrijpt. Ik heb niks aan iemand die 'OOP' en "functioneel" en "SCM/VCS" in het algemeen kent. Sure, je kan de specifieke implementatie van wat er gebruikt wordt waarschijnlijk prima leren en na een maandje opstarten vast heel productief zijn, maar dat kan iemand uit Roemenië ook, en die is 10x goedkoper.

Als je ergens wil werken maar niks te bieden hebt t.o.v. iemand die de gebruikte talen, frameworks en workflow wel kent, dan solliciteer je dus al met een achterstand.
Jij bevestigd het, je moet het trucje kunnen. Het is nogal cru om van een achterstand te spreken, je kent even niet wat de specifieke markt vraagt op dat moment en je mag het ook niet leren want dat kost teveel. Je kan natuurlijk andere dingen dan hartstikke goed weten maar dat is dan helemaal niets meer waard omdat je dat ene trucje niet op je CV hebt staan. Programmeren is lopende band werk. Dit is krankzinnig.Het gaat echt alleen maar over geld, geen langer termijn maar kort termijn

[Reactie gewijzigd op zaterdag 10 juni 2017 00:20]


Door Tweakers user Erwines, donderdag 8 juni 2017 15:34

.....................................................................

[Reactie gewijzigd op donderdag 8 juni 2017 15:42]


Door Tweakers user solidous, donderdag 8 juni 2017 23:16

Erwines schreef op donderdag 8 juni 2017 @ 15:24:
[...]

Er zijn zelfs programmeurs die leren het framework als taal leren met het gevolg dat ze helemaal vastgebakken zitten aan dat framework. ..

Bijvoorbeeld in een vacature van Philips werd AngularJs vereist (terwijl dat nog niet eens zo lang bestaat), het woord javascript kwam niet voor. Dus als ik solliciteer met javascript op mijn CV, ondersteunend met verschillende frameworks maar niet AngularJs, dan word je het niet.

...
Dat probleem heb ik ook. Het probleem ligt niet aan HRM maar aan de lead developer van dat bedrijf dat mensen zoekt. Als hij zegt zegt dat de sollicitant dit-en-dat moet kennen, dan wordt het 1-op-1 doorgezet naar de projectleider en vervolgens stuurt die het weer door naar de HRM of externe recruiters.

Wat mij betreft is framework en library kennis een pre en geen knockout eis.
Het probleem is dat het ook niet ophoudt bij frameworks, maar ook kennis van libraries in Github. Ik weet niet hoeveel gigabytes dagelijks aan nieuwe code in Github wordt geprop, dat hou je echt niet bij.

Frameworks en libraries zijn net als bederf goederen beperkt houdbaar. Voor je het weet moet je upgraden/migreren, omdat security bugs niet meer verholpen wordt.

Sommige frameworks zijn ook irritant door slechte documentie. Ik weet wel hoe ik in dat programmeertaal moet maken, maar niet in dat framework of library. Ik moet soms noodgedwongen urenlang uitzoeken welke objecten en vage framework magic ik moet aanroepen om datzelfde resultaat te krijgen.

Bedrijven dat perse een specifiek framework of library programmeur zoekt, zijn niet de moeite waard om voor te werken. Je leert nauwelijks hoe je een businiess case moet oplossen, maar meer hoe krijg ik deze magic werkend met dit framework. Je zal ook nooit out-of-the-box denken, want je bent 100% afhankelijk van het framework.

Door Tweakers user Oerdond3r, vrijdag 9 juni 2017 01:31

Frameworks zijn vandaag de dag een vereiste voor applicatieontwikkeling. En terecht. Een goed framework biedt veiligheid out-of-the-box. Een goed framework houdt je code schaalbaar, en zorgt ervoor dat je snel een applicatie kan opzetten.

Het enige nadeel zijn inderdaad de leercurve en de wildgroei. Onder andere op het gebied van Frontend Webdevelopment ( laten we het dan nog niet eens over backend dingen hebben ), was het 3(?) jaar terug nog normaal om alleen JQuery te gebruiken. Opeens was daar Angular, wat een compleet andere manier van applicaties opbouwen gaf. Sinds vorig jaar ongeveer besloot niet alleen Angular met een complete rewrite te komen ( Angular 2 ). Maar kwam ook React om de hoek kijken, wat dus ook weer een compleet andere methodiek.

Parallel aan deze ontwikkelingen is er ook nog een enorme evolutie geweest in de manier van package management via Bower, Npm ( van Node ) of drop-in placement van Npm: Yarn. Om al je Javascript en CSS bij volautomatisch bij elkaar te gooien is volgens mij het nieuwste van het nieuwste wat je er tegenwoordig voor kan gebruiken WebPack.

En tegelijkertijd is de onderliggende taal Javascript ook aan verandering toegeweest. Ecmascript 6 is nu een ding, met allemaal nieuw spul wat niet op alle browsers werkt, dus heb je daar ook nog een transpiler voor verzonnen. Ondertussen hadden ze bij Angular 2 besloten TypeScript te gebruiken ( een dialect op Javascript van Microsoft ) die ook weer getranspiled moet worden met een pakketje.

Voor CSS kun je nu overstappen naar SASS of LESS, kan ook weer getranspiled worden met een pakketje.

Echter vind ik dit een slechte ontwikkeling? Nee. Ik vind het evolutie.

Je kan namelijk nog steeds een website bouwen met of JQuery of Angular 1. Geen probleem. Dit wordt allemaal nog ondersteund.

Echter zitten bedrijven hier niet meer op te wachten. De huidige ontwikkelingen zijn daadwerkelijke verbeteringen op het voorgaande spul, elke iteratie weer.

Elke keer dat ik weer dacht voor een 'klein' projectje 'snel' JQuery te gebruiken, mondde het weer uit in veel te veel regels code, die veel moeilijker te onderhouden waren dan als ik het met Angular 1 had gedaan. ( Ik heb nog geen ervaring met 2 of React voorlopig)

De blogpost die je citeerde had het over de Java wereld. Alhoewel ik zo nu en dan een beetje hobby-matig Java doe, zit ik daar niet in de framework sfeer, en kan ik daar geen uitspraak over geven. Maar op het gebied van webdevelopment merk ik dat elke iteratie weer er verbeteringen waar te nemen zijn, in plaats van dat iemand weer het wiel opnieuw uitvind.

Heel veel mensen proberen een framework te bouwen met in hun achterhoofd de volgende gedachte: 'Hoe kan ik een framework bouwen waarin met zo min mogelijk code een applicatie in gebouwd kan worden, terwijl alles toch zo veel mogelijk schaalbaar en onderhoudbaar blijft?'. Veel frameworks zullen het niet overleven, maar de frameworks die hier de beste uit de bus komen, worden opgepakt door een community, die er weer verder op borduurt. Soms wordt er weer een rewrite gedaan, of wordt er weer iets nieuws verzonnen, maar worden er wel ideeën van de vorige iteratie meegenomen. Vandaar de term 'evolutie'.

Het enige verdere nadeel is de leercurve. Het ene principe is het andere niet, als jij 5 jaar geen frontend webdevelopment hebt gedaan, wordt je wakker in een heel andere wereld, en dat zal de volgende 5 jaar hetzelfde verhaal zijn. Misschien leven we nu gewoon in een wilde tijd en stabiliseert de hele boel en is iedereen bij React blijven steken, maar dat kan niemand je zeggen.

[Reactie gewijzigd op vrijdag 9 juni 2017 01:33]


Door Tweakers user JoeyPrr, vrijdag 9 juni 2017 11:06

In de front-end wereld loopt het al helemaal uit de hand.. Normale websites (let op: geen web APPS) die gemaakt worden met React en toegankelijkheid volledig overboord gooien. Websites die niet meer werken zodra JS uitstaat, HTML/CSS/JS door elkaar etc. Het lijkt wel of we alles wat we de afgelopen 10, 20 jaar belangrijk vonden uit het raam hebben gegooid, want Javascript.

Door Tweakers user JoeyPrr, vrijdag 9 juni 2017 11:08

JoeyPrr schreef op vrijdag 9 juni 2017 @ 11:06:
In de front-end wereld loopt het al helemaal uit de hand.. Normale websites (let op: geen web APPS) die gemaakt worden met React en toegankelijkheid volledig overboord gooien. Websites die niet meer werken zodra JS uitstaat, HTML/CSS/JS door elkaar etc. Het lijkt wel of we alles wat we de afgelopen 10, 20 jaar belangrijk vonden uit het raam hebben gegooid, want Javascript.
^ Excuses, quote knopje ingedrukt ipv. de bewerk knop..

[Reactie gewijzigd op vrijdag 9 juni 2017 11:08]


Door Tweakers user q-enf0rcer.1, vrijdag 9 juni 2017 11:09

Oerdond3r schreef op vrijdag 9 juni 2017 @ 01:31:
Frameworks zijn vandaag de dag een vereiste voor applicatieontwikkeling. En terecht. Een goed framework biedt veiligheid out-of-the-box. Een goed framework houdt je code schaalbaar, en zorgt ervoor dat je snel een applicatie kan opzetten.

Het enige nadeel zijn inderdaad de leercurve en de wildgroei. Onder andere op het gebied van Frontend Webdevelopment ( laten we het dan nog niet eens over backend dingen hebben ), was het 3(?) jaar terug nog normaal om alleen JQuery te gebruiken. Opeens was daar Angular, wat een compleet andere manier van applicaties opbouwen gaf. Sinds vorig jaar ongeveer besloot niet alleen Angular met een complete rewrite te komen ( Angular 2 ). Maar kwam ook React om de hoek kijken, wat dus ook weer een compleet andere methodiek.

Parallel aan deze ontwikkelingen is er ook nog een enorme evolutie geweest in de manier van package management via Bower, Npm ( van Node ) of drop-in placement van Npm: Yarn. Om al je Javascript en CSS bij volautomatisch bij elkaar te gooien is volgens mij het nieuwste van het nieuwste wat je er tegenwoordig voor kan gebruiken WebPack.

En tegelijkertijd is de onderliggende taal Javascript ook aan verandering toegeweest. Ecmascript 6 is nu een ding, met allemaal nieuw spul wat niet op alle browsers werkt, dus heb je daar ook nog een transpiler voor verzonnen. Ondertussen hadden ze bij Angular 2 besloten TypeScript te gebruiken ( een dialect op Javascript van Microsoft ) die ook weer getranspiled moet worden met een pakketje.

Voor CSS kun je nu overstappen naar SASS of LESS, kan ook weer getranspiled worden met een pakketje.

Echter vind ik dit een slechte ontwikkeling? Nee. Ik vind het evolutie.

Je kan namelijk nog steeds een website bouwen met of JQuery of Angular 1. Geen probleem. Dit wordt allemaal nog ondersteund.

Echter zitten bedrijven hier niet meer op te wachten. De huidige ontwikkelingen zijn daadwerkelijke verbeteringen op het voorgaande spul, elke iteratie weer.

Elke keer dat ik weer dacht voor een 'klein' projectje 'snel' JQuery te gebruiken, mondde het weer uit in veel te veel regels code, die veel moeilijker te onderhouden waren dan als ik het met Angular 1 had gedaan. ( Ik heb nog geen ervaring met 2 of React voorlopig)

De blogpost die je citeerde had het over de Java wereld. Alhoewel ik zo nu en dan een beetje hobby-matig Java doe, zit ik daar niet in de framework sfeer, en kan ik daar geen uitspraak over geven. Maar op het gebied van webdevelopment merk ik dat elke iteratie weer er verbeteringen waar te nemen zijn, in plaats van dat iemand weer het wiel opnieuw uitvind.

Heel veel mensen proberen een framework te bouwen met in hun achterhoofd de volgende gedachte: 'Hoe kan ik een framework bouwen waarin met zo min mogelijk code een applicatie in gebouwd kan worden, terwijl alles toch zo veel mogelijk schaalbaar en onderhoudbaar blijft?'. Veel frameworks zullen het niet overleven, maar de frameworks die hier de beste uit de bus komen, worden opgepakt door een community, die er weer verder op borduurt. Soms wordt er weer een rewrite gedaan, of wordt er weer iets nieuws verzonnen, maar worden er wel ideeën van de vorige iteratie meegenomen. Vandaar de term 'evolutie'.

Het enige verdere nadeel is de leercurve. Het ene principe is het andere niet, als jij 5 jaar geen frontend webdevelopment hebt gedaan, wordt je wakker in een heel andere wereld, en dat zal de volgende 5 jaar hetzelfde verhaal zijn. Misschien leven we nu gewoon in een wilde tijd en stabiliseert de hele boel en is iedereen bij React blijven steken, maar dat kan niemand je zeggen.
Je verhaal klinkt herkenbaar, ik vind wel dat die wildgroei in principe niet echt een probleem is. Als je eenmaal framework X kent, is het onder de knie krijgen van framework Y helemaal geen grote stap meer. Angular 2 en React om maar als voorbeeld te nemen, er zijn heel veel patronen van React terug te vinden in Angular 2. En zo gaat dat eigenlijk met elk nieuw framework, het beste van andere frameworks wordt meegenomen om ook de leercurve toch enigzins behapbaar te houden. Sla je een paar generaties frameworks over dan kom je wellicht wel voor een probleem te staan, dan zie je de bomen door het bos niet meer.

[Reactie gewijzigd op vrijdag 9 juni 2017 11:10]


Door Tweakers user Erwines, vrijdag 9 juni 2017 22:51

JoeyPrr schreef op vrijdag 9 juni 2017 @ 11:06:
In de front-end wereld loopt het al helemaal uit de hand.. Normale websites (let op: geen web APPS) die gemaakt worden met React en toegankelijkheid volledig overboord gooien. Websites die niet meer werken zodra JS uitstaat, HTML/CSS/JS door elkaar etc. Het lijkt wel of we alles wat we de afgelopen 10, 20 jaar belangrijk vonden uit het raam hebben gegooid, want Javascript.
Bedankt voor je reactie. Ja daar heb je een goed punt, o.a. websites die niet werken zonder javascript, de logic is aan het verplaatsen naar de client-kant wat naar mijn idee helemaal niet wenselijk is, zelfs gevaarlijk kan zijn. Vergelijkbaar met flash eigenlijk, er waren websites geheel in flash gemaakt die zonder flash een geheel lege pagina tonen. Hetzelfde met de extreme afhankelijkheid van javascript waardoor je een lege pagina ziet als je de site zonder javascript wordt opgevraagd of erger nog, als er een fout in de code zit. Test het wel eens en er zijn erbij die tonen een lege pagina, bijvoorbeeld met bootstrap.

Er zijn ook nog bij die hebben html of templates in het framework script zitten, de site kan echter nooit zonder die scripts werken. Qua onderhoud is dat killing, een soep aan verschillende opmaak en talen vergelijkbaar met sites gemaakt in php 4 of lager alleen dan aan de client-kant Je bent eigenlijk weer terug bij af. Het is het beste om opmaak en code gescheiden te houden en te werken met templates die op de server staan en daar komt ook de opmaak vandaan. Ook de routing wordt bepaald op de server ipv de client, de server is meer veilige omgeving om dat te bepalen. Ook security rules horen niet thuis aan de client kant. Ik begrijp dus ook niet de reactie van anderen dat er security issues kunnen zijn met een js framework. Dat zou helemaal niet moeten voorkomen, niet kunnen.

Je hebt gelijk dat je zegt dat helemaal uit de hand loopt met die frameworks die roepen nog beter te zijn dan de ander, eindeloos lijkt het. Veranderen om het moeten veranderen ofzo. Het lijkt wel een code wegwerpcultuur, lekker iedere keer opnieuw beginnen.

Gezond verstand en tech/de taal gebruiken waarvoor bedoeld is (javascript is ondersteunende service en niet bedoeld om een hele site in te bouwen) en dus niet wat ervan gemaakt is omdat het zogenaamd handiger zou zijn. Verkeerde ontwikkeling. Daarom begrijp ik de bedrijven ook niet die als een kip zonder kop achter elke hype aanlopen met de wetenschap dat het net zo snel verdwenen kan zijn als dat het gekomen is. Dan ben je toch een dief van je eigen portemonnee? Bijvoorbeeld services van Google zijn best wel onbetrouwbaar gebleken, Google heeft in het verleden al best wat dingen geïntroduceerd en daarna weer geschrapt of extreem gewijzigd.

Door Tweakers user Erwines, zaterdag 10 juni 2017 00:05

Oerdond3r schreef op vrijdag 9 juni 2017 @ 01:31:
Elke keer dat ik weer dacht voor een 'klein' projectje 'snel' JQuery te gebruiken, mondde het weer uit in veel te veel regels code, die veel moeilijker te onderhouden waren dan als ik het met Angular 1 had gedaan.
Sorry maar dat vind ik echt onbegrijpelijk, dan gebruik je het verkeerd. Of je vind Angular misschien gemakkelijker. Of je wilt jQuery gebruiken als Angular. jQuery is een tool een bibliotheek (library), geen framework. Een library kun je gebruiken en een framework is een gedachtegang om tot een oplossing te komen en dan moet je het gebruiken.
Oerdond3r schreef op vrijdag 9 juni 2017 @ 01:31:
Je kan namelijk nog steeds een website bouwen met of JQuery of Angular 1. Geen probleem. Dit wordt allemaal nog ondersteund.
Van ondersteuning is geen sprake, het werkt op javascript, de taal waarop het leunt en dat zal niet meer drastisch wijzigen. Dat is de reden dat het nog werkt. Of de uitwerking hetzelfde zal zijn, hangt heel erg af wat je precies gebruikt en hoe je het gebruikt. Is het uitsluitend op syntaxbasis dan zal er weinig veranderen. jQuery manipuleert voornamelijk de DOM (daar hangt dus ook af wat je gebruikt) en wordt daarnaast actief ontwikkeld, dus de kans dat het blijft werken is erg groot. Als je zeker wilt dat het blijkt werken onttrek je een kopie (complete source+minfied) en laat je het niet laden vanaf een externe CDN.
Oerdond3r schreef op vrijdag 9 juni 2017 @ 01:31:
De blogpost die je citeerde had het over de Java wereld.
Ja zijn ingang was Java maar het ook Python of andere 'talen' die hij noemt, het gaat over frameworks, de wildgroei van frameworks in welke taal dan ook.
Oerdond3r schreef op vrijdag 9 juni 2017 @ 01:31:
Heel veel mensen proberen een framework te bouwen met in hun achterhoofd de volgende gedachte: 'Hoe kan ik een framework bouwen waarin met zo min mogelijk code een applicatie in gebouwd kan worden, terwijl alles toch zo veel mogelijk schaalbaar en onderhoudbaar blijft?'.
Precies en dat is nu juist het probleem, wat vroeger in het klein gebeurde, gebeurd nu in grotere kampen omdat het een ieder de mogelijkheid heeft het te publiceren via het net. Het is een mindset van de ontwikkelaar, wat je vroeger in het klein had. Dit staat trouwens ook genoemd in die blogpost. Vind deze afbeelding fantastisch, het geeft in drie afbeeldingen aan hoe het werkt. Iets toevoegen omdat het zogenaamd handiger is maar de soep alleen nog meer ingewikkelder maakt: https://xkcd.com/927/
[url url="https://erwinus-kladblok.tweakblogs.net/blog/14875/ict-en-de-framework-madness-begrijpen-we-elkaar-nog-zoektocht-100-procent-match#r_208529" external=0]
Het enige verdere nadeel is de leercurve.
Dat is ook wat ik niet snap, waarom zou je het moeilijker maken dan het is. Het is niet een taal die je leert maar een methodiek om met een bepaalde gedachtegang, met een geforceerde werkwijze, een oplossingsmodel, een probleem op te lossen dat niet door jou is ontworpen. Laat het probleem oplossen over aan de programmeur zelf en spreek met het ontwikkelteam een standaard af, leg dat vast. Dat zorgt voor meer continuïteit dan om de zoveel tijd te switchen naar een nieuw framework.

En tevens: @solidous schreef:
Je zal ook nooit out-of-the-box denken, want je bent 100% afhankelijk van het framework.
Precies, een framework is juist een belemmering voor de creativiteit, het heeft niets te maken met de taal maar forceert je denken. Stop ermee, niet goed, weggegooide energie.

[Reactie gewijzigd op zaterdag 10 juni 2017 00:27]


Door Tweakers user Oerdond3r, zaterdag 10 juni 2017 01:50

Erwines schreef op zaterdag 10 juni 2017 @ 00:05:
[...]

Sorry maar dat vind ik echt onbegrijpelijk, dan gebruik je het verkeerd. Of je vind Angular misschien gemakkelijker. Of je wilt jQuery gebruiken als Angular. jQuery is een tool een bibliotheek (library), geen framework. Een library kun je gebruiken en een framework is een gedachtegang om tot een oplossing te komen en dan moet je het gebruiken.
Klopt. Eigenlijk is het een vergelijking van het gebruiken van een framework ( Angular ) vs 'even snel wat Javascript typen' ( met als library jQuery, dus zonder verdere framework). jQuery en Angular samen gebruiken is afgeraden, omdat jQuery niet samenwerkt met de 'digest cycle' van Angular. ( Je hoeft ook nauwelijks tot nooit in je code meer DOM elementen te selecteren, vanwege de two-way-binding die je in Angular 1 hebt )

Uiteindelijk kwam ik erachter dat 'even snel wat javascript typen' mij meer tijd kostte, dan van dat ik het gedaan zou hebben met Angular.
[...]

Van ondersteuning is geen sprake, het werkt op javascript, de taal waarop het leunt en dat zal niet meer drastisch wijzigen. Dat is de reden dat het nog werkt. Of de uitwerking hetzelfde zal zijn, hangt heel erg af wat je precies gebruikt en hoe je het gebruikt. Is het uitsluitend op syntaxbasis dan zal er weinig veranderen. jQuery manipuleert voornamelijk de DOM (daar hangt dus ook af wat je gebruikt) en wordt daarnaast actief ontwikkeld, dus de kans dat het blijft werken is erg groot. Als je zeker wilt dat het blijkt werken onttrek je een kopie (complete source+minfied) en laat je het niet laden vanaf een externe CDN.
Ben ik het helemaal eens. ( behalve dat de syntax van Javascript stilstaat, kijk maar eens wat EcmaScript 6 allemaal te bieden zal hebben ). Ik reageerde op een eerdere reactie van solidous, over de beperkte houdbaarheid van bepaalde frameworks en libraries. Misschien gebeurt het wel in andere talen vaker dat je een framework gebruikt dat opeens niet meer ondersteund wordt, maar ik heb het nog niet meegemaakt. Vervolgens ging mijn post verder over waarom bedrijven ondanks de blijvende ondersteuning toch liever het nieuwste van het nieuwste willen.
[...]

Ja zijn ingang was Java maar het ook Python of andere 'talen' die hij noemt, het gaat over frameworks, de wildgroei van frameworks in welke taal dan ook.

[...]

Precies en dat is nu juist het probleem, wat vroeger in het klein gebeurde, gebeurd nu in grotere kampen omdat het een ieder de mogelijkheid heeft het te publiceren via het net. Het is een mindset van de ontwikkelaar, wat je vroeger in het klein had. Dit staat trouwens ook genoemd in die blogpost. Vind deze afbeelding fantastisch, het geeft in drie afbeeldingen aan hoe het werkt. Iets toevoegen omdat het zogenaamd handiger is maar de soep alleen nog meer ingewikkelder maakt: https://xkcd.com/927/

[...]
Ik ben ook van mening dat de wildgroei een nadeel is, maar dat zich van zelf rechttrekt ( slechte frameworks worden verlaten, goede frameworks worden populair ), als onderdeel van die evolutie.
Dat is ook wat ik niet snap, waarom zou je het moeilijker maken dan het is. Het is niet een taal die je leert maar een methodiek om met een bepaalde gedachtegang, met een geforceerde werkwijze, een oplossingsmodel, een probleem op te lossen dat niet door jou is ontworpen. Laat het probleem oplossen over aan de programmeur zelf en spreek met het ontwikkelteam een standaard af, leg dat vast. Dat zorgt voor meer continuïteit dan om de zoveel tijd te switchen naar een nieuw framework.

En tevens: @solidous schreef:

[...]


Precies, een framework is juist een belemmering voor de creativiteit, het heeft niets te maken met de taal maar forceert je denken. Stop ermee, niet goed, weggegooide energie.
Een framework zie ik niet als een belemmering voor de creativiteit, ik zie het als een 'raamwerk' voor mijn applicatie om direct aan de slag te gaan. Een goed framework belemmert niet, maar doet het standaardwerk voor je. En als het helemaal mee zit, gebruikt het methodieken zodat jij minder regels hoeft te schrijven, en hebben ze nagedacht over schaalbaarheid en onderhoudbaarheid van de code die jij erin gaat schrijven. Je kan meteen beginnen met regels code schrijven voor de opdracht, het 'domain model' / de 'bedrijfsregels' ( als je een applicatie voor een bedrijf bouwt ). Binnen dat domain model kan je ontzettend creatief zijn. In plaats van dat je met de helft van de tijd bezig bent met 'algemene opbouw' dat niks met de opdracht te maken heeft.

Als jij aan 2 senior developers ( A en B ) afzonderlijk vraagt om applicatie X in Taal Y te bouwen, krijg je twee compleet verschillende applicaties. A moet eerst nog in B's code duiken om de algemene opbouw te snappen van B, en vice versa.

( En als er niet aan schaalbaarheid vanaf het begin is gedacht, zijn er ook nog eens verschillende rewrites geweest, wegens tijdsdruk is dat niet helemaal netjes gedaan, en is de code traag en complex geworden, maar laten we even bedenken dat dat hier niet het geval is geweest )

Vraag 2 senior developers om afzonderlijk applicatie X in Framework Z te bouwen, is het veel makkelijker voor A om verder te gaan in B's code verder te gaan, sterker nog ze kunnen allebei in compleet andere Applicaties (Q en R?) bijna direct beginnen, omdat de algemene opbouw hetzelfde is geweest.

( En er waren vanaf het begin af aan geen grote 'core rewrites' geweest, omdat de frameworkbouwers dachten aan schaalbaarheid )

Als jij denkt dat jij met alleen taal en programmeermethodiek een schaalbare, onderhoudbare en leesbare applicatie kan maken, zonder teveel tijd te verliezen die je eigenlijk aan je 'domain model' had kunnen spenderen, be my guest.

Maar dan ben ik jou nog niet in de praktijk tegengekomen. In de praktijk ben ik wel mensen tegengekomen die zichzelf tot 'senior developer' status verheven, om vervolgens jaren bezig te zijn met een stuk of 7 versies van een stuk software dat nooit het daglicht heeft gezien (niet overdreven, helaas een keer waargebeurd ).

De ervaring van waaruit ik spreek is bijna altijd een ervaring van teams met niet meer dan ~6 man. Maar ook in een groot team kan ik me voorstellen dat je gewoon een solide basis wilt hebben. Die kun je met genoeg mankracht zelf maken, en de instructies ervoor verspreiden onder je team. Je kan ook een bestaand framework gebruiken, die al publiekelijk beschikbare documentatie heeft, zodat je die niet meer zelf hoeft te typen voor de rest van je team, scheelt ook weer tijd.

[Reactie gewijzigd op zaterdag 10 juni 2017 01:55]


Door Tweakers user Erwines, zaterdag 10 juni 2017 04:21

Oerdond3r schreef op zaterdag 10 juni 2017 @ 01:50:
Als jij denkt dat jij met alleen taal en programmeermethodiek een schaalbare, onderhoudbare en leesbare applicatie kan maken, zonder teveel tijd te verliezen die je eigenlijk aan je 'domain model' had kunnen spenderen, be my guest.
Reageer heel even kort op jou quote. Ik weet niet hoe jij je 'domain model' inschat maar als dat geld is dan heb je gelijk op kort termijn. Probleem zit bijna altijd in de langere termijn, op langer termijn. Wat ik veel gezien heb in mijn developer zijn is dat het bijna altijd fout gaat op langer termijn, door adhoc/snelle beslissingen in de korte termijn of extreme koerswijzigingen omdat in basis niet goed is nagedacht waar het naartoe zou kunnen gaan (dan krijg je vernieuwbouw, kost ontzettend veel geld). De meeste projecten groeien, wat voor project het ook is. Daarnaast dat er vaak geen richtlijn is qua programmatuur (zeg maar gerust meestal niet), wel qua prestatie, qua uiterlijk, qua functie maar niet qua toetsing inhoudelijke gezondheid. Er wordt getoetst op prestatie, op voortgang, het product maar er is niemand die controleert of het een beetje volgens de afgesproken richtlijnen is (als die richtlijnen er al zijn en dat is niet alleen de afspraak een bepaald framework en/of library te moeten gebruiken, gaat veel verder dan dat).

Stel de werkdruk is hoog en wordt iemand ingehuurd, een student of extern bureau, een free-lancer whatever. Er wordt gekeken naar het resultaat en niet naar inhoudelijke samenstelling van die oplossing. Want he, het werkt toch? Ziet er goed uit. Dat hadden we nodig, probleem opgelost. Zo gaat dat. Dat is waar de ellende begint, werkdruk en prestatie.

Ik zie dan ook de toevlucht in frameworks als stuiptrekking van een organisatie die eigenlijk ook niet zo goed weet welke kant op te gaan omdat de ervaring er niet is om koers te op langer termijn succesvol te houden/behouden. Aan de ene kant is er dus wel aandacht voor, vaak als het te laat is, en andere kant zijn we naarstig op zoek naar een betere structuur en denken dat te vinden in een methodiek van een ander.

Soort toverformule voor de organisatie om alle neuzen dezelfde richting op te forceren. Als de afspraken niet goed georganiseerd zijn, dan werkt dit ook niet, sterker nog het zal nooit werken op de langer termijn. Je krijgt alleen maar meer fragmentatie, er zijn projecten die met een ouder framework werken, nog sneller dan je als organisatie het zelf goed georganiseerd zou hebben. Maar dan moet je het wel goed organiseren en dat is vaak het onderliggende probleem. Goed organiseren kost tijd denken velen net als jij, tijd is geld maar dan onderschat je de waarde van continuïteit. Als je het goed doet kost het inderdaad in beginsel meer tijd maar dat betaald zich terug in stabiliteit, minder nazorg bijvoorbeeld én dat scheelt weer tijd.

Dat geldt ook voor documentatie, dat wat je aanhaalt, iemand anders heeft het geschreven, so what, als het framework niet meer bestaat is het oude documentatie en zal niet meer worden bijgewerkt, ook als het niet volledig was. Je leunt heel erg op wat externen bedacht hebben en dat kan nadelige effecten tot gevolg hebben, trekken externe de stekker eruit dan ben je weg. Zeker als het online staat (en geen backup hebt), weg is weg.

Bibliotheken, nog zoiets, hoe vaak er geen bibliotheken worden aangelegd voor veel voorkomende oplossingen specifiek voor een bedrijf. Heb je een financieel bedrijf, dan leg je een bibliotheek aan met oplossingen voor vele formules, althans zou je denken maar heel vaak gebeurd dat dus niet. Zeker niet in zulke kleine teams als jij beschrijft, er is geen tijd voor want tijd is geld.

Ik heb hier een bibliotheek liggen uit 94 en het werkt nog steeds, ontzettend handig en tijd besparend en het werkt super stabiel omdat alle fouten eruit zijn, geovuleerd en een beetje bijgewerkt door de tijd en is in feite uitontwikkeld. Functienamen hetzelfde etc en het werkt zelfs als je het gebruikt in nieuwe omgevingen. Dat is voordeel, want uiteindelijk gaat het toch om het eindresultaat en hoe snel je dat kunt doen? Als je echt zo snel wilt doen, dan moet je dit doen, aanrader, wel documenteren en geen excuus dat het niet kan omdat het teveel tijd kost, Dan hoeft je niet steeds te focussen op wat een ander weer bedacht heeft, je bent ontwikkelaar of je bent niet, je bent toch geen circusartiest wat een kunstje kan?

[Reactie gewijzigd op zaterdag 10 juni 2017 22:54]


Door Tweakers user SBTweaker, zondag 11 juni 2017 10:02

Vind wel erg veel reacties klinken of de reaguurders vast in de tijd zitten. Jquery en angular zijn heel verschillend qua syntax goed angular schrijven leer je niet in een paar weken.
Stel je zoekt personeel om een houten kast te maken die met een bepaalde techniek ontwikkeld wordt, de sollicitant kent veel technieken maar niet de techniek die nodig is voor de kast, ga je deze dan aannemen als het een maand duurt om te leren? Vergeet niet als je iemand aanneemt die het wel kant je ook een maand winst kwijt bent die je wel gehad zou hebben met iemand die het wel kon en niet eerst hoefde te leren.

Door Tweakers user JoeyPrr, zondag 11 juni 2017 12:33

SBTweaker schreef op zondag 11 juni 2017 @ 10:02:
Vind wel erg veel reacties klinken of de reaguurders vast in de tijd zitten. Jquery en angular zijn heel verschillend qua syntax goed angular schrijven leer je niet in een paar weken.
Stel je zoekt personeel om een houten kast te maken die met een bepaalde techniek ontwikkeld wordt, de sollicitant kent veel technieken maar niet de techniek die nodig is voor de kast, ga je deze dan aannemen als het een maand duurt om te leren? Vergeet niet als je iemand aanneemt die het wel kant je ook een maand winst kwijt bent die je wel gehad zou hebben met iemand die het wel kon en niet eerst hoefde te leren.
Huh? Angular en jQuery zijn 2 totaal verschillende dingen en de mensen die hier gereageerd hebben lijken dat ook te begrijpen.. Angular/React zijn 2 frameworks om web-apps te bouwen en jQuery is een library om extra functionaliteit aan je website toe te voegen. Heeft niks met vast zitten in de tijd te maken, maar met de juiste tools kiezen. Je zou wel kunnen stellen dat jQuery ipv. vanilla JS gebruiken vast zitten in de tijd is en daar zou ik het dan enigszins mee eens zijn. Maar zo gebruiken we ook nog SCSS voor CSS, daar CSS zelf al veel flexibeler is geworden (alleen zijn de browsers nog niet bij); de syntax is prettiger.

Als ik bijvoorbeeld zie dat een bedrijf dat alleen maar simpele websites voor het MKB maakt in een vacature vraagt om React-kennis ga ik mezelf heel erg afvragen wat ze daar mee denken te bereiken en of ze wel verstand van zaken hebben.

Dat is nou juist het punt, ik huur iemand in voor een simpele website en je krijgt een bak overkill aan code terug omdat mensen maar naar een framework als React grijpen zonder goed te begrijpen waar React nou precies voor bedoeld is (in eerste instantie voor web-apps ala Facebook).

Edit: dit is wel een leuke toevoeging aan de discussie: http://vanilla-js.com
Edit2: nog een leuke toevoeging: https://twitter.com/thomasfuchs/status/810885087214637057 & https://twitter.com/thomasfuchs/status/873276796510326784

[Reactie gewijzigd op zondag 11 juni 2017 12:47]


Door Tweakers user johnkeates, zondag 11 juni 2017 15:54

Er is natuurlijk wel een dik verschil tussen onzin vragen en onzin krijgen. Als ik iemand nodig heb die in een bestaande symfony 3 applicatie met REST interface en Angular2 frontend onderhoud moet gaan doen, dan ga ik niet in op mensen die random 'PHP, DHTML en XMLRPC' specificeert in z'n skillset. Dan ga ik eerder voor iemand die 'ervaring met REST, Symfony 2 of 3, Angular2' genoteerd heeft staan. Die mensen zijn er namelijk gewoon.

Aan de andere kant is het natuurlijk onzin om random woorden in je vacature te plaatsen in de hoop 'stoere' developers te krijgen. Als je aan de onderkant van de markt zit en alleen maar wordpress op shared hosting doet, dan kan je maar beter geen enkele taal of framework noemen.

Door Tweakers user Erwines, zondag 11 juni 2017 19:09

johnkeates schreef op zondag 11 juni 2017 @ 15:54:
Als ik iemand nodig heb die in een bestaande symfony 3 applicatie met REST interface en Angular2 frontend onderhoud moet gaan doen, dan ga ik niet in op mensen die random 'PHP, DHTML en XMLRPC' specificeert in z'n skillset. Dan ga ik eerder voor iemand die 'ervaring met REST, Symfony 2 of 3, Angular2' genoteerd heeft staan. Die mensen zijn er namelijk gewoon.
Je bent dus de bevestiging van de regel. Dus als er sollicitant is die ontzettend mooie projecten gedaan heeft, zijn vak goed verstaat, misschien zelfs iets gedaan heeft wat lijkt op wat je vraagt, in de buurt komt, dan valt deze sollicitant toch buiten de boot. Dan is het niet de moeite om te bekijken waard. Is er een sollicitant die net van school komt, en wel de gevraagde keywords op zijn CV heeft staan, wel het trucje zegt te kennen, dan valt deze CV in het goede bakje.

Met andere woorden, wat je in het verleden hebt gedaan, je ervaring, is niets meer waard als de vereiste keywords niet op je CV staan. Er zijn zo ontiegelijk veel frameworks die over het algemeen best wel raakvlakken hebben met elkaar, om te beginnen de taal waarvoor het gebouwd is, waar het eigenlijk over zou moeten gaan, dat het heel goed mogelijk is dat het smaakje niet voorkomt op je CV maar wél een ander smaakje. In dat geval word je als sollicitant gewoon buitengesloten van deelname, op voorhand, zonder te kijken wie het is en wat deze persoon allemaal heeft gedaan, te bieden heeft.

Als je alle frameworks zou moeten kennen, alle in-en-outs, dan heb je daar een full-time job aan. Het is gekkenwerk, alsof iemand niet in staat zou zijn, een uitstekende kandidaat te zijn, die bereidt is om jou gedachtegoed op te pikken, te leren. Bijvoorbeeld mede omdat deze kandidaat iets gedaan heeft wat er sterk op lijkt. Een kandidaat dat wel voldoet aan de keywordeis, daarvan is ook niet gezegd dat hij/zij goed is in het vak, iedereen kan opschrijven dat je dat kent maar ben je er ook goed in, beheers je de materie?

Ik kan maar tot één conclusie komen, dit heeft met niet willen investeren, dus met geld te maken, op safe willen spelen. Dit gaat niet meer over expertise, dit gaat over een trucje/kunstje, een model kunnen toepassen. Als je dat zegt te kunnen, dan is het goed. En bij een gros van de bedrijven is het zo, om te bevestigen dat jij dat mogelijk dat zou kunnen (we kijken niet wat je gedaan hebt, dat is niets waard) doen ze een toelatingstest, iq-test of inhoudelijke test (laatste kan ik nog inkomen) en dat gebeurd dan vaak nog voor je uberhaupt een gesprek hebt gehad. Kennismakingsgesprek slaan we over want wie je bent lijkt ook niet belangrijk te zijn, hup meteen aan de test. Wat zoeken deze lui, robots, lopende band medewerkers?

Vind het echt een hele nare ontwikkeling, onpersoonlijk en hard. Voor de mensen die nu goed zitten qua keywords, ontstaat er voor deze groep een aantal jaar later hetzelfde probleem. Stupide beleid waarbij ervaring in het verleden niet meer telt.

In 2015 kwam het bericht dat er In Limburg zou een tekort zou zijn aan hoog opgeleide ict-ers. Bekijk de eerste reactie van Katsunami op dit artikel en zie hoe bizar de zoektocht naar nieuw personeel verloopt. Er is geen tekort, het wordt gewoon ontzettend moeilijk gemaakt door op zoek te gaan naar die 100% match.
nieuws: Maastricht start met nieuwe ict-opleiding voor werkloze 50-plussers

[Reactie gewijzigd op zondag 11 juni 2017 20:20]


Door Tweakers user Erwines, zondag 11 juni 2017 20:13

JoeyPrr schreef op zondag 11 juni 2017 @ 12:33:
Dat is nou juist het punt, ik huur iemand in voor een simpele website en je krijgt een bak overkill aan code terug omdat mensen maar naar een framework als React grijpen zonder goed te begrijpen waar React nou precies voor bedoeld is (in eerste instantie voor web-apps ala Facebook).

Edit: dit is wel een leuke toevoeging aan de discussie: http://vanilla-js.com
Edit2: nog een leuke toevoeging: https://twitter.com/thomasfuchs/status/810885087214637057 & https://twitter.com/thomasfuchs/status/873276796510326784
Ja dat is inderdaad wat ik bedoel, als een kip zonder kop achter een hype aanlopen zonder te weten wat het nou eigenlijk is. In feite blindelings gedachtegoed van iemand anders overnemen. Dat zag je vroeger al terug met database gebruik, te pas en te onpas toepassen, ook voor hele eenvoudige dingen zelfs. Of alles in classes proppen, voor elk dingetje een class maken en geen functies (in een library aanleggen). Een "hello world" demo, dat bestaat dan uit 100 regels terwijl het in 20 regels zou kunnen bijvoorbeeld.

Daarom beschrijf een framework, zoals dat nu wordt gevraagd, de manier waarop, als een trucje/kunstje dat je moet kunnen. Het gaat niet over de programmeertaal zelf, de inhoudelijke kennis daarvan, maar over gedachtengoed, een model, een dialect dat je moet kunnen verstaan. Raar en niet fair.

Het VanillaJS wat je trouwens aanhaalt is het eigenlijk ook grote nonsens om vanwege de snelheid, op basis van de voorbeelden die daar staan, het huidige dat wat je nu gebruikt in te ruilen voor VanillaJS met alle gevolgen die het gaat voortbrengen.

De grootste snelheidswinst zit um juist in efficiency, dus niet alles in één keer willen doen, dat wat vaak ook niet nodig is. Dat zie je vaak in de code terug dat hele pagina (DOM) in een keer, op meerdere manieren wordt gescand wat ontzettend belastend is.

Door manipulaties pas uit te voeren, uit te stellen, als de bezoeker wat doet op de pagina, dat scheelt enorm in laadtijd en belasting. Dus ja, het is maar hoe het probleem aanpakt. Als 100.000 elementen op je pagina hebt staan en gaat aan elk element een click event toevoegen, dat is traag. Maar als je pas gaat kijken waar de bezoeker op klikt op het moment dat deze ergens op klikt, dat bespaart je dan 100.000 click events.

Daar zou meer de focus op moeten liggen, effeciency maar dat lijkt ook aardig naar de achtergrond te verdwijnen. Als een NES 8-bit game met de huidige modellen van vandaag zou worden gemaakt en de processors van toen, dan was het niet vooruit te branden. :)

[Reactie gewijzigd op zondag 11 juni 2017 20:25]


Door Tweakers user johnkeates, zondag 11 juni 2017 21:57

Erwines schreef op zondag 11 juni 2017 @ 19:09:
[...]

Je bent dus de bevestiging van de regel. Dus als er sollicitant is die ontzettend mooie projecten gedaan heeft, zijn vak goed verstaat, misschien zelfs iets gedaan heeft wat lijkt op wat je vraagt, in de buurt komt, dan valt deze sollicitant toch buiten de boot. Dan is het niet de moeite om te bekijken waard. Is er een sollicitant die net van school komt, en wel de gevraagde keywords op zijn CV heeft staan, wel het trucje zegt te kennen, dan valt deze CV in het goede bakje.

Met andere woorden, wat je in het verleden hebt gedaan, je ervaring, is niets meer waard als de vereiste keywords niet op je CV staan. Er zijn zo ontiegelijk veel frameworks die over het algemeen best wel raakvlakken hebben met elkaar, om te beginnen de taal waarvoor het gebouwd is, waar het eigenlijk over zou moeten gaan, dat het heel goed mogelijk is dat het smaakje niet voorkomt op je CV maar wél een ander smaakje. In dat geval word je als sollicitant gewoon buitengesloten van deelname, op voorhand, zonder te kijken wie het is en wat deze persoon allemaal heeft gedaan, te bieden heeft.

Als je alle frameworks zou moeten kennen, alle in-en-outs, dan heb je daar een full-time job aan. Het is gekkenwerk, alsof iemand niet in staat zou zijn, een uitstekende kandidaat te zijn, die bereidt is om jou gedachtegoed op te pikken, te leren. Bijvoorbeeld mede omdat deze kandidaat iets gedaan heeft wat er sterk op lijkt. Een kandidaat dat wel voldoet aan de keywordeis, daarvan is ook niet gezegd dat hij/zij goed is in het vak, iedereen kan opschrijven dat je dat kent maar ben je er ook goed in, beheers je de materie?

Ik kan maar tot één conclusie komen, dit heeft met niet willen investeren, dus met geld te maken, op safe willen spelen. Dit gaat niet meer over expertise, dit gaat over een trucje/kunstje, een model kunnen toepassen. Als je dat zegt te kunnen, dan is het goed. En bij een gros van de bedrijven is het zo, om te bevestigen dat jij dat mogelijk dat zou kunnen (we kijken niet wat je gedaan hebt, dat is niets waard) doen ze een toelatingstest, iq-test of inhoudelijke test (laatste kan ik nog inkomen) en dat gebeurd dan vaak nog voor je uberhaupt een gesprek hebt gehad. Kennismakingsgesprek slaan we over want wie je bent lijkt ook niet belangrijk te zijn, hup meteen aan de test. Wat zoeken deze lui, robots, lopende band medewerkers?

Vind het echt een hele nare ontwikkeling, onpersoonlijk en hard. Voor de mensen die nu goed zitten qua keywords, ontstaat er voor deze groep een aantal jaar later hetzelfde probleem. Stupide beleid waarbij ervaring in het verleden niet meer telt.
Nou, niet dus. Volgens mij heb je zelf alleen maar in de positie gezeten waarbij je niet geschikt was voor de positie en verder eigenlijk niet na hoeft te denken over de rest van het bedrijf. Ik heb zelf aan alle kanten gezeten, en er is een nogal groot verschil tussen wat mensen denken te bieden en een bedrijf denkt nodig te hebben. Dat is tenminste wat uit je posts op te maken valt tot zo ver.

Specifiek:
Je bent dus de bevestiging van de regel. Dus als er sollicitant is die ontzettend mooie projecten gedaan heeft, zijn vak goed verstaat, misschien zelfs iets gedaan heeft wat lijkt op wat je vraagt, in de buurt komt, dan valt deze sollicitant toch buiten de boot.
Dat is dus niet hoe het werkt. Als ik 10 CV's vergelijk, en 8 hebben REST en JSON in een recent project gebruikt, en 2 hebben dat niet en voldoen verder ook niet, dan gaan die twee als eerste de prullenmand in. Dan kan het wel zo zijn dat ze ook 'iets met een API' gedaan hebben, of ook wel eens een data-interchange of file formaat gebruikt hebben, maar daar schieten we niks mee op. Als je iemand alles nog moet leren kan zit er totaal geen onderscheid meer tussen de IT'ers waar je uit kan kiezen en kan je net zo goed geen CV hebben om dat je er toch niet op kan matchen.

Stel dat er een CV tussen zit van iemand die wel met Angular2 gewerkt heeft, maar ZendFramework of Laravel gebruikt heeft in plaats van Symfony, maar verder dezelfde bundles gebruikt heeft, dan komt die net zo goed door als iemand die letterlijk Symfony had staan. Maar iemand die nul relevante framework kennis heeft komt er niet in. Dat is gewoon te kostbaar en er zijn altijd mensen die dat wel hebben en dat voor hetzelfde geld wel kunnen komen doen.

Los van het hele vacature/CV verhaal werken 99% van de software afdelingen die zichzelf een beetje serieus nemen op basis van frameworks en niet op basis van random talen en paradigma's met de hoop dat even een framework leren kennen gratis is. Je kan een bedrijf gewoon niet runnen en laten overleven als je iedereen maar altijd alles moet leren en software tot in den treure met de hand gemaakt moet worden. Dat is misschien niet leuk, maar dat is wel waar het geld zit, en zonder geld kan je de programmeurs, engineers, architecten en ops niet betalen. Op kosten van de zaak leren en nieuwe ontwikkelingen maken en volgen doe je op het moment dat je je proefperiode doorstaan hebt. Investeren is geen probleem, maar zonder kennis binnenkomen zit er gewoon niet in.

Door Tweakers user Erwines, maandag 12 juni 2017 01:04

johnkeates schreef op zondag 11 juni 2017 @ 21:57:
Los van het hele vacature/CV verhaal werken 99% van de software afdelingen die zichzelf een beetje serieus nemen op basis van frameworks en niet op basis van random talen en paradigma's met de hoop dat even een framework leren kennen gratis is. Je kan een bedrijf gewoon niet runnen en laten overleven als je iedereen maar altijd alles moet leren en software tot in den treure met de hand gemaakt moet worden. Dat is misschien niet leuk, maar dat is wel waar het geld zit, en zonder geld kan je de programmeurs, engineers, architecten en ops niet betalen. Op kosten van de zaak leren en nieuwe ontwikkelingen maken en volgen doe je op het moment dat je je proefperiode doorstaan hebt. Investeren is geen probleem, maar zonder kennis binnenkomen zit er gewoon niet in.
Zonder kennis binnen komen, pardon? Je bevestigd dus wel degelijk de regel want waar het over gaat is geld en niet in mensen willen investeren, ook niet na de proefperiode. Het staat altijd wel zo leuk "mogelijkheid opleiding/cursus volgen" maar dat gebeurd alleen als het nodig voor is het bedrijf (al zo vaak gezien en meegemaakt), dat staat ergens als een voetnoot maar staat niet in de vacature. Nieuwe ervaringen opdoen zonder noodzaak voor het eigen bedrijf, dat is er niet bij, heel erg een kokervisie, allemaal mee-marcheren. Als ik dan in mijn eigen tijd met een betere oplossing zou komen, dan omarm je dat en dan zeg je bedankt, maar dat moet ik dan wel in mijn eigen tijd doen want de baas wil niet dat ik zijn tijd nieuwe ervaringen opdoe, ja alleen als het in het straatje past. Nieuwe inzichten krijg je hier niet door als je zo in kokervisie hangt. Je mensen zijn niet belangrijk, alleen wat ze produceren als resultaat is belangrijk, zo snel en goedkoop mogelijk. Creativiteit is niet van toepassing.

Ik snap dat het belangrijk is om koers te houden maar je kunt ook overdrijven, dat het niet om personeel (de persoon) gaat maar alleen over specs is een slechte indicatie. Heb ik een interessante vraag voor je. Stel, je wisselt van framework, er is weer iets beters gekomen, geef je het personeel dan een upgrade d.m.v. een opleiding/cursus, of denk je van ik verleng het contract niet en neem een nieuwe aan die dat al wél kan. Laatste kost minder nietwaar? Dan hoef je geen opleiding te betalen, hoef je niet te investeren. Kun je de boel uitfaseren zullen we maar zeggen. Als je al zo picky bent bij het aannemen van nieuw personeel, kan ik mij het laatste omschreven heel goed indenken dat het zo werkt.

Vraag mij af hoe je mensen betrokken houdt bij het bedrijf als er sprake is van zo'n kokervisie met zulke harde zwart/wit eisen, al vanaf het begin. Er wordt geen programmeur gevraagd, er wordt iemand gevraagd die een kunstje kan, een soort typegeit die kan produceren volgens een bepaald model. Wie bent maakt niet uit, wat je verder nog kunt maakt niet uit, of wat je gedaan hebt maakt niet uit, aan welke projecten je hebt gewerkt maakt niet uit, hoe groot die projecten waren maakt niet uit, hoe creatief je bent maakt niet uit (liefst niet natuurlijk want dat is bedreiging voor de continuïteit), als je maar dat ene kunstje kan, als je maar het dialect van een taal spreekt zodat in geen geval het bedrijf hoeft te investeren. Waar gaat het dan om? Niet over kwaliteit en niet over mensen, ordinair productie, geldkwestie (voor een dubbeltje op de eerste rang zitten, gebruik maken van expertise waarvoor je geen cent hebt betaald) Creativiteit hoef je ook niet te hebben, doe maar gewoon wat de baas wil, dan doe je al gek genoeg, ja toch?

Teleurstellend en triest.

[Reactie gewijzigd op maandag 12 juni 2017 01:22]


Door Tweakers user Oerdond3r, maandag 12 juni 2017 22:20

Of een framework nuttig is of niet wil ik wel even in het midden laten, ik wil best wel geloven dat er een hele hoop software projecten geslaagd die zonder framework begonnen zijn, mits natuurlijk de juiste kennis en ervaring in huis was.

Zijn er eigenlijk wel general-purpose frameworks voor low-level talen zoals C++? Volgens mij alleen veelgebruikte libraries.

Ik denk dat er vooral binnen web development zoveel frameworks binnen zijn ontsproten, omdat daarbinnen zoveel te 'raamwerken' valt:
Ten eerste natuurlijk backend REST API's (vrij single-purpose, en dingen als security kunnen vrij makkelijk gestandaardiseerd worden).
Ten tweede natuurlijk de frontend kant, om de wirwar aan html/Javascript/CSS features te kunnen stroomlijnen.

Echter wil ik nog twee dingetjes kwijt m.b.t. je laatste post:

- Is het niet zo dat er nog altijd een ontzettend tekort is aan IT personeel? Ergo de bedrijven hebben het helemaal niet voor het kiezen? ( Of is dat niet meer zo anno 2017? Serieus dat wil ik dan wel weten.. ). Ze kunnen dus allemaal wel frameworks op hun vacatures plempen, volgens mij zijn ze alsnog prima blij als er iemand met genoeg development kennis en ervaring erop reageert. Dat weekje / maandje omscholen nemen ze wel voor lief. En zo niet, zijn er denk ik nog TIG andere bedrijven die je dan wel willen.

- Ik heb programmeren in een framework nooit als een 'kunstje' beschouwt. Eerder altijd als een verademing. Ik wordt regelmatig ge-outsourced, maar mag op kosten van de baas prima een week of wat besteden aan het leren van een nieuwe framework of techniek als de opdracht dat vereist. Naast dat ik het simpelweg leuk vind om nieuwe dingen te leren., heb ik nog steeds eerdere kennis en ervaring nodig om A: Het framework tot me te nemen en B: Tijdens de opdracht er alsnog een geslaagd project ervan te maken. Het voelt altijd lekker om tickets snel weg te kunnen knallen omdat de basis gewoon in 1 keer klopt. En binnen de dingen die ik wel moet programmeren is nog zat ruimte voor creativiteit.
Maar goed, dat is mijn persoonlijke ervaring, en meningen kunnen daarover natuurlijk verschillen. Als je vele jaren software elke keer vanaf de grond af aan hebt opgebouwd kan ik me er wel wat bij voorstellen dat je daar geen uitdaging in ziet zitten.

[Reactie gewijzigd op maandag 12 juni 2017 22:26]


Door Tweakers user Fledder2000, dinsdag 13 juni 2017 00:10

Ik sluit me aan bij de auteur: het is een slecht idee om een framework (dialect) te gebruiken om mensen per direct al uit te sluiten.

Ik zeg dat op basis van 20 jaar ervaring in een multinational waar telkens teams en technologieen verschuiven, waardoor ik al honderden programmeurs heb zien komen en gaan. Bij velen doe ik persoonlijk de tech interviews, en heb dus enig zicht op het scheiden van het kaf en het koren.

Bij sommige van onze beste mensen kan het bijvoorbeeld best voorkomen dat ze een bepaald relatief nieuw framework (1-3 jaar oud) nog niet kennen, simpelweg omdat ze nog geen opdracht gehad hebben, te druk met andere, bestaande opdrachten. Ze zullen zo'n framework begrijpen, maar hebben er geen praktijkervaring mee.

Welke ze vliegensvlug opdoen zodra er wel een opdracht is. We starten regelmatig projecten waar zo'n top developer een framework voor het eerst gebruikt, en dat gaat prima. We hebben het hier over mensen met 15, 20 of meer jaren ervaring. Die tig talen en frameworks hebben zien komen en gaan.

Dergelijke mensen uitsluiten is waanzin. Je laat erg veel lopen. Betrek ze gewoon in de selectie ronde, als blijk dat ze slecht zijn, kun je alsnog afwijzen.

Tot slot, tech skills is in mijn ervaring een van de minst belangrijke selectie criteria. De goede developers bij ons maken altijd het verschil op een ander vlak. Ze zijn zelfstandig. Verantwoordelijk. Communiceren goed. Gaan voor de goede oplossing en maken geen rommeltje.

En vergeet absoluut niet de conceptuele en architectuur skills. 20 jaar geleden op de HTS programmeerden we in Delphi. We hadden data binding, event driven patronen, separation of concerns, en zo kun je doorgaan. Grappig maar waar: de programmeer wereld staat conceptueel gezien al zo'n 30 jaar stil, want er is geen ene fuck veranderd aan al deze concepten. We programmeren nog steeds in 3GL talen (soms een deel 4G) en dus is alles hetzelfde, slechts de syntax veranderd.

Door Tweakers user Erwines, dinsdag 13 juni 2017 03:14

Oerdond3r schreef op maandag 12 juni 2017 @ 22:20:
Of een framework nuttig is of niet wil ik wel even in het midden laten, ik wil best wel geloven dat er een hele hoop software projecten geslaagd die zonder framework begonnen zijn, mits natuurlijk de juiste kennis en ervaring in huis was.
Ja dat klopt, mits goed georganiseerd. Organisatie is vaak het probleem, de afspraken maken en naleven en niet door werkdruk in de soep laten lopen. Niet even iets ertussen hacken zodat het werkt en daarna er niet meer naar kijken, dan gaat het fout, dat is het begin van het einde. Dat is een soort sneeuwbal van een gletsjer afduwen effect. Zal ik niet weer helemaal opsommen want staat hierboven ergens genoemd.

Ben niet zo weg van steeds het wiel opnieuw te moeten uitvinden als de situatie niet dermate veranderd is. Dus als het een stabiele oplossing is, werkt probleemloos in de taal waarvoor het gemaakt is (dus niet in het framework), dan gebruik ik dat. Mijn manier van software maken is dat het altijd optioneel is en stabiel blijft werken en dan ga ik het dus niet omschrijven in framework-format als dat niet strikt noodzakelijk is met het risico dat er dan weer nieuwe bugs optreden. Een framework van derden is een extra risico, extra weakness, als het omvalt, en dat gebeurd nog wel eens, dan kun je alles weer opnieuw gaan inrichten. Dat heb je met een taal een stuk minder.

Tevens in een framework kan niet alles wat in de taal wel kan, dan kan fijn zijn maar dat kan ook een belemmering zijn of niet goed geregeld zijn. Bijvoorbeeld met websites, caching headers, bijna altijd is het niet goed georganiseerd. Ik heb daar een sublieme oplossing voor maar dat zit niet gevangen in een framework en kan dus overal probleemloos werken. Dat scheelt zo ontiegelijk veel onnodig dataverkeer, zeker voor hele grote sites. Maar dan moet ik wel de kennis die ik heb kunnen gebruiken en als ik gevangen zit in zo'n denkmodel dan is dat niet toegestaan om het op taalniveau (een lager niveau) aan te pakken.

Dat is leuk voor de mens dat het zo toegankelijk is geworden/gemaakt (alhoewel daar zijn veel verschillende ideeen over), een machine werkt niet als een mens. Een hoop extra bladiebla maakt het voor de machine niet gemakkelijker, juist moeilijker. Daarom schreef ik eerder: "Als een NES 8-bit game met de huidige modellen van vandaag zou worden gemaakt en de processors van toen, dan was het niet vooruit te branden. "
Zijn er eigenlijk wel general-purpose frameworks voor low-level talen zoals C++? Volgens mij alleen veelgebruikte libraries.
Ja die zijn er wel, google it.
Ik denk dat er vooral binnen web development zoveel frameworks binnen zijn ontsproten, omdat daarbinnen zoveel te 'raamwerken' valt:
Ja, goede stelling, daarom is ook niet wenselijk dat men dat allemaal denkt terug te vinden in één denkmodel, als super oplossing, het te pas en te onpas toepassen. Alle opdrachten lijken wel op elkaar maar kunnen specifieke eisen bevatten die het toch weer heel bijzonder maken. Wat @JoeyPrr ook terecht aangaf, dan krijg je iets terug wat heel ingewikkeld is gemaakt terwijl de vraag heel simpel was. Ik heb ook een voorbeeld genoemd uit het verleden met het te pas en te onpas toepassen database gebruik, alles in een klasse etc.
Is het niet zo dat er nog altijd een ontzettend tekort is aan IT personeel? Ergo de bedrijven hebben het helemaal niet voor het kiezen? ( Of is dat niet meer zo anno 2017? Serieus dat wil ik dan wel weten.. ). Ze kunnen dus allemaal wel frameworks op hun vacatures plempen, volgens mij zijn ze alsnog prima blij als er iemand met genoeg development kennis en ervaring erop reageert. Dat weekje / maandje omscholen nemen ze wel voor lief. En zo niet, zijn er denk ik nog TIG andere bedrijven die je dan wel willen.
Als je iets beter je best had gedaan ;-) dan had je dat antwoord kunnen vinden ;-). Er is misschien wel een tekort aan personeel maar dat heeft een (gecreëerde) andere reden en dat is besparing, niet willen investeren in goed personeel, op voorhand niet. Dat kunnen vier dingen/redenen zijn (naar mijn idee):

1. Er is inderdaad niet genoeg geld door ontwikkelingen op de markt (door crisis of omdat mensen een reeds geautomatiseerde standaard oplossing kiezen ipv maatwerk);
2. Men wil voor een dubbeltje op de eerste rang zitten, winstmaximalisatie omdat het aanbod ICT-ers enorm is, er zit altijd wel iemand bij die het wel kan, is de gedachte. De 100% match dus. Als iemand niet hoeft te 'leren' hoef je er ook niet in te investeren, is dus goedkoper;
3. Als recruiter zijnde wil je iemand aanbieden die voldoet aan alle eisen, de 100% match, zodat je rendement wat zekerder is,. Ze kijken echter niet altijd even goed en bellen je om je op pad te sturen maar lezen je CV niet goed of nauwelijks (keyword match). Dat wat de vacaturemarkt een slechte naam geeft en daardoor de eisen aangescherpt zijn;
4. Het gaat alleen om produceren, kwaliteit (en wie je bent) is niet belangrijk (dus ook jij niet alleen als je het gevraagde kunstje kan en kan produceren). Het gaat om de kassa van de toko.

Zitten wat gemeenschappelijke raakvlakken in zoals "goedkoop", geldkwestie, het mag allemaal niet teveel kosten, het op zeker spelen, wantrouwen dus eigenlijk betreft risico. Leeftijd speelt wellicht ook een rol, hoe ouder hoe kritischer en hoe meer je ervaring je hebt, eigenzinnige mensen of mensen die uit ervaring spreken willen ze niet. Dan ben je niet zo volgzaam als je wat ouder bent, ben je niet zo beïnvloedbaar. In iedere geval geen gezond klimaat, het gaat in eerste instantie niet over kwaliteit.
- Ik heb programmeren in een framework nooit als een 'kunstje' beschouwt. Eerder altijd als een verademing. Ik wordt regelmatig ge-outsourced, maar mag op kosten van de baas prima een week of wat besteden aan het leren van een nieuwe framework of techniek als de opdracht dat vereist.
Daar zit de crux: "als de opdracht dat vereist". Dat is precies wat ik al eerder aangaf. Bijvoorbeeld bij Google kun je één keer per maand iets voor jezelf proberen, dat kan je tot nieuwe inzichten brengen maar dat kan niet als het gevangen zit in een denkmodel van het bedrijf (of welke andere koker). Dan krijg je pas echt een beetje de mogelijkheid om jezelf te zijn, iets persoonlijks toe te voegen aan, stimuleert om buiten kaders te leren denken, daar komt vooruitgang uit voort, nieuwe visies. Ik neem aan dat je daar niet alleen voor het bedrijf zit maar ook zelf wenst wijzer te worden, niet alleen binnen de kaders van het bedrijf.

Buiten de kaders mogen denken is:
a) Goed voor het bedrijf want jij maakt onderdeel uit van dat bedrijf en het zomaar kunnen zijn dat jij met iets baanbrekend komt waar het bedrijf nog niet aan gedacht had; Experimenteren is altijd goed, kan ervoor zorgen dat je dezelfde fout niet meer maakt (een praktijkbevestiging) of je komt met een aantoonbare reden dat het beter kan;
b) Goed voor jezelf, je gerespecteerd voelen als lid van dat bedrijf,nog enige inspraak hebt, dat stimuleert je om mee te denken, dat je nog enigszins van betekenis bent en niet alleen een medewerker.

Omdat bedrijven op te centjes moeten letten of voor (extra) winstmaximalisatie gaan, vergeten ze een heel belangrijk ding. Personeel, mensen, maakt het bedrijf en waardeer dat, spreek dat uit, zonder personeel geen bedrijf, zonder waardering geen langdurig bedrijf en geen ontwikkeling, zeker niet met een kokervisie. Wat voor nu geldt hoeft niet voor later te gelden. De bedenkers van alleen maar financiële voortgang en volgens (voorgekauwde) protocollen, zijn korte termijn denkers, zitten daar maar voor één ding, hunzelf. Er zijn plenty voorbeelden in de history waaruit dat blijkt dat alleen voor financieel gewin gaan op de langer termijn niet werkt.

Alleen de bedrijven die het serieus aanpakken redden het, zoals @johnkeates noemt, ik citeer:
"99% van de software afdelingen die zichzelf een beetje serieus nemen werken op basis van frameworks en niet op basis van random talen en paradigma's met de hoop dat even een framework leren kennen gratis is."
Als je dit roept dan begrijp je niet hoe het werkt. op de korte termijn misschien wel effectief qua inkomsten (totdat personeel echt in de gaten krijgt hoe het werkelijk zit, dat ze niets betekenen behalve voor de continuïteit). Zeker gezien de walhalla aan frameworks en de mogelijk maatwerk wat er kan zijn, is dit een niet realistische eis (zoals ik al eerder heb uitgelegd). Als je dat wil, dan zoek je een eenheidsworst, iemand om het klusje te klaren.

Iedere keer is het weer wat anders, vroeger had je UML (hoor je niets meer van), nu heb je weer Agile/Scrum (uit de klei getrokken gedateerde meuk en behoorlijk gehyped) en zo volgen we weer elke 'nieuwe' slimme methode om maar elk excuus in te bouwen om goed bezig te zijn. We weten het zelf als organisatie ook niet op te lossen dus halen we er maar weer een techniek/methodiek erbij om het voor het bedrijf de organisatieproblemen op te lossen wat vervolgens ook niet werkt (op de langer termijn). Probleem is de organisatie zelf en dan toevlucht zoeken in een methodiek om dat voor het bedrijf op te lossen. Het is eindeloos, uiteindelijk oplossing is heel eenvoudig, duidelijke afspraken en waardering naar je personeel toe.

Als bedrijven denken als bedrijf als @johnkeates bijvoorbeeld, dan ben je als bedrijf geen stuiver waard, alleen maar willen voorzien in 'behoefte' (dat ook nog eens gecreëerd is), niet willen investeren in mensen en ontwikkelingen buiten de kaders om, dan wil je geld op dat moment, dat is het enige dat deze bedrijven drijft. Niet de beste bedrijven om voor te werken.

[Reactie gewijzigd op dinsdag 13 juni 2017 04:26]


Door Tweakers user Erwines, dinsdag 13 juni 2017 15:51

Fledder2000 schreef op dinsdag 13 juni 2017 @ 00:10:
Ik sluit me aan bij de auteur: het is een slecht idee om een framework (dialect) te gebruiken om mensen per direct al uit te sluiten.

Ik zeg dat op basis van 20 jaar ervaring in een multinational waar telkens teams en technologieen verschuiven, waardoor ik al honderden programmeurs heb zien komen en gaan. Bij velen doe ik persoonlijk de tech interviews, en heb dus enig zicht op het scheiden van het kaf en het koren.

Bij sommige van onze beste mensen kan het bijvoorbeeld best voorkomen dat ze een bepaald relatief nieuw framework (1-3 jaar oud) nog niet kennen, simpelweg omdat ze nog geen opdracht gehad hebben, te druk met andere, bestaande opdrachten. Ze zullen zo'n framework begrijpen, maar hebben er geen praktijkervaring mee.

Welke ze vliegensvlug opdoen zodra er wel een opdracht is. We starten regelmatig projecten waar zo'n top developer een framework voor het eerst gebruikt, en dat gaat prima. We hebben het hier over mensen met 15, 20 of meer jaren ervaring. Die tig talen en frameworks hebben zien komen en gaan.

Dergelijke mensen uitsluiten is waanzin. Je laat erg veel lopen. Betrek ze gewoon in de selectie ronde, als blijk dat ze slecht zijn, kun je alsnog afwijzen.

Tot slot, tech skills is in mijn ervaring een van de minst belangrijke selectie criteria. De goede developers bij ons maken altijd het verschil op een ander vlak. Ze zijn zelfstandig. Verantwoordelijk. Communiceren goed. Gaan voor de goede oplossing en maken geen rommeltje.

En vergeet absoluut niet de conceptuele en architectuur skills. 20 jaar geleden op de HTS programmeerden we in Delphi. We hadden data binding, event driven patronen, separation of concerns, en zo kun je doorgaan. Grappig maar waar: de programmeer wereld staat conceptueel gezien al zo'n 30 jaar stil, want er is geen ene fuck veranderd aan al deze concepten. We programmeren nog steeds in 3GL talen (soms een deel 4G) en dus is alles hetzelfde, slechts de syntax veranderd.
Had jou reactie nog niet gezien, inderdaad wat je zegt, vooral je laatste alinea spreekt boekdelen, de smaakjes komen allemaal op hetzelfde neer behalve de schrijfwijze. Wat je schrijft:
[
Grappig maar waar: de programmeer wereld staat conceptueel gezien al zo'n 30 jaar stil, want er is geen ene fuck veranderd aan al deze concepten.
Het is in basis uitontwikkeld maar ze willen toch steeds met iets nieuws komen, dat is hip, zogenaamd gemakkelijker maar eigenlijk is het niet meer dan een gedachtegoed. Daar kun je jezelf in thuis voelen of niet, of je kunt het gemakkelijk leren want het lijkt allemaal zo op elkaar.

Meest stoor ik mij aan het eindeloos willen verbinden van verschillende concepten in één, daaruit volgt dan weer een andere schrijfwijze en/of taal dat in feite weer een nieuwe standaard creëert, zoals dit plaatje in drie frames duidelijk laat zien:
https://xkcd.com/927/

Voorbeelden zijn Flash Builder, PhoneGap, TypeScript, SASS, LESS, .NET, etc, de lijst is eindeloos dat een extra afhankelijkheid inbrengt, en/of beperkt (als niet alles mogelijk is wat rechtstreeks wel kan) en de schrijfwijze veranderd. Met het gevolg dat het over hetzelfde gaat maar iedereen een andere taal/dialact spreekt en elkaar dus in basis niet begrijpt. Of de oorsprong verhuist naar een andere locatie in de applicatie hiërarchie waar het helemaal niet thuis hoort. Templates in Javascript bijvoorbeeld om maar iets te noemen. Het was goed om alles gescheiden te houden en te gebruiken waarvoor het bedoeld is, en nu gooien we weer alles bij elkaar. Dat is dan handiger, onbegrijpelijk.

Ik denk dat de grootste oorzaak is van dit alles de fabrikanten zijn die door weer met iets nieuws willen komen, de upgradecarrousel als reden of programmeurs te willen binden aan een platform. De ene gebruikt QT, de andere Java, C/C++ en nog een ander gebruikt XCode voor praktisch hetzelfde, dingen met dezelfde eigenschappen, om maar iets te noemen. Dat wat dan wel wordt gelijkgetrokken als je een browser gebruikt, daar zijn dan wel standaarden voor, dat werkt in principe op elk device. Boordevol vertaalslagen. Het is natuurlijk goed om keuze te hebben maar je kunt ook overdrijven, doorslaan.

Het steeds maar proberen het schijnbaar gemakkelijker te maken is doorgeslagen en bemoeilijkt nu juist de situatie door alle smaakjes en features en zeker als het ook nog eens vereist is. Soort toren van Babel. Taal, de basis, kan ik nog inkomen om dat te vereisen maar een dialect niet, dat wat jij ook beschrijft.

[Reactie gewijzigd op dinsdag 13 juni 2017 16:09]


Reageren is niet meer mogelijk