Is java de grootste vloek in de informatica?

[Michali]

Hydra schreef op maandag 15 december 2008 @ 14:34:
[...]


Het is een bekend probleem dat mensen het verschil tussen Agile en Cowboy Coding soms uit het oog verliezen. Ik ben een voorstander van Agile programmeren omdat je veel sneller en beter in kan spelen op customer feedback. Je hebt dus korte increments (ben een fan van scrum, hoewel ik het nog niet echt 100% heb mogen toepassen) waarbij gebruikers snel zien wat er komt van hun requirements, en snel kunnen reageren als het niet is wat ze verwachten. Beter dat je dat aan het begin hoort dan aan het eind van het project.

Maar dit betekent niet dat je vooraf, zo in detail mogelijk, vastlegt wat nu precies de bedoelingen zijn. En dat betekent dat je, voordat je uberhaupt gaat designen (laat staan coden) redelijk intensieve workshops (brown paper sessions zijn erg nuttig) uit gaat zetten om iedereen op een lijn te krijgen. Doe je dat niet, dan krijg je 5 verschillende 'facties' die elk compleet andere ideeen hebben. Je moet wel een ontwerpdocument hebben waarop je kunt wijzen als ze met iets compleet anders komen, al is het alleen maar omdat je dan uit kan leggen waarom die tijdsinschattingen nooit gehaald gaan worden.

Ik zie dus niet waarom Agile niet met een goed afgebakende set requirements verenigbaar zouden zijn.

Oh, maar daar ben ik het absoluut mee eens hoor. Misschien begreep ik je verkeerd, ik vatte het woorde "afdichten" een beetje op alsof je de opgestelde requirements echt bevriest en niet meer aanpasbaar maakt. Ook denk ik dat je het nooit helemaal rond kunt krijgen, maar uit je tekst hierboven begrijp ik ook dat jij er ook wel zo over denkt.


Maar goed, we dwalen af in een topic dat wegens afdwaling is afgesplitst We zijn weer lekker bezig hier.

[ Voor 3% gewijzigd door Michali op 15-12-2008 14:41 ]

[Michali]

Hydra schreef op maandag 15 december 2008 @ 14:37:
[...]


Wil je dan je hele leven als programmeur werken? Lijkt me toch niet meer dan logisch dat je naar een meer adviserende / managende rol groeit?

Hmm, ik denk dat ik dat wel zie zitten ja. Ik hou echt van het vak programmeren, ik vind het super leuk. Dat is waarom ik informatica ben gaan doen en waarom ik ook zoveel zelfstudie doe.

[Hydra]

Michali schreef op maandag 15 december 2008 @ 14:39:
Oh, maar daar ben ik het absoluut mee eens hoor. Misschien begreep ik je verkeerd, ik vatte het woorde "afdichten" een beetje op alsof je de opgestelde requirements echt bevriest en niet meer aanpasbaar maakt. Ook denk ik dat je het nooit helemaal rond kunt krijgen, maar uit je tekst hierboven begrijp ik ook dat jij er ook wel zo over denkt.

Maar goed, we dwalen af in een topic dat wegens afdwaling is afgesplitst We zijn weer lekker bezig hier.

Ja ach, volgens mij waren we het er al vrij unaniem over eens dat de TS uit z'n nek lult

Michali schreef op maandag 15 december 2008 @ 14:42:
Hmm, ik denk dat ik dat wel zie zitten ja. Ik hou echt van het vak programmeren, ik vind het super leuk. Dat is waarom ik informatica ben gaan doen en waarom ik ook zoveel zelfstudie doe.

Ieder z'n ding

[ Voor 19% gewijzigd door Hydra op 15-12-2008 14:43 ]

[Castor385]

Hydra schreef op maandag 15 december 2008 @ 14:34:

[...]
Projecten falen niet omdat een programmeur z'n werk niet doet. Een goeie manager houdt sowieso een vinger aan de pols en signaleert op tijd dat er problemen zijn.

Dat klopt. Wat je vaak ziet, is dat de project manager niet de juiste informatie van de programmeur ontvangt, waardoor de verwachtingen aan van beiden uiteenlopen. Dan komt de signalering van het probleem vaak net te laat, waardoor er weer vertraging wordt opgelopen. Overigens zijn er véél meer factoren waaraan het falen van een project ligt. Scherpe offertes aanbieden voor een te lage prijs. Niet alles goed afgebakend. etc.

Hydra schreef op maandag 15 december 2008 @ 14:34:
[...]
In princiepe heeft de klant eigenlijk altijd meer kennis van zijn vakgebied dan jij. Dus ik zie je punt niet zo? Als ej als developer niet begrijpt wat je aan het developen bent, gaat er lijkt me sowieso iets heel erg fout.

Mijn punt is, dat er meer belangrijke skills zijn voor een programmeur, dan alleen je code intiepen. Als je als programmeur een fantastisch sorteer algoritme kan schrijven, good for you. Maar als je tegelijk totaal onhandelbaar bent, dan wordt je programmeer talent nooit volledig benut.

(even heel zwart-wit gezegd)

[g4wx3]

phobosdeimos schreef op zondag 14 december 2008 @ 21:31:
Iemand die nu in België afstudeerd als bachelor informatica, weet niet wat een pointer is.
Weet niet wat een double linked list is.
Weet niet wat een preprocessor of een compiler nu eigenlijk doet.
Weet niet hoe quicksort eigenlijk werkt, laat staan om het zelf te implementeren.

How?
Zelfs ik, die geen informatica heeft gedaan (misschien nog gaat doen) kan alle vragen beantwoorden.
*allemaal via wikipedia, herhinner me zelfs dat er een ander artikel gewijd was en het gebruik van plaatjes oid, en daar zat het plaatje bij van het wiki artikel over quicksort

Dus ik denk dat je het belgisch ondwerijs wel onderschat...
Maar het is wel een punt dat veel studente veel betere begeleiding zouden moeten krijgen bij hun studiekeuze. (dan had ik nu wel een bachelor informatica..) Veel studente zitten gewoon in de foute richting, infodagen zijn er gewoon om leerlingen te rondselen, en ze overtuigen je allemaal om bij hun te komen. Ook is het belgisch systeem ASO TSO BSO gewoon slecht. Het niveau van TSO gaat omlaag, omdat er mensen komen die geen ASO aankunnen, maar TSO is niet in principe lager, maar toespits op andere onderdelen. Anders moeten ze mij maar eens uitleggen hoe ik electronica kan leren op "ASO niveau". Nu moet je eerst 6 jaar verspillen op ASO, en daarna kun je naar de universiteit om electronica te studeren. (chip ontwerpen worden niet zomaar uit een mouw geschudt...)

[.oisyn]

g4wx3 schreef op maandag 15 december 2008 @ 14:52:
[...]


How?
Zelfs ik, die geen informatica heeft gedaan (misschien nog gaat doen) kan alle vragen beantwoorden.
*allemaal via wikipedia, herhinner me zelfs dat er een ander artikel gewijd was en het gebruik van plaatjes oid, en daar zat het plaatje bij van het wiki artikel over quicksort

Dus ik denk dat je het belgisch ondwerijs wel onderschat...

Rare beredenering hou je erop na. Omdat jij het wel weet terwijl je geen opleiding hebt gedaan concludeer je dat phobosdeimos de opleidingen onderschat? Hoe kun je dat nou bepalen door zelf niet zo'n opleiding te hebben gedaan noch daar onderzoek naar hebt gedaan? Wat je wellicht wel zou kunnen concluderen is dat de gemiddelde student niet genoeg zelf-onderzoek doet.

[ Voor 6% gewijzigd door .oisyn op 15-12-2008 15:06 ]

[Confusion]

Hydra schreef op maandag 15 december 2008 @ 14:34:
Maar dit betekent niet dat je vooraf, zo in detail mogelijk, vastlegt wat nu precies de bedoelingen zijn.

Ik neem aan dat je hier een 'niet' vergeten bent: "Maar dit betekent niet dat je niet vooraf, zo in detail mogelijk, vastlegt wat nu precies de bedoelingen zijn."?

Ik zie dus niet waarom Agile niet met een goed afgebakende set requirements verenigbaar zouden zijn.

Omdat je ontzettend moet oppassen dat je niet alsnog in een waterval verzeild raakt. Als je te goed je best doet om vantevoren een goed afgebakende en gedefinieerde set requirements te verzamelen, dan trap je precies weer in alle vallen die je juist probeerde te vermijden.

[rickjehh]

Hydra schreef op maandag 15 december 2008 @ 14:37:
[...]


Wil je dan je hele leven als programmeur werken? Lijkt me toch niet meer dan logisch dat je naar een meer adviserende / managende rol groeit?

Dat zie ik ook zeker niet zitten, om m'n hele leven als programmeur te gaan werken. Maar je moet, zoals je hierboven al zei een aantal reacties eerder, ergens beginnen. Ik vind programmeren nu erg leuk om te doen en zal ook op dat niveau gaan instappen wanneer ik volgend jaar zal afstuderen. Daarnaast wil ik me gaan specialiseren in .NET en wil ik daarin graag doorgroeien en een aantal certificaten behalen, waarbij ik me op den duur natuurlijk op wil werken en uiteindelijk verder weg kom te zitten van het echte programmeerwerk.

[momania]

Hydra schreef op maandag 15 december 2008 @ 14:37:
[...]


Wil je dan je hele leven als programmeur werken? Lijkt me toch niet meer dan logisch dat je naar een meer adviserende / managende rol groeit?

Niet persee logisch. Niet iedereen ziet een management rol zitten. Ik zou zelf 't liefst zo lang mogelijk lekker blijven programmeren.

Daarnaast, aansluitend op het punt van Michali, is het imo zonde als je goede programmeurs als enige keus geeft om te stoppen met programmeren als ze meer willen verdienen.

[Woy]

Castor385 schreef op maandag 15 december 2008 @ 14:49:
Mijn punt is, dat er meer belangrijke skills zijn voor een programmeur, dan alleen je code intiepen. Als je als programmeur een fantastisch sorteer algoritme kan schrijven, good for you. Maar als je tegelijk totaal onhandelbaar bent, dan wordt je programmeer talent nooit volledig benut.

(even heel zwart-wit gezegd)

Dat is zeker waar, wij hadden hier op het werk een chinese jongen, en dat was best een goede programmeur. Hij had ook op een goede chinese school gestudeerd. Maar er viel totaal niet met hem te communiceren, waardoor het product wat hij opleverde nooit overeen kwam met de verwachtingen. Ik ben blij dat hij hier niet meer werkt, want het was echt een hel om mee samen te werken.

Verder ben ik het met de meeste hier eens dat het gebruik van een Taal ( Java in dit geval ) niet de oorzaak kan zijn van het slechte onderwijs. In Java kan je perfect alle belangrijke zaken bijbrengen ( Al is het voor sommige low-level zaken wat lastiger ).

Bij mij op de opleiding ( Hogere Informatica, richting TI ) werd ook het meeste in Java gegeven, maar daar zijn echt wel dingen als Data-Structuren/Sorteer algo's/etc.. behandeld. Voor de wat meer low-level dingen zoals Operating Systems werd er dan wel terug gegrepen op c++, maar in princiepe zou je dat soort dingen ook in Java kunnen onderwijzen.

Ik ben het wel met je eens dat het nivo van de opleidingen niet altijd even goed is ( Ik kan ook genoeg kritiek bedenken op mijn eigen opleiding ), maar om dat nou op de taal Java af te schuiven vind ik wat kortzichtig.

[Janoz]

Hydra schreef op maandag 15 december 2008 @ 14:13:
[...]


Euh, ik had het over m'n eigen ervaringen.

* Janoz is op dit moment via Logica geplaatst bij een grote overheidsinstelling .

Volgens mij is het je taak als SE te zorgen, nay...af te dwingen dat de requirements helder zijn. Ik weet niet meer waar de quote vandaan komt (zou Dijkstra kunnen zijn) maar ik leef nog altijd bij het "Als je niet weet wat je gaat programmeren, moet je er niet aan beginnen". Een belangrijk onderdeel van het hele ontwikkelproces is gewoon de requirements afdichten. Later roepen dat de requirements niet duidelijk waren heb ik vaker gezien, en dat was vooral om hun eigen management falen te verhullen. Dat iets niet op papier staat vind ik een compleet loos argument, wat weerhoudt je ervan mensen te interviewen?

