[detachering] Combinatie van competenties niet te vinden

[seweso]

_{deze post is niet bedoeld als (verkapte) vacature maar is een (in mijn ogen) legitieme vraag over de gang van zaken bij een detacheringsbureau waar ik mee te maken heb.}

Wij zoeken (via een detacheringsbureau) iemand die de volgende competenties beschikt:

1. Webdesign, in staat zijn om website xxx professioneler én simpeler te maken.
2. (X)html, elk gewenste ontwerp in xhtml kunnen implementeren.
3. Javascript, de gebruikers-ervaring verbeteren door gebruik te maken van javascript.
4. Xsl (Xslt, Xpath), kennis van alle xslt en xpath functies (alle xhtml word op de pater-noster namelijk gegenereerd middels xml-transformatie).
5. Php, mocht er extra zoekfunctionaliteit, data-opslag en dergelijke toegevoegd moeten worden aan de pater-noster dan is kennis van php vereist.
6. Mysql en phpMyAdmin, voor geavanceerde sql commando's of aanpassingen in de structuur van de database van de pater-noster is kennis van MySql (en phpMyAdmin) vereist.

Het breekpunt is vaak het punt xsl, en nu is mijn vraag of er echt zo weinig programmeurs zijn die daar ervaring mee hebben? Is het normaal dat zo'n bureau niet iemand kan sturen die met alle onderwerpen bekend is?

Ik word nu namelijk gillend gek van alle mensen die ze op ons af sturen die zeggen ervaring te hebben maar als het puntje bij het paaltje komt echt niks presteren. Één persoon was zelfs in staat om te vragen wat Xsl en Xhtml nou eigenlijk is

Dus is het normaal dat ik zelf de competenties van een gedetacheerde medewerker moet controleren?

Ben ik gek als ik het belachelijk vind als iemand 3 uur nodig voor 75 regels code die alleen maar een uitbreiding (lees: knip en plak werk met kleine aanpassingen) zijn op een bestaand bestand?

Alvast bedankt voor alle fijne reacties hoewel dit schrijven ook al erg oplucht

[raptorix]

Waarom regel je dit via een detacheringsbureau, IMO zou je beter gebruik kunnen maken van een Freelancer, dan kan je tenminste fixprice werken, en niet goed geld terug. Daarnaast is de kwaliteit van freelancers over het algemeen hoger als mensen die gedetacheerd werken.

[Maasluip]

Ja, voor dit soort specifieke zaken is het heel normaal dat een detacheringsbureau daar niks vanaf weet. Ik zou zeggen: meld je voor de gein eens zelf aan, dan zie je wat voor vragenlijsten je voorgelegd krijgt. Voor programmeurs zijn die in de tegenwoordige tijd verre van toereikend (Xsl, Xhtml heb ik er tenminste nog nooit op zien staan).

En 3 uur voor 75 regels code? Vind ik aardig snel voor iemand die de applicatie niet kent. En testen heb je dan helemaal niet gedaan.

[ Voor 17% gewijzigd door Maasluip op 10-03-2005 14:20 ]

[curry684]

seweso schreef op donderdag 10 maart 2005 @ 14:15:
Dus is het normaal dat ik zelf de competenties van een gedetacheerde medewerker moet controleren?

Dat is sowieso normaal ja, detacheerbureaus zijn prutskutten en controleren niets van wat ze aangeboden wordt

En wat betreft je andere punt: er is inderdaad verdomd weinig praktische toepassing van XSL, waardoor er weinig competentie in is bij mensen. Ikzelf bijvoorbeeld kwalificeer ook (ruimschoots) op alle eisen die je noemt behalve XSL

[seweso]

Wij (lees: het directie-team van het bedrijf waar ik werk) wil iemand op korte termijn zonder al te veel touwtjes, daarnaast is het detacheringsbureau ook weer een klant van ons... dus vandaar dat we daar mee werken. Maar daar zit ik niet aan vast, aan een freelancer had ik eigenlijk nog niet gedacht...dat is misschien wel een betere oplossing.

[u_nix_we_all]

Waarom niet een extern web development bedrijf inschakelen ?
Dan heb je ook nog iets om op terug te vallen indien later blijkt dat er nog een
aanpassing nodig is , of problemen zijn.

Dat soort bedrijven hebben wel skilled developers over het algemeen.

[markvt]

Er moeten toch wel wat mensen rondlopen met die XSL kennis wij krijgen dat als module op school in ieder geval.

[seweso]

curry684 schreef op donderdag 10 maart 2005 @ 14:21:
[...]
Dat is sowieso normaal ja, detacheerbureaus zijn prutskutten en controleren niets van wat ze aangeboden wordt

En wat betreft je andere punt: er is inderdaad verdomd weinig praktische toepassing van XSL, waardoor er weinig competentie in is bij mensen. Ikzelf bijvoorbeeld kwalificeer ook (ruimschoots) op alle eisen die je noemt behalve XSL

Xsl is eigenlijk heel erg simpel, ik heb mezelf alles via w3schools aangeleerd. Eigenlijk is het een geavanceerde template engine.

Ik heb zelf voor Xsl gekozen dus daar pluk ik nu de vruchten van... misschien had ik het bij php alleen moeten houden, dat is uiteindelijk ook een template-engine alleen is dan de neiging om data/business/gui -logic door elkaar te gooien...

[whoami]

offtopic:
Jouw blog leest eigenlijk verschikkelijk slecht (rode letters op die blauw-grijze achtergrond), of ligt dat aan mij ?

[leuk_he]

Xls is volgens mij redelijk zeldzaam, maar zeker wel te vinden. Aleen de echter cracks die als die dingen hebben zitten uiteraard niet op de bank voor je te wachten.

seweso schreef op donderdag 10 maart 2005 @ 14:15:
Dus is het normaal dat ik zelf de competenties van een gedetacheerde medewerker moet controleren?

Ben ik gek als ik het belachelijk vind als iemand 3 uur nodig voor 75 regels code die alleen maar een uitbreiding (lees: knip en plak werk met kleine aanpassingen) zijn op een bestaand bestand?

Vertrouw je je detacherings bureau niet? Zeg het hun, of kies een andere.

2: als iemand de omgevinen kent: nee je bent niet gek. Als iemand de omgeving niet kent: de aanpassing kost je 5 minuten en de test aanzienlijk langer (tenzij je een ontwikkelaar wilt die niet test? )

[seweso]

Ik weet voor nu wel even genoeg, gelukkig ben ik niet gek! Thanx!

whoami schreef op donderdag 10 maart 2005 @ 14:27:

offtopic:
Jouw blog leest eigenlijk verschikkelijk slecht (rode letters op die blauw-grijze achtergrond), of ligt dat aan mij ?

Druk onder mijn logo op next (misschien moet ik ook bij de competenties vragen naar iemand die wél verstand heeft van kleuren)

[curry684]

seweso schreef op donderdag 10 maart 2005 @ 14:25:
[...]

Xsl is eigenlijk heel erg simpel, ik heb mezelf alles via w3schools aangeleerd. Eigenlijk is het een geavanceerde template engine.

Ow ik weet exact wat het is, maar weet er absoluut niet verkoopbaar voldoende inhoudelijk van. En zolang er nul vraag naar is ga ik geen tijd verspillen door me er in te verdiepen en houdt ik mezelf liever marketable als C/C#/C++ en SQL Server expert.

Ik heb zelf voor Xsl gekozen dus daar pluk ik nu de vruchten van... misschien had ik het bij php alleen moeten houden, dat is uiteindelijk ook een template-engine alleen is dan de neiging om data/business/gui -logic door elkaar te gooien...

Voor zover ik XSL ken (wat dus niet veel is geef ik grif toe) vind ik het een overcomplexe syntax voor te weinig tastbaar resultaat in 95% van de gevallen waar je het potentieel in zou kunnen zetten. Maja da's offtopic hier

[u_nix_we_all]

whoami schreef op donderdag 10 maart 2005 @ 14:27:

offtopic:
Jouw blog leest eigenlijk verschikkelijk slecht (rode letters op die blauw-grijze achtergrond), of ligt dat aan mij ?

offtopic:
Sorry voor dit offtopic geneuzel, maar moest wel even lachen om je blog,
vooral dat idee van een open source bundle.
Die bestaan al, en het heet "linux distributie"
Krijg je er ook nog eens een OS bij waarmee je minder kans hebt op virussen e.d.
en derhalve minder kans op data loss... en de mogelijke complicaties daarvan......

[Verwijderd]

XSLT als eis stellen jaagt m.i. de meeste decent ontwikkelaars al weg.

OK, je kunt er leuk XML mee transformeren, maar je wordt in een keurslijf gedrukt waar geen enkele programmeur zich happy in kan voelen. Welke idioot is ooit op het idee gekomen dat je de waarde van een xsl:variable niet mag wijzigen? Noem 't dan een xsl:constant of zo!

Waarom moet je wanneer je eigenlijk alleen een for-next loopje wil, je in allerlei recursive bochten wringen om 't voor elkaar te krijgen?
Ik schrijf 't dan wel in een taal die gewoon werkt op de manier die ik wil, en het transformeren van XML is ook geen rocket science of zo.

[curry684]

u_nix_we_all schreef op donderdag 10 maart 2005 @ 14:38:
[...]

offtopic:
Sorry voor dit offtopic geneuzel, maar moest wel even lachen om je blog,
vooral dat idee van een open source bundle.
Die bestaan al, en het heet "linux distributie"
Krijg je er ook nog eens een OS bij waarmee je minder kans hebt op virussen e.d.
en derhalve minder kans op data loss... en de mogelijke complicaties daarvan......

offtopic:
Ik moest er ook wel om lachen ja, hier en daar pure comedy

[Martin Sturm]

u_nix_we_all schreef op donderdag 10 maart 2005 @ 14:38:
[...]

offtopic:
Sorry voor dit offtopic geneuzel, maar moest wel even lachen om je blog,
vooral dat idee van een open source bundle.
Die bestaan al, en het heet "linux distributie"
Krijg je er ook nog eens een OS bij waarmee je minder kans hebt op virussen e.d.
en derhalve minder kans op data loss... en de mogelijke complicaties daarvan......

offtopic:
Om nog maar te zwijgen over http://www.theopencd.org/, wat ECHT precies is waar ie over schrijft.. onderzoek doen is ook onderdeel van het 'schrijven'

[Verwijderd]

seweso schreef op donderdag 10 maart 2005 @ 14:15:
Ik word nu namelijk gillend gek van alle mensen die ze op ons af sturen die zeggen ervaring te hebben maar als het puntje bij het paaltje komt echt niks presteren. Één persoon was zelfs in staat om te vragen wat Xsl en Xhtml nou eigenlijk is

Wat verwacht je wat een detacheringsbureau doet met mensen die zeggen dat ze ervaring hebben? Een detacheringsbureau kan gespecialiseerd zijn in ICT, maar dan nog hoeven ze in mijn ogen niet mensen op die competenties te gaan testen. Zij hebben toch nooit de kennis om te kunnen beoordelen of iemand 75 regels binnen X uur kan coden in een zelden gebruikte taal?

Volgens mij zijn detacheringsbureaus ervoor om mensen te zoeken die zeggen dat ze de door jou ge-eiste competenties hebben. Dit om jou de moeite van t zorgen dat de juiste advertenties en vacatures op de juiste plaats staan, te ontnemen. Ook is het een eerste drempel door on-gemotiveerde mensen en diegenen die toch reageren terwijl ze niet aan de eisen voldoen, nooit bij jou op de stoep staan.

[Alarmnummer]

Verwijderd schreef op donderdag 10 maart 2005 @ 14:50:
XSLT als eis stellen jaagt m.i. de meeste decent ontwikkelaars al weg.

OK, je kunt er leuk XML mee transformeren, maar je wordt in een keurslijf gedrukt waar geen enkele programmeur zich happy in kan voelen. Welke idioot is ooit op het idee gekomen dat je de waarde van een xsl:variable niet mag wijzigen? Noem 't dan een xsl:constant of zo!

Waarom moet je wanneer je eigenlijk alleen een for-next loopje wil, je in allerlei recursive bochten wringen om 't voor elkaar te krijgen?
Ik schrijf 't dan wel in een taal die gewoon werkt op de manier die ik wil, en het transformeren van XML is ook geen rocket science of zo.

Precies.. daarom gebruiken wij voor transformaties meestal Velocity. Niemand bij ons werkt graag met xslt omdat het meer werk kost dan het bespaard. Een normale template engine met een minder imbiciele syntax is imho veel praktischer.

[seweso]

Ik realiseer me heel goed dat mijn keuze voor xsl nu bij het aantrekken van hulp erg ongelukkig is, daar heb ik het directie-team ook over geinformeerd. Misschien ben ik dus toch gek geweest om voor xsl te kiezen. Persoonlijk heb ik niet het gevoel dat ik tegengehouden word in de onwikkeling doordat ik gebruik maak van xsl. Het is voor mij de perfecte manier om data om te zetten naar (x)html aangezien ik met generieke functies xml genereer en daar dus geen tot weinig aandacht meer aan hoef te besteden.

Maar misschien heb ik een waas voor mijn ogen omdat ik gek ben op nieuwe en onbekende technologiën. In mijn ogen heb ik gekozen voor een techniek die toekomst heeft. Ik had waarschijnlijk toen ik met het project begon hier (op got) moeten aankloppen...

Ik zal mijn keuze voor xsl even toelichten omdat dat zo'n beetje de oorzaak is van deze discussie. Het project betreft een online crm-applicatie welke gekoppeld moet worden (via internet) met een lokale foxpro database. Voor de communicatie met de server heb ik gekozen voor xml, ik neem aan dat ik die keuze niet hoef uit te leggen. In eerste instantie hoefde de gegevens alleen weergegeven te worden. Daarom heb ik niet voor alle xml-data velden aangemaakt in de database maar de xml als tekst opgeslagen. Vanuit daar was de keuze voor xsl niet zo gek aangezien ik dan in één stap van xml naar (x)html kon. Nu zijn we al weer een heel stuk verder en werkt de inbox/agenda-functie/zoek en management functionaliteit en ben ik dus in staat alles te maken m.b.v. xsl.

Wat voordelen op een rij:
1. Makkelijk klantspecifieke aanpassingen (door oa specifieke templates te vervangen)
2. Intern (foxpro) en extern (php) kunnen dezelfde stylesheets gebruikt worden
3. Doordat de gehele applicatie op xml is gebasseert is deze makkelijker te koppelen
4. Meerdere uitvoer formaten zoals wml, svg en xsl-fo zijn mogelijk.
5. Hele stricte scheiding tussen data en stylesheets (omdat er geen/weinig logica gebouwd kan worden in een stylesheet).

Maar misschien ben ik dus toch een beetje gek...

[Alarmnummer]

Het is denk ik ook hoeveel ervaring je ermee hebt. XSLT is een taal die je regelmatig moet gebruiken denk ik om alles een beetje op peil te houden. Wij gebruiken verder liever velocity omdat het een minder onduidelijke syntax heeft, minder onduidelijk werk/taal constructies heeft, en perfecte integratie met java heeft (je kunt vanuit velocity ook java objecten aanspreken).

De instap van velocity is veel en veel lager dan dat van xslt. En voor kleine dingetjes (want dat is het toch vaak) geeft xslt meer problemen dan voordelen bij ons. Het is niet dat we er niet mee werken, maar velocity doe je met plezier.. en xslt met een zucht..

Xslt is trouwens wel veel krachtiger dan velocity.. dus als je echt complexe transformatie zaken wilt ondernemen, of al helemaal in een xml gebaseerde omgeving zit, dan is xslt wel een betere keuze denk ik. Alleen als je al in een volledige xml omgeving zit dan is er geloof ik iets fundamenteels fout gegaan. En als ik echt complexe transformatie zaken wil ondernemen pak ik wel iets zoals Jamon..

[ Voor 27% gewijzigd door Alarmnummer op 10-03-2005 16:01 ]

[GX]

Van alle eisen die je daar stelt lijkt mij persoonlijk een standaard lijstje; zelfs de XML+XSL-family is in het bedrijf waar ik werk goed vertegenwoordigd door ontwikkelaars en word het ook al gebruikt in nieuwe onderdelen.

Ik kan mezelf eigenlijk ook niet voorstellen dat je jezelf een "webdeveloper" kan noemen als je je niet een beetje interesseert in nieuwe technieken.

[seweso]

Jamon en Velocity zijn beide java oplossingen, ik heb als programmeer-taal/engine php gekozen. Dan zijn die template engines voor mij dus geen optie. Verder bouw ik xsl templates niet met een zucht, maar misschien ben ik niet meer objectief aangezien je niet snel afkraakt wat je zelf heb gekozen/gemaakt.

Maar hoe dan ook, als jullie representief zijn voor alle programmeurs dan heb ik mezelf redelijk genaaid door de keuze voor xsl. Maar daar los ik mijn probleem natuurlijk niet mee op. Overstappen op iets anders is niet echt een keuze, behalve als ik het systeem weer opnieuw van de grond af ga opbouwen. Of ik moet alle xsl stylesheets via een xsl-stylesheet omzetten naar een andere template-engine

Ik ga ff kijken op nationalevacaturebank op xsl zoeken... kijken of er iets uitkomt.

[seweso]

GX schreef op donderdag 10 maart 2005 @ 16:07:
Van alle eisen die je daar stelt lijkt mij persoonlijk een standaard lijstje; zelfs de XML+XSL-family is in het bedrijf waar ik werk goed vertegenwoordigd door ontwikkelaars en word het ook al gebruikt in nieuwe onderdelen.

Ik kan mezelf eigenlijk ook niet voorstellen dat je jezelf een "webdeveloper" kan noemen als je je niet een beetje interesseert in nieuwe technieken.

Ha eindelijk een ander geluid! Bedankt

offtopic: deze vind je vast ook leuk, speciaal voor IE http://test.seweso.com/crash/

[Alarmnummer]

seweso schreef op donderdag 10 maart 2005 @ 16:10:
Jamon en Velocity zijn beide java oplossingen, ik heb als programmeer-taal/engine php gekozen. Dan zijn die template engines voor mij dus geen optie. Verder bouw ik xsl templates niet met een zucht, maar misschien ben ik niet meer objectief aangezien je niet snel afkraakt wat je zelf heb gekozen/gemaakt.

Maar hoe dan ook, als jullie representief zijn voor alle programmeurs dan heb ik mezelf redelijk genaaid door de keuze voor xsl.

Ik denk dat dat best meevalt. Er zijn genoeg developers die er absoluut geen problemen mee hebben. Trouwens... met een goeie XML ide (oXygen bv) is het ook veel minder vervelend om mee te werken.

[ Voor 3% gewijzigd door Alarmnummer op 10-03-2005 16:21 ]

[seweso]

Er staan (op nationalevacaturebank) 61 vacatures met de tekst 'xslt' en 0 met 'velocity'. Ter vergelijking: er staan 89 vacatures met 'php', 334 met 'xml' en 562 vacatures met 'java'.

[curry684]

Dat zijn natuurlijk nietszeggende getallen. Als ik even een eigen interpretatie mag geven: iedere idioot kan PHP leren en doet dat ook, waardoor er weinig reden is om nationale vacatures uit te zetten. Java-kenners zijn minder massaal aanwezig, en XSLT wordt niet tot nauwelijks gebruikt. Met deze hypothetische verklaring kan ik zo hard maken dat er 5000 PHP en 5000 Java-experts nodig zijn maar die dermate makkelijk te vinden zijn relatief dat er maar resp. 89 en 562 nationale vacatures overblijven na interne selectie et al. XSL kenners zijn niet te vinden, en dus komen er van de 100 vacatures 61 op de vacaturebank.

Dit is volstrekt hypothetisch natuurlijk, maar een potentieel valide uitleg van die cijfertjes. Met statistiek kun je alles bewijzen

[Alarmnummer]

seweso schreef op donderdag 10 maart 2005 @ 16:35:
Er staan (op nationalevacaturebank)

Dat komt omdat velocity zo eenvoudig is om te leren dat het niet eens een eis is

[seweso]

curry684 schreef op donderdag 10 maart 2005 @ 16:43:
Dat zijn natuurlijk nietszeggende getallen. Als ik even een eigen interpretatie mag geven: ....