Hierbij neem je aan dat er maar twee typen requirements zijn. Duidelijke en onduidelijke. Zo zwart wit is het niet. Het grote gevaar zit hem meer in erg duidelijke, maar onjuiste requirements. Zeker wanneer je met een groot project bezig bent dat meerdere afdelingen raakt waarbij je te maken hebt met meerdere groepen gebruikers is de kans daarop veel groter. Requirements sluiten elkaar vaak uit en degenen die zeggen dat ze het mandaat hebben zijn vaak niet degenen die ook daadwerkelijk een knoop door willen hakken. Daarnaast ben je als requirement specifier vaak beperkt tot een 'interface' met een organisatie omdat je nu eenmaal geen 1000 mensen kunt interviewen. Daar kunnen dan net de verkeerde mensen tussen zitten (mensen met stokpaardjes, of die ene manager die wel even denkt dat hij voor de vloer keuzes kan maken). Ik ben zelf wel eens de hort op geweest om uberhaupt te achterhalen waar een implementatie keuze vandaan kwam (Het werd wel requirement genoemd, maar 'audittrail opslaan moet in aparte tabel' is toch echt een oplossing en geen requirement. Ik heb een heleboel mensen gesproken, maar eigenlijk heb ik nog steeds niet kunnen achterhalen wat nu eigenlijk de achterliggende reden is. Constant is het "Ja dat moet", en na doorvragen "Dat komt uiteindelijk bij pietje weg". Pietje zegt dat het bij Jantje weg komt en Jantje zegt dat het bij Klaasje weg komt en Klaasje zegt dat het bij Pietje weg komt. Maar Geen van allen durft, ook na ze het uitgelegd te hebben, te zeggen dat de 'requirement' van tafel kan.

Als klap op de vuurpijl krijg je bij projecten ook nog eens te maken met veranderende requirements vanwege wetswijzigingen, andere van bovenaf opgelegde keuzes, terugdraaien van budgetten waardoor stekkers uit cruciale afhankelijkheden getrokken worden of omdat een prototype gewoon niet blijkt te doen wat de architect ervan verwachte.

Ja, en da's dus gewoon mismanagement. En dan van het malafide soort. Want die managers weten best dat als hun developers een quote van X dagen geven, dat X werkdagen zijn. En dat je dan niet moet roepen dat je klaar bent over X/7 - 1 weken om maar met een financieel aantrekkelijker aanbod te komen dan de concurrent. Probleem is alleen dat dat door de aanbestedingscultuur in stand wordt gehouden.

Onzin. Zo werkt dat misschien in sweatshop mini toko's waar ze net afgestudeerde HIO-ers voor E1800 per maand weken van 50 uur laten draaien omdat ze toch zo communicatie gestoord zijn dat ze er niks tegenin willen brengen. Zeker een fatsoenlijke club krabt zich wel drie keer achter de oren voor ze op die manier een bid gaan doen. Bedenk dat het vaak fixed price aanbestedingen zijn. De pijn gaat dan niet naar de opdrachtgever, maar de opdrachtnemer. Daarnaast roepen developers vaak X dagen, maar dan blijkt dat X*3 te zijn. Dat is inherent aan het feit dat software trajecten gewoon niet goed te voorspellen zijn vanwege het onzekere karakter.

[Hydra]

Confusion schreef op maandag 15 december 2008 @ 15:03:
Ik neem aan dat je hier een 'niet' vergeten bent: "Maar dit betekent niet dat je niet vooraf, zo in detail mogelijk, vastlegt wat nu precies de bedoelingen zijn."?

Klopt

Omdat je ontzettend moet oppassen dat je niet alsnog in een waterval verzeild raakt. Als je te goed je best doet om vantevoren een goed afgebakende en gedefinieerde set requirements te verzamelen, dan trap je precies weer in alle vallen die je juist probeerde te vermijden.

Tuurlijk. Het is lastig, en een kwestie van een balans zoeken tussen goed duidelijk hebben bij de eindgebruikers wat er nu precies ontwikkeld gaat worden, en ze zoveel vrijheid geven dat het een eindeloos project wordt. Wat vooral IMHO belangrijk is, is wel ruimte overlaten voor niet te grote wijzigingen, maar zorgen dat vooraf de hele groep gebruikers het onderling eens is over wat er gaat komen. Anders krijg je dus groepjes binnen de gebruikersgroep die het onderling niet eens zijn en teleurgesteld concluderen dat naar hun niet geluisterd is.

momania schreef op maandag 15 december 2008 @ 15:15:
Niet persee logisch. Niet iedereen ziet een management rol zitten. Ik zou zelf 't liefst zo lang mogelijk lekker blijven programmeren.

Niet developer zijn betekent niet automagisch management natuurlijk. Je kunt ook een meer adviserende rol hebben. Zelf vind ik het leuk de FO en TO's te maken, en de implementatie aan een ander over te laten. Altijd fijn dat iemand jouw inschattingen waar mag gaan maken

[Verwijderd]

Ads door Google
Programmeurs 22,50 p/u
Probeer het, 40 uur no cure no pay Java,Php,.Net, Vba, Flex,etc.
www.iq-offshore.com

dat dus

[Zoijar]

Confusion schreef op maandag 15 december 2008 @ 14:22:
Klinkt als de "vroeger was alles beter" variant: "als je nooit zelf memory management hebt hoeven doen, dan laat je alles maar rondslingeren". Te weinig nadenken levert slechte code op.

Een beetje misschien. Maar ik zie toch ook weinig begrip van goede resource management. En dat komt gewoon omdat mensen denken nooit iets op te hoeven ruimen. Dat gaat toch automatisch? Ja, tot er ergens een reference blijft hangen en je kleine chat programma 200 MB geheugen nodig heeft. Vroeger werd je er gewoon mee geconfronteerd dat je een programma moest schrijven dat niet lekt, en om daar voor te zorgen moest je alles netjes aanmaken en verwijderen en nadenken over lifetimes. Precies wat jij zegt eigenlijk Ik snap dat er mensen zijn die wel nadenken, maar dat is zeg maar niet de default.

Trouwens, waarom denken zo veel dat een goede programmeur sorteer algoritmes moet kennen? Waarom? Waarom zou ik in godsnaam sorteer algotimes moeten kennen? Het is een leuke applicaties op de universiteit waarbij je met veel dingen geconfronteerd wordt: memory management, pointers, data structuren, complexiteit. Dat is wat je moet begrijpen. Algoritme op zich zegt natuurlijk niets. Als je dat nodig hebt zoek je het op bij je requirements.

[remmelt]

Een opleiding/diploma zegt helemaal niets. Bij mij (HBO, ik ben Bachelor ICT) zat alles door elkaar. Er waren lapzwansen die geen woord konden programmeren en maar een beetje meeliepen met de rest en zich erdoor sloegen op het schrijven van requirements, wat de meeste programmeurtypes minder leuk vonden. Aan de andere kant zat ik bij iemand die altijd bezig was weer wat clockcycles van z'n zelfgeschreven 3D engine af te schaven, in ASM.

Ik heb zelf nooit echt les gehad in java, wel in C++ (en scheme, ASM, en nog wat kleintjes). Ik weet dus inderdaad wel van pointers en bubblesort etc etc. Design patterns kan ik ook mee omgaan (een interface beschrijft iets wat iets KAN, niet wat iets IS, enzovoorts).
Ja, het voegt iets toe aan wat ik kan als programmeur en nee, ik heb het niet elke dag nodig. Maar goed, geschiedenisles op de middelbare school heb je als programmeur ook niet nodig, toch is het goed dat je het hebt gehad. Verdieping en verbreding van kennis is altijd een goed iets, zeker als je een opleiding volgt.

Het punt met opleidingen tegenwoordig is dat er alleen een echte schifting is na het eerste jaar. Scholen (en universiteiten?) kunnen slecht presterende studenten na het eerste jaar wegsturen, maar daarna niet meer. Het kan wel, maar dan krijgen ze geen subsidie voor die student. Na het eerste jaar is het de school er dus alles aan gelegen om je te laten afstuderen. Bij ons lag dat er behoorlijk dik bovenop, wat de motivatie bij sommige studenten niet altijd ten goede kwam. Dit systeem is natuurlijk kapot, omdat het best voor kan komen dat iemand het eerste jaar wel haalt maar toch faalt na het tweede of derde jaar. Om die mensen met veel steun en moeite toch nog te laten afstuderen en dan nog wel met hetzelfde diploma als de normale studenten is gekkenwerk.

De enige troost is dat de incompetente lui bij een bedrijf direct tegen de lamp lopen, waarschijnlijk bij het eerste sollicitatiegesprek al.

En of je die design principles nou in java doet of in php of in visual basic, dat maakt mij niet uit. Een programmeur kan programmeren in elke taal. Je krijgt dus ook geen taal maar een programmeurstudie. Als dat toevallig in java is, kan je alsnog een steengoede programmeur worden.
Bovendien is er ook nog zoiets als de studie aanpassen aan de vraag uit het bedrijfsleven, vooral bij een HBO-studie. Bedrijven vragen om java: er komen meer HBO's die java-studenten bieden.
Bovendien, wat is een goede programmeur? Iemand die zelf z'n computer in elkaar soldeert, z'n eigen programmeertaal verzint en daar de compiler in en voor schrijft? Iemand die alles maar dan ook alles van java weet, met tien jaar ervaring en certificaten etc? IT is zo breed dat deze mensen allebei goede programmeurs kunnen zijn, en ook allebei precies de verkeerde man op de verkeerde plaats.

Ik ben de laatste die geluk in geld uit gaat drukken, maar ik heb het een beetje gehad met de mensen die zich beter voelen omdat ze weten hoe quicksort werkt. Leuk hoor, maar vind maar eens een baan, dan praten we verder over je double linked lists. Tuurlijk is daar werk in te vinden, maar lang niet zo veel en dus ook lang niet zo makkelijk als met java/C#/PHP. Succes.

Overigens vind ik "50% van de IT-projecten falen wegens java" nogal erg kort door de bocht, sterker nog, ik kan zo al een aantal dingen noemen waarvan ik uit ervaring weet dat ze veel meer invloed hebben op het al dan niet falen van een project dan de taal waarin de boel is geimplementeerd. Noem me één project wat is gefaald enkel en alleen doordat er java is ingezet en niet een andere programmeertaal. Projecten falen wegens incompetentie bij management, het schrijven van de requirements, time management skills van de programmeur, kennis van de programmeur, feature creep, scope creep, het niet luisteren naar de klant. Vrijwel alles is op te lossen door betere communicatie, verwachtingsmanagement en een beetje zelfkennis.

Dus nee, java is niet de grootste vloek van de informatica. Joel Spolsky haalt oorzaak en gevolg door elkaar, of hij baalt ervan dat de studenten die worden aangeboden door de scholen/universiteiten niet aansluiten bij zijn eisenpakket.

[ Voor 9% gewijzigd door remmelt op 15-12-2008 16:21 ]

[Janoz]

Zoijar schreef op maandag 15 december 2008 @ 16:04:
Trouwens, waarom denken zo veel dat een goede programmeur sorteer algoritmes moet kennen? Waarom? Waarom zou ik in godsnaam sorteer algotimes moeten kennen? Het is een leuke applicaties op de universiteit waarbij je met veel dingen geconfronteerd wordt: memory management, pointers, data structuren, complexiteit. Dat is wat je moet begrijpen. Algoritme op zich zegt natuurlijk niets. Als je dat nodig hebt zoek je het op bij je requirements.

Precies, helemaal mee eens. Ik heb eigenlijk sinds mijn studie nooit meer uit mijn hoofd bubblesort moeten implementeren. Ik heb echter wel meerdere keren een afweging gemaakt waarbij ik uiteindelijk voor een LinkedList ipv een ArrayList implementatie gekozen heb omdat een bepaalde bewerking gewoon de lijst doorliep en daar veel elementen tussenuit haalde of tussenin stopte. Een college algoritme en datastructuren hoort je dat begrip bij te brengen. Rijtjes in je kop stampen deden ze op de Mavo wel.

[rickjehh]

Janoz schreef op maandag 15 december 2008 @ 16:14:
[...]

Precies, helemaal mee eens. Ik heb eigenlijk sinds mijn studie nooit meer uit mijn hoofd bubblesort moeten implementeren. Ik heb echter wel meerdere keren een afweging gemaakt waarbij ik uiteindelijk voor een LinkedList ipv een ArrayList implementatie gekozen heb omdat een bepaalde bewerking gewoon de lijst doorliep en daar veel elementen tussenuit haalde of tussenin stopte. Een college algoritme en datastructuren hoort je dat begrip bij te brengen. Rijtjes in je kop stampen deden ze op de Mavo wel.

Eens. Ik heb tijdens mijn eerste semester vorig jaar ook een sorteeralgoritme gebruikt (bubblesort en quicksort), maar om nou te zeggen dat ik ze nog vaak ga gebruiken en dat het me een betere programmeur maakt dan andere programmeurs die evenveel weten als ik, maar geen kennis hebben van een sorteeralgoritme? nee. Het hele begrip "goede programmeur" is in mijn ogen relatief. Iedereen heeft wel een mening over wat een goede programmeur is, maar staat het vast? Nee, zoals hierboven al vermeld is, iemand die geen kennis van een bepaalde programmeertaal heeft, kan wel een steengoede programmeur zijn. Alles is te leren en het maakt niet uit in welke taal je leert, als je de basisprincipes maar kan toepassen.

[ Voor 10% gewijzigd door rickjehh op 15-12-2008 16:31 ]

[Config]

phobosdeimos schreef op zondag 14 december 2008 @ 21:31:
Een beetje nuanceren: ik zeg niet dat Java de taal des duivels is, die altijd moet vermeden worden.
Voor mij mag Java in elke hogeschool en universiteit gegeven worden.
Het probleem is dat plots heel het onderwijssysteem nog maar 1 programmeertaal kent, en dat is Java.
Iemand die nu in België afstudeerd als bachelor informatica, weet niet wat een pointer is.
Weet niet wat een double linked list is.
Weet niet wat een preprocessor of een compiler nu eigenlijk doet.
Weet niet hoe quicksort eigenlijk werkt, laat staan om het zelf te implementeren.

Dat is hetgene waar ik me persoonlijk vragen bij stel.
Alles moet simpeler, eenvoudiger en laagdrempeliger, om toch maar voldoende studenten laten af te studeren.

Een student I&E (Informatica & Economie @ Eramus Rotterdam, let op 50-50 economie en informatica vakken in een normale BC van 180 ECTS), heeft wel degelijk kennis van de laatste 3 zaken uit je lijstje.

Heb je er trouwens ooit bij stilgestaan dat het vakgebied informatica ontzettend veel richtingen kent, waarvan programmeren er maar een paar vormt? Bij het samenstellen van een curriculum proberen de instellingen je zo breed mogelijk te scholen, niet zo diep mogelijk op wat jij blijkbaar belangrijk vindt. Bijscholen is zo ongeveer de enige constante voor IT personeel, dus wat je niet leert op de uni leer je wel op je werk.

[rickjehh]

Config schreef op maandag 15 december 2008 @ 16:33:
[...]


Een student I&E (Informatica & Economie @ Eramus Rotterdam, let op 50-50 economie en informatica vakken in een normale BC van 180 ECTS), heeft wel degelijk kennis van de laatste 3 zaken uit je lijstje.

Heb je er trouwens ooit bij stilgestaan dat het vakgebied informatica ontzettend veel richtingen kent, waarvan programmeren er maar een paar vormt? Bij het samenstellen van een curriculum proberen de instellingen je zo breed mogelijk te scholen, niet zo diep mogelijk op wat jij blijkbaar belangrijk vindt. Bijscholen is zo ongeveer de enige constante voor IT personeel, dus wat je niet leert op de uni leer je wel op je werk.

Hier ben ik het mee eens. Het zo-breed-mogelijk scholen van studenten is iets waar veel HBO-Instellingen heel erg op aansturen. Natuurlijk kun je je in bepaalde aspecten verdiepen maar over het algemeen is het heel breed georiënteerd wat je voorgeschoteld krijgt. Het echte verdiepen komt pas op het moment dat je echt gaat werken.

[pedorus]

Config schreef op maandag 15 december 2008 @ 16:33:
[...]

Een student I&E (Informatica & Economie @ Eramus Rotterdam, let op 50-50 economie en informatica vakken in een normale BC van 180 ECTS), heeft wel degelijk kennis van de laatste 3 zaken uit je lijstje.

Er wordt uitgelegd wat een preprocessor doet? Een preprocessor is zo hopeloos achterhaalt, dat ze dat beter zouden kunnen overslaan, en je iets nuttigs zouden kunnen leren Van dat lijstje vind ik eigenlijk alleen de linked list enigszins algemeen nuttig.

Voor de rest is Java natuurlijk niet het probleem. Het probleem zit hem hooguit in de financiering (op diploma's) en het principe dat iedereen het moet kunnen halen. Ik denk dat Joel verwacht dat universiteiten programmeurs voor hem aan het opleiden zijn, en dat is natuurlijk niet zo. Er worden concepten bijgeleerd, en daar kun je prima Java voor gebruiken, en ook in Java kun je nog genoeg problemen tegenkomen (bijv. NullPointerExceptions). Als elke school Java gebruikt, dan is dat alleen maar handiger bij uitwisselingen.

.oisyn schreef op maandag 15 december 2008 @ 12:49:
Dat blijkt niet uit z'n opmaak. Dus wellicht dat t.net iets doet dat niet door IE / alleen door FF wordt ondersteund, of FF doet er zelf iets mee.

Dat iemand als jij werkt met een op dit moment exploitbare browser en the project cartoon niet kent.

[.oisyn]

Afgezien van het feit dat je zin niet klopt, heb ik nooit beweerd dat ik die strip niet kende. En veel plezier met het exploiten van de door mij gebruikte browser

[Hydra]

Janoz schreef op maandag 15 december 2008 @ 16:14:
Precies, helemaal mee eens. Ik heb eigenlijk sinds mijn studie nooit meer uit mijn hoofd bubblesort moeten implementeren. Ik heb echter wel meerdere keren een afweging gemaakt waarbij ik uiteindelijk voor een LinkedList ipv een ArrayList implementatie gekozen heb omdat een bepaalde bewerking gewoon de lijst doorliep en daar veel elementen tussenuit haalde of tussenin stopte. Een college algoritme en datastructuren hoort je dat begrip bij te brengen. Rijtjes in je kop stampen deden ze op de Mavo wel.

Als je denkt dat je het implementeren van dat soort sorteeralgorithmen leert om die dingen later nog een keer te doen heb je het niet helemaal begrepen Dat soort vingeroefeningen zorgen ervoor dat je beter begrijpt wat er nu precies gebeurt als je Array.sort() (oid) aanroept. Dus dat je weet dat het niet iets is wat 1 clockcycle kost. Bovendien leert het je 'denken' zoals een computer 'denkt' en dus de vertaalslag van functioneel naar technisch te maken. Een hoop dingen die je tijdens je opleiding leert ga je niet weer gebruiken, ik ga ook echt geen LZW implementatie meer maken, maar ik weet wel hoe het werkt.

rickjehh schreef op maandag 15 december 2008 @ 16:38:
Hier ben ik het mee eenas. Het zo-breed-mogelijk scholen van studenten is iets waar veel HBO-Instellingen heel erg op aansturen. Natuurlijk kun je je in bepaalde aspecten verdiepen maar over het algemeen is het heel breed georiënteerd wat je voorgeschoteld krijgt. Het echte verdiepen komt pas op het moment dat je echt gaat werken.

Ja, en dan kom je in de problemen. Informatica is gewoon toegepaste wiskunde, en je moet ook op zo'n manier problemen kunnen oppakken, en da's vaak een probleem. Ik heb dit jaar nog een groep studenten begeleidt en maar een daar van was iemand die zelf oplossingen kon bedenken en de discussie met je aan kon gaan. De rest zat een beetje passief af te wachten tot je ze vertelde was ze moesten gaan doen.

.oisyn schreef op maandag 15 december 2008 @ 17:05:
Afgezien van het feit dat je zin niet klopt, heb ik nooit beweerd dat ik die strip niet kende. En veel plezier met het exploiten van de door mij gebruikte browser

Ik snap zijn redenatie ook niet. Je hebt idd gelijk dat firefox dat voor me regelt.

[Config]

Hydra schreef op maandag 15 december 2008 @ 17:40:
Informatica is gewoon toegepaste wiskunde

Met name "toegepast"...

[YopY]

Wat ben ik blij dat niet alle werkgevers en/of scholen dezelfde hoge standaarden heeft als de auteur van het artikel in de fipo, dan kon maar 5% van de mensen die een opleiding begon die opleiding ook afmaken en werk vinden. Er zullen dan veel mensen zijn die niks over pointers leren tijdens hun opleiding, maar dat is dan een falen van die opleiding én van die personen zelf, aangezien ze blijkbaar ook met oogkleppen op door hun opleiding heenlopen, danwel totaal niet aan zelfstudie doe.

Java, en overigens alle talen waar de programmeurs niet aan memory of pointer-management hoeven te doen, of waar ze zelf niet (nogmaals) een sorteeralgoritme in uit hoeven te voeren, zorgen voor een veel hogere productiviteit, maken het mogelijk dat er veel meer mensen aan een project kunnen werken, zorgen ervoor dat grotere projecten ook kunnen slagen omdat er veel minder mis kan gaan (een bug is veel sneller gemaakt in een taal waarbij je direct geheugenadressen kunt aanpassen), en zorgen ervoor dat mensen een baan kunnen krijgen bij werkgevers die wel genoegen geven met iemand die misschien wel geen snelle bubblesort kan schrijven (ook al zouden de meesten die een informatica-opleiding afmaken dat wel kunnen doen), maar die wél de gewenste functionaliteit kan programmeren.

Zoals gezegd, als elke werkgever hetzelfde niveau van zijn (toekomstige) werknemers zou eisen als de auteur van het artikel in de fipo, zou er een enorm tekort aan programmeurs zijn, en zou de IT wereld een stuk kleiner en exclusiever zijn.

[momania]

YopY schreef op maandag 15 december 2008 @ 18:26:
Java, en overigens alle talen waar de programmeurs niet aan memory of pointer-management hoeven te doen, of waar ze zelf niet (nogmaals) een sorteeralgoritme in uit hoeven te voeren, zorgen voor een veel hogere productiviteit, maken het mogelijk dat er veel meer mensen aan een project kunnen werken, zorgen ervoor dat grotere projecten ook kunnen slagen omdat er veel minder mis kan gaan (een bug is veel sneller gemaakt in een taal waarbij je direct geheugenadressen kunt aanpassen)

Toch is de basis belangrijk om te weten, ook als je het niet hoeft te gebruiken. Je moet weten wat voor effect je code heeft (ook al is geheugen etc automatisch gemanaged). Verschillende implementaties kunnen veel verschillende impacts hebben.

Programmeurs die die basis kennis niet hebben kunnen misschien wel een stukje software schrijven, maar hebben imo niet genoeg in de gaten waar ze mee bezig zijn en zijn eigenlijk 'monkeys' (Ze kennen een truckje, implementeren wat code en weten niet waarom of wat de impact daarvan is)

Kan uiteindelijk voor alleen maar meer bugs en tragere systemen zorgen

Zo kan je het ook zien

[rickjehh]

Hydra schreef op maandag 15 december 2008 @ 17:40:

Ja, en dan kom je in de problemen. Informatica is gewoon toegepaste wiskunde, en je moet ook op zo'n manier problemen kunnen oppakken, en da's vaak een probleem. Ik heb dit jaar nog een groep studenten begeleidt en maar een daar van was iemand die zelf oplossingen kon bedenken en de discussie met je aan kon gaan. De rest zat een beetje passief af te wachten tot je ze vertelde was ze moesten gaan doen.

Dat je in de problemen komt ben ik met je eens. Maar bij mijn opleiding (Informatica aan de HAN te Arnhem) sturen ze ook wel degelijk aan op zelfstandig werken en het zelf aanpakken van problemen en de oplossingen daarvoor zoeken. Het is natuurlijk niet zo dat alles voorgekauwd wordt en voor elk probleem bestaat een oplossing dat wel ergens in een boek of op google rondzwerft. Dus dat mag het probleem niet zijn. Dat dit toch vaak het geval is heeft veelal te maken met de kwaliteit van lesgeven. Zoals je al zegt hebben veel studenten veel te weinig inlevingsvermogen en/of zijn te lui om zelf de oplossing te vinden of hebben gewoonweg niet genoeg initiatief om zelf de oplossing te gaan zoeken.

[Down]

Als ik zo terugkijk op m'n opleiding (HBO informatica) klopt het inderdaad wel dat er genoeg mensen rondlopen die geen idee hebben waar ze mee bezig zijn, volgens mij heeft dit echter geenszins te maken met Java. Ik ben absoluut geen fan van Java maar de theorie waar over gerept wordt werd op mijn opleiding gegeven in Java (datastructures, recursion, sorting (bubble/merge/quick)) en dat werkte verder prima. Ik heb ook geen problemen gehad met het toepassen van deze theorie in andere talen zoal c++, c#, php en asm (gedeeltelijk).

Het is handig en soms zelfs noodzakelijk om kennis te hebben van lowlevel zaken. De werking van geheugen, het OS en cpu registers zijn allemaal interessant maar de noodzaak van het kunnen toepassen van deze zaken wordt hier schromelijk overdreven. Multiple inheritance wordt al snel onoverzichtelijk en het nut hiervan vind ik vrij gelimiteerd. De laatste keer dat ik echt met pointers heb gewerkt was met directx in c++ en dit is twee jaar geleden. Alle business software waar ik sindsdien in bedrijfsverband heb aan ontwikkeld was allemaal in C#/ASP.net danwel Java en als ik iets moet sorteren dan gebruik ik inderdaad gewoon de sort methode van een collectie. Fantastisch, al die voorgekauwde zaken uit de API, hoef ik daar geen tijd aan te besteden. Pointers mis ik niet. Af en toe doe ik eens iets met een reference maar dat is zeer sporadisch. Dat geeft mij meer tijd om me bezig te houden met belangrijkere zaken zoals requirements.

Uiteraard is begrip van wat er eigenlijk gebeurt wel belangrijk, maar IMHO niet in de mate die hier gesuggereerd wordt. Daarbij moet ik zeggen dat ik lowlevel ontzettend leuk vindt en microcode schrijven voor de MIC1 (Tanenbaum) ontzettend leerzaam was.

De TS klinkt nogal elitair en praat imho Joel Spolsky achterna. Veel artikelen van deze man kan ik waarderen (en om lachen) maar hier komt hij nogal over als een verbitterd mannetje.

Waar ik het wel mee eens ben is dat het niveau van de Informatica opleidingen niet denderend hoog is. Zo ben ik genoeg mensen tegengekomen op de opleiding die niets weten van interfaces(!), sql, databases, algoritmes, performance en ga zo maar door en ook genoeg van deze mensen behalen hun diploma. Deze mensen liften mee met anderen en studeren af en met vakken die niet veel technische diepgang hebben. Het merendeel van deze mensen waren denk ik beter op hun plek geweest op de bedrijfskundige tak van de opleiding.

[Confusion]

Hydra schreef op maandag 15 december 2008 @ 14:37:
Wil je dan je hele leven als programmeur werken? Lijkt me toch niet meer dan logisch dat je naar een meer adviserende / managende rol groeit?

Het is toch zonde dat degenen die het beste code kunnen schrijven daar mee ophouden? Dat ze ophouden juist als ze echt goed beginnen te worden? En dat ze dan een ander vak moeten gaan uitoefenen, waar ze misschien helemaal niet zo goed in zijn?

[H!GHGuY]

De belangrijkste reden die het artikel aanhaalt is dat JavaSchools graduates niet op meerdere niveau's tegelijk kunnen programmeren.

Schoolvoorbeeld (hoe toepasselijk) hierin is iemand in het begin van de discussie:

Het ligt niet aan de taal, maar aan de opdrachten die je moet voltooien. Priegelige memory management zoals bij C (krijg je bij Systems Programming) is nou niet echt een algemeen belangrijke skill in de informatica.

Net door het probleem dat je moet oplossen te combineren met het moeten managen van geheugen verplicht je de programmeur om op meerdere niveau's tegelijk te denken. En Joel haalt net een van Java's grootste troeven aan als 1 van de oorzaken: Je moet je enkel nog op je probleem focussen en de rest is bijzaak.

Het gevolg is dat, zoals anderen hier al aanhalen, een complete nul samen met google en de Java API iets in elkaar kan typen. Voeg daar 4 jaar JavaSchools aan toe en hij schrijft je prompt een 13-in-een-dozijn accountancy programma.

Goed voor bedrijven die zo'n software schrijven, slecht voor bedrijven die meer verwachten van hun nieuwe collega's.

[Verwijderd]

H!GHGuY schreef op maandag 15 december 2008 @ 20:35:
Net door het probleem dat je moet oplossen te combineren met het moeten managen van geheugen verplicht je de programmeur om op meerdere niveau's tegelijk te denken. En Joel haalt net een van Java's grootste troeven aan als 1 van de oorzaken: Je moet je enkel nog op je probleem focussen en de rest is bijzaak.

Dan moet je als bedrijf vragen of je sollicitant even voor je kan demonstreren hoe je een binaire zoekboom efficient implementeert in assembly. Dan heb je alle lagen van abstractie wel gehad denk ik. Behalve als de ISA-laag ook nog leakt, zoals Joel zou zeggen. Dan kan je je sollicitant beter logische schakelingen laten tekenen op papier.

Eigenlijk is het een heel slecht idee om dat soort niveau's van abstractie niet te gebruiken. Memory management valt nog mee, maar als je bijvoorbeeld een audio streaming protocol ontwerpt, dan ga je niet het afhandelen van de filestream (zoals in TCP) combineren met het audio-protocol (codec-informatie, etc). Dat maakt je gecombineerde protocol alleen maar ingewikkeld.

[ Voor 46% gewijzigd door Verwijderd op 15-12-2008 21:41 . Reden: smiley toegevoegd... niet te serieus nemen ;) ]

[Dooievriend]

phobosdeimos schreef op zondag 14 december 2008 @ 21:31:
Iemand die nu in België afstudeerd als bachelor informatica, weet niet wat een pointer is.
Weet niet wat een double linked list is.
Weet niet wat een preprocessor of een compiler nu eigenlijk doet.
Weet niet hoe quicksort eigenlijk werkt, laat staan om het zelf te implementeren.

Owkey, misschien een beetje oprakelen van oude post, maar dit raakt kant nog wal (ben beledigd als student bachelor Informatica in België) =>
pointer: in vak Objectgericht Programmeren (met Java) gezien, net als bij hashing (en andere hoofdstukken)in Gegevensstructuren en Algoritmen.
double linked list: Gegevensstructuren en Algoritmen
preprocessor/compiler: net een metavertolker geschreven in Prolog (voor het vak Declaratieve Talen), ken heus wel het verschil tussen machinetaal en hogere talen (geleerd in het vak Structuur en Organisatie van Computersystemen)
quicksort: 3 hoofdstukken over allerlei sort-methodes (bubble, insertion, heap, quick, binary, merge...) in Gegevensstructuren en Algoritmen, heb er gisteren nog eentje geïmplementeerd.

Al deze vakken zijn noodzakelijk voor het "diploma" van bachelor Informatica. Ik snap dus niet hoe je zoiets kunt beweren

[Kettrick]

H!GHGuY schreef op maandag 15 december 2008 @ 20:35:
Je moet je enkel nog op je probleem focussen en de rest is bijzaak.

Ben ik toch erg benieuwd wat daar op tegen is ? . Alles wat niet direct bijdraagt tot het oplossen van mijn probleem beschouw ik als overhead

[djengizz]

Confusion schreef op maandag 15 december 2008 @ 19:51:
Het is toch zonde dat degenen die het beste code kunnen schrijven daar mee ophouden? Dat ze ophouden juist als ze echt goed beginnen te worden? En dat ze dan een ander vak moeten gaan uitoefenen, waar ze misschien helemaal niet zo goed in zijn?

Inderdaad en ik ben dit regelmatig tegen gekomen.
Zeker in een organisatie waar software ontwikkeling niet de core business is zie je vaak een prestatiemodel gebaseerd op verbreding en moeten de goede programmeurs zich op een gegeven moment gaan 'ontwikkelen' tot leidinggevende om te kunnen groeien in salaris.
Om zo van een ninja programmeur een matige projectleider oid te maken is wel jammer.

[Janoz]

Hydra schreef op maandag 15 december 2008 @ 17:40:
Als je denkt dat je het implementeren van dat soort sorteeralgorithmen leert om die dingen later nog een keer te doen heb je het niet helemaal begrepen Dat soort vingeroefeningen zorgen ervoor dat je beter begrijpt wat er nu precies gebeurt als je Array.sort() (oid) aanroept. Dus dat je weet dat het niet iets is wat 1 clockcycle kost. Bovendien leert het je 'denken' zoals een computer 'denkt' en dus de vertaalslag van functioneel naar technisch te maken. Een hoop dingen die je tijdens je opleiding leert ga je niet weer gebruiken, ik ga ook echt geen LZW implementatie meer maken, maar ik weet wel hoe het werkt.

We zeggen het anders, maar we bedoelen precies hetzelfde . Het gaat inderdaad niet om het oplepelen van algoritmen, maar om het begrip. Wat een sort in houdt (jouw verhaal) en/of waarom je voor een bepaalde datastructuur kiest (mijn verhaal).

[pedorus]

Dooievriend schreef op maandag 15 december 2008 @ 20:57:
Owkey, misschien een beetje oprakelen van oude post, maar dit raakt kant nog wal (ben beledigd als student bachelor Informatica in België) =>
pointer: in vak Objectgericht Programmeren (met Java) gezien, net als bij hashing (en andere hoofdstukken)in Gegevensstructuren en Algoritmen.

Mm, dat zijn denk ik toch niet pointers zoals Joel die bedoelt, waarbij bepaalde dingen mis kunnen gaan (segmentation fault). Probeer anders deze vraag eens te beantwoorden .

.oisyn schreef op maandag 15 december 2008 @ 17:05:
Afgezien van het feit dat je zin niet klopt, heb ik nooit beweerd dat ik die strip niet kende. En veel plezier met het exploiten van de door mij gebruikte browser

_{Ha, maar je hebt ook niet beweert dat je hem wel kende, ook niet als reactie op Rhapsody. En zwijgen is.... Juist.}
Over IE: Ik doe niet aan dat soort illegale praktijken, maar ik zou IE gebruiken niet aanraden totdat er een patch is... Zo'n typisch gevalletje buffer overflow exploit waar je met Java geen last van heb, wellicht hebben ze van die Java-schoolgangers ingezet.

[H!GHGuY]

RoeLz schreef op maandag 15 december 2008 @ 20:58:
[...]
Ben ik toch erg benieuwd wat daar op tegen is ? . Alles wat niet direct bijdraagt tot het oplossen van mijn probleem beschouw ik als overhead

Ik zeg dan ook dat het een van Java's troeven is.

Wanneer je een MasterPiece™ maakt verwacht ik zelfs voor je design dat je zal moeten kunnen redeneren op meerdere lagen. Van high-level tot low-level, van implementatie-details tot hoogste abstractie.
Het leren van dit soort denken verbeter je door dit zo vroeg mogelijk aan te leren.

Door in Java te programmeren, verlies je alles wat jij als overhead aanhaalt en mis je de 3rde dimensie om het zo uit te drukken. Chocopasta is misschien niet noodzakelijk om te overleven, maar een boterhammetje mét smaakt toch zoveel beter. Dat is denk ik waar de discussie om draait.

[Kettrick]

H!GHGuY schreef op maandag 15 december 2008 @ 23:10:
[...]

Ik zeg dan ook dat het een van Java's troeven is.

Ik dacht een sarcasme te lezen, my bad

Wanneer je een MasterPiece™ maakt verwacht ik zelfs voor je design dat je zal moeten kunnen redeneren op meerdere lagen. Van high-level tot low-level, van implementatie-details tot hoogste abstractie.
Het leren van dit soort denken verbeter je door dit zo vroeg mogelijk aan te leren.

Door in Java te programmeren, verlies je alles wat jij als overhead aanhaalt en mis je de 3rde dimensie om het zo uit te drukken. Chocopasta is misschien niet noodzakelijk om te overleven, maar een boterhammetje mét smaakt toch zoveel beter.

De vraag hierbij is uiteindelijk wat de klant wil. Veel projecten duren uiteindelijk te lang en worden te uitgebreid gebouwd, waardoor de klant ipv de gevraagde kale boterham veel te laat een half beschimmeld stuk brood met opgedroogde chocopasta krijgt.

Een MasterPiece™ is wat mij betreft precies maken wat de klant wil, niets meer niets minder. Of je het geheugen management zelf doet of niet zal de klant werkelijk een worst wezen, de markt waarin dergelijke optimalisaties nodig zijn is gewoon erg klein.

Dat is denk ik waar de discussie om draait.

Moraal van deze discussie is wat mij betreft dat de markt meer behoefte heeft aan business gerichte ontwikkelaars dan aan perfectionistische nerdjes die de laatste bit geheugen willen gebruiken, dat is gewoon te duur.

[writser]

Interessante discussie. Ik ben het helemaal eens met Janoz en Hydra. Op je studie leer je allerlei kennis die je niet noodzakelijk nodig hebt als je gaat werken. Maar deze kennis zorgt er volgens mij wel voor dat je beter snapt wat je allemaal aan het doen bent op je werk. Toen ik 8 of 10 was leende ik ooit een boek in de bibliotheek waar complete sourcecode in Basic voor spelletjes voor mijn Atari in stond. Na uren typen had je dan een spelletje. Maar ik snapte geen bal van wat ik aan het doen was. Afgezien van wat strings aanpassen kon ik helemaal niks en als ik ergens een typefout had gemaakt deed het spelletje het niet. Afgelopen jaren heb ik studenten technische bedrijfskunde geassisteerd bij werkcollege's Imperatief Programmeren (in Java). Die werkten in principe op dezelfde manier. Overtikken, wat namen aanpassen en dan hopen dat het werkt.

Het nuttige van een studie informatica vind ik dat je allemaal details leert (bijv. verschillende sorteeralgoritmes, P = NP, hardware ontwerpen in VHDL, vertalerbouw, PageRank algoritme) die je later misschien nooit meer nodig hebt. Maar als je later een spelletje overtikt in Java of Basic (of bezig bent met een serieus project) heb je toch enorm veel aan die kennis. Je snapt plotseling foutmeldingen van je compiler, omdat je zelf een compiler hebt gebouwd. Je herkent design patterns. Je ziet waar bottlenecks zitten. Ik denk dat je met deze "theoretische" kennis een betere programmeur kan zijn. Ik moet er in elk geval niet aan denken dat de copy-pasters bij wie ik heb geassisteerd ooit programmeerwerk voor mij zouden moeten doen. Maar ik werk nog niet, dus kan dit niet bevestigen.

Ook in Groningen wordt het curriculum aangepast: de focus verschuift van "snappen wat een computer doet" naar "requirements opstellen". Een gevolg hiervan is dat Java meer in het curriculum komt. Met java zet je sneller wat leuks in elkaar, dus is er meer tijd om te besteden aan de ontwerpfase. Dit is iets wat de topicstarter volgens mij niet doorheeft. Het curriculum verandert niet door Java. Java komt er in omdat het curriculum verandert. Misschien is dat voor het bedrijfsleven een goede verandering, maar ik ben zelf van mening dat de balans wat te ver doorschiet richting het bedrijfsleven en dat vind ik jammer. Niet in de laatste plaats omdat ik het opstellen van eindeloze documenten ***-werk vind. Dat ga ik wel doen als ik er voor betaald wordt, niet als ik er zelf voor moet betalen ..

Chocopasta is misschien niet noodzakelijk om te overleven, maar een boterhammetje mét smaakt toch zoveel beter. Dat is denk ik waar de discussie om draait.

Ik heb werkelijk geen idee wat je hier bedoelt ..

[Nick The Heazk]

writser schreef op dinsdag 16 december 2008 @ 01:06:
Het nuttige van een studie informatica vind ik dat je allemaal details leert (bijv. verschillende sorteeralgoritmes, P = NP, hardware ontwerpen in VHDL, vertalerbouw, PageRank algoritme) die je later misschien nooit meer nodig hebt.

Stuur dat bewijs maar door naar m'n email .

[rickjehh]

writser schreef op dinsdag 16 december 2008 @ 01:06:
Interessante discussie. Ik ben het helemaal eens met Janoz en Hydra. Op je studie leer je allerlei kennis die je niet noodzakelijk nodig hebt als je gaat werken. Maar deze kennis zorgt er volgens mij wel voor dat je beter snapt wat je allemaal aan het doen bent op je werk. Toen ik 8 of 10 was leende ik ooit een boek in de bibliotheek waar complete sourcecode in Basic voor spelletjes voor mijn Atari in stond. Na uren typen had je dan een spelletje. Maar ik snapte geen bal van wat ik aan het doen was. Afgezien van wat strings aanpassen kon ik helemaal niks en als ik ergens een typefout had gemaakt deed het spelletje het niet. Afgelopen jaren heb ik studenten technische bedrijfskunde geassisteerd bij werkcollege's Imperatief Programmeren (in Java). Die werkten in principe op dezelfde manier. Overtikken, wat namen aanpassen en dan hopen dat het werkt.

Klopt, zo ben ik ook begonnen. Ik had geen flauw idee wat ik aan het doen was, maar ik typte gewoon dingen over en als het niet werkte dan gooide ik de hele zooi weer weg. Je ziet ook dat veel studenten op die manier meeliften met mensen die wel aanleg hebben om te programmeren: Ze gaan samen aan de slag, de persoon met aanleg heeft alle ideeën en neemt het initiatief. De persoon die meelift vind het allemaal wel best en neemt het over van de ander.

Het nuttige van een studie informatica vind ik dat je allemaal details leert (bijv. verschillende sorteeralgoritmes, P = NP, hardware ontwerpen in VHDL, vertalerbouw, PageRank algoritme) die je later misschien nooit meer nodig hebt. Maar als je later een spelletje overtikt in Java of Basic (of bezig bent met een serieus project) heb je toch enorm veel aan die kennis. Je snapt plotseling foutmeldingen van je compiler, omdat je zelf een compiler hebt gebouwd. Je herkent design patterns. Je ziet waar bottlenecks zitten. Ik denk dat je met deze "theoretische" kennis een betere programmeur kan zijn. Ik moet er in elk geval niet aan denken dat de copy-pasters bij wie ik heb geassisteerd ooit programmeerwerk voor mij zouden moeten doen. Maar ik werk nog niet, dus kan dit niet bevestigen.

Hier ben ik het mee eens. Het is niet zozeer dat ze jou meteen specialiseren in een bepaald iets op school, ze presenteren een breed scala aan mogelijkheden en leren je de basis van een aantal zaken (OO, sorteeralgoritmes etc). Wat ze je dus willen leren (op mijn school iig) is de basis van het programmeren, om je door te laten krijgen waarom je een bepaalde keuze maakt en hoe je die keuze verwerkt en vertaald naar het programmeren. Al moet ik wel zeggen dat het snappen van design patterns pas gaat gebeuren als je weet hoe OOP werkt. Toen ik vorig jaar voor het eerst kennis maakte met OOP en design patterns, snapte ik geen bal van de design patterns, omdat ik de basis van OOP niet doorhad. Nu ik dat wel heb, begrijp ik ook hoe design patterns werken en hoe je deze toe kan passen tijdens het programmeren.

Ook in Groningen wordt het curriculum aangepast: de focus verschuift van "snappen wat een computer doet" naar "requirements opstellen". Een gevolg hiervan is dat Java meer in het curriculum komt. Met java zet je sneller wat leuks in elkaar, dus is er meer tijd om te besteden aan de ontwerpfase. Dit is iets wat de topicstarter volgens mij niet doorheeft. Het curriculum verandert niet door Java. Java komt er in omdat het curriculum verandert. Misschien is dat voor het bedrijfsleven een goede verandering, maar ik ben zelf van mening dat de balans wat te ver doorschiet richting het bedrijfsleven en dat vind ik jammer. Niet in de laatste plaats omdat ik het opstellen van eindeloze documenten ***-werk vind. Dat ga ik wel doen als ik er voor betaald wordt, niet als ik er zelf voor moet betalen ..

Hier ben ik het deels mee eens. Ik denk niet dat het helemaal daarmee te maken heeft. Ik kan me nog herinneren dat ik met mijn ouders naar de info-avond in Arnhem ging. Daar vertelden ze me dat ze veel JAVA gebruikten, omdat dat in het bedrijfsleven veel gebruikt werd. Het is dus niet in alle gevallen een verschuiving van "snappen wat een computer doet" naar "requirements opstellen", want requirements opstellen heb ik wel degelijk geleerd en ook het snappen wat een computer doet zit in de opleiding verweven. Het is dus maar net waar een opleiding voor kiest.

[Zoijar]

writser schreef op dinsdag 16 december 2008 @ 01:06:
Ook in Groningen wordt het curriculum aangepast: de focus verschuift van "snappen wat een computer doet" naar "requirements opstellen".

Zonde. Kunnen ze die mensen beter doorsturen naar bedrijfsinformatica.

[? ?]

..

[ Voor 113% gewijzigd door ? ? op 25-01-2013 09:51 ]

[Hydra]

Vanuit de hoek van de TS vernemen we weinig nieuws

Dooievriend schreef op maandag 15 december 2008 @ 20:57:
pointer: in vak Objectgericht Programmeren (met Java) gezien, net als bij hashing (en andere hoofdstukken)in Gegevensstructuren en Algoritmen.

Hij bedoelt C pointers, geen Java references

[ Voor 74% gewijzigd door Hydra op 16-12-2008 11:30 ]

[kenneth]

Hydra schreef op dinsdag 16 december 2008 @ 11:26:
Hij bedoelt C pointers, geen Java references

Het verschil is nu niet echt schokkend als je pointer arithmetic en GC achterwege laat.

[Hydra]

kenneth schreef op dinsdag 16 december 2008 @ 12:14:
Het verschil is nu niet echt schokkend als je pointer arithmetic en GC achterwege laat.

Nee, maar daar doelde hij dus op, dat mensen 'nieteens' leren met pointers om te gaan. Hoewel ik het niet eens ben met z'n post ben ik wel blij ook C++ gehad te hebben. Zelf je rotzooi op moeten ruimen is wel iets dat je IMHO moet leren, en ik vind ook dat HBO/WO informatica studenten zeker C++ moeten leren. Alleen is het IMHO goed dat je eerst in Java begint, en later in C++, in plaats van andersom. Ik heb me ook een hoop bagger af moeten leren die ik danzij m'n eigen knutselwerk aan had geleerd.

[.Gertjan.]

Hydra schreef op dinsdag 16 december 2008 @ 12:28:
[...]


Nee, maar daar doelde hij dus op, dat mensen 'nieteens' leren met pointers om te gaan. Hoewel ik het niet eens ben met z'n post ben ik wel blij ook C++ gehad te hebben. Zelf je rotzooi op moeten ruimen is wel iets dat je IMHO moet leren, en ik vind ook dat HBO/WO informatica studenten zeker C++ moeten leren. Alleen is het IMHO goed dat je eerst in Java begint, en later in C++, in plaats van andersom. Ik heb me ook een hoop bagger af moeten leren die ik danzij m'n eigen knutselwerk aan had geleerd.

Inderdaad. Eerst de denkwijze van het programmeren in Java of C# leren (+ eventueel een andere taal zodat men doorheeft dat je voor een andere taal alleen de syntax en het framework hoeft te leren). Zodra de denkwijze erin zit (dus classes maken, variabelen verbergen (correct gebruik private en public)) kan men zichzelf gaan verdiepen in de "onderliggende" techniek.

Voor mijzelf was C++ een verdieping. Omdat je wat dichter op de pointers en "garbage collection" zit, weet je een beetje hoe de andere talen het op de achtergrond afhandelen (waarom bijvoorbeeld bepaalde dingen byref en byval gaan en begrijp je waarom je als je een object byref als parameter en je de parameter aanpast waarom het "originele object" ook verandert).

Zelf vond ik het bijvoorbeeld ook grappig om te zien wat bepaalde algoritmes doen in assembly en waarom je daarom voor een bepaalde aanpak zou moeten kiezen. Als je iets begrijpt is het leuk om de details te leren kennen.

[GTOfire]

Ik moet zeggen, ik snap zeker waar het sentiment vandaan komt om te claimen dat java een belangrijke oorzaak is van het verloederen van skills van nieuw afgestudeerden. Door te leren proggen met Java in een omgeving als BlueJ zoals bij ons in Den Bosch kan idd iedere sukkel de programmeer vakken van het 1e jaar afronden.
De opleidingen zijn verschoven van het uitpikken van zij die de kunde al hebben naar het proberen aan te brengen van deze kunde bij mensen die dat nog niet bezitten. Je kunt je overigens afvragen of dat wel zo'n slecht idee is...

Dit zou echter wel gecombineerd moeten worden met het bijbrengen van alle kunde, en niet zoals door een aantal mensen al genoemd, de skills om met java en google een accountancy prog in elkaar te flanzen.

Ik wil alleen echter wel claimen dat dit verschijnsel echt heel erg te maken heeft met de leraar en manier van lesgeven, en veel minder met de taal dan genoemd wordt.
Ik heb Java gekregen van een docent die juist hamert op het zoeken naar de juiste en beste oplossing en je na laat denken over "wat nu als..".

Ik krijg C++ van een docent die al 20 jaar geleden met de vut had moeten gaan, niet uit kan leggen wat bijv. het keyword const op een bepaalde plaats precies doet, en wiens opdrachten bestaan uit het copy-pasten van een document code van 16 kantjes en het implementeren van 1 of 2 methodes die hij leeg heeft gelaten. We leren werkelijk niets diepzinnigs van pointers en geheugen management en compiler errors (die bij C++ lastig te doorgronden kunnen zijn) snapt hij zelf minder dan wij.

Daarnaast kan je nog zo goed lesgeven, als de school de lat te laag legt kom je nog nergens. Ik herinner me een tentamen OO Modeleren, waarbij 20% een onvoldoende haalde (een niet heel moeilijk tentamen I might add). Toen keek ik voor de gein nog eens goed, en wat bleek: nog eens 40% zat tussen de 5,5 en 6,4. De leraar had iedereen 1 vol punt "aanwezigheidsbonus" gegeven...
Nou maakt mij het niet uit of ik nu een 9,4 of een 10 haal voor een simpel tentamen, maar zo wordt mijn diploma straks wel minder waard. Heeft alleen niets te maken met de taal, maar met de drang van school om meer mensen af te leveren met een BICT stempel erop.

Ik ben het eens met de stelling dat de gebruikte taal een middel kan zijn om goede studenten te onderscheiden van de rest. Maar als school wil je toch juist zoveel mogelijk mensen de benodigde kennis bij brengen, en dat is juist geheel afhankelijk van de manier van lesgeven, de leraar en de hoogte van de lat die aangehouden wordt. Als we het hebben over de vermindering in waarde van de afgeleverde gediplomeerden, dan moet je eerst zorgen dat de school minder beloond wordt voor kwantiteit en meer voor kwaliteit. Want je kan de mannen wel van de jongens willen scheiden met een taal als C/C++, maar als de jongens vervolgens ook gewoon aan de grote-mensen-tafel mogen eten heeft het geen effect gehad.

[Michali]

@GTOfire: Wat je schrijft is exact hoe ik er over denk en het ook ervaar op school.

Het niveau is bij mij op school ook echt bedroevend.

Ik heb dan nog wel les gehad in data structuren en algoritmen, maar dat kwam er ook vaak op neer om uit een stuk van te voren geschreven code een foutje te halen. Nou wat leer je daar veel van zeg. De meeste klasgenoten hadden na dit vak te hebben gehad nog steeds geen idee waar het over ging.

Als het niveau met sommige vakken ook niet gehaald wordt door de groep, dan wordt die gewoon een stukje naar beneden bijgesteld. Ik kan nou niet echt zeggen dat dit heel goed voor mijn motivatie is.

[.oisyn]

Michali schreef op dinsdag 16 december 2008 @ 18:50:
Ik heb dan nog wel les gehad in data structuren en algoritmen, maar dat kwam er ook vaak op neer om uit een stuk van te voren geschreven code een foutje te halen. Nou wat leer je daar veel van zeg.

Niet om 't een of ander, maar debuggen is dan weer wel een kunst op zich, waar ook wel wat meer aandacht aan besteed mag worden. Maar natuurlijk niet ten koste van algoritme-leer

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

[MLM]

Bij mij op school is het niveau juist vrij hoog, maar gefocust op maar 1 taal: C++
Het Java verhaal gaat echter ook (maar wel in mindere mate) op bij mij, je leert een taal ipv dat je leert coden.
Ik denk zelfs dat in mijn geval het soms een goed idee is om meerdere talen te doceren, zodat je toch een bredere kennis opdoet, en makkelijker de overeenkomsten tussen talen ziet (en dus niet taal-gebonden leert coden).

Ik doe zelf nog wel enige zelfstudie hiernaast, dus ik denk dat het met mij wel goed komt, maar deze discussie is zeker wel relevant voor de grote hoeveelheden niet-identieke ICT opleidingen in Nederland.

[Pathogen]

Zo, na de eerste pagina gelezen te hebben: dit is wel een fel topic zeg!

Desalniettemin wil ik hier toch mijn mening geven, simpelweg omdat ik programmeer in het dagelijks leven.

Naar mijn idee bestaat de programmeurswereld uit grofweg twee schiftingen.
Enerzijds heb je de mensen die een (of meerere uiteraard) programmeertaal tot op het bot kennen, weten wat functies onderhuids doen en waarom die verrekte memory leak zich elke keer weer voordoet. Hierna verwijs ik naar deze soort als de hardcore-progger.

Anderzijds heb je de algemenere programmeur: iemand die uitzoekt welke functies hij nodig heeft om een doel te bereiken. Deze soort kan dit vaak met een redelijk korte (zelf-)studie af en klust een werkend programma in elkaar. Uitvoerend automatiseerder zou wat mij betreft een passende titel zijn, ik houd het hierna even op automatiseerder.

Deze twee soorten zijn allebei nodig. Een hardcore-progger is bijvoorbeeld uitermate geschikt voor het optimaliseren van device drivers, terwijl een automatiseerder zich prima verdienstelijk kan maken voor bedrijven die een proces willen automatiseren, vereenvoudigen of vernieuwen.

De hardcore-progger is iemand die ins en outs kent en is naar mijn mening het best op zijn plaats in functies waar performance en scalability er echt toe doet. Volgens mij hoef je sommige hardcore-proggers ook niet te vragen om een administratieprogramma te schrijven voor een bedrijfje van 50 man. De hardcore-progger is dan ook een zeldzaam stukje personeel, is vaak moeilijk te vinden en ook nog eens flink duur.
Hij is echter wel goed in zijn vak en is daar trots op.

De automatiseerder is het goedkopere alternatief. Je hoeft geen high-end retedure hardcore-progger in te huren om programma's te schrijven die niet per se performant of schaalbaar hoeven te zijn. Vooral interne bedrijfsapplicaties hebben meestal niet veel aan een ultiem, tot de tanden getweakt systeem.
Waar de systemen die deze groep aflevert soms een rochel in het gezicht zijn van een hardcore-progger, dienen ze toch hun functie, met de bijkomstigheid dat een hardcore-progger zich niet tot dit soort triviale applicaties hoeft te verlagen.

Dan krijg je nog het derde oogpunt: dat van de niet-informatici. Hoe simpel het ook moge zijn door de ogen van iemand die zich met hart en ziel inzet op het computervlak, de meeste mensen hebben geen flauw benul van het verschil tussen de hardcore-progger en de automatiseerder.
Veelgehoorde opmerking bij mij is dan ook "Jij doet toch iets met computers? Ja ik heb een probleem met mijn internet." terwijl ik, als programmerend medemens, geen bal afweet van hoe de internetverbinding van de desbetreffende persoon in elkaar steekt.

De vloek in de informatica is naar mijn mening dat de automatiseerder en de hardcore-progger over één kam geschoren worden: "programmeur". Voor de hardcore-progger is dat een trap tegen het zere been, want iedere "suflul" met een informaticaopleiding kan zich programmeur noemen. Voor de automatiseerder is het echter juist een mooie kans om mee te liften op een "dure" titel en van die kans wordt veelvuldig gebruik gemaakt.

Conclusie: waar de titel "programmeur" voorheen nog was voorbehouden aan mensen die bij wijze van spreken de nulletjes en eentjes zelf konden schrijven, is het vakgebied verbreed en de titel verwaterd. Een programmeur vandaag de dag is iemand die, op welk niveau en met welke tools dan ook, een programma in elkaar zet.
Waar voorheen de "script kiddies" het leven van de hardcore-progger zuur maakten, doet nu een door het bedrijfsleven gewilde groep automatiseerders dit, hoewel ik poog te stellen dat een aanzienlijk percentage van deze automatiseerders niet meer kennis bevatten dan een script kiddy met een papiertje.

Overigens, ik heb een mbo-papiertje en voer in het dagelijks leven mijn baan uit als "automatiseerder". Voor diegenen die zich zo diep in de materie hebben gestort dat ze met recht het label "hardcore-progger" van me hebben gekregen heb ik diep respect, maar voor mijn functie is zo'n persoon helemaal niet nodig.
Natuurlijk optimaliseer ik wel eens queries of stukken programma die te traag zijn, dat is ook wel nodig als er 200+ man tegelijk met je applicatie bezig kan zijn. Daarvoor gebruik ik echter mijn favoriete tool, Google, met wat zeer gerichte zoektermen. Inhoudelijk hoef ik niet per se te snappen waarom iets sneller of beter werkt, als het maar daadwerkelijk zo is.

Disclaimer: deze post omvat mijn mening, ook waar ik dat niet expliciet aangeef. Mijn mening moet niet als waarheid worden aangenomen of gezien zonder dat de context en strekking van bovenstaand relaas zijn begrepen en een poging is gedaan om anderswijzende argumenten te genereren.

[AtleX]

GTOfire schreef op dinsdag 16 december 2008 @ 18:26:
Ik moet zeggen, ik snap zeker waar het sentiment vandaan komt om te claimen dat java een belangrijke oorzaak is van het verloederen van skills van nieuw afgestudeerden. Door te leren proggen met Java in een omgeving als BlueJ zoals bij ons in Den Bosch kan idd iedere sukkel de programmeer vakken van het 1e jaar afronden.
De opleidingen zijn verschoven van het uitpikken van zij die de kunde al hebben naar het proberen aan te brengen van deze kunde bij mensen die dat nog niet bezitten. Je kunt je overigens afvragen of dat wel zo'n slecht idee is...

Ik heb het verkorte traject SE gedaan (ben nu aan het afstuderen) op Avans en daarbij vielen wel behoorlijk wat mensen al in het eerste halfjaar weg. Dat waren de mensen die er echt niets van bakten. Helaas blijven er dan nog genoeg over waar Informatica imho echt niet de juiste opleiding voor is.

Dit zou echter wel gecombineerd moeten worden met het bijbrengen van alle kunde, en niet zoals door een aantal mensen al genoemd, de skills om met java en google een accountancy prog in elkaar te flanzen.

Mwah, ik heb toch een aantal projecten gedaan die, weliswaar door eigen initiatief, zeker niet makkelijk waren. Het laatste project van het 4e jaar van regulier (het 2e jaar bij mij dus) was een project waarbij de groep zelf een klant moest benaderen, zelf de requirements duidelijk moest krijgen en zelf het hele definitie-, ontwerp-, implementatie- en nazorgtraject moest verzorgen. Helaas werd het niet streng genoeg beoordeeld, maar dan zie je pas echt wie er goed bezig zijn en wie er aanklooien.

Ik wil alleen echter wel claimen dat dit verschijnsel echt heel erg te maken heeft met de leraar en manier van lesgeven, en veel minder met de taal dan genoemd wordt.
Ik heb Java gekregen van een docent die juist hamert op het zoeken naar de juiste en beste oplossing en je na laat denken over "wat nu als..".

Ik krijg C++ van een docent die al 20 jaar geleden met de vut had moeten gaan, niet uit kan leggen wat bijv. het keyword const op een bepaalde plaats precies doet, en wiens opdrachten bestaan uit het copy-pasten van een document code van 16 kantjes en het implementeren van 1 of 2 methodes die hij leeg heeft gelaten. We leren werkelijk niets diepzinnigs van pointers en geheugen management en compiler errors (die bij C++ lastig te doorgronden kunnen zijn) snapt hij zelf minder dan wij.

Afaik ben ik de laatste lichting geweest die C++ heeft gehad, maar als ik het zo lees geeft P. de N. het nog steeds? Welke richting doe je eigenlijk?

Want je kan de mannen wel van de jongens willen scheiden met een taal als C/C++, maar als de jongens vervolgens ook gewoon aan de grote-mensen-tafel mogen eten heeft het geen effect gehad.

Oneens, Software Engineering gaat om concepten, planning, requirements duidelijk kunnen krijgen, meedenken met de klant. Een taal is een tool, en imho is iemand die geweldig kan ontwikkelen in Java meer waard dan iemand die 'aardig' C++ kent.

[ Voor 6% gewijzigd door AtleX op 16-12-2008 20:19 ]

[H!GHGuY]

RoeLz schreef op maandag 15 december 2008 @ 23:42:
De vraag hierbij is uiteindelijk wat de klant wil. Veel projecten duren uiteindelijk te lang en worden te uitgebreid gebouwd, waardoor de klant ipv de gevraagde kale boterham veel te laat een half beschimmeld stuk brood met opgedroogde chocopasta krijgt.

Een MasterPiece™ is wat mij betreft precies maken wat de klant wil, niets meer niets minder. Of je het geheugen management zelf doet of niet zal de klant werkelijk een worst wezen, de markt waarin dergelijke optimalisaties nodig zijn is gewoon erg klein.
[...]
Moraal van deze discussie is wat mij betreft dat de markt meer behoefte heeft aan business gerichte ontwikkelaars dan aan perfectionistische nerdjes die de laatste bit geheugen willen gebruiken, dat is gewoon te duur.

En daar denk ik dat heel deze discussie dan ook fout loopt. Dat de klant geen baat heeft bij bitneukers besef ik al te goed. Mijn punt (en ik denk dat van Joel ook) is dat je met het leren denken op verschillende niveau's van abstractie/detail tegelijk een beter werk aflevert onafhankelijk van de taal.

Wat Joel dan ook zegt is dat je iemand met een opleiding waarin (naar zijn voorbeeld) Scheme, Haskell en C++ aangeleerd wordt binnen luttele momenten omschoolt in een Java-pro die (waarschijnlijk gemiddeld genomen) beter werk aflevert dan een JavaSchools programmeur met 5jr ervaring.

Iemand die alle aspecten ineens kan in acht nemen bij het maken van zijn software is simpelweg meer waard dan iemand die volgens het monkey-see-monkey-do principe Java+OO leert en dan maar gaat code kloppen.

Misschien is de vergelijking hierboven van iemand behoorlijk accuraat:
Niemand spreekt Oud-Grieks of Latijn. Het wordt echter wel gegeven op school omdat het je leert nadenken en alle aspecten van de taal tegelijk in acht nemen om een goeie vertaling neer te zetten.

era.zer schreef op dinsdag 16 december 2008 @ 11:22:
Ik ben euh 4 jaartjes geleden afgestudeerd bachelor informatica (graduaat toegepaste informatica)
//er bestaan veel bachelors informatica, maar met dé bachelor wordt toegepaste informatica bedoeld

In het bedrijfsleven staat Toegepaste Informatica zéér hoog aangeschreven hier in België. Dat een universitair vast wel beter diepgaandere en lowlevel zaken kan is maar normaal zeker?
Toegepaste informatica is niet zo geschikt om game-ontwikkelaar te worden of drivers te schrijven of Operating Systems uit te gaan vinden. Het is wel geschikt om goed te programmeren met kennis van heel veel uiteenlopende zaken. Maar zoals altijd leer je pas echt coden/... op je werk.

Dan moet je eens beter rondhoren. Dat ze geheid een job vinden is waar. Maar hoog aangeschreven is iets anders. Je hebt overal prutsers en wizzkids, ook in TI, maar het niveau ligt daar zo belachelijk laag dat het om van te schreien is. In de III (Ind.Ing.Informatica) kwamen de SV'ers (Studieduur Verkorting - zij die eerst TI studeerden en dan in 2 jaar extra een III diploma op zak willen) er bij. Stuk voor stuk mensen die me vertelden dat ze in hun jaren TI geen boek hebben opengedaan. En jammer genoeg moet ik er bij zeggen dat enkele van hen helemaal niet bedoeld waren om ook maar dicht bij een PC te komen.

Ook mijn eigen ervaring met TI'ers is jammerlijk. Alles gaat goed zolang je het hen voorkauwt of wanneer ze zelfs niets moeten uitzoeken. Maar o wee als ze het onderwerp niet eerder voorgeschoteld kregen.
Idem zijn de verhalen die ik van enkele bedrijfsleiders reeds gehoord heb.

Nogmaals, ik kan gerust aannemen dat jij een wizzkid bent, die misschien zelfs beter een zwaarder diploma had proberen op zak halen, maar je had daar nogal een boude stelling in je post staan.

[GTOfire]

AtleX schreef op dinsdag 16 december 2008 @ 20:17:
[...]

Afaik ben ik de laatste lichting geweest die C++ heeft gehad, maar als ik het zo lees geeft P. de N. het nog steeds? Welke richting doe je eigenlijk?

Ik doe het reguliere 4-jaar traject in de volgorde I/BI (slechte keus, <brrr> BI), hoofdfase I, Gaming minor, Software Architectuur minor. Misschien dat jij de minor tijden net hebt gemist, maar je kan nu per half jaar kiezen. Heb dus geen Middleware gedaan (wat, mocht je het je afvragen, inderdaad onder leiding van P de N nog steeds ieder jaar hard faalt), maar multimedia - gaming, en daarna richting SE.

Oneens, Software Engineering gaat om concepten, planning, requirements duidelijk kunnen krijgen, meedenken met de klant. Een taal is een tool, en imho is iemand die geweldig kan ontwikkelen in Java meer waard dan iemand die 'aardig' C++ kent.

Eens ik bedoelde ook niet zo zeer het scheiden van de jongens en mannen wat betreft allround ITer, maar vooral wat betreft programmeren en de juiste manier van denken. Ik denk echter dat de 2 gerelateerd zijn. Iemand die content is met het vinden van de eerste ipv de beste programmeer oplossing zal ook niet in staat zijn een volledige en eenduidige requirements lijst op te stellen bijvoorbeeld. Ook het netjes modelleren van systemen wordt geholpen als je beter snapt wat wel en niet kan in de implementatie. Bijna iedereen vind bijvoorbeeld het maken van een AKD nutteloos "we houden ons er toch nooit aan". Dan denk ik, was dan je AKD niet gewoon bagger? Ik zeg niet dat een AKD 100% van tevoren vast moet staan en perfect moet zijn, maar in mijn projectgroepjes was het wel altijd de leidraad om een goeie basis op te zetten.

[Enfer]

GoTCoast schreef op zondag 14 december 2008 @ 21:48:
Ikzelf zit nog op de middelbare school dus kan nog niet echt meepraten.

Maar mijn vervolgopleiding (Informatica B, Saxion Enschede) die geeft in het eerste jaar/eerste semester Java i.c.m. BlueJ & krijg je al de (wiskunde & biologische) theorie van recursief denken.
En tweede semester ga je al naar Java i.c.m. Eclipse (wel met BlueJ-plugin). Als keuze-'taal' kan je dan ook nog PHP/Python/VB.net kiezen.
In jaar 2, begin je al met C/C++/C#; dus je krijgt het merendeel van die opleiding gewoon alles, incl pointers en geheugenbeperkingen (garbage collector).

Dus het ligt echt net aan de (school)instelling hoe & wat je leert. En of die (school)instelling dus de Informatica B (let op de B ) geeft.

offtopic:
De Informatica die ik in Enschede studeer, aan het Saxion, heeft mij tot aan mijn 5e semester nog steeds niet de keuze tot PHP/VB/Python geboden. Ook denk ik niet dat die keuze er gaat komen..

[ Voor 12% gewijzigd door Enfer op 16-12-2008 22:00 ]

[Haijo]

Thrackan schreef op dinsdag 16 december 2008 @ 20:02:

-verhaal-

Kan het hier niet meer mee eens zijn eigenlijk. Misschien het kleine puntje dat Java dus voornamelijk ontwikkeld is specifiek voor de "automatiseerder" en dat het daarom dus de reputatie heeft bij sommige mensen van "n00b-taal".

[Confusion]

Haijo schreef op dinsdag 16 december 2008 @ 22:06:
Misschien het kleine puntje dat Java dus voornamelijk ontwikkeld is specifiek voor de "automatiseerder" [..]

Hoe kom je daar bij? Oorspronkelijk was het bedoeld voor set-top boxes. Vervolgens is het ge-evolueerd en waren volgens Sun de ontwerpdoelen: http://java.sun.com/docs/white/langenv/Intro.doc2.html

[kenneth]

GTOfire schreef op dinsdag 16 december 2008 @ 18:26:
Ik moet zeggen, ik snap zeker waar het sentiment vandaan komt om te claimen dat java een belangrijke oorzaak is van het verloederen van skills van nieuw afgestudeerden. Door te leren proggen met Java in een omgeving als BlueJ zoals bij ons in Den Bosch kan idd iedere sukkel de programmeer vakken van het 1e jaar afronden.

Dus dat ligt dan aan Java en niet aan de programmeervakken zelf?

Dat is namelijk steeds de vraag die de Javacritici zichzelf veelal niet stellen ...

[GTOfire]

kenneth schreef op dinsdag 16 december 2008 @ 23:53:
[...]
Dus dat ligt dan aan Java en niet aan de programmeervakken zelf?

Dat is namelijk steeds de vraag die de Javacritici zichzelf veelal niet stellen ...

Uit je post kan ik moeilijk opmaken of je denkt dat ik 1 van die mensen ben en zo denk, dus ik reageer er maar even op:

Nee dat ligt niet alleen aan java en die hele post gaat er juist over dat het aan de programmeervakken en manier van lesgeven ligt. Ik ben echter wel van mening dat het een onderdeel is van. All other things being equal, is het wel zo dat C++ net ietsje meer intelligentie vereist dan Java. Vandaar dat ik ook zeg dat ik de stelling wel enigzins begrijp.

[alienfruit]

Op de kunstacademie heb ik ook C++ en Java gehad en moesten wij ook leren over pointers, en hoe je linked lists moest maken. Maar ook hoe je dingen als Arduino's of PIC kon gebruiken en programmeren. Niks spannends aan hoewel het wel een afslachting was

[.Gertjan.]

AtleX schreef op dinsdag 16 december 2008 @ 20:17:


Afaik ben ik de laatste lichting geweest die C++ heeft gehad, maar als ik het zo lees geeft P. de N. het nog steeds? Welke richting doe je eigenlijk?

Hehe. Die heeft mij ook nog C++ gegeven (en ASP ). Ik moet eerlijk toegeven dat ik niet echt onder de indruk was van zijn kennis en lesmethode. Misschien dat hij de kennis wel had, maar het gewoon niet kon overbrengen.

In C++ heb ik veel mensen onderuit zien gaan omdat ze zijn uitleg niet helemaal konden bevatten. Dat is wel jammer, want zeker C++ is belangrijk genoeg om op zijn minst IETS van te weten.

Meeste voorbeelden/codesnippets van P. de N. moest je eerst gaan debuggen. Stonden vol met fouten (soms ook doordat MS Word er een zooi van heeft gemaakt). Of een scrabble spel met maar 25 verschillende letters

Het beheersen van een taal is niet heiligmakend (zelfs niet C++). Je zult op zijn minst een bepaalde denkwijze moeten hebben en ik vond tijdens mijn opleiding (SE) dat er maar weinig mensen waren die die denkwijze hadden (en daardoor zijn er heel wat mensen gestopt).

Ik denk dat je abstract moet kunnen denken, als je dat niet kunt kun je alleen een concrete opdracht uitvoeren (dus echt code kloppen aan de hand van wat een ander bedacht heeft). Als je een goede denkwijze hebt kun je makkelijker vanaf nul beginnen. Een goede developer is namelijk ook een analist, die het probleem kan analyseren en oplossen.

[Haijo]

Confusion schreef op dinsdag 16 december 2008 @ 22:59:
[...]

Hoe kom je daar bij? Oorspronkelijk was het bedoeld voor set-top boxes. Vervolgens is het ge-evolueerd en waren volgens Sun de ontwerpdoelen: http://java.sun.com/docs/white/langenv/Intro.doc2.html

Uit jouw stukje:

The system that emerged to meet these needs is simple, so it can be easily programmed by most developers; familiar, so that current developers can easily learn the Java programming language;

Daar is bij Sun gewoon rekening mee gehouden zodat de taal makkelijk wordt opgepikt door bedrijven.

[ Voor 20% gewijzigd door Haijo op 17-12-2008 08:38 ]

[Hydra]

Thrackan schreef op dinsdag 16 december 2008 @ 20:02:
Zo, na de eerste pagina gelezen te hebben: dit is wel een fel topic zeg!

Desalniettemin wil ik hier toch mijn mening geven, simpelweg omdat ik programmeer in het dagelijks leven.

Naar mijn idee bestaat de programmeurswereld uit grofweg twee schiftingen.
Enerzijds heb je de mensen die een (of meerere uiteraard) programmeertaal tot op het bot kennen, weten wat functies onderhuids doen en waarom die verrekte memory leak zich elke keer weer voordoet. Hierna verwijs ik naar deze soort als de hardcore-progger.

Anderzijds heb je de algemenere programmeur: iemand die uitzoekt welke functies hij nodig heeft om een doel te bereiken. Deze soort kan dit vaak met een redelijk korte (zelf-)studie af en klust een werkend programma in elkaar. Uitvoerend automatiseerder zou wat mij betreft een passende titel zijn, ik houd het hierna even op automatiseerder.

Deze twee soorten zijn allebei nodig. Een hardcore-progger is bijvoorbeeld uitermate geschikt voor het optimaliseren van device drivers, terwijl een automatiseerder zich prima verdienstelijk kan maken voor bedrijven die een proces willen automatiseren, vereenvoudigen of vernieuwen.

Je gaat even compleet aan het hele feit voorbij dat het hier niet om het programmeren an sich staat, maar het kunnen vertalen van een vraag naar een oplossing. Elke goeie developer kan dat, compleet ongeacht de taal.

En sorry hoor, device drivers schrijven is nou ook weer niet bijzonder moeilijk. Da's gewoon een HBO-I vak.

Daarnaast vind ik je "goedkope alternatief" gewoon ronduit denigrerend. De meest gezochte en duurste developers zijn die met een gebruiker om tafel kunnen gaan zitten en zijn problemen om kunnen zetten naar oplossingen. Een in zichzelf gesloten nerd die toevallig erg goed device drivers kan schrijven is handig om achter de hand te hebben in het bezemhok, maar daar win je de oorlog niet mee.

[? ?]

..

[ Voor 129% gewijzigd door ? ? op 25-01-2013 09:51 ]

[Creepy]

Anderzijds heb je de algemenere programmeur: iemand die uitzoekt welke functies hij nodig heeft om een doel te bereiken. Deze soort kan dit vaak met een redelijk korte (zelf-)studie af en klust een werkend programma in elkaar. Uitvoerend automatiseerder zou wat mij betreft een passende titel zijn, ik houd het hierna even op automatiseerder.

Dit stukje uit je post pak ik er even uit.

Ik denk namelijk dat dit precies is waarom het "nivo" van de gemiddelde software ontwikkelaar naar beneden lijkt te kelderen. Een goede automatiseerder moet veel meer doen dan alleen maar een werkend programma op te leveren. Hele hopen mensen hebben dat niet door en denken dan ook vaak onterecht dat ze met een korte zelfstudie daadwerkelijk goed aan de gang kunnen. Een werkend programma afleveren is lang niet altijd hetzelfde als een goede oplossing opleveren voor de gebruikers. Ik wil je niet persoonlijk aanvallen maar het is stuitend dat er mensen zijn die blijkbaar na het volgen van een informatica opleiding dat nog niet doorhebben (dat zegt meer over de opleiding waarschijnlijk dan over jou ) Het doel is niet om een werkend programma af te leveren, maar om de gebruiker te ondersteunen. En om dat goed te doen moet je meer doen dan alleen domweg code kloppen.

Wat jij hardcore progger noemt vindt ik een normale ontwikkelaar, evenals de persoon die jij een automatiseerder noemt. Ze moeten namelijk allebei hetzelfde doen: zorgen dat de gebruiker goed aan de slag kan

[ Voor 9% gewijzigd door Creepy op 17-12-2008 11:07 ]

[MBV]

Ik doe eigenlijk ook zelden een boek open. Als docenten het duidelijk genoeg uitleggen, en de slides etc duidelijk zijn, dan is dat vaak niet nodig om de stof te begrijpen, en gebruik ik ze alleen als naslagwerk. Op het HBO (TH Rijswijk) was dat zeker het geval, op de universiteit nog steeds bij veel vakken.

@era.zer: Jij doet alsof er het verschil tussen programmeurs er niet toe doet. Ik denk dat dat juist heel belangrijk is: veel van die prutsers zorgen ervoor dat een bedrijf met een gigantisch systeem zit dat niet te onderhouden valt, maar waar wel het hele bedrijfsproces op draait. Maar helaas is het niet op programmeerkennis waar de echt grote projecten op falen, misschien heeft testosteron daar wel mee te maken.

@Creepy: Zoals ik al zei: grote projecten lopen helemaal niet stuk op programmeerkennis. Dat gaat op interactie tussen klant en automatiseerder, te ambitieuze doelen bij de klant (grote procesveranderingen doorvoeren onder het mom van automatisering, zie 'IT Governance'), onrealistische verwachtingen (dubbeltje eerste rang verhaal), aanbestedingsprocedures waardoor het product bij oplevering achterhaald is, enzovoort.
Als je iemand hebt die dat oplost is dat veel meer waard, en dat is wat ik denk dat Thrackan met de 'automatiseerder' bedoelt.

[ Voor 27% gewijzigd door MBV op 17-12-2008 11:10 ]

[? ?]

..

[ Voor 116% gewijzigd door ? ? op 25-01-2013 09:51 ]

[MBV]

Het niveau van afstudeerders van de TH Rijswijk, wat toch staat aangeschreven als een van de betere Bachelor Technische Informatica opleidingen, viel mij anders best tegen. Er waren maar 5 van de 20 die ik echt hoog had staan, bij de rest vroeg ik me af of ze genoeg inzicht hadden om zich te onderscheiden van hobbyisten. En ja, bij die 15 zaten ook een paar echte prutsers. Die zijn de meer business-gerichte richting gaan doen...
Maar goed, toen ik op de TU/e begon werd ik weer met beide benen op de grond gezet

[ Voor 24% gewijzigd door MBV op 17-12-2008 11:15 ]

[? ?]

..

[ Voor 121% gewijzigd door ? ? op 25-01-2013 09:51 ]

[Hydra]

MBV schreef op woensdag 17 december 2008 @ 11:04:
@Creepy: Zoals ik al zei: grote projecten lopen helemaal niet stuk op programmeerkennis. Dat gaat op interactie tussen klant en automatiseerder, te ambitieuze doelen bij de klant (grote procesveranderingen doorvoeren onder het mom van automatisering, zie 'IT Governance'), onrealistische verwachtingen (dubbeltje eerste rang verhaal), aanbestedingsprocedures waardoor het product bij oplevering achterhaald is, enzovoort.
Als je iemand hebt die dat oplost is dat veel meer waard, en dat is wat ik denk dat Thrackan met de 'automatiseerder' bedoelt.

Kennelijk is het altijd de schuld van de klant als iets niet afkomt?

[Creepy]

Ik denk dat MBV met "enzovoort" ook zaken bedoelt als
- Iets opleveren waar de klant niet om heeft gevraagd
- Te laat met opleveren omdat er iemand de boel zit "dood te designen" of code te generiek maakt puur om het te generiek te maken,
- Iets opleveren wat wel werkt maar slecht/onhandig werkt voor de gebruiker.
- etc. etc.

Het is echter de taak van de ontwikkelaar om alle zaken te bekijken en iets werkends op te leveren dat bruikbaar is voor de gebruiker en technische goed in elkaar steekt qua snelheid, onderhoudbaarheid en uitbreidbaarheid en vervolgens ook nog dit goed te plannen en op tijd op te leveren.

Voor mij geld dat voor iedereen die code schrijft. Het onderscheid in "hardcode progger" of "automatiseerder" maak ik dan ook niet.

[ Voor 4% gewijzigd door Creepy op 17-12-2008 11:32 ]

[.oisyn]

Hydra schreef op woensdag 17 december 2008 @ 11:23:

Kennelijk is het altijd de schuld van de klant als iets niet afkomt?

Logisch toch? Een goede programmeur weet hoe hij de schuld van zich af kan laten wijzen

[ Voor 51% gewijzigd door .oisyn op 17-12-2008 11:56 ]

[? ?]

..

[ Voor 102% gewijzigd door ? ? op 25-01-2013 09:51 ]

[AtleX]

GTOfire schreef op dinsdag 16 december 2008 @ 21:57:
[...]


Ik doe het reguliere 4-jaar traject in de volgorde I/BI (slechte keus, <brrr> BI), hoofdfase I, Gaming minor, Software Architectuur minor. Misschien dat jij de minor tijden net hebt gemist, maar je kan nu per half jaar kiezen.

Ik heb geen minors gehad, ik ben de laatste die verkort in 2.5 jaar afrond.

Heb dus geen Middleware gedaan (wat, mocht je het je afvragen, inderdaad onder leiding van P de N nog steeds ieder jaar hard faalt)

Ja, ik heb Middleware begin dit kalenderjaar gehad wat inderdaad compleet fout ging.

[...]
Eens ik bedoelde ook niet zo zeer het scheiden van de jongens en mannen wat betreft allround ITer, maar vooral wat betreft programmeren en de juiste manier van denken. Ik denk echter dat de 2 gerelateerd zijn. Iemand die content is met het vinden van de eerste ipv de beste programmeer oplossing zal ook niet in staat zijn een volledige en eenduidige requirements lijst op te stellen bijvoorbeeld. Ook het netjes modelleren van systemen wordt geholpen als je beter snapt wat wel en niet kan in de implementatie. Bijna iedereen vind bijvoorbeeld het maken van een AKD nutteloos "we houden ons er toch nooit aan". Dan denk ik, was dan je AKD niet gewoon bagger? Ik zeg niet dat een AKD 100% van tevoren vast moet staan en perfect moet zijn, maar in mijn projectgroepjes was het wel altijd de leidraad om een goeie basis op te zetten.

Juist, en daar wordt te weinig aandacht aan besteed op de verschillende opleidingen. Bij Avans Den Bosch ligt de nadruk heel erg op het proces en wordt er vrijwel nooit naar code, requirements, ontwerp, documentatie, etc. gekeken. Imho is dat niet slim. Iemand die een geweldig proces had maar compleet gefaalde producten oplevert is nog steeds fout bezig.

.Gertjan. schreef op woensdag 17 december 2008 @ 08:32:
[...]
In C++ heb ik veel mensen onderuit zien gaan omdat ze zijn uitleg niet helemaal konden bevatten. Dat is wel jammer, want zeker C++ is belangrijk genoeg om op zijn minst IETS van te weten.

Meeste voorbeelden/codesnippets van P. de N. moest je eerst gaan debuggen. Stonden vol met fouten (soms ook doordat MS Word er een zooi van heeft gemaakt). Of een scrabble spel met maar 25 verschillende letters

offtopic:
Ja, dat heb ik ook moeten doen. Veel mensen hadden echt een hopeloos probleem bij Scrabble omdat de uitleg over pointers totaal niet overkwam

[writser]

.oisyn schreef op woensdag 17 december 2008 @ 11:30:
[...]


Logisch nog? Een goede programmeur weet hoe hij de schuld van zich af kan laten wijzen

Dat biedt hoop voor de toekomst

[Hydra]

.oisyn schreef op woensdag 17 december 2008 @ 11:30:
Logisch nog? Een goede programmeur weet hoe hij de schuld van zich af kan laten wijzen

Als je dat niet in je opleiding leert, leer je het snel genoeg bij je eerste baan

[Creepy]

era.zer schreef op woensdag 17 december 2008 @ 11:34:
Als een klant per sé iets wil dat idioot is, tja. Of het nu idioot is op papier of op de computer, het blijft idioot, maar don't shoot the paper-maker or the programmer !

Alleen als je als ontwikkelaar met de klant hebt overlegd dat wat ie wil idioot is. Een klant weet 9 van de 10 keer niet wat ie wil. Je zult als ontwikkelaar aan de klant moeten uitleggen wat ie eigenlijk wil hebben.

[Hydra]

Creepy schreef op woensdag 17 december 2008 @ 12:04:
[...]

Alleen als je als ontwikkelaar met de klant hebt overlegd dat wat ie wil idioot is. Een klant weet 9 van de 10 keer niet wat ie wil.

Euh.

Een klant weet 9 van de 10 keer prima wat 'ie wil. Of het uberhaupt mogelijk is, is een tweede. Of heb ik zo'n geluk gehad?

[.oisyn]

Gelukkig heb ik nooit te maken met klanten. Hoewel... artists zijn net zo erg.

.edit @ Hydra: tja, het is natuurlijk maar net hoe je het interpreteert. Als een klant iets wilt waarbij iets moet werken na handeling X, terwijl de werking na X eigenlijk ambigu is en er dus ook een Y nodig is om te kunnen bepalen wat de bedoeling is, weet ie dan niet wat ie wilt of weet ie wel wat ie wilt maar is het onmogelijk?

[ Voor 70% gewijzigd door .oisyn op 17-12-2008 12:37 ]

[rapture]

Creepy schreef op woensdag 17 december 2008 @ 12:04:
Alleen als je als ontwikkelaar met de klant hebt overlegd dat wat ie wil idioot is. Een klant weet 9 van de 10 keer niet wat ie wil. Je zult als ontwikkelaar aan de klant moeten uitleggen wat ie eigenlijk wil hebben.

Op mijn stage zetten ze een stagiair bij een klant die 2x per dag van mening verandert. Het geduld van de stagiair werd getest en op het einde van de rit zal er wel bruikbare informatie gedestilleerd worden zodat de ontwikkelaars weten wat ze moeten doen.

[? ?]

..

[ Voor 99% gewijzigd door ? ? op 25-01-2013 09:51 ]

[Pathogen]

Hydra schreef op woensdag 17 december 2008 @ 10:30:
[...]


Je gaat even compleet aan het hele feit voorbij dat het hier niet om het programmeren an sich staat, maar het kunnen vertalen van een vraag naar een oplossing. Elke goeie developer kan dat, compleet ongeacht de taal.

En sorry hoor, device drivers schrijven is nou ook weer niet bijzonder moeilijk. Da's gewoon een HBO-I vak.

Daarnaast vind ik je "goedkope alternatief" gewoon ronduit denigrerend. De meest gezochte en duurste developers zijn die met een gebruiker om tafel kunnen gaan zitten en zijn problemen om kunnen zetten naar oplossingen. Een in zichzelf gesloten nerd die toevallig erg goed device drivers kan schrijven is handig om achter de hand te hebben in het bezemhok, maar daar win je de oorlog niet mee.

Het kunnen vertalen van een vraag naar een oplossing is 1, snappen waarom die oplossing de juiste is is 2. Dat is kort gezegd mijn punt, waarbij ik stel dat 2 niet altijd nodig is.

Device drivers heb ik zelf nog nooit geschreven, het is een voorbeeld dat ik aanhaalde omdat ik er van uit ging dat het schrijven van een goeie device driver veel optimalisatiewerk bevat en dus een in-depth kennis vereist.

In dat geval denigreer ik mezelf ook, maar dat is niet zo bedoeld. Ik poog vooral aan te geven dat iemand die aan de programmeerkant een schat aan dieptekennis bevat niet per se nodig is voor het ontwikkelen van een systeem.

Creepy schreef op woensdag 17 december 2008 @ 10:59:
[...]

Dit stukje uit je post pak ik er even uit.

Ik denk namelijk dat dit precies is waarom het "nivo" van de gemiddelde software ontwikkelaar naar beneden lijkt te kelderen. Een goede automatiseerder moet veel meer doen dan alleen maar een werkend programma op te leveren. Hele hopen mensen hebben dat niet door en denken dan ook vaak onterecht dat ze met een korte zelfstudie daadwerkelijk goed aan de gang kunnen. Een werkend programma afleveren is lang niet altijd hetzelfde als een goede oplossing opleveren voor de gebruikers. Ik wil je niet persoonlijk aanvallen maar het is stuitend dat er mensen zijn die blijkbaar na het volgen van een informatica opleiding dat nog niet doorhebben (dat zegt meer over de opleiding waarschijnlijk dan over jou ) Het doel is niet om een werkend programma af te leveren, maar om de gebruiker te ondersteunen. En om dat goed te doen moet je meer doen dan alleen domweg code kloppen.

Wat jij hardcore progger noemt vindt ik een normale ontwikkelaar, evenals de persoon die jij een automatiseerder noemt. Ze moeten namelijk allebei hetzelfde doen: zorgen dat de gebruiker goed aan de slag kan

Het gedeelte inventarisatie en omgang met wensen en eisen heb ik totaal buiten beschouwing gelaten, waarbij ik aannam dat dit of door een competente programmeur wordt gedaan of door een designer oid die specifiek voor die taak aangesteld is.
Wat niet wegneemt dat die taak vaak versmolten is in de werkzaamheden van de programmeur en dat er veel programmeurs zijn die deze taken niet goed kunnen uitvoeren.

In mijn ogen is een "pure" programmeur iemand die de stap van (goed) design naar eindproduct verwezenlijkt. Niet dat ik daarmee de ogen sluit voor de vele mensen die zowel inventarisatie en design als programmeren voor hun rekening nemen, ik laat deze versmelting alleen buiten beschouwing om de vergelijking te vereenvoudigen.

Daar ligt ook een ander (onbedoeld in mijn originele vergelijking) verschil tussen de "hardcore-progger" en de "automatiseerder" zoals ik die schetste. Wat ik als "hardcore-progger" zie is iemand die zich normaalgesproken niet met de design- en inventarisatiekant bezighoudt, maar iemand die zich voornamelijk richt op het realiseren van een design, met efficiëntie en dieptekennis in het hoofd.

De automatiseerder is meer de versmelting van deze tak met de designer. Iets minder dieptekennis, maar met een vertaalvermogen om gebruikerswensen om te zetten in een programma.

Overigens voel ik me totaal niet aangevallen, omdat ik in mijn werkzaamheden direct contact heb met mijn gebruikers (ik programmeer intern) en de wensen en eisen vaak zeer direct op het bordje komen te liggen. Ik voel dan ook niet dat ik op dat gebied tekortschiet, mede gezien het feit dat mijn opleiding juist de nadruk legde op dit aspect. Mijn doel is grofweg om mijn gebruikers het werk te vergemakkelijken.

[ Voor 50% gewijzigd door Pathogen op 17-12-2008 13:19 ]

[Creepy]

Hydra schreef op woensdag 17 december 2008 @ 12:15:
[...]


Euh.

Een klant weet 9 van de 10 keer prima wat 'ie wil. Of het uberhaupt mogelijk is, is een tweede. Of heb ik zo'n geluk gehad?

Ik denk dat je geluk hebt gehad of je hebt direct de wensen van de klant goed geïnterpreteerd. Het komt bij mij zelden voor dat wat we maken 100% gelijk is aan wat de klant heeft aangegeven wat ie wil.

era.zer schreef op woensdag 17 december 2008 @ 12:59:
[...]

Nog zo'n probleem. Als ontwikkelaar moet je al zoveel taken doen, moet je nog eens gaan bedenken wat ze nodig zouden kunnen hebben -terwijl je soms niet eens thuis bent in hun industrie. En als er dan iets fout loopt is het ons schuld.

Nadat je huis gebouwd is, ga je toch ook niet zeggen aan de architect dat je nog graag een ondergronde sauna met cinemazaal zou hebben.

Nope, dus vastleggen en goed afspreken met de klant wat er wel wordt gemaakt/geleverd.

Die architect moet toch niet vragen 'Hey klant, zou je geen ondergrondse sauna willen?' als er nooit iets over gerept wordt? En een ontwikkelaar wel?

Nope. dat heb ik ook niet gezegd.

Of hey, ik zou de voordeur graag in 't midden hebben en de garage op het eerste verdiep. En dan reclameren dat een aanpassing veel kost en veel tijd vraagt?

Again, afspreken wat je wel maakt.

Informatici laten zich teveel doen. Ik zei ook altijd "ja dat kan ik doen" op een vraag. (omdat ik zowat alles kan doen op technisch vlak); nu zeg ik gewoon: "nope dat is onmogelijk", (lees: kost mij teveel tijd, jou teveel geld en je zou toch niet tevreden zijn)

Lekker dan..... je gaat er direct vanuit dat de klant niet tevreden gaat zijn. Denk dan mee met de klant en stel iets voor war hij wel tevreden mee gaat zijn.

Anyway, dit zijn niet de voorbeelden waar ik op doelde. Als een klant vraag om een bad op z'n kop in de badkamer te laten plaatsen dan hoop ik dat de architect er melding van maakt dat dat niet handig is en met een betere oplossing gaat komen. Dat bedoel ik met "de klant weet niet wat ie wil". De klant weet dat ie een bad wil en zegt dat het op de kop moet worden geplaatst terwijl de klant een bad wil waar ie in kan badderen. Subtiel verschil En dat gebeurd in de informatica met enige regelmaat. Een klant roept dat het zo en zo moet werken en dan wordt het maar doodleuk gemaakt. Een klant heeft geen verstand van software ontwikkeling, wij wel. Help de klant dan ook. Heb je een projectleider/architect/whatever/insert senior term here/etc die dat niet goed doet, geef dat dan in elk geval aan hem aan dat ie dat wel had moeten doen.

Note: ook de projectleider/architect/whatever/insert senior term here/etc zie ik hier als ontwikkelaar. Niet alleen de code klopper.

Mijn doel is grofweg om mijn gebruikers het werk te vergemakkelijken.

[ Voor 12% gewijzigd door Creepy op 17-12-2008 13:34 ]

[MBV]

Hydra schreef op woensdag 17 december 2008 @ 11:23:
[...]


Kennelijk is het altijd de schuld van de klant als iets niet afkomt?

Ja en nee. Als ik naar een architect loop, en zeg: "Ik wil mijn huis zus en zus en zo hebben" dan zegt die architect niet "goh leuk, gaan we maken" om er vervolgens achter te komen dat het niet specifiek genoeg is, en dat een paar dingen onmogelijk zijn (je kan niet overal vandaan uitzicht op zee hebben). Zelfs voor hij de eerste tekening zal maken zal hij daarover opmerkingen maken. Hij maakt, na meer concreet maken, een ontwerp, en gaat na goedkeuring het laten bouwen.
Veel IT'ers vinden "zus en zus en zo" duidelijk genoeg, doen niet aan terugkoppeling met de klant, maken een systeem wat an sich al brak is, en komen er bij oplevering achter dat de klant het heel anders bedoelde. Sterker nog: dit wordt in de hand gewerkt door (fout uitgevoerde) aanbestedingen.

Creepy schreef op woensdag 17 december 2008 @ 11:30:
Ik denk dat MBV met "enzovoort" ook zaken bedoelt als
- Iets opleveren waar de klant niet om heeft gevraagd
- Te laat met opleveren omdat er iemand de boel zit "dood te designen" of code te generiek maakt puur om het te generiek te maken,
- Iets opleveren wat wel werkt maar slecht/onhandig werkt voor de gebruiker.
- etc. etc.

Die eerste 2 zijn eigenlijk nog wel technische problemen: met betere opleiding op programmeer/ontwerpgebied kan je dat voorkomen. En dat was precies wat ik niet bedoelde.

Het is echter de taak van de ontwikkelaar om alle zaken te bekijken en iets werkends op te leveren dat bruikbaar is voor de gebruiker en technische goed in elkaar steekt qua snelheid, onderhoudbaarheid en uitbreidbaarheid en vervolgens ook nog dit goed te plannen en op tijd op te leveren.

Voor mij geld dat voor iedereen die code schrijft. Het onderscheid in "hardcode progger" of "automatiseerder" maak ik dan ook niet.

Dat iedereen het moet kunnen, neemt niet weg dat de een beter is in een snel algoritme ontwerpen, iemand anders beter in low-level optimalisaties, weer iemand anders in globaal ontwerp, en weer iemand anders uitblinkt in communicatie met de klant. Met hardcore-progger denk ik niet aan uitblinkers in het globale ontwerp en communicatie met de klant, maar andere vlakken.

.oisyn schreef op woensdag 17 december 2008 @ 11:30:
[...]


Logisch toch? Een goede programmeur weet hoe hij de schuld van zich af kan laten wijzen

Inderdaad, daarvoor leren ze op de TU/e heel veel bewijsvoering: "Mijn code werkt, kijk maar"

Als reactie op de laatste pagina:

[Creepy]

En het "what the user asked for" t.o.v. "what the user really wanted" is precies wat ik bedoel
Tssk.. stiekum de afbeelding vervangen..

En het "how the customer explained it" t.o.v. "what the customer really needed" is precies wat ik bedoel met "een klant weet niet wat ie wil"

[ Voor 51% gewijzigd door Creepy op 17-12-2008 13:37 ]

[Kentsfield]

Een programmeur moet kunnen programmeren lijkt me, een functioneel ontwerp kunnen omzetten in bruikbare software lijkt me alles wat je moet kunnen. Dit is indd wat zwart wit zeker wanneer je werkt voor kleinere bedrijven en heel veel zelf doet. Klant contact ed. en het maken van een FO is volgens mij meer iets voor een ontwerper.

[Hydra]

Thrackan schreef op woensdag 17 december 2008 @ 13:04:
Het kunnen vertalen van een vraag naar een oplossing is 1, snappen waarom die oplossing de juiste is is 2. Dat is kort gezegd mijn punt, waarbij ik stel dat 2 niet altijd nodig is.

Kun je me uitleggen hoe je een oplossing kunt bedenken zonder het probleem te begrijpen?

Device drivers heb ik zelf nog nooit geschreven, het is een voorbeeld dat ik aanhaalde omdat ik er van uit ging dat het schrijven van een goeie device driver veel optimalisatiewerk bevat en dus een in-depth kennis vereist.

Grappig dat je zo hoog van de toren blaast dan. Persoonlijk vind ik het schrijven van een DD een stuk simpeler dan een complexe webapplicatie. En dat laatste is iets waar al "type 2" mensen van jou toch vooral aan werken.

In dat geval denigreer ik mezelf ook, maar dat is niet zo bedoeld. Ik poog vooral aan te geven dat iemand die aan de programmeerkant een schat aan dieptekennis bevat niet per se nodig is voor het ontwikkelen van een systeem.

Voor vrijwel elk systeem heb je mensen nodig met in-depth kennis. Alleen gaat dat tegenwoordig vaak om bijvoorbeeld J2EE gerelateerde kennis. Iemand met alleen Device Driver 'kennis' is vaak vrij nutteloos in een groot enterprise project.

In mijn ogen is een "pure" programmeur iemand die de stap van (goed) design naar eindproduct verwezenlijkt. Niet dat ik daarmee de ogen sluit voor de vele mensen die zowel inventarisatie en design als programmeren voor hun rekening nemen, ik laat deze versmelting alleen buiten beschouwing om de vergelijking te vereenvoudigen.

Een 'pure programmeur' doet niks anders dan een aangeboden ontwerp uitcoden. En dat zijn gewoon MBO ICT types. Een software engineer maakt het ontwerp. In sommige gevallen code hij ook, in veel gevallen ook niet.

Daar ligt ook een ander (onbedoeld in mijn originele vergelijking) verschil tussen de "hardcore-progger" en de "automatiseerder" zoals ik die schetste. Wat ik als "hardcore-progger" zie is iemand die zich normaalgesproken niet met de design- en inventarisatiekant bezighoudt, maar iemand die zich voornamelijk richt op het realiseren van een design, met efficiëntie en dieptekennis in het hoofd.

Iemand die zich niet met het design bezig houdt, dus puur een gemaakt design uitwerkt, is gewoon een code klopper. Da's MBO niveau.

De automatiseerder is meer de versmelting van deze tak met de designer. Iets minder dieptekennis, maar met een vertaalvermogen om gebruikerswensen om te zetten in een programma.

Automatiseerder is uberhaupt geen term die iets te maken heeft met SE.

Overigens voel ik me totaal niet aangevallen, omdat ik in mijn werkzaamheden direct contact heb met mijn gebruikers (ik programmeer intern) en de wensen en eisen vaak zeer direct op het bordje komen te liggen. Ik voel dan ook niet dat ik op dat gebied tekortschiet, mede gezien het feit dat mijn opleiding juist de nadruk legde op dit aspect. Mijn doel is grofweg om mijn gebruikers het werk te vergemakkelijken.

Ik probeer ze een flinke kuttijd te bezorgen. Op z'n minst maak ik een GUI die echt nergens op slaat.

Creepy schreef op woensdag 17 december 2008 @ 13:28:
Ik denk dat je geluk hebt gehad of je hebt direct de wensen van de klant goed geïnterpreteerd. Het komt bij mij zelden voor dat wat we maken 100% gelijk is aan wat de klant heeft aangegeven wat ie wil.

Als de wensen van de klant niet goed geinterpreteerd worden, betekent dit dus dat de developer niet weet wat de klant wil, niet dat de klant het niet precies weet. Dat een klant het vaak niet precies kan verwoorden is een gegeven en iets waar je altijd rekening mee moet houden. Da's ook waarom je vaak als een van de eerste stappen een mock-up maakt.

[ Voor 9% gewijzigd door Hydra op 17-12-2008 13:47 ]

[rapture]

Op de FPGA van een CompactRIO (embedded) programmeren is een beperkte omgeving. Er zit een aantal poortjes die geprogrammeerd kunnen worden om je code te laten uitvoeren. Als je een if met 2 mogelijkheden hebt, dan worden er met de poortjes 2 paden uitgewerkt. Als je onder een if nog een if plaats zodat er 3 mogelijkheden zijn, dan worden er met de poortjes 3 paden uitgewerkt. Voordat je weet zijn de poortjes op.

Als je 4 bits meetwaarden heeft, dan kan je dat 2 zulke meetwaarden in een byte opslaan. Achteraf moet je de meetwaarden terug scheiden. Dan heb je nog beperkingen in de wiskundige bewerkingen, gemiddelde van kwadraten laten uitrekenen kan nog, maar geavanceerde bewerkingen past niet erin.

Er wordt dus aan "bitneukerij" gedaan. Een andere wereld dan desktophardware, waar je goedkoop en ranzig kan coderen. Is het te traag? Wet van Moore lost het wel op, steeds geavanceerdere processors en steeds snellere computers. Need moar ram's, 4GB induwen? Geen probleem. Dat pacman vroeger met 64k tevreden was en tegenwoordig minstens een Pentium 3 nodig heeft voor hetzelfde? Een nieuwe Dell computer tot aan de voordeur laten komen is blijkbaar goedkoper dan wat manuren tegen aansmijten.

Je specialistische zaken en je hebt de gewone zaken.

[Hydra]

rapture schreef op woensdag 17 december 2008 @ 13:47:
Op de FPGA van een CompactRIO (embedded) programmeren is een beperkte omgeving. Er zit een aantal poortjes die geprogrammeerd kunnen worden om je code te laten uitvoeren. Als je een if met 2 mogelijkheden hebt, dan worden er met de poortjes 2 paden uitgewerkt. Als je onder een if nog een if plaats zodat er 3 mogelijkheden zijn, dan worden er met de poortjes 3 paden uitgewerkt. Voordat je weet zijn de poortjes op.

Als je 4 bits meetwaarden heeft, dan kan je dat 2 zulke meetwaarden in een byte opslaan. Achteraf moet je de meetwaarden terug scheiden. Dan heb je nog beperkingen in de wiskundige bewerkingen, gemiddelde van kwadraten laten uitrekenen kan nog, maar geavanceerde bewerkingen past niet erin.

Er wordt dus aan "bitneukerij" gedaan. Een andere wereld dan desktophardware, waar je goedkoop en ranzig kan coderen. Is het te traag? Wet van Moore lost het wel op, steeds geavanceerdere processors en steeds snellere computers. Dat pacman vroeger met 64k tevreden was en tegenwoordig minstens een Pentium 3 nodig heeft voor hetzelfde? Een nieuwe Dell computer tot aan de voordeur laten komen is blijkbaar goedkoper dan wat manuren tegen aansmijten.

Je specialistische zaken en je hebt de gewone zaken.

Je punt is? Omdat de omgeving zo beperkt is, is die programmeur 'beter'? Sorry hoor, maar ik hobby zelf ook met coden voor m'n Atmel processor, en dat komt kwa complexiteit bij lange na niet bij grote projecten in de buurt.

En dat je ruimte hebt om crap code op te leveren; dus? In echte projecten ga je echt wel op je plaat als na een codereview of profiling sessie blijkt dat je kut werk geleverd hebt.

[rapture]

Niet perse beter. In de ene omgeving heb je mensen nodig die onderste uit de kan kunnen halen en in een andere omgeving is "als het maar werkt" voldoende. Net goed genoeg is het optimale in de markt. Overkill is te duur en kan dus goedkoper. De specialisten zitten waar ze nodig zijn.

[Hydra]

rapture schreef op woensdag 17 december 2008 @ 14:06:
Niet perse beter. In de ene omgeving heb je mensen nodig die onderste uit de kan kunnen halen en in een andere omgeving is "als het maar werkt" voldoende. Net goed genoeg is het optimale in de markt. Overkill is te duur en kan dus goedkoper. De specialisten zitten waar ze nodig zijn.

"Als het maar werkt" is een instelling die je in projecten later duur komt te staan. Dan moet er uitgebreid worden, komt er meer functionaliteit bij, en vallen er links en rechts zaken om omdat je geen regressietests ontwikkeld hebt.

[Pathogen]

Hydra schreef op woensdag 17 december 2008 @ 13:45:
[...]

Blaas ik hoog van de toren? Ik heb slechts een uitgesproken mening volgens mij. Dat je het wel of niet met die mening eens bent hoeft toch niet te betekenen dat mijn mening vanuit de hoogte komt?
Ja, ik maak vergelijkingen, en waarschijnlijk is het jouw beroepsgroep, waardoor je je wellicht enigzins aangevallen voelt door mijn stellingen. Laat me nog een keer verduidelijken dat ik nooit op jou persoonlijk doel, misschien helpt dat. Ik ken je niet eens, hoe kan ik je dan aanvallen?

Ik probeerde neutraal en kalm bewoord een stukje uiteen te zetten, maar blijkbaar wordt die toon gezien alsof ik denk dat ik er boven sta. Zelf ben ik van mening dat als ik puur mijn beleving van het verhaal beschrijf ik niet een volledig begrijpelijk standpunt neerzet.

En ik mag hopen dat het stukje over je "GUI die nergens op slaat" sarcastisch bedoeld is, hoewel ik niet snap waarom je je op dit punt in een discussie van sarcasme bedient. Mijns inziens komt het een normale conversatie niet ten goede.

Wat betreft een oplossing bedenken zonder het probleem te begrijpen: Ik schrijf duidelijk dat het de oplossing is die niet begrepen wordt, niet het probleem.

Nogmaals, er is verschil tussen een codeklopper en iemand die snapt wat zijn code doet. Dat is mijn punt, en dat komt volgens mij nog steeds niet door bij je.
Daarnaast probeer ik duidelijk te maken dat elk van die twee zo zijn of haar nut heeft. Dat is alles. Dat mijn voorbeelden niet 100% correct zijn omdat device drivers makkelijk te schrijven zijn is jammer, maar zelfs met een totaal gebrek aan interpretatievermogen is het nog leesbaar dat ik daar een voorbeeld gebruik, ik geef in mijn post daarna zelfs nog aan dat mijn voorbeeld niet geheel correct is.

[? ?]

..

[ Voor 183% gewijzigd door ? ? op 25-01-2013 09:51 ]

[kenneth]

Hydra schreef op woensdag 17 december 2008 @ 14:10:
[...]


"Als het maar werkt" is een instelling die je in projecten later duur komt te staan. Dan moet er uitgebreid worden, komt er meer functionaliteit bij, en vallen er links en rechts zaken om omdat je geen regressietests ontwikkeld hebt.

Daarom zegt rapture ook niet dat in iedere situatie "Als het maar werkt" goed is. Ik heb in één bedrijf verschillende soorten projecten meegemaakt die qua uitvoer van academisch tot "Als het maar werkt" gingen, en het bedrijf bestaat nog steeds Je moet weten wanneer je waarvoor kiest. Ik heb net een draak van een query geschreven die 3m00 uitvoertijd heeft, terwijl dat echt tien keer zo snel kan. Maar na vanmiddag ga ik die query weggooien. Gevalletje "Als het maar werkt" dus

En verder: wat je zegt is helemaal waar, maar de baas betaalt de rekening, en die denkt vaak in wat kortere termijn ...

[Hydra]

Thrackan schreef op woensdag 17 december 2008 @ 14:17:
Blaas ik hoog van de toren? Ik heb slechts een uitgesproken mening volgens mij. Dat je het wel of niet met die mening eens bent hoeft toch niet te betekenen dat mijn mening vanuit de hoogte komt?
Ja, ik maak vergelijkingen, en waarschijnlijk is het jouw beroepsgroep, waardoor je je wellicht enigzins aangevallen voelt door mijn stellingen. Laat me nog een keer verduidelijken dat ik nooit op jou persoonlijk doel, misschien helpt dat. Ik ken je niet eens, hoe kan ik je dan aanvallen?

Joh, dat snap ik toch ook wel? Dit is een discussie, als jij met argumente komt waar ik het niet mee eens bent, ga ik daar met m'n eigen "uitgesproken mening" tegenin. Ik vind dat jij een verkeerd beeld hebt van mijn vakgebied, maar ik vat niks persoonlijks op. Don't worry

Ik probeerde neutraal en kalm bewoord een stukje uiteen te zetten, maar blijkbaar wordt die toon gezien alsof ik denk dat ik er boven sta. Zelf ben ik van mening dat als ik puur mijn beleving van het verhaal beschrijf ik niet een volledig begrijpelijk standpunt neerzet.

En ik mag hopen dat het stukje over je "GUI die nergens op slaat" sarcastisch bedoeld is, hoewel ik niet snap waarom je je op dit punt in een discussie van sarcasme bedient. Mijns inziens komt het een normale conversatie niet ten goede.

Ja dat was sarcastisch, en ja ik vind ook dat dat gewoon een "no shit sherlock" stukje was.

Wat betreft een oplossing bedenken zonder het probleem te begrijpen: Ik schrijf duidelijk dat het de oplossing is die niet begrepen wordt, niet het probleem.

Als je de oplossing niet begrijpt, kun je het probleem niet begrijpen, en vice versa.

Nogmaals, er is verschil tussen een codeklopper en iemand die snapt wat zijn code doet. Dat is mijn punt, en dat komt volgens mij nog steeds niet door bij je.

Volgens mij heb jij een erg simpel beeld van wat developen inhoudt. Je kunt niet programmeren zonder je code in ieder geval voor 't grootste deel te begrijpen. Iemand die niks snapt van code noem ik geen programmeur maar een projectleider

Daarnaast probeer ik duidelijk te maken dat elk van die twee zo zijn of haar nut heeft. Dat is alles. Dat mijn voorbeelden niet 100% correct zijn omdat device drivers makkelijk te schrijven zijn is jammer, maar zelfs met een totaal gebrek aan interpretatievermogen is het nog leesbaar dat ik daar een voorbeeld gebruik, ik geef in mijn post daarna zelfs nog aan dat mijn voorbeeld niet geheel correct is.

Het is niet "niet geheel correct", het punt is dat je kennelijk niet veel kennis hebt van ons vakgebied. Te veel mensen denken dat je bij een HBO-I opleiding opgeleidt wordt tot code klopper. Dat is (zonder denigrerend te willen klinken) toch echt een MBO niveau opleiding. HBO-I is een beta opleiding, waar je een behoorlijke wiskundeknobbel voor nodig hebt. HBO-I is in het 1e en 2e jaar een massaslachting wat betreft uitval door alle mensen die de opleiding te makkelijk inschatten. In mijn 1e jaar viel 70% uit, een groot deel types die vonden dat HBO-I wel een goed idee was omdat ze graag spelletjes speelden.

Een SE kan in princiepe het hele traject aan. Functioneel ontwerp. Technisch ontwerp. Projectmanagement. Coden. Testen. De hele rambam. Sommige SEs vinden vooral het coden zelf het allerleukste, andere mensen vinden het ontwerpdeel leuker (ik ben daar een van) en laten het coden liever aan aan andere mensen over.

kenneth schreef op woensdag 17 december 2008 @ 14:24:
Daarom zegt rapture ook niet dat in iedere situatie "Als het maar werkt" goed is. Ik heb in één bedrijf verschillende soorten projecten meegemaakt die qua uitvoer van academisch tot "Als het maar werkt" gingen, en het bedrijf bestaat nog steeds

Dat een bedrijf nog steeds bestaat zegt niks. Als ik niet onder NDA zou staan kon ik je zo een paar grote bedrijven opnoemen die echt op een redelijk bizarre manier met klanten omgaan, en die bestaan ook nog gewoon.

[ Voor 7% gewijzigd door Hydra op 17-12-2008 14:55 ]

[Exirion]

Hydra schreef op woensdag 17 december 2008 @ 14:53:
Iemand die niks snapt van code noem ik geen programmeur maar een projectleider

Of een architect. Die weten het vaak ook alleen maar leuk te vertellen in Powerpoints. Of ze komen niet verder dan een beetje Java... Oeps, wat zeg ik nou weer

[Hydra]

Exirion schreef op woensdag 17 december 2008 @ 14:57:
Of een architect. Die weten het vaak ook alleen maar leuk te vertellen in Powerpoints. Of ze komen niet verder dan een beetje Java... Oeps, wat zeg ik nou weer

Ik weet dat het op zich grappig bedoeld is, maar een softwarearchitect is in veel gevallen ooit begonnen als developer en in die richting doorgegroeid. Ik ken er ook wel een die zo incompetent als de pest is, maar ik ken er meer die heel goed zijn in overall ontwerpen maken. Het is bovendien een rol waarin ik mij in de toekomst ook wel zie. Zoals ik al eerder zei; ik vind het leuker oplossingen uit te denken dan ze daadwerkelijk te implementeren.

[Dutchmega]

kenneth schreef op woensdag 17 december 2008 @ 14:24:
[...]
Daarom zegt rapture ook niet dat in iedere situatie "Als het maar werkt" goed is. Ik heb in één bedrijf verschillende soorten projecten meegemaakt die qua uitvoer van academisch tot "Als het maar werkt" gingen, en het bedrijf bestaat nog steeds Je moet weten wanneer je waarvoor kiest. Ik heb net een draak van een query geschreven die 3m00 uitvoertijd heeft, terwijl dat echt tien keer zo snel kan. Maar na vanmiddag ga ik die query weggooien. Gevalletje "Als het maar werkt" dus

En verder: wat je zegt is helemaal waar, maar de baas betaalt de rekening, en die denkt vaak in wat kortere termijn ...

En dat zal je altijd houden. Er zullen altijd bedrijven zijn die goedkopere "prutsprogrammeurs" in zullen huren en slechtere producten zullen opleveren. Er is simpelweg vraag hiervoor

[Hydra]

Dutchmega schreef op woensdag 17 december 2008 @ 15:01:
En dat zal je altijd houden. Er zullen altijd bedrijven zijn die goedkopere "prutsprogrammeurs" in zullen huren en slechtere producten zullen opleveren. Er is simpelweg vraag hiervoor

Yup. Grote integrators zetten vaak eerst de junior 'consultants' weg, en pas als er echt grote issues zijn wordt er een keer een senior meegestuurd.

En wat ebtreft de 'vraag': er is geen klant die zit te wachten op gepruts. Helaas komen ze d'r pas achter dat ze eigenlijk gewoon gronding genaaid zijn als de deadlines nog maar een paar weken weg zijn en er al een hoop geld geinvesteerd is.

[justmental]

^^^ met Creepy
Het belangrijkste is nog de communicatie. Er moet gerealiseerd worden wat de klant echt nodig heeft.

Vwb. java: dat zie ik liever niet omdat er in mijn ervaring te hoog niveau programmeurs voor nodig zijn om daar redelijk bug-arm mee te werken.