Hmm, misschien was het beter als ik in het aanbod (cv's) zocht in plaats van in de vacatures.

[GambitRS]

curry684 schreef op donderdag 10 maart 2005 @ 16:43:
Dit is volstrekt hypothetisch natuurlijk, maar een potentieel valide uitleg van die cijfertjes. Met statistiek kun je alles bewijzen

Kan je dan ook bewijzen dat je met statistiek eigenlijk niks kan bewijzen? Of heb je dat met je voorbeeld al bewezen?

xml/xsl is eigenlijk niet iets wat je als ontwikkelaar standaard gaat gebruiken. Het gebruik van php en html of xhtml is namelijk een stuk makkelijker. Ook met php kan je gewoon valide xhtml maken en je kan heel makkelijk for loops, variabelen en functies maken. Makkelijker dan met xsl/xml.

Ik vraag me trouwens af hoe slim het is om in plaats van kollommen/tabellen te maken in je database al de data in een xml bestand te stoppen. Is dit soms sneller?

[Alarmnummer]

GambitRS schreef op donderdag 10 maart 2005 @ 17:05:
[...]
Ik vraag me trouwens af hoe slim het is om in plaats van kollommen/tabellen te maken in je database al de data in een xml bestand te stoppen. Is dit soms sneller?

Dat is zo traag als stront. Databases zijn gemaakt om efficient data in op te slaan, te queryen. XML is alleen geschikt voor data uitwisseling (en eventueel transformatie). Iemand die XML gebruikt als data opslag heeft duidelijk 0.0 er van begrepen en de wereld zou behoed moeten worden voor zijn domheid.

[Verwijderd]

Alarmnummer schreef op donderdag 10 maart 2005 @ 15:18:
Precies.. daarom gebruiken wij voor transformaties meestal Velocity. Niemand bij ons werkt graag met xslt omdat het meer werk kost dan het bespaard. Een normale template engine met een minder imbiciele syntax is imho veel praktischer.

Sttttttttttrrrriiiikkkeeee! Play ball ..

[curry684]

Alarmnummer schreef op donderdag 10 maart 2005 @ 17:06:
[...]

Dat is zo traag als stront. Databases zijn gemaakt om efficient data in op te slaan, te queryen. XML is alleen geschikt voor data uitwisseling (en eventueel transformatie). Iemand die XML gebruikt als data opslag heeft duidelijk 0.0 er van begrepen en de wereld zou behoed moeten worden voor zijn domheid.

Bot doch terecht. Amen

[Alarmnummer]

curry684 schreef op donderdag 10 maart 2005 @ 17:10:
[...]

Bot doch terecht. Amen

De opmerking was trouwens niet naar GambitRS..

[curry684]

Alarmnummer schreef op donderdag 10 maart 2005 @ 17:13:
[...]


De opmerking was trouwens niet naar GambitRS..

Als algemene statement is ie ook gewoon voluit terecht hoor

als het een persoonlijke flame naar iemand was geweest had er wel een edit gestaan intussen

[Verwijderd]

Alarmnummer schreef op donderdag 10 maart 2005 @ 17:06:
[...]
Dat is zo traag als stront. Databases zijn gemaakt om efficient data in op te slaan, te queryen. XML is alleen geschikt voor data uitwisseling (en eventueel transformatie). Iemand die XML gebruikt als data opslag heeft duidelijk 0.0 er van begrepen en de wereld zou behoed moeten worden voor zijn domheid.

Hangt natuurlijk ook van de data af. Bestaat de data uit iets wat conceptueel losse files zijn, dan kun je dat heel goed in XML opslaan. Bijvoorbeeld, een systeem waaraan ik werk heeft een verscheidenheid aan tekst templates. Deze templates zijn eigenlijk HTML met wat extra meta parameters.Vanuit het systeem roep je ze eenvoudig weg aan met een naam. Nu kan ik deze data ook wel in een DB gaan opslaan, maar wat is de meerwaarde. Ik ga geen counts doen, geen joins, of wat dan ook. Als alle tekst templates losse files zijn kan ik ze gewoon met elke tekst editor die ik wil editten.

Alle templates in 1 grote XML file opslaan, en dan doormiddel van parsing de juiste template er uit vissen is natuurlijk wel grote onzin.

[Verwijderd]

Verwijderd schreef op donderdag 10 maart 2005 @ 14:58:
[...]
Volgens mij zijn detacheringsbureaus ervoor om mensen te zoeken die zeggen dat ze de door jou ge-eiste competenties hebben. Dit om jou de moeite van t zorgen dat de juiste advertenties en vacatures op de juiste plaats staan, te ontnemen. Ook is het een eerste drempel door on-gemotiveerde mensen en diegenen die toch reageren terwijl ze niet aan de eisen voldoen, nooit bij jou op de stoep staan.

Ik ben zelf altijd bang dat zo'n bureau voornamelijk kijkt naar hoe gelikt en 'snel' iemand over komt. Een beetje zoals dat standaard verhaaltje dat een recruiter binnen 10 seconden heeft besloten of een kandidaat een kans maakt of niet. Mischien is dat complete onzin hoor, ik heb het ook alleen van horen zeggen, maar als dat wel zo is dan krijg ik daar echt een hele nare smaak van in de mond.

Het zijn vooral de mensen die er een beetje leuk uitzien en een goede babbel hebben die dan geselecteerd worden. Voor sommige beroepen is juist dat een vereiste, maar voor de meer technische IT beroepen juist helemaal niet. Als development bedrijf zitten wij dus absoluut niet op zulk soort babbelaars te wachten.

Vanwege die vooroordelen over recruiters doen wij dus altijd de solicitaties zelf. Daar gaat wel een behoorlijke tijd in zitten overigens. Wij zijn maar een redelijk klein bedrijf (16 mensen) en nodigen slechts een mannetje of 5 a 6 uit, maar zelfs dan ben je al behoorlijk lang er mee bezig.

[Alarmnummer]

Verwijderd schreef op donderdag 10 maart 2005 @ 19:27:
[...]


Hangt natuurlijk ook van de data af. Bestaat de data uit iets wat conceptueel losse files zijn, dan kun je dat heel goed in XML opslaan. Bijvoorbeeld, een systeem waaraan ik werk heeft een verscheidenheid aan tekst templates. Deze templates zijn eigenlijk HTML met wat extra meta parameters.Vanuit het systeem roep je ze eenvoudig weg aan met een naam. Nu kan ik deze data ook wel in een DB gaan opslaan, maar wat is de meerwaarde. Ik ga geen counts doen, geen joins, of wat dan ook. Als alle tekst templates losse files zijn kan ik ze gewoon met elke tekst editor die ik wil editten.

Voor kleine hoeveelheden data maakt het idd niet zoveel uit. XML is dan wel handig aangezien je niet zelf een parser in elkaar hoeft te plakken, niet vast zit aan rare serialisatie problematiek en eventueel ook nog uitgewisseld kan worden. Daar gebruik ik ook nog wel eens een xml bestandje voor.

Maar voor 'serieuze' hoeveelheden informatie en echt betrouwbare opslag kom je al snel bij een database uit.

[Verwijderd]

Een aantal discussies naast elkaar, hier mijn poging over iets zonvols over te zeggen:

Ja, je moet ALTIJD externe mensen testen op hun competenties. Daarom moet je ook een serieus intake gesprek organiseren, waarin zowel persoonlijke kwaliteiten en technische kennis getest worden. Er zijn zat mensen 'weggezet' die geen of nauwelijks kennis / ervaring hadden van het gevraagde, dat is mij ook weleens overkomen. In deze tijd kunnen IT bedrijven hun mensen moeilijker kwijt, dus wees kritisch en ga bij meerdere bedrijven shoppen of beding een lagere prijs. Stuur niet direkt iemand weg die een goede kandidaat is maar op 1 vlak minder of geen ervaring heeft, want training on the job kan soms goed werken, en je kunt evt. met de detacheerder een gereduceerd tarief afspreken voor de inwerktijd. Freelancers zijn ook een goede mogelijkheid, zoals al eerder genoemd, maar wees ook daar kritisch.

XSL(T) weet ik niet zo veel vanaf, maar als ik het nodig zou hebben, zou ik het me redelijk snel eigen kunnen maken. Wat ik er wel van weet is het inderdaad wat overkill voor templates, en ook voor PHP zijn er vast template engines die minder complex en het overwegen waard zijn.

Ben ik gek als ik het belachelijk vind als iemand 3 uur nodig voor 75 regels code die alleen maar een uitbreiding (lees: knip en plak werk met kleine aanpassingen) zijn op een bestaand bestand?

Tja, dat is zo afhankelijk van de omstandigheden dat hier weinig over valt te zeggen. Kennis van de code kan iets voor jou tot knip en plakwerk maken, waar een ander de code moet ontleden om het te begrijpen voordat het gebruikt kan worden. Aan de andere kant kan het ook een teken zijn van onkunde. Iets nieuws maken is over het algemeen een meer eerlijke benchmark voor iemands vaardigheden dan het laten onderhouden van bestaande code.

[Verwijderd]

Ik heb wel 's 3 uur nodig gehad voor 1 regel code, en dat was dan ook nog in source die ik volledig zelf geschreven had...
De capaciteiten van een ontwikkelaar meet je niet in het aantal regels dat 'ie per uur uitpoept.

[GambitRS]

Als je gaat betalen voor regels code dan krijg je rare situaties. Dan zal er nooit een efficient algoritme geschreven worden dat maar 5 regels code beslaat als er ook een zeer uitgebreid log algoritme bestaat wat hetzelfde doet en 100 regels code beslaat. Het algoritme van 5 regels is misschien sneller, efficienter en veel onderhoudbaarder, de programmeur krijgt 20 keer zoveel geld voor het logge algoritme.

Als ze echt per regels code betalen dan is het niet meer zo interessant om een loop te maken die 10 keer doorlopen wordt in een for lus, dan gaan mensen echt wel alles 10 keer knippen en plakken en de variabele zelf een beetje aanpassen.

[Verwijderd]

Vergeet ook niet dat de kunde die je vraagt niet 100% overeen hoeft te komen met wat iemand kent.

Zo hebben wij bijvoorbeeld een tijd geleden voor een Java project iemand aangenomen die een kei bleek te zijn in C++, maar eigenlijk amper Java aangeraakt had. Deze persoon heeft zich, geheel volgens mijn verwachting, in een mum van tijd Java aangeleerd. Een collega van mij wilde eerst dat we deze persoon niet zouden aannemen, enkel om het feit dat hij geen Java kende. Zijn voorkeur ging uit naar een veel middelmatiger persoon die dan toevallig wel met Java gewerkt had. Die bijna afgewezen kandidaat is nu een van onze top programmeurs...

In onze vacatures zetten we dus nu bijna bij elke eis "of gelijkwaardig". Laat de kandidaat dan maar uitleggen welke kennis hij of zij gelijkwaardig vind. Hoewel wij niet super vaak nieuwe mensen aan kunnen nemen, lijkt het er toch op dat dit betere kandidaten opleverd. Ik zie wel eens vacatures van andere bedrijven staan, en sommige eisen pakketten zijn zo specificiek dat ik zeker weet dat zelfs de meest hardcore devers op deze aardbol daar nog niet allemaal aan kunnen voldoen.

[Verwijderd]

Iemand die OO heeft leren denken, en niet te beroerd is om zich de syntax van een andere OO-taal aan te leren, kan gewoon overal terecht.

Maar ja, daar heeft TS niet zoveel aan, die zoekt juist zo'n mannetje/vrouwtje...

[Verwijderd]

Wat ik voornamelijk bedoel is dat TS niet te critisch moet zijn. Als je een kundig genoeg iemand treft met bijvoorbeeld veel ervaring met XML maar niet perse met Xpath, dan zou je ervan uit moeten gaan dat deze het snel kan leren.

Heck, elke IT prof kan zo'n beetje elke techniek wel redelijk snel onder de knie krijgen. Ik heb nog niet echt veel in postscript geprogrammeerd (wie wel ), maar wedden dat als ik een weekje of twee daar intensief op ga zitten dat ik een heel eind kom. Geldt voor zoveel dingen. Iemand die win32 doet, zal best snel met GTK uit de voeten kunnen, iemand die al veel met J2EE doet zal redelijk snel Struts kunnen gaan leren, etc.

Heb je echter voor een specificiek en ingewikkeld probleem een echte expert op dat gebied nodig, tsja, dan is het mischien wel een andere eis. Maar om 'gewoon' mee te developpen kun je gewoon van mensen aannemen dat ze bij geschiktheid voor gelijkwaardige technieken jouw specifieke techniek er bij kunnen leren.

[curry684]

Verwijderd schreef op donderdag 10 maart 2005 @ 22:59:
Iemand die OO heeft leren denken, en niet te beroerd is om zich de syntax van een andere OO-taal aan te leren, kan gewoon overal terecht.

Maar ja, daar heeft TS niet zoveel aan, die zoekt juist zo'n mannetje/vrouwtje...

Ik kreeg op dinsdag te horen dat ik de maandag erop C# expert moest zijn, even boek geregeld, die had ik vrijdag, helft in het weekend doorgelezen en hoppa maandag was ik C# expert

[GX]

curry684 schreef op vrijdag 11 maart 2005 @ 02:20:
[...]

Ik kreeg op dinsdag te horen dat ik de maandag erop C# expert moest zijn, even boek geregeld, die had ik vrijdag, helft in het weekend doorgelezen en hoppa maandag was ik C# expert

Grapjas

Imho kan je geen expert zijn door even een boekje te lezen ; als dat zo was zou je iedere starter aan kunnen nemen als zijnde expert. Expertise komt met ervaring en niet door botweg een paar jaar geleerd te hebben hoe het zou moeten en/of een boekje in een weekend te lezen.

Toegegeven, ernstig oppervlakkig. C# scheelt syntax-gewijs bijzonder weinig van andere populaire talen, maar toch moest ik 't statement kwijt

[Alarmnummer]

Verwijderd schreef op donderdag 10 maart 2005 @ 22:59:
Iemand die OO heeft leren denken, en niet te beroerd is om zich de syntax van een andere OO-taal aan te leren, kan gewoon overal terecht.

Maar ja, daar heeft TS niet zoveel aan, die zoekt juist zo'n mannetje/vrouwtje...

Ben ik niet met je eens. Iemand die goed oo kan hoeft bv totaal geen enkel inzicht te hebben in allerlei client server problematiek. En uiteraard.. hij zal het vast wel kunnen leren, maar hoeveel tijd gaat dit kosten? Ik kan een paar regeltjes java programmeren en J2EE specs waren me in grote lijnen wel bekend, maar het kost een berg tijd om het me goed meester te maken (dus om de juiste beslissingen te kunnen nemen)

De vraag is dus: ga je iemand aannemen met daarbij de wetenschap dat het een behoorlijke tijd gaat duren voordat die persoon echt effectief is. Ik zou liever iemand die j2ee beheerst aannemen (voor J2EE zaken uiteraard) dan iemand die bv meester in de c++ is.

[ Voor 5% gewijzigd door Alarmnummer op 11-03-2005 08:38 ]

[koli-man]

Verwijderd schreef op donderdag 10 maart 2005 @ 20:47:
Een aantal discussies naast elkaar, hier mijn poging over iets zonvols over te zeggen:

Ja, je moet ALTIJD externe mensen testen op hun competenties. Daarom moet je ook een serieus intake gesprek organiseren, waarin zowel persoonlijke kwaliteiten en technische kennis getest worden. Er zijn zat mensen 'weggezet' die geen of nauwelijks kennis / ervaring hadden van het gevraagde, dat is mij ook weleens overkomen. In deze tijd kunnen IT bedrijven hun mensen moeilijker kwijt, dus wees kritisch en ga bij meerdere bedrijven shoppen of beding een lagere prijs. Stuur niet direkt iemand weg die een goede kandidaat is maar op 1 vlak minder of geen ervaring heeft, want training on the job kan soms goed werken, en je kunt evt. met de detacheerder een gereduceerd tarief afspreken voor de inwerktijd. Freelancers zijn ook een goede mogelijkheid, zoals al eerder genoemd, maar wees ook daar kritisch.

Zo werkt het bij een (ICT)detacheringsbedrijf toch ook. Je krijgt aanvragen en aan de hand daarvan zoeken fieldmanagers geschikte mensen daarbij, die dan aangeboden wordt bij het desbetreffende bedrijf. dan krijg je ALTIJD nog een sollicitatiegesprek met het bedrijf zelf waarbij ze je aan de tand kunnen voelen. Elk bedrijf doet dat ook, want dat is hun goed recht en ze zouden stom zijn om dat niet te doen.
En het risico van: "Hij zei dat hij het kon" dat hou je altijd. Nog met gewoon interne mensen die aangenomen moeten worden.

@afterlife: Ik hoop niet dat het om i++; ging

[ Voor 3% gewijzigd door koli-man op 11-03-2005 08:29 ]

[MSalters]

curry684 schreef op vrijdag 11 maart 2005 @ 02:20:
[...]

Ik kreeg op dinsdag te horen dat ik de maandag erop C# expert moest zijn, even boek geregeld, die had ik vrijdag, helft in het weekend doorgelezen en hoppa maandag was ik C# expert

Lijkt me reeel. Heb voor onze analisten meeting meegeholpen aan de demo. Die was in C#, en dat had ik nog nooit gezien op het moment dat ik eraan begon. 't Is gewoon VB met een Java syntax.

[whoami]

MSalters schreef op vrijdag 11 maart 2005 @ 09:49:
[...]

't Is gewoon VB met een Java syntax.

is wel een beetje heel kort door de bocht.

[koli-man]

MSalters schreef op vrijdag 11 maart 2005 @ 09:49:
[...]

Lijkt me reeel. Heb voor onze analisten meeting meegeholpen aan de demo. Die was in C#, en dat had ik nog nooit gezien op het moment dat ik eraan begon. 't Is gewoon VB met een Java syntax.

Ik zie het meer als c++ voor het .NET framework zonder multiple inheritance met java syntax.
Want het is echt niet gewoon VB. VB.NET is ook ietsjes(:lees veel) anders dan VB6 (IMHO)

[ Voor 5% gewijzigd door koli-man op 11-03-2005 09:57 ]

[seweso]

Die potentiële gedetacheerde zei dat hij wel veel van php wist maar vervolgens kende hij niet de functie array_merge(). Misschien is het wat kort door de bocht om dan te concluderen dat hij niet genoeg verstand in zijn bol heeft. Maar persoonlijk vind ik dat array_merge één van de krachtigste en handigste functie van php is.

---

Om meer inzicht te geven in xsl (voor de leken) heb ik hier een voorbeeld, dit is tevens waar 70 regels code in geschreven waren (voor een paar extra velden):

code:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:template match="/xml_http">
       <xsl:text disable-output-escaping="yes"><![CDATA[<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">]]></xsl:text>
        <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="nl" lang="nl">
            <head>
                <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
                <title>Leveringsovereenkomst <xsl:value-of select="//handelsnaam1_30"/></title>
                
                <style type="text/css">
                    body {
                        margin:             0cm;
                        padding:            0cm;
                        color:              black;
                        
                        font-family:        Arial;
                        font-size:          0.4cm;
                    }
                    div {
                        position:           absolute;
                    }
                    #outer {
                        top:                -1.8cm; 
                        left:               -1.75cm;
                    }
                    #bg {
                        top:                0cm; 
                        left:               0cm;
                        
                        width:              20.99cm; 
                        height:             29.55cm;
                    }

                    #id                 {   top:  3.05cm;   left: 15.67cm; }
                    #bedrijfsnaam       {   top:  3.05cm;   left:  3.10cm; }
                    #contactpersoon     {   top:  3.60cm;   left:  6.50cm; }
                    #telefoonnummer     {   top:  4.16cm;   left:  3.50cm; }
                    #faxnummer          {   top:  4.16cm;   left: 12.90cm; }
                    #email              {   top:  4.71cm;   left:  2.05cm; }
                    #kvknummer          {   top:  4.71cm;   left: 15.67cm; }
                    
                    #leveringsadr       {   top:  5.81cm;   left:  3.65cm; } 
                    #postcode1          {   top:  6.41cm;   left:  2.40cm; }
                    #postplaats         {   top:  6.41cm;   left:  9.00cm; }
                    
                    #postadr            {   top:  7.50cm;   left:  3.70cm; }
                    #postcode           {   top:  8.05cm;   left:  2.30cm; }
                    #woonplaats         {   top:  8.05cm;   left:  9.00cm; }

                </style>
            </head>
            <body>
                <div id="outer">

                    <!-- Bedrijfsnaam -->
                    <div id="bedrijfsnaam">
                        <xsl:value-of select="//handelsnaam1_30"/>
                        <xsl:if test="//handelsnaam2_30 != ''">
                             - <xsl:value-of select="//handelsnaam2_30"/>
                        </xsl:if>
                    </div>
    
                    <!-- Bedrijfsnaam -->
                    <div id="id">
                        Ons nummer: S<xsl:value-of select="//intid"/>
                    </div>

                    <!-- Contactpersoon -->
                    <div id="contactpersoon">
                        <xsl:value-of select="//contactpersoon/xtra/volledig"/>
                    </div>
    
                    <!-- Telefoonnummer -->
                    <div id="telefoonnummer">
                        <xsl:value-of select="//bedrijf/telefoonnummer"/>
                    </div>
    
                    <!-- Faxnummer -->
                    <div id="faxnummer">
                        <xsl:value-of select="//bedrijf/faxnummer"/>
                    </div>
    
                    <!-- Email -->
                    <div id="email">
                        <xsl:value-of select="//bedrijf/email"/>
                    </div>
    
                    <!-- Kvknummer -->
                    <div id="kvknummer">
                        <xsl:value-of select="//bedrijf/key_dossiernummer"/> - <xsl:value-of select="//bedrijf/key_subdossiernummer"/>
                    </div>
                    
                    <!-- leveringsadr -->
                    <div id="leveringsadr">
                        <xsl:value-of select="//bedrijf//va_straatnaam"/>
                    </div>
            
                    <!-- postcode1 -->
                    <div id="postcode1">
                        <xsl:value-of select="//bedrijf/va_postcode"/>
                    </div>
            
                    <!-- postplaats -->
                    <div id="postplaats">
                        <xsl:value-of select="//bedrijf/va_woonplaats_nen"/>
                    </div>

                    <!-- postadr -->
                    <div id="postadr">
                        <xsl:value-of select="//bedrijf/ca_straatnaam"/>
                    </div>
                    
                    <!-- postcode -->
                    <div id="postcode">
                        <xsl:value-of select="//bedrijf/ca_postcode"/>
                    </div>
                
                    <!-- woonplaats -->
                    <div id="woonplaats">
                        <xsl:value-of select="//bedrijf/ca_woonplaats_nen"/>
                    </div>
                    
                </div>
            </body>
        </html>     
    </xsl:template>

</xsl:stylesheet>

persoonlijk lijkt me niet dat iemand kan zeggen dat dat er complex uit ziet.

---

En nee ik had inderdaad geen zin om zelf iemand een cursus xsl/css/php te geven, ik zou het juist leuk vinden als ik een collega krijg waar ík iets van kan leren. Iemand die meer kan dan hij zegt i.p.v. andersom.

---

offtopic: Ik gebruik uiteraard niet alleen xml als datastorage, velden waarop gezocht/gegroepeerd moet kunnen worden hebben een eigen veld in de database. En ja dat is redundant maar dat is een index die je op een veld legt eigenlijk ook. Om sommige velden alleen in xml op te slaan is gewoon om de ontwikkelsnelheid te verhogen, tevens waren heel veel velden simpelweg niet meer nodig en is die informatie alleen ter info aanwezig.

[koli-man]

seweso schreef op vrijdag 11 maart 2005 @ 09:59:
Die potentiële gedetacheerde zei dat hij wel veel van php wist maar vervolgens kende hij niet de functie array_merge(). Misschien is het wat kort door de bocht om dan te concluderen dat hij niet genoeg verstand in zijn bol heeft. Maar persoonlijk vind ik dat array_merge één van de krachtigste en handigste functie van php is.

php heeft duizenden handige functies. Wellicht gebruikt hij andere handige functies waar jij de werking niet van kent. Als hij maar weet wat een array is en wat bedoelt wordt met merge. Dat is toch genoeg. De rest kan hij opzoeken en dat is vrij snel gebeurd

[Bor]

raptorix schreef op donderdag 10 maart 2005 @ 14:18:
Waarom regel je dit via een detacheringsbureau, IMO zou je beter gebruik kunnen maken van een Freelancer, dan kan je tenminste fixprice werken, en niet goed geld terug.

Dat kan met een detacheerder ook prima hoor.

Daarnaast is de kwaliteit van freelancers over het algemeen hoger als mensen die gedetacheerd werken.

En dat is totale onzin.

[curry684]

MSalters schreef op vrijdag 11 maart 2005 @ 09:49:
[...]

Lijkt me reeel. Heb voor onze analisten meeting meegeholpen aan de demo. Die was in C#, en dat had ik nog nooit gezien op het moment dat ik eraan begon. 't Is gewoon VB met een Java syntax.

Nou ik vind C++ zonder globals, templates, multiple inheritance, memory leaks, pointers en references een prettiger omschrijving, wat ook verklaart waarom ik het in 2 dagen moeiteloos onder de knie had: het ging meer om het afleren van een paar dingen dan feitelijk iets nieuws leren

[curry684]

seweso schreef op vrijdag 11 maart 2005 @ 09:59:
Die potentiële gedetacheerde zei dat hij wel veel van php wist maar vervolgens kende hij niet de functie array_merge(). Misschien is het wat kort door de bocht om dan te concluderen dat hij niet genoeg verstand in zijn bol heeft. Maar persoonlijk vind ik dat array_merge één van de krachtigste en handigste functie van php is.

Sorry maar dit vind ik dus idioot kortzichtig, om een potentiele kandidaat af te fakkelen op het feit dat ie 1 functie niet kent die jij wel kent, en wat hij wellicht al jaren efficienter op lost dan met die ene functie die jij "persoonlijk één van de krachtigste en handigste functies van php vindt". Anders sta je even open voor andere inzichten

persoonlijk lijkt me niet dat iemand kan zeggen dat dat er complex uit ziet.

Je pakt ook wel een idioot simplistisch voorbeeld. Post nu even de XSLT die deze pagina op GoT zou renderen uit de XML-feed van React?

[koli-man]

curry684 schreef op vrijdag 11 maart 2005 @ 10:21:
[...]

Nou ik vind C++ zonder globals, templates, multiple inheritance, memory leaks, pointers en references een prettiger omschrijving, wat ook verklaart waarom ik het in 2 dagen moeiteloos onder de knie had: het ging meer om het afleren van een paar dingen dan feitelijk iets nieuws leren

Tja...Ik had eens een operator= nodig bij C#. En die mag ook niet.

[whoami]

seweso schreef op vrijdag 11 maart 2005 @ 09:59:
Die potentiële gedetacheerde zei dat hij wel veel van php wist maar vervolgens kende hij niet de functie array_merge(). Misschien is het wat kort door de bocht om dan te concluderen dat hij niet genoeg verstand in zijn bol heeft. Maar persoonlijk vind ik dat array_merge één van de krachtigste en handigste functie van php is.

Het al of niet kennen van één of andere functie wil niet zeggen dat je daarom geen verstand in je bol hebt.
Ik vind het ook maar onzinnig om iemand z'n potentieel te gaan testen adhv het al of niet kennen van bepaalde specifieke functies.

Om meer inzicht te geven in xsl (voor de leken) heb ik hier een voorbeeld, dit is tevens waar 70 regels code in geschreven waren (voor een paar extra velden):

Ja, daar krijgt een leek inzicht van....
Ik kan hier ook een stuk code gaan neerkwakken over iets zodat jij er meer inzicht zou in krijgen; maar als ik totaal niet vertel waarvoor dat stukje code dient, of wat het doet, dan krijg je daar helemaal geen inzciht in.

[whoami]

curry684 schreef op vrijdag 11 maart 2005 @ 10:21:
[...]

Nou ik vind C++ zonder globals, templates, multiple inheritance, memory leaks, pointers en references een prettiger omschrijving, wat ook verklaart waarom ik het in 2 dagen moeiteloos onder de knie had: het ging meer om het afleren van een paar dingen dan feitelijk iets nieuws leren

Qua taal opzich moet je idd niet echt veel 'nieuws' leren; maar qua 'algemene mogelijkheden' in .NET kan ik me niet voorstellen dat je daar niets nieuws hebt moeten leren.

(Ow, en pointers in C# kunnen wel hoor, en memory leaks eigenlijk min of meer ook.).

[curry684]

whoami schreef op vrijdag 11 maart 2005 @ 10:36:
[...]

Qua taal opzich moet je idd niet echt veel 'nieuws' leren; maar qua 'algemene mogelijkheden' in .NET kan ik me niet voorstellen dat je daar niets nieuws hebt moeten leren.

Ja een aantal dingen moet je even globaal inzicht in krijgen, met name grappen als de relatie tussen IEnumerable en foreach etc., evenals IDisposable en ICollection. On the other hand zijn dat typisch dingen waar je alleen even globaal wat van hoeft te weten, en als het nodig is heb je het binnen 5 minuten opgezocht en snap je het ook voor de rest van je leven

(Ow, en pointers in C# kunnen wel hoor, en memory leaks eigenlijk min of meer ook.).

Het keyword unsafe erken ik niet Als ik ranzig wil raggen pak ik wel meteen C++

[whoami]

curry684 schreef op vrijdag 11 maart 2005 @ 10:39:
[...]

Ja een aantal dingen moet je even globaal inzicht in krijgen, met name grappen als de relatie tussen IEnumerable en foreach etc., evenals IDisposable en ICollection. On the other hand zijn dat typisch dingen waar je alleen even globaal wat van hoeft te weten, en als het nodig is heb je het binnen 5 minuten opgezocht en snap je het ook voor de rest van je leven

Idd, en ook dingen zoals .NET remoting; ADO.NET; etc....

Het keyword unsafe erken ik niet Als ik ranzig wil raggen pak ik wel meteen C++

Daarmee erken je dus dat C++ ranzig is.

[curry684]

whoami schreef op vrijdag 11 maart 2005 @ 10:42:
[...]

Daarmee erken je dus dat C++ ranzig is.

Nee, C++ staat me toe ranzig te raggen als ik daar behoefte aan heb

[whoami]

Viespeuk.

[Verwijderd]

Alarmnummer schreef op vrijdag 11 maart 2005 @ 08:05:
De vraag is dus: ga je iemand aannemen met daarbij de wetenschap dat het een behoorlijke tijd gaat duren voordat die persoon echt effectief is. Ik zou liever iemand die j2ee beheerst aannemen (voor J2EE zaken uiteraard) dan iemand die bv meester in de c++ is.

Er zijn natuurlijk veel meer factoren die meespelen, zoals bv. kennis van en ervaring in de branche waarvoor je software bedoeld is.
Als die c++ meester die kennis en ervaring in huis heeft, krijgt een J2EE goeroe zonder die achtergrond het verdraaide lastig...

Praktijkvoorbeeldje: we hebben ooit 's een Delphi ontwikkelaar aangenomen die die taal meer dan beheerste. Maar ze had eigenlijk alleen maar ervaring in het ontwikkelen van back office / administratieve pakketten.
Gevolg: ze ging allerlei handige print dialogs en save dialogs in de UI inbouwen (welke printer? briefpapier of blanco? waar moet 't bestand naartoe?). Prachtig voor een boekhouder, maar een crime aan de receptie van een hotel wanneer er 100+ mensen willen uitchecken.
Iemand met een hotelbranche-achtergrond zou meteen weten dat je in zo'n situatie geen dialogs etc. wil hebben.

Het aanleren van dat soort branche-specifieke dingen kost vaak meer tijd dan het aanleren van een nieuwe taal.

[FendtVario]

Verwijderd schreef op vrijdag 11 maart 2005 @ 11:34:
Praktijkvoorbeeldje: we hebben ooit 's een Delphi ontwikkelaar aangenomen die die taal meer dan beheerste. Maar ze had eigenlijk alleen maar ervaring in het ontwikkelen van back office / administratieve pakketten.
Gevolg: ze ging allerlei handige print dialogs en save dialogs in de UI inbouwen (welke printer? briefpapier of blanco? waar moet 't bestand naartoe?). Prachtig voor een boekhouder, maar een crime aan de receptie van een hotel wanneer er 100+ mensen willen uitchecken.
Iemand met een hotelbranche-achtergrond zou meteen weten dat je in zo'n situatie geen dialogs etc. wil hebben.

Zoiets kun je natuurlijk ook in de specs opnemen

[Verwijderd]

FendtVario schreef op vrijdag 11 maart 2005 @ 11:44:
Zoiets kun je natuurlijk ook in de specs opnemen

Ehm... 1 van haar taken was 't definieren en documenteren van de specs...

[FendtVario]

Ja kijk, dat schreef je er niet bij.

De competenties die TS stelt aan de detacheerder liggen redelijk op een lijn. Dat er maar weinig mensen zijn die kennis XSL hebben is misschien ook wel omdat niemand de kracht er van inziet of omdat het op het eerste gezicht redelijk ingewikkeld lijkt. De XSL zoals hierboven is een van het simpele soort, een XSL tutorial dat ik ook eens op devworks van IBM bekeken heb was al ingewikkelder.

Over het algemeen heb ik altijd wel het idee dat er in vacatures (en waarschijnlijk dus ook bij detachering) gevraagd wordt naar mensen van 25 met 30 jaar ervaring. Soms zie je lijsten, deze bijv uit de vacaturebank van de automatiseringsgids:

Java Software Professionals met werkervaring in moderne technologieën als RUP,
DSDM, Object Oriëntatie, UML, datamodellering, portals, J2EE, Java, WASD, WAS, Struts, XML, JSP, JDBC, HTML, SQL, Corba, Internet/Intranet/Extranet/Web applicaties, JBuilder, JDeveloper, WebSphere, Eclipse, Tomcat, Apache, Silverstream, Client/Server, Multi-tier, (Relationele) Databases, Rational Suite Development Studio, Oracle, SQL Server, Windows en Unix/Linux;

[EfBe]

MSalters schreef op vrijdag 11 maart 2005 @ 09:49:
[...]
Lijkt me reeel. Heb voor onze analisten meeting meegeholpen aan de demo. Die was in C#, en dat had ik nog nooit gezien op het moment dat ik eraan begon. 't Is gewoon VB met een Java syntax.

Tuurlijk. En C++ is C# voor mensen die graag moeilijk doen wanneer het makkelijk kan, toch?

Curry: En dan nu de duizenden api classes nog even... in een middag. Het taaltje leren kost je nog geen uur volgens mij als C++ programmeur, alhoewel dingen als object references passen by ref, delegates en dangling event handlers de problemen wel vergroten voor je.

Over het onderwerp zelf: detacheringsbureaus leveren over het algemeen lagere kwaliteit mensen af, omdat ze aan CV-opleuken doen. Als je het boek ook maar onder je monitor hebt liggen vanwege ergomische rederen dan ben je al specialist.

Het is ook niet handig via detacheringsbureaus te werken, want je betaalt veel te veel, soms zitten er meerdere tussen jou en de gedetacheerde! Dat levert een scheef beeld op: de werkgever denkt: "Ik betaal die harkemaaier 100EUR/uur en hij kan nauwelijks wat!!" en die gedetacheerde denkt: "Sjezus, ik krijg 35EUR/uur en die eikels verwachten dat ik werk lever alsof ik voor 100 EUR/uur betaald krijg!" en die detacheerders maar lachen. Beetje ouwehoeren en wat in de auto rijden en that's it.

Pooiers zijn het en dat uitschot is er mede de oorzaak van dat de IT een slechte naam heeft: weinig werk voor veel geld en vaak ook nog voor belabberde kwaliteit.

TS: plaats een posting in nl.markt.freelance. 10 tegen 1 dat je wel de mensen krijgt en zonder tussenbureau.

[ Voor 68% gewijzigd door EfBe op 11-03-2005 13:16 . Reden: opm. verduidelijkt ]

[curry684]

EfBe schreef op vrijdag 11 maart 2005 @ 12:54:
[...]

Tuurlijk.

En dan nu de duizenden api classes nog even... in een middag.

Mjah kan aan mij liggen maar ik heb in .NET nog nooit langer dan 5 minuten naar een specifieke class hoeven zoeken die ik nodig had. Je kunt niet zeggen dat het niet logisch in mekaar zit Dat is ook de essentie van de statement die we maken: zodra je kunt programmeren, computers inhoudelijk snapt en een hoop ervaring met development hebt is een nieuwe taal niets anders dan wat nieuwe grammatica voor trucjes die je al kent, en een nieuw framework enkel een andere verpakking om concepten die je al kent. Hell, .NET volgt zelfs interfacetechnisch de C++ frameworks vrijwel perfect die ik door de jaren heen heb geschreven, there's only so many ways to define the same thing.

Hetzelfde voor XSLT, geef me 2 dagen met een goed boek en een goeie tutorial en ik durf mezelf als XSLT-expert aan topicstarter te verkopen, en waarschijnlijk trapt ie er nog in ook. De rest leer ik wel on the fly uit de helpfiles. Ik vind het alleen voor XSLT de moeite niet waard.

[EfBe]

curry684 schreef op vrijdag 11 maart 2005 @ 13:00:
Mjah kan aan mij liggen maar ik heb in .NET nog nooit langer dan 5 minuten naar een specifieke class hoeven zoeken die ik nodig had. Je kunt niet zeggen dat het niet logisch in mekaar zit

Dat valt wel tegen. Sommige areas wel, veel niet. Komt omdat de .NET api door verschillende teams is gemaakt.

Dat is ook de essentie van de statement die we maken: zodra je kunt programmeren, computers inhoudelijk snapt en een hoop ervaring met development hebt is een nieuwe taal niets anders dan wat nieuwe grammatica voor trucjes die je al kent, en een nieuw framework enkel een andere verpakking om concepten die je al kent. Hell, .NET volgt zelfs interfacetechnisch de C++ frameworks vrijwel perfect die ik door de jaren heen heb geschreven, there's only so many ways to define the same thing.

Over de taalsyntaxis: mee eens. Over kennis van framework: grote onzin. Als we beide op dezelfde .NET opdracht zitten programmeer ik jou vierkant onder de tafel met je middagje C# boekje lezen en je helpfiles. Dat is ook niet raar, ik zit er al 3 jaar 10 uur per dag in. Jij moet dus veel opzoeken en maakt iedere beginnersfout die je kunt maken, moet veel naar google om op te zoeken waarom een class method niet doet wat hij zou moeten doen volgens jou etc. Override maar eens Equals in je class, welke arraylist methods veranderen dan allemaal van functie? Zodra je wat complexere zaken moet gaan oplossen sta jij met je mond vol tanden en ben je uren aan het opzoeken en proberen.

No offence, maar dat is dus jouw klant oplichten.

Hetzelfde voor XSLT, geef me 2 dagen met een goed boek en een goeie tutorial en ik durf mezelf als XSLT-expert aan topicstarter te verkopen, en waarschijnlijk trapt ie er nog in ook. De rest leer ik wel on the fly uit de helpfiles. Ik vind het alleen voor XSLT de moeite niet waard.

Tuurlijk leer je veel uit helpfiles, en XSLT is ook niet zo moeilijk op zich (tenzij de xml complex is met namespaces en andere zooi en je veel complexe xpaths nodig hebt etc.) Je bent echter wel veel meer uren kwijt. En die moet de klant wel betalen. Dat is niet alleen etisch gezien niet juist, het is ook nog eens voor jou niet zo slim, want die klant gaat jou niet nog eens inhuren (en als je mij als werkgever had schopte ik je er direct uit zodra ik doorkrijg dat je niet meer dan een beginner bent. Het lullige is dat ik wel specialist ben in dit kader, en de gemiddelde inhuurder dat niet is en dus niet kan beoordelen of het geleverde werk per uur wel de kwaliteit heeft die je mag verwachten voor het geld dat betaald wordt. En daar maken die IT-pooiers dankbaar gebruik van. )

[ Voor 8% gewijzigd door EfBe op 11-03-2005 13:15 ]

[whoami]

EfBe schreef op vrijdag 11 maart 2005 @ 12:54:
[...]

Over het onderwerp zelf: detacheringsbureaus leveren over het algemeen lagere kwaliteit mensen af, omdat ze aan CV-opleuken doen. Als je het boek ook maar onder je monitor hebt liggen vanwege ergomische rederen dan ben je al specialist.

Ik ken het.
Ik heb nog voor een detacheerbureau gewerkt, maar dat doe ik NOOIT meer.

Toen ik een tijdje op de bank zat, zochten een klant van hen mensen die kennis hadden van een of andere taal.
Het detacheerbureau hield van al z'n werknemers een CV bij, en die CV's werden dan naar klanten gestuurd. Die konden dan op basis van dat CV een eerste keuze maken.
Nu moest een collega van me op gesprek naar het eerder vermelde bedrijf. Het eerste wat die klant vroeg aan die gast was:
'Jij hebt gestudeerd aan xxxx-school?' Waarop hij positief antwoorde.
Dan zei ze: 'Nu moet jij mij eens uitleggen hoe je daar informatica kunt gestudeerd hebben zoals op jouw CV staat, want ze bieden daar niet eens de opleiding informatica aan'.

Wat bleek: die gast had electronica oid gestudeerd, en dat zelf ook op z'n CV gezet, maar blijkbaar had het detacheerbureau die gast z'n CV doodleuk aangepast zonder z'n medeweten, en electronica veranderd naar informatica....

[Alarmnummer]

curry684 schreef op vrijdag 11 maart 2005 @ 13:00:
[...]

Mjah kan aan mij liggen maar ik heb in .NET nog nooit langer dan 5 minuten naar een specifieke class hoeven zoeken die ik nodig had.

Het gaat niet om het vinden van een class, maar de ideeen achter iets begrijpen en weten wanneer je wel of niet iets moet toepassen, wat sterke punten en zwakke punten zijn, en wat de consequenties zijn. Dat is iets heel anders dan wat classes terug zien te vinden.

Dat is ook de essentie van de statement die we maken: zodra je kunt programmeren, computers inhoudelijk snapt en een hoop ervaring met development hebt is een nieuwe taal niets anders dan wat nieuwe grammatica voor trucjes die je al kent, en een nieuw framework enkel een andere verpakking om concepten die je al kent.

Ben ik niet met je eens. Er zijn genoeg frameworks waarbij je op een fundamenteel andere manier te werk gaat dan alles wat je eerder hebt gedaan, bv Spring.

Hetzelfde voor XSLT, geef me 2 dagen met een goed boek en een goeie tutorial en ik durf mezelf als XSLT-expert aan topicstarter te verkopen, en waarschijnlijk trapt ie er nog in ook. De rest leer ik wel on the fly uit de helpfiles. Ik vind het alleen voor XSLT de moeite niet waard.

Ik geef je geen schijn van kans bij bv J2EE. Dat is een grote set met complexe specificaties waar je gerust jaren zoet mee kunt zijn om overal even mee in aanraking te komen (laat staan specialist in te zijn)

[ Voor 6% gewijzigd door Alarmnummer op 11-03-2005 13:23 ]

[koli-man]

EfBe schreef op vrijdag 11 maart 2005 @ 12:54:
[...]


Pooiers zijn het en dat uitschot is er mede de oorzaak van dat de IT een slechte naam heeft: weinig werk voor veel geld en vaak ook nog voor belabberde kwaliteit.

TS: plaats een posting in nl.markt.freelance. 10 tegen 1 dat je wel de mensen krijgt en zonder tussenbureau.

hmmmz..en bedankt
Ik vind het jammer dat er weer iedereen over een kam geschoren wordt, want er zijn ook mensen die de goede opleidingen gevolgd hebben voordat ze bij een detacheerder gaan werken. Die wel nog moeite doen en het leuk vinden om thuis wat bij te hobbyen om hun vak beter te kunnen beoefenen
En daar nog extra cursussen bij kunnen en willen doen.

[ Voor 9% gewijzigd door koli-man op 11-03-2005 13:32 ]

[whoami]

koli-man schreef op vrijdag 11 maart 2005 @ 13:29:
[...]

hmmmz..en bedankt
Ik vind het jammer dat er weer iedereen over een kam geschoren wordt, want er zijn ook mensen die de goede opleidingen gevolgd hebben voordat ze bij een detacheerder gaan werken. Die wel nog moeite doen en het leuk vinden om thuis wat bij te hobbyen om hun vak beter te kunnen beoefenen
En daar nog extra cursussen bij kunnen en willen doen.

Ik denk niet dat EfBe het zo gemunt heeft op de mensen die voor een detacheerder werken, maar op het detacheer-bedrijf zelf. Ikzelf heb er ook zo geen goeie ervaringen mee (zie m'n reply hier iets boven).

[koli-man]

whoami schreef op vrijdag 11 maart 2005 @ 13:36:
[...]


Ik denk niet dat EfBe het zo gemunt heeft op de mensen die voor een detacheerder werken, maar op het detacheer-bedrijf zelf. Ikzelf heb er ook zo geen goeie ervaringen mee (zie m'n reply hier iets boven).

Ik geloof ook wel dat EfBe het zo bedoeld. En tuurlijk willen de fieldmanagers je overal wegzetten waar ze maar kunnen. Alleen ben jij uiteindelijk de verantwoordelijke en het is voor jezelf helemaal niet leuk als je iets moet gaan doen wat je eigenlijk niet kunt waarmaken dus neem je jezelf zeker in bescherming en ga je niet zomaar alles aannemen en zeggen dat je iets kunt.
En als een detacheringsbureau dit regelmatig flikt, dan zijn ze heel snel de pineut denk ik.

[EfBe]

koli-man schreef op vrijdag 11 maart 2005 @ 13:29:
[...]
hmmmz..en bedankt
Ik vind het jammer dat er weer iedereen over een kam geschoren wordt, want er zijn ook mensen die de goede opleidingen gevolgd hebben voordat ze bij een detacheerder gaan werken. Die wel nog moeite doen en het leuk vinden om thuis wat bij te hobbyen om hun vak beter te kunnen beoefenen
En daar nog extra cursussen bij kunnen en willen doen.

Trek het je niet persoonlijk aan, ik doel op de algemene wijze waarop deze bureaus werken, niet de gedetacheerde zelf (de it-er). Ik heb het over de verkopers die 'mensen wegzetten' alsof het pakken koffie zijn en die je zoveel mogelijk geld aftrochelen voor mensen die veelal minder kennis hebben dan wordt voorgeschoteld (Dat kan nog steeds veel kennis zijn, maar het is door de bank genomen steevast minder dan wordt voorgeschoteld).

In 1998 zat ik eens voor 75 gulden/uur bij een bedrijf via een tussenbureau, bleken er 2 tussen te zitten, de klant betaalde 150 gulden / uur voor mij! Nu weet ik toevallig een beetje hoe ze werken en het werk wat ze er aan doen is echt 0.0. Alleen in de illegale prostitutie kom je dat soort pooier-toestanden tegen.

Dit is overigens niet anders bij grote toko's als CMG, Cap en friends (trust me)

koli-man schreef op vrijdag 11 maart 2005 @ 13:42:
Ik geloof ook wel dat EfBe het zo bedoeld. En tuurlijk willen de fieldmanagers je overal wegzetten waar ze maar kunnen. Alleen ben jij uiteindelijk de verantwoordelijke en het is voor jezelf helemaal niet leuk als je iets moet gaan doen wat je eigenlijk niet kunt waarmaken dus neem je jezelf zeker in bescherming en ga je niet zomaar alles aannemen en zeggen dat je iets kunt.

Dat is op papier wel een aardige opmerking, maar zeker mensen in vaste dienst bij een detacheerder hebben die keuze nauwelijks en bij de slappe markt van de laatste jaren is het als freelancer niet echt makkelijk opdrachten te vinden (voor sommigen dan ) en de keuze voor een opdracht is dan makkelijker gemaakt. ("dat lukt wel...", ik zoek het wel op in de helpfiles!)

En als een detacheringsbureau dit regelmatig flikt, dan zijn ze heel snel de pineut denk ik.

Cap gemini en CMG bestaan nog steeds en de clubs met wat minder allure, zoals de Computer Futures en co. houden ook nog steeds hun hoofd boven water, dus ik denk dat je het mis hebt.

[ Voor 32% gewijzigd door EfBe op 11-03-2005 13:59 ]

[bigbeng]

FendtVario schreef op vrijdag 11 maart 2005 @ 12:20:
...
Over het algemeen heb ik altijd wel het idee dat er in vacatures (en waarschijnlijk dus ook bij detachering) gevraagd wordt naar mensen van 25 met 30 jaar ervaring. Soms zie je lijsten, deze bijv uit de vacaturebank van de automatiseringsgids:
[...]

Wow, 27 van de 34, das toch best een aardige match
Ik ben trouwens beschikbaar via mijn detacheringsbedrijf

[koli-man]

EfBe schreef op vrijdag 11 maart 2005 @ 13:56:
[...]

Dit is overigens niet anders bij grote toko's als CMG, Cap en friends (trust me)


[...]

Dat is op papier wel een aardige opmerking, maar zeker mensen in vaste dienst bij een detacheerder hebben die keuze nauwelijks en bij de slappe markt van de laatste jaren is het als freelancer niet echt makkelijk opdrachten te vinden (voor sommigen dan ) en de keuze voor een opdracht is dan makkelijker gemaakt. ("dat lukt wel...", ik zoek het wel op in de helpfiles!)


[...]

Cap gemini en CMG bestaan nog steeds en de clubs met wat minder allure, zoals de Computer Futures en co. houden ook nog steeds hun hoofd boven water, dus ik denk dat je het mis hebt.

Nou....wat betreft computer futures heb ik echt de neus vol. Ik heb er nooit voor gewerkt, maar toen ik een mailtje kreeg wist ik genoeg. Maar dat zie ik niet eens als detacheerder. Maar ik werk dus bij de sister van Cap(schoppen rood) en de opdrachten zijn dus nu minder schaars en je hoeft helemaal niet alles te pakken wat er te pakken is. En wat ik ook vaker merk, is dat bedrijven externe mensen inhuurt om af en toe eentje weg te plukken en in vaste dienst te nemen na een paar keer verlenging.

[ Voor 29% gewijzigd door koli-man op 11-03-2005 14:12 ]

[curry684]

EfBe schreef op vrijdag 11 maart 2005 @ 13:11:
[...]

Override maar eens Equals in je class, welke arraylist methods veranderen dan allemaal van functie? Zodra je wat complexere zaken moet gaan oplossen sta jij met je mond vol tanden en ben je uren aan het opzoeken en proberen.

No offence, maar dat is dus jouw klant oplichten.

Mjah zie ik persoonlijk het probleem niet zo in, als ik er al een keer de mist op in ga lees ik dat 's avonds in m'n eigen tijd wel bij. Wat in de praktijk zelden tot nooit gebeurt

En die moet de klant wel betalen. Dat is niet alleen etisch gezien niet juist, het is ook nog eens voor jou niet zo slim, want die klant gaat jou niet nog eens inhuren

Ik heb nergens gezegd dat ik het nette of correcte praktijken vind of dat ik het anderen aanraadt

De reden dat ik het ooit heb gedaan was een samenspel van heel veel vooral bedrijfskundige oorzaken. En tja, ik durf voor mezelf wel te stellen dat het bij mij niet fout loopt. Dat het bij 99% van het IT-tuig (om maar even binnen de terminologie te blijven bedoel ik daarmee dus de omgeschoolde rioolwerkers die "Teach yourself VB in 24 hours" vluchtig hebben doorgelezen) falikant misloopt en er veel te veel geld down the drain gaat is doodzonde ja.

Alarmnummer schreef op vrijdag 11 maart 2005 @ 13:21:
[...]

Het gaat niet om het vinden van een class, maar de ideeen achter iets begrijpen en weten wanneer je wel of niet iets moet toepassen, wat sterke punten en zwakke punten zijn, en wat de consequenties zijn. Dat is iets heel anders dan wat classes terug zien te vinden.

Mjah en jij wil als Java-goeroe nu claimen dat je met een week hands-on C# werk niet 90% van dat niveau op C# weet te bereiken? Vanzelfsprekend is die laatste 10% die je een echte goeroe in je gebied maakt het meeste werk, maar met 90% ben je al beter dan het absolute merendeel van je collega's in de meeste bedrijven.

Ben ik niet met je eens. Er zijn genoeg frameworks waarbij je op een fundamenteel andere manier te werk gaat dan alles wat je eerder hebt gedaan, bv Spring.

Niet echt boeiend. Dan spendeer je een ochtendje aan de 'andere insteek' ontdekken en zie je daarna dezelfde logica erin als die je in andere frameworks ook al zag.

Ik ben altijd weinig geneigd om hoog op te geven over technische kennis. Zoals ik al zeg maakt de laatste 10% altijd de absolute goeroe, maar zodra je jarenlang op topniveau meedraait is iedere nieuwe technologie binnen enkele dagen tot 'zeer acceptabel niveau' te krijgen. Als dat niet zo is draai je niet al jaren op topniveau mee.

Ik geef je geen schijn van kans bij bv J2EE. Dat is een grote set met complexe specificaties waar je gerust jaren zoet mee kunt zijn om overal even mee in aanraking te komen (laat staan specialist in te zijn)

Ik zal dan ook maar niet zeggen wat ik van Java en J2*E vind, dan moet ik mezelf dadelijk bannen

[curry684]

koli-man schreef op vrijdag 11 maart 2005 @ 14:05:
[...]

Nou....wat betreft computer futures heb ik echt de neus vol. Ik heb er nooit voor gewerkt, maar toen ik een mailtje kreeg wist ik genoeg. Maar dat zie ik niet eens als detacheerder. Maar ik werk dus bij de sister van Cap en de opdrachten zijn dus nu minder schaars en je hoeft helemaal niet alles te pakken wat er te pakken is. En wat ik ook vaker merk, is dat bedrijven externe mensen inhuurt om af en toe eentje weg te plukken en in vaste dienst te nemen na een paar keer verlenging.

Vooral Computer Futures en Huxley zijn in principe gewoon de dozenschuivers of misschien zelfs opperpooiers van de IT. Geen inhoudelijk verstand van zaken, puur en alleen zoveel mogelijk uurtje factuurtje doorverkopen en zoveel mogelijk afromen tussen klant en leverancier. In het jaar dat ik via Computer Futures heb gewerkt heb ik geloof ik in totaal anderhalf uur een account manager gezien (hij betaalde iig wel de lunch, viel dan weer mee) en wil ik echt niet weten wat voor fortuin ze hebben afgeroomd voor het doorsturen van de factuurtjes.

[Alarmnummer]

curry684 schreef op vrijdag 11 maart 2005 @ 14:12:
[...]

Mjah en jij wil als Java-goeroe nu claimen dat je met een week hands-on C# werk niet 90% van dat niveau op C# weet te bereiken?

Dat is precies wat ik dus niet claim Als ik een doorgewinterde .netter wil worden ben ik ook een jaar of wat verder.

Niet echt boeiend. Dan spendeer je een ochtendje aan de 'andere insteek' ontdekken en zie je daarna dezelfde logica erin als die je in andere frameworks ook al zag.

Hmm tja... ik doe dat niet in een ochtend. Ik lees veel, kijk naar veel verschillende platformen (ben nu aan het klooien met allerlei weblayer/mvc implementaties) en probeer daar relaties tussen te trekken. Wat hun sterke/zwakke punten zijn... dat is niet iets dat ik tussen neus en lippen door doe.

Ik ben altijd weinig geneigd om hoog op te geven over technische kennis. Zoals ik al zeg maakt de laatste 10% altijd de absolute goeroe, maar zodra je jarenlang op topniveau meedraait is iedere nieuwe technologie binnen enkele dagen tot 'zeer acceptabel niveau' te krijgen. Als dat niet zo is draai je niet al jaren op topniveau mee.

Tja.. is niet mijn ervaring. Ik ben zelf ook met allerlei soorten technieken bv:
concurrency problematiek
asynchrone/synchrone communicatie
inversion of control en alle gevolgen...

Ik kan je 1 ding zeggen.. dit zijn geen dingen die ik in een ochtendje begrijp. Sommige dingen ben ik al jaren mee bezig en nog steeds doe ik iedere keer nieuwe inzichten op (bij het volgende project doe ik dit en dat anders) Er is een verschil tussen weten wat in het platform zit en het echt goed weten toe te passen.

Ik zal dan ook maar niet zeggen wat ik van Java en J2*E vind, dan moet ik mezelf dadelijk bannen

Dat is niet interessant voor deze discussie.

De vraag is of je zomaar specialist in een platform kunt worden als je al specialist ben in een ander. Uiteraard zul je, als je specialist bent, kennis van het ene naar het platform mee kunnen nemen, en sommige concepten zullen op beide platform gelijk zijn en alleen in een ander jasje gestoken zijn. Maar dat wil niet zeggen dat je meteen een goeie gebruiker bent, laat staan een specialist.

Ik denk dat je een goeie specialist kunt herkennen aan het feit dat hij alternatieve oplossingen kan geven, en de alternatieven kan beoordelen op hun voor en nadelen.

[ Voor 12% gewijzigd door Alarmnummer op 11-03-2005 15:00 ]

[curry684]

Alarmnummer schreef op vrijdag 11 maart 2005 @ 14:39:
[...]

Ik kan je 1 ding zeggen.. dit zijn geen dingen die ik in een ochtendje begrijp. Sommige dingen ben ik al jaren mee bezig en nog steeds doe ik iedere keer nieuwe inzichten op (bij het volgende project doe ik dit en dat anders) Er is een verschil tussen weten wat in het platform zit en het echt goed weten toe te passen.

Maar dat is algemene developerervaring. Ik leer ook nog steeds iedere dag weer nieuwe dingen natuurlijk, en heb intussen ook een rijk arsenaal aan methodieken die op verschillende manieren hetzelfde resultaat bewerkstelligen. Maar dat relateer ik niet aan het platform, als ik morgen een nieuwe techniek of insteek leer kan ik die morgen op al mijn expertisegebieden toepassen.

Ik denk dat je een goeie specialist kunt herkennen aan het feit dat hij alternatieve oplossingen kan geven, en de alternatieven kan beoordelen op hun voor en nadelen.

Dat is sowieso een feit

[Verwijderd]

Efbe, je deed het net klinken alsof alleen maar een specialist zijn geld waard is, en alle mensen die nog wat / veel te leren hebben waardeloze rommel leveren. Misschien heb ik je verkeerd begrepen, maar ik ben het niet hiermee eens.

Ik ben nooit ergens een specialist in geweest en heb toch zat waardevol werk gedaan. Misschien dat ik het meer kennis sneller of beter (schaalbaarder, sneller, beter onderhoudbaar) had kunnen maken, maar dat betekent nog niet dat het rotzooi is.

In mijn ervaring is uberhaupt de kwaliteit van het hele ontwikkeltraject (van offerte tot onderhoud) vaak bagger, en dat door veel meer oorzaken dat de technische kennis van developers. Als het project een rommeltje is, zullen de uiteindelijke gevolgen bij het werk van de developers pas concreet worden, bijv. door rommelige code vanwege haastige wijzigingen zonder een duidelijke impactanalyse. Vaak worden de developers daar verantwoordelijk voor gehouden, terwijl slechte ontwerpen, onduidelijke afspraken, veel wijzigingen tussendoor en daarbij een naderende deadline meer de schuldigen zijn.

Samenvattend: de kwaliteit van het werk van een developer is zwaar afhankelijk van zijn werkomgeving, en software hoeft niet altijd optimaal te zijn, maar gewoon goed is ook voldoende.

[EfBe]

Verwijderd schreef op vrijdag 11 maart 2005 @ 15:47:
Efbe, je deed het net klinken alsof alleen maar een specialist zijn geld waard is, en alle mensen die nog wat / veel te leren hebben waardeloze rommel leveren. Misschien heb ik je verkeerd begrepen, maar ik ben het niet hiermee eens.

Zeg ik niet, je moet beter lezen (ik haat die opmerking, maar deze keer is hij wel terecht ). Ik probeerde duidelijk te maken dat degene die het werk gaat doen (de gedetacheerde) kwaliteit kan leveren voor N euro per uur en hij wordt verkocht voor N+M euro per uur. Dat houdt in dat de inhurende partij verwachtingen heeft dat de gedetacheerde voor N+M kwaliteit levert maar hij kan maar N kwaliteit leveren. Dat is niets ten nadele van de gedetacheerde, er is alleen een verschil ontstaan tussen wat men verwacht (de inhurende) en wat men logischerwijs verwachten MOET (de kwaliteit van de gedetacheerde). Die matchen zelden in detacheerdersland.

Ik ben nooit ergens een specialist in geweest en heb toch zat waardevol werk gedaan. Misschien dat ik het meer kennis sneller of beter (schaalbaarder, sneller, beter onderhoudbaar) had kunnen maken, maar dat betekent nog niet dat het rotzooi is.

Dat was ook niet de strekking van mijn opmerking. Die strekking is: Indien je als specialist wordt weggezet (ik gebruik maar even het detacherings-branch-jargon ) en je kunt dat niet leveren, dan lever je IMHO prutswerk, want je levert ONDER DE MAAT. Dat houdt NIET in dat je slecht bent, je levert onder het gestelde kwaliteitsniveau van de specialist waar je voor door moet gaan.

In mijn ervaring is uberhaupt de kwaliteit van het hele ontwikkeltraject (van offerte tot onderhoud) vaak bagger, en dat door veel meer oorzaken dat de technische kennis van developers. Als het project een rommeltje is, zullen de uiteindelijke gevolgen bij het werk van de developers pas concreet worden, bijv. door rommelige code vanwege haastige wijzigingen zonder een duidelijke impactanalyse. Vaak worden de developers daar verantwoordelijk voor gehouden, terwijl slechte ontwerpen, onduidelijke afspraken, veel wijzigingen tussendoor en daarbij een naderende deadline meer de schuldigen zijn.

Nou, dat is wat kort door de bocht. Ik heb dit in mijn laatste detacheringsopdracht (in aug-nov 2002 bij data**** in veenendaal (Hey Nielsz!)) meegemaakt en kan toch niet zeggen dat mijn werk daar nou onder leed. Dat komt wellicht omdat ik elke dag liet merken dat het project verkeerd werd geleid en dat men de gevolgen daarvan dus ook zou merken. Achteraf dan aankomen dat ik iets niet afkreeg is dan uitlegbaar omdat ik dat al had aangegeven. Ik ben daar ook weggegaan, ik heb de opdracht teruggegeven. Met stomheid geslagen waren ze. Mja, als je blijft zitten en je houdt je mond en geeft niet aan wat er fout is, dan kan een buitenstaander dat opvatten als "Hij ziet niet dat het fout is". Maar wellicht is dat persoonlijk, geen idee. Ik hou persoonlijk mijn kaken niet op elkaar als iets fout zit in een project.

Los daarvan, je kunt nog zulk slecht project management hebben, je kunt t.a.t. zien of iemand zn geld waard is of niet.

Samenvattend: de kwaliteit van het werk van een developer is zwaar afhankelijk van zijn werkomgeving, en software hoeft niet altijd optimaal te zijn, maar gewoon goed is ook voldoende.

Als er maar geleverd wordt waar degene voor is ingehuurd. Als ik jou inhuur om een sybase driver te bouwen voor mijn o/r mapper en jij zegt dat je dat zeker kunt en je legt daar de nodige CV elementen voor op tafel en jij bent daar 4 weken mee bezig dan is er echt wat fout, want dan heb je kennelijk iewat overdreven in het geheel. Wellicht ligt dat aan mij, dat kan heel goed, maar IMHO is het gewoon zaak dat wanneer iemand zegt kwaliteit A te leveren en hij doet dat niet, die persoon daar ZELF verantwoordelijk voor is. Hij staat nl. in voor die kwaliteit. Daar hoort dus ook bij dat als de persoon gedurende het werk constateert dat A niet gehaald kan worden door omstandigheden (die jij bv aankaartte) dan behoort de persoon in kwestie dat zelf aan te geven. Immers alleen iemand die WEET wat kwaliteit A is kan constateren of hij ook A levert of niet.