Kan iedereen leren programmeren?

[RayNbow]

.oisyn schreef op donderdag 10 april 2014 @ 22:33:
[...]

Die wetenschapper is dan ook geen programmeur van beroep

Maar doet het nou ook niet echt voor z'n hobby.

[Grompie]

Ik zou ook eerst geneigd zijn ja te zeggen maar als ik een beetje rondkijk besef ik ook wel van niet. Ik ken hoop mensen die erg slim zijn en vele malen hogere studies gedaan hebben dan ik maar als je ze zou moeten leren programmeren denk ik dat je er een vette kluif aan zou hebben.
Het hangt ook meestal een stuk samen met wiskunde hierin is er ook een groot stuk logica in weggelegd en mensen die snel wiskunde oppikken zullen dan ook sneller logica oppikken en daar draait programmeren voor een groot stuk rond.
Er is idd een klik moment wanneer je voor het eerst leert programmeren maar dit is pas in het hele begin eenmaal je daar over bent zie je pas dat je slechts een glas water hebt overzwommen en er nog een hele oceaan voor je ligt.

[Anoniem: 428693]

Ik denk vooral dat je goed moet stilstaan bij wat je met je studie gaat doen. Het doorlopen van je studie zal met voldoende inzet wel lukken, de vraag is of je hier ook gelukkig van gaat worden. Het niveau van studenten is verdeeld en een opleiding is vooral gemaakt op het gemiddelde niveau. Als jij hieronder zit, wat natuurlijk niet erg is, gaat alles je erg veel moeite kosten.

Ik ken een hoop mensen die desondanks doorgebikkeld hebben en nu inderdaad afgestudeerd zijn. Bijna allemaal heb ik ze compleet stuk zien gaan bij afstudeervakken. Als je altijd op je tenen moet lopen is er weinig lol aan. Een niveautje lager/andere richting was waarschijnlijk een betere oplossing geweest. Ook omdat ze na het afstuderen toch op werkplekken terecht komen die ze met een andere opleiding ook prima hadden kunnen bereiken.

Ik zou voor jezelf nagaan hoeveel tijd je werkelijk aan je studie besteed. Als dit ver boven het gemiddelde is en je komt dan nog steeds erg moeilijk overal doorheen dan toch afwegen of dit echt is wat je wil doen.

[NMe]

Fiber schreef op donderdag 10 april 2014 @ 22:44:
[...]

Het was vast geen ruim vijf jaar (van 50 weken x 40 uur) en jullie hadden vast meer vakken dan alleen programmeren en waarschijnlijk ook geen echt goede leraren...

Of misschien heeft het toch een beetje met talent en aanleg te maken?

[.oisyn]

Grompie schreef op vrijdag 11 april 2014 @ 08:38:
Het hangt ook meestal een stuk samen met wiskunde hierin is er ook een groot stuk logica in weggelegd en mensen die snel wiskunde oppikken zullen dan ook sneller logica oppikken en daar draait programmeren voor een groot stuk rond.

Dat is maar een deel, maar zoals ik eerder liet zien kun je daar heel goed in zijn en toch de meer basale dingen van het alledaags programmeren niet op kunnen pikken.

[NMe]

.oisyn schreef op vrijdag 11 april 2014 @ 11:41:
[...]

Dat is maar een deel, maar zoals ik eerder liet zien kun je daar heel goed in zijn en toch de meer basale dingen van het alledaags programmeren niet op kunnen pikken.

Ook andersom trouwens. Iemand die goed is in programmeren is niet per se een wiskundig genie. Ik merk in mijn eigen omgeving vaak dat mensen denken dat ik de hele dag rekensommetjes zit te maken, maar de hele grap van programmeren is juist dat je de computer dat voor je laat doen.

[.oisyn]

Uiteraard, de case waar ik het over heb komt relatief veel minder voor, maar hij bestaat weldegelijk.

[ Voor 17% gewijzigd door .oisyn op 11-04-2014 11:57 ]

[Hydra]

NMe schreef op vrijdag 11 april 2014 @ 11:51:
Ook andersom trouwens. Iemand die goed is in programmeren is niet per se een wiskundig genie. Ik merk in mijn eigen omgeving vaak dat mensen denken dat ik de hele dag rekensommetjes zit te maken, maar de hele grap van programmeren is juist dat je de computer dat voor je laat doen.

Het ligt ook aan wat voor'n programmeerwerk je precies doet. Het gaat niet eens zozeer om wiskunde zelf, als het 'zien' van het resultaat van een wiskundige functie. Ik ben erg visueel ingesteld en had op de middelbare geen problemen met Meetkunde. Algebra daarentegen was helemaal mijn ding niet. Dat zie ik ook terug in mijn HIO studie: alle programmeervakken gingen super goed, vertalerbouw en statistiek was weer mijn ding helemaal niet.

Als ik in mijn werk met data aan de slag moet; super. Ga ik proberen een shader te maken dan loop ik vrij snel aardig vast; op een of andere manier ligt het me helemaal niet. Kennelijk hebben m'n hersentjes een soort complexiteitslimiet. Wat niet helpt is dat ik erg ongeduldig ben

[.oisyn]

Hydra schreef op vrijdag 11 april 2014 @ 12:12:
Wat niet helpt is dat ik erg ongeduldig ben

Maar dat is het fundamentele bestaansrecht van de automatisering

[MrMonkE]

Hydra schreef op vrijdag 11 april 2014 @ 12:12:
Ga ik proberen een shader te maken dan loop ik vrij snel aardig vast; op een of andere manier ligt het me helemaal niet. Kennelijk hebben m'n hersentjes een soort complexiteitslimiet.

Ja, alle hersenen hebben limieten

[Hydra]

MrMonkE schreef op vrijdag 11 april 2014 @ 14:47:

Ja, alle hersenen hebben limieten

Ja, wel balen want als me iets leuk lijkt is gewoon eens een keer een leuk 3D webgl spelletje afmaken. Maarja

[NMe]

Hydra schreef op vrijdag 11 april 2014 @ 14:53:
[...]

Ja, wel balen want als me iets leuk lijkt is gewoon eens een keer een leuk 3D webgl spelletje afmaken. Maarja

Offtopic hier natuurlijk, maar tot op zekere hoogte los je dat op met een bestaand framework of engine. Zal geen technisch hoogstandje worden maar als het je leuk lijkt om te doen kun je natuurlijk om je eigen kennisgat heen werken.

[Hydra]

NMe schreef op vrijdag 11 april 2014 @ 15:07:
Offtopic hier natuurlijk, maar tot op zekere hoogte los je dat op met een bestaand framework of engine. Zal geen technisch hoogstandje worden maar als het je leuk lijkt om te doen kun je natuurlijk om je eigen kennisgat heen werken.

Je hebt verschillende niveau's van frameworks. Ik ben bijvoorbeeld bezig met ThreeJS die een hoop voor je doet, maar dan nog moet je wel het e.e.a. van shaders snappen. Of nouja, best een hoop. Met iets als Unity aan de slag gaan trekt me aan de andere kant weer niet.

[NMe]

Hydra schreef op vrijdag 11 april 2014 @ 15:15:
[...]

Je hebt verschillende niveau's van frameworks. Ik ben bijvoorbeeld bezig met ThreeJS die een hoop voor je doet, maar dan nog moet je wel het e.e.a. van shaders snappen. Of nouja, best een hoop. Met iets als Unity aan de slag gaan trekt me aan de andere kant weer niet.

Ik doelde inderdaad op iets als Unity/XNA maar als dat wat lagere niveau je niet trekt houdt het inderdaad een beetje op.

[Xalephsis]

Samengevat komt het er gewoon op neer: ja iedereen kan wel leren "scripten" m.a.w. wat aanmodderen, vaak testen en fouten maken, maar uiteindelijk wel een resultaat bereiken, maar kan lang niet iedereen "programmeren".

Met programmeren wordt hier meer software engineering bedoeld. Het meedenken en uitwerken van concepten, ideeen en dit vertalen ( al dan niet d.m.v. UML of andere schema`s ) en snel kunnen wisselen van omgeving.

Met omgeving wordt dan vaak bedoeld een programmeertaal + tools of bijvoorbeeld dat je een ander project voorgeschoteld krijgt en daar in een keer mee bezig kan/moet.

Een software engineer denkt namelijk erg abstract en linear. De term logica is al vaker voorgekomen, maar daar is waar een software engineer in uitblinkt. Daarnaast zal een software engineer problemen oplossen bij de kern en zal een scripter een omweg zoeken.

Het grote verschil is ook dat een software engineer het zo elegant mogelijk wil oplossen ( minder regels code = beter ) omdat het minder debugging kost, minder tijd voor andere engineers/programmeurs kost om in te lezen en je compilatie / intepretatie korter zal zijn. M.a.w. de engineer lost niet alleen een probleem op, hij minimaliseert ook direct risico`s die in de toekomst kunnen optreden.

TL;DR
Iedereen kan leren scripten, lang niet iedereen kan programmeren ( software engineering )

En dan nog iets, niemand zal ooit een alleskunner zijn, je hebt mensen met aanleg voor het programmeren, die zullen e.e.a. vast en zeker sneller oppakken dan anderen maar je moet niet vergeten dat jij ook kwaliteiten hebt die jij veel sneller oppakt dan de programmeertalenten. Het belangrijkste is jou motivatie bij je opleiding, als jij intrinsiek gemotiveerd bent, dan haal je het 100%. Daar heeft zo`n 10,000 uren regel niets mee te maken, of het wel/slecht kunnen programmeren.

[RayNbow]

Xalephsis schreef op vrijdag 11 april 2014 @ 18:56:
Een software engineer denkt namelijk erg abstract en linear.

Wat verstaan we onder linear denken?

[Xalephsis]

Slecht omschreven inderdaad, ik bedoel met linear denken hetzelfde als oplossingsgericht denken. Zonder direct allerlei andere casuale omstandigheden mee te nemen in een oplossing. M.a.w. het probleem herkennen en hiervoor een oplossing zoeken.

[sypie]

Rechtlijnig bedoel je. Dat is iets anders dan lineair. (lineair is meestal in een omhooggaande lijn, of wanneer je achteruit gaat een neergaande lijn)

[bwerg]

Xalephsis schreef op vrijdag 11 april 2014 @ 18:56:
Het grote verschil is ook dat een software engineer het zo elegant mogelijk wil oplossen ( minder regels code = beter ) omdat het minder debugging kost, minder tijd voor andere engineers/programmeurs kost om in te lezen en je compilatie / intepretatie korter zal zijn. M.a.w. de engineer lost niet alleen een probleem op, hij minimaliseert ook direct risico`s die in de toekomst kunnen optreden.

Met "minder regels code = beter" geef je slechts een ongenuanceerd voorbeeldje, en bedoel je alleen gevallen waarbij het verkorten niet inlevert op andere kwaliteitsfactoren, neem ik aan? Als je de leesbaarheid vergroot met een extra regel code lijkt me dat helemaal niet verkeerd.

Ik ken wel wat lolbroeken die heel trots zijn op hun korte code, terwijl alle namen in het programma uit één letter bestaan. Dat is géén vooruitgang.

[Xalephsis]

Haha ik ken ze ook, en nee dat is absoluut geen vooruitgang, al ligt het ook aan de situatie en wat de technische ontwerpen beschrijven.

Met korte code bedoel ik zo weinig mogelijk functies/methodes aanroepen om het gewenste resultaat te bereiken. Ja, het kan heel mooi met super-de-luxe String classes en allerlei string bewerkingen, terwijl een simpel const char[] vaak al voldoet. Hierdoor heb je geen dependencies op je mooie String class en blijft het lekker kort, dit leest makkelijker en sneller en omdat er minder code is, valt er ook minder te debuggen.

[Anoniem: 350934]

Anoniem: 428693 schreef op vrijdag 11 april 2014 @ 11:18:
Ik ken een hoop mensen die desondanks doorgebikkeld hebben en nu inderdaad afgestudeerd zijn. Bijna allemaal heb ik ze compleet stuk zien gaan bij afstudeervakken. Als je altijd op je tenen moet lopen is er weinig lol aan. Een niveautje lager/andere richting was waarschijnlijk een betere oplossing geweest. Ook omdat ze na het afstuderen toch op werkplekken terecht komen die ze met een andere opleiding ook prima hadden kunnen bereiken.

Ik zou voor jezelf nagaan hoeveel tijd je werkelijk aan je studie besteed. Als dit ver boven het gemiddelde is en je komt dan nog steeds erg moeilijk overal doorheen dan toch afwegen of dit echt is wat je wil doen.

Eén theorievak bedraagt ongeveer 60-70 uren aan studielast. Ik heb wel een achterstandje opgelopen in het tweede blok, maar die heb ik inmiddels alweer zo goed als weggepoetst. Met programmeren ben ik nog niet zo heel lang serieus thuis bezig (o.a. ook door laksheid en gemakszucht), maar ik probeer sinds anderhalve maand elke dag wel even te programmeren. Ik weet gewoon niet heel goed welke kant het op gaat lopen. Ga ik die klik wel of niet krijgen en is het wijs om daar maar op te gokken? Trek ik aan het verkeerde eind, dan verlies ik tijd en geld. Die zaken spelen heel erg door mijn hoofd op dit moment. Ik vind de opleiding leuk, programmeren leuk, maar ik wil later inderdaad niet op mijn teentjes moeten lopen om alles maar bij te houden.

Xalephsis schreef op vrijdag 11 april 2014 @ 18:56:
En dan nog iets, niemand zal ooit een alleskunner zijn, je hebt mensen met aanleg voor het programmeren, die zullen e.e.a. vast en zeker sneller oppakken dan anderen maar je moet niet vergeten dat jij ook kwaliteiten hebt die jij veel sneller oppakt dan de programmeertalenten. Het belangrijkste is jou motivatie bij je opleiding, als jij intrinsiek gemotiveerd bent, dan haal je het 100%. Daar heeft zo`n 10,000 uren regel niets mee te maken, of het wel/slecht kunnen programmeren.

Tuurlijk, daar heb je helemaal gelijk in. Mede door dit topic, waar de consensus toch wel een beetje is dat aanleg en talent een (belangrijke) rol spelen, ben ik echter wel heel erg aan het twijfelen geslagen. Waar ik voorheen nog dacht 'dat gaat wel goed komen, komt vanzelf', denk ik nu van '.... ja, of toch niet'.

Vandaag had ik toevallig een tentamen informatica (komende maandag heb ik er weer eentje) en ik heb er weer eens de grootste moeite mee gehad. Programmeren met toegang tot internet en boeken lukt me wel, maar in anderhalf uur meerdere programma's schrijven uit je hoofd, daar heb ik behoorlijk veel moeite mee. Volgens mij zit ik qua ontleding van problemen wel redelijk op de goede weg, maar aan de vertaling naar code schort het 'm nog een beetje. Eén van de opdrachten was bijvoorbeeld om uit een aminozuur bepaalde zijketens te vissen en het percentage (met twee cijfers achter de komma) van elk opgegeven aminozuur in die hele sequentie te bepalen. Ik zal de opdracht even wat simplistisch opschrijven:

Opdracht:
Bepaal voor H, G, S en W het percentage van voorkomen in de hele sequentie

aminozuurbestandje
>aminozuur naam
GGHGHERYREGSDGWWGSGWDSASAFSSDGSDG (als voorbeeld even wat random letters)

Wat ik als eerste heb gedaan is de hele opdracht ontleden in allemaal deelstappen:

1. Bestand inlezen.
2. De header (beginnend met '>' weghalen), die is in deze immers niet belangrijk.
3. De lengte van de hele sequentie bepalen.
4. Een tellertje maken voor H, G, S en W en elke keer als de for loop deze tegenkomt, er 1 bij optellen.
5. Met de totale lengte van de hele sequentie en het aantal H's, G's, S's en W's kun je het percentage per letter berekenen en printen.

De code zelf heb ik niet volledig werkend gekregen, maar voor ontleding van het probleem zijn gelukkig ook punten te verdienen.

[Rmg]

Anoniem: 350934 schreef op vrijdag 11 april 2014 @ 20:40:
[...]
Programmeren met toegang tot internet en boeken lukt me wel, maar in anderhalf uur meerdere programma's schrijven uit je hoofd, daar heb ik behoorlijk veel moeite mee.

Dat moet ook je doel niet zijn, geen enkele programmeur doet dat echt, Ik heb ook op mijn werk altijd wel een reference site als: http://www.tutorialspoint...rary/c_function_fread.htm open, bij anderen staat er altijd wel MSDN, Java doc api open of stackoverflow open.

Overal liggen ook boeken over design patterns / OO programmeren / DDT

En het boek van Kernighan & Ritchie ligt hier ook overal als naslag werk.

Ja een for loopje e.d. moet gewoon uit het hoofd kunnen, maar in een professionele omgeving ligt een naslagwerk altijd binnen handbereik.

[RayNbow]

Anoniem: 350934 schreef op vrijdag 11 april 2014 @ 20:40:
Opdracht:
Bepaal voor H, G, S en W het percentage van voorkomen in de hele sequentie

Voor die opdracht is het volgende een belangrijke bouwsteen: weten wat een dict is. Hiermee kun je redelijk gemakkelijk de volgende hulpfunctie schrijven:

Python:

def compute_frequency(string):
    frequency_table = {}
    for char in string:
        frequency_table[char] = frequency_table.get(char, 0) + 1
    
    return frequency_table

[Anoniem: 350934]

Rmg schreef op vrijdag 11 april 2014 @ 20:54:
[...]
Dat moet ook je doel niet zijn, geen enkele programmeur doet dat echt, Ik heb ook op mijn werk altijd wel een reference site als: http://www.tutorialspoint...rary/c_function_fread.htm open, bij anderen staat er altijd wel MSDN, Java doc api open of stackoverflow open.

Ja, precies. Daarom ben ik ook niet echt te spreken over de manier waarop informatica getoets wordt. Informatica 1 bestond bij ons uit print, lists, dicts, tuples, if statements, for-loops en indexen, maar het is in die beginfase juist belangrijk dat je leert om een casus te ontleden, zodat je je niet blind staart op het totaalplaatje. Een opdracht waarbij je bijvoorbeeld een flowschema maakt van alledaagse actie, zoals het inschenken van een glaasje ranja of whatever, laat je toch net even wat dieper nadenken over een ogenschijnlijk eenvoudige actie. Daarnaast leer je ook details in kaart te brengen (het dopje moet er op en af, de fles moet ook weer terug in de koelkast, et cetera). Naar mijn weten wordt er pas later in deze opleiding aandacht besteedt aan deze structuren/schema's, maar omdat je met de code meegroeit zou dat mijns inziens direct al moeten.

RayNbow schreef op vrijdag 11 april 2014 @ 20:58:
[...]

Voor die opdracht is het volgende een belangrijke bouwsteen: weten wat een dict is. Hiermee kun je redelijk gemakkelijk de volgende hulpfunctie schrijven:

Python:

def compute_frequency(string):
    frequency_table = {}
    for char in string:
        frequency_table[char] = frequency_table.get(char, 0) + 1
    
    return frequency_table

Dat gaat mij nog de pet te boven. Met dicts werken doen we overigens wel, maar ik zou hier nooit op gekomen zijn. Het is een stuk efficienter dan wat ik er van gemaakt heb in ieder geval. Het zet me wel aan het denken: moet ik stapje voor stapje toe gaan werken naar functies of moet ik direct beginnen met functies en van daaruit verder leren?

[Caelorum]

Anoniem: 350934 schreef op vrijdag 11 april 2014 @ 22:38:
[...]
Het zet me wel aan het denken: moet ik stapje voor stapje toe gaan werken naar functies of moet ik direct beginnen met functies en van daaruit verder leren?

Functies zijn geen magische dingen. Het wel of niet gebruiken is afgezien van leesbaarheid en onderhoudbaarheid niet zo van belang.

[MrMonkE]

[ ] geschikt
[ x ] niet geschikt

Ja, gelijk met functies. Het is wel degelijk heel belangerijk.
Zodat je niet 4x hetzelfde of bijna hetzelfde doet. Als je dingen hebt die gelijk zijn dan ga je die in functies onderbrengen.

Als een functie niet op je scherm past is hij te groot. (Leidraad, mag best wel eens groter zijn) en ook veel commentaar in je code zetten wat de code moet doen. Zeker als je afwijkende dingen doet.

[farlane]

Je bouwt eerst alles achter elkaar zodat het werkt, daarna zie je waar functies van te maken zijn en die refactor je er uit.

Met meer oefening kun je de voor de hand liggende functies tijdens de eerste fase er meteen al uit halen.

[Douweegbertje]

farlane schreef op zaterdag 12 april 2014 @ 01:04:
Je bouwt eerst alles achter elkaar zodat het werkt, daarna zie je waar functies van te maken zijn en die refactor je er uit.

Met meer oefening kun je de voor de hand liggende functies tijdens de eerste fase er meteen al uit halen.

Met als resultaat dat je 1 lap code hebt die werkt en waar je nooit meer naar om kijkt. Famous last words "ik refactor dit zo wel". Functies moeten juist slim zijn, en niet snippets code die je even erin zet om maar via een functie aan te roepen want dan mis je het punt.
Op jouw manier krijg je nooit goede functies. Een goede functie zou je niet eens kunnen maken op basis van een copy/paste uit je "lang achter elkaar geklopte code" zoals jij voorstelt. Tenzij je letterlijk heel het zootje om gaat gooien wat weer zoveel extra werk kost.

Persoonlijk vind ik functies wel erg belangrijk. Sterker nog het hele OOP / class gebeuren vind ik zeer belangrijk en mijn ervaring is dat nieuwere mensen dit totaal negeren wat resulteert in vrij slechte code.
Naar mijn mening kun je er dan ook niet vroeg genoeg mee beginnen, ook al zul je het niet direct op de juiste manier gaan gebruiken. Daarbij geeft het ook nog een vorm van overzicht en wat meer duidelijkheid, wat altijd handig is als je nog niet alles onder de knie hebt.

[ Voor 26% gewijzigd door Douweegbertje op 12-04-2014 01:15 ]

[NMe]

farlane schreef op zaterdag 12 april 2014 @ 01:04:
Je bouwt eerst alles achter elkaar zodat het werkt, daarna zie je waar functies van te maken zijn en die refactor je er uit.

Met meer oefening kun je de voor de hand liggende functies tijdens de eerste fase er meteen al uit halen.

Tijdens het leerproces zul je inderdaad zo te werk gaan maar als je wat meer ervaren bent gaat het uiteindelijk toch vooral automatisch. Niet alleen de meest voor de hand liggende functies schrijf je dan vanzelf, maar alle functies. Dat neemt niet weg dat je bij voortschrijdend inzicht later alsnog zou kunnen of moeten refactoren, maar ik kan me niet herinneren dat ik in de laatste 10 jaar nog een grote lap code heb geschreven waarvan ik pas na meer dan 5 minuten doorhad dat ik 'm beter kon uitsplitsen naar losse functies. Waar het wél regelmatig bij voorkomt is tijdens het refactoren: een kort stukje code dat je al had moet worden uitgebreid waardoor het handig is omdat hele stuk code te verplaatsen naar een functie.

[Caelorum]

Wat NMe dus zegt. Er wordt gevraagd of hij/zij nu wel of niet moet *beginnen* met functies en dat geeft IMO het niveau al aan. Op dat niveau waar je nog moeite hebt een eenvoudig vraagstuk op te lossen in werkende code is het echt nog niet zo van belang dat je al functies gebruikt. Dat zou de stap daarna zijn. Zorg maar eerst dat je zo'n vraagstuk überhaupt kan oplossen. Daarna kan je kijken naar het herbruikbaar maken van delen van die code door middel van zinnige functies.

[Gomez12]

Anoniem: 350934 schreef op vrijdag 11 april 2014 @ 22:38:
[...]
Dat gaat mij nog de pet te boven. Met dicts werken doen we overigens wel, maar ik zou hier nooit op gekomen zijn. Het is een stuk efficienter dan wat ik er van gemaakt heb in ieder geval. Het zet me wel aan het denken: moet ik stapje voor stapje toe gaan werken naar functies of moet ik direct beginnen met functies en van daaruit verder leren?

Wat gaat je de pet te boven? In wezen is het gewoon jouw stap 4 alleen dan met een dict met tellertjes erin ipv allemaal losse tellertjes...

Dit zijn nou echt van die dingen waarbij ik zoiets heb : De code kan verschillen, maar jouw bedachte oplossing is in lekentaal gelijk.
En het gaat om de bedachte oplossing, de code is puur afhankelijk van de taal.

En qua of je met functies moet beginnen of niet, instinctief verdeel je het al in meerdere stappen. Die stappen zouden een goed beginpunt kunnen zijn om functies te maken, dus opzich vind ik je aanpak wel op de goede weg

[ Voor 17% gewijzigd door Gomez12 op 12-04-2014 09:22 ]

[Onbekend]

Anoniem: 350934 schreef op donderdag 10 april 2014 @ 01:53:
Lang verhaal kort: kan iedereen (met de nodige toewijding en motivatie) leren programmeren of is daar een bepaalde logica voor nodig waar je gezegend mee moet zijn?

Kort gezegt: Ja.
Iedereen kan alles leren, maar soms kost dit erg veel tijd. Alleen als je het programmeren zelf compleet niet begrijpt, moet je je afvragen of dat wel voor jou is weggelegd. Na een paar maanden proberen en experimenteren met je toch zeker de for-loop, while-loop en if-statements begrijpen.
Maar als je wel de basis van programmeren begrijpt, namelijk het opdelen van 1 groot probleem, naar meerdere sub-problemen. En elk sub-probleem kunnen vertalen naar code, dan ben je al zeer goed op weg.

Verder maakt iedereen die programmeert foutjes, dus dat is niet erg. Als je daarna ook nog de fouten weet op te lossen, kan je zeker de kunst van het programmeren leren.
Het is handig als je de basis van wiskunde en natuurkunde begrijpt en een beetje logisch kunt nadenken. Ook komt het vaak aan op ervaring van eerdere projecten. Je leert namelijk elke keer weer wat bij waardoor je het volgende stukje code weer sneller en/of beter kunt maken.

[Haas_nl]

Ik heb action script in flash geleerd uit mezelf, en wat cnc en robot programma's.
Maar iemand die niet in staat is om lange tijd te concentreren op saaie teksten is niet in staat om te leren programmeren.
En in mijn ogen zijn dat heeeeeeeeel veel mensen.

[Caelorum]

Wat is er nou saai aan code? Het is niet alsof je een of andere droge tekst over een of ander stoffig onderwerp aan het lezen bent...

[Gomez12]

Haas_nl schreef op zaterdag 12 april 2014 @ 10:40:
Maar iemand die niet in staat is om lange tijd te concentreren op saaie teksten is niet in staat om te leren programmeren.
En in mijn ogen zijn dat heeeeeeeeel veel mensen.

Je kan ertegenaan kijken als concentreren op saaie teksten of je kan kijken naar doelgericht programmeren (definieer gewoon 85 tussendoelen zodat je elke keer weer progressie ziet en steeds een stukje verder komt)

Het saaie teksten gedeelte heb ik enkel bij uitgebreide algoritmes, voor de rest deel ik het gewoon zo in dat ik elke dag aan het einde van de dag kan zeggen : Dit heb ik vandaag bereikt, zodat ik iets heb om op korte termijn (1 of 2 dagen) naar toe te werken.

Dus jouw punt vind ik meer een stukje zelfkennis / planning. In principe valt bijna alles wel op te delen naar tussentijdse doelen (en gelijk testpunten).

Niets is idd zo saai als 3 weken blind coden (zonder meetpunten) en daarna nog 3 weken te gaan debuggen / refactoren omdat je in de basis iets fout hebt gedaan en het een doorwerkende fout is geworden

[martin_v_z]

NMe schreef op donderdag 10 april 2014 @ 22:35:
[...]

Alleen als die 10k uur kloppen. Ik heb op school gezeten met mensen die op de eerste dag al briljante programmeurs waren en met mensen die zelfs bij hun afstuderen nog geen letter code konden schrijven...

Sorry voor de extreem late reactie. Maar die 10.000 uur moet je lezen als in echt goed zijn in een bepaalde vaardigheid. Dat betekend niet dat je 10.000 uur nodig hebt om een beetje te kunnen programmeren. Zie het meer als dit: In het begin ben je student, dan junior, daarna pas volwaardige programmeur. Dit traject kost veel tijd. Dat sommige mensen op school al bij de eerste dag vrij goed kunnen programmeren komt meestal omdat ze al zelf tijd hebben gestopt in het leren, dat kan ongemerkt al heel veel uur zijn in hun tienertijd. Zo ben ik zelf ook begonnen, maar als ik nu terug kijk naar de kennis die ik had toen ik begon als fulltime programmeur en nu dan zit daar wel een groot verschil in. Terwijl ik toen ook wel kon "programmeren" maar ik heb nog enorm veel geleerd in de jaren daarna.

[Gomez12]

@martin_v_z : maar juist bij programmeren (/digitale kunsten) gaat die 10.000 uur regel heel erg slecht op. Want na 2000 uur is er een nieuwe versie van de programmeertaal of er wordt overgestapt op een andere programmeertaal of ... of ... En dan kan je spontaan je al bestede uren door de helft delen (het is niet totaal nutteloos, maar het is ook niet totaal bruikbaar)

Qua realiteit betekent die 10.000 uur enkel goed zijn in een bepaalde vaardigheid (qua digitaal : in een bepaalde versie) in een bepaald paradigma. Een huizenbouwer die enkel rijtjeshuizen bouwt die kan niet na 10.000 uur opeens paleizen bouwen (ook al zijn dat ook huizen)

[Xalephsis]

Sorry maar daar ben ik het niet mee eens Gomez. Alles waar je tijd in steekt, levert nieuwe inzichten op. Of het nu later vervangen wordt of niet.

Bovendien ben ik tegen de 10,000 uren regel. Nergens is bewezen dat wanneer je ergens 10,000 uur insteekt, je hierdoor een expert wordt. Er is onderzoek gedaan naar deze regel en daaruit bleek dat een schamele 33% te wijden is aan tijd. Aanleg, talent en andere zaken spelen een veel grotere rol.

Over het vaardigheid verhaal, als jij je hele leven rijtjeshuizen bouwt, doe jij ervaring op in bouwen, niet architectuur en/of het ontwerpen. Een paleis bouwen komt op precies hetzelfde neer, je krijgt bouwtekeningen, lijsten met materialen die nodig zijn, welke combinaties van materialen nodig zijn voor cement, fundering etc. Toegegeven, het zal relatief gezien wellicht wat langer duren om een paleis te bouwen, maar dat gaat je echt wel lukken dan.

Over functies, begin er zo snel mogelijk mee. Naast functies zou ik ook direct proberen in te zien wat scope betekent en waarom dit belangrijk is. Wat het verschil is tussen functie scope en class scope en allerlei andere scopes. Hoe dit werkt en hoe je dit kunt omzeilen d.m.v. references en/of pointers en waarom je dit juist wel of niet wil doen.

Trouwens, ik had zelf vroeger ook altijd moeite met deze concepten hoor, toen ik begon met programmeren. Niet zozeer functies als wel het concept van de "array." Terugkijkend daarop lach ik er nu om, maar sommige kwartjes duren nu eenmaal wat langer voor ze vallen.

Ik ben van mening dat de aanhouder wint, en nogmaals, doorzetten is key. Niemand kan out-of-the-box direct goed programmeren, het kost tijd, zelfs als je interesse niet ligt in programmeren, kun je nog steeds ontzettend veel leren over het biologische aspect.

Trouwens, iets wat ik toevallig aan het lezen ben is http://natureofcode.com/book/ hier staat van alles in over natuurlijke simulaties, bewegingen in de natuur, kudde gedrag etc en hoe je dit kunt programmeren aan de hand van handige algoritmes, de source is ook beschikbaar ( helaas, alleen processing ) maar dat is niet zo`n ramp. Ik vond het wel een goed boek, mede ook omdat ik momenteel deze simulaties moet programmeren.

[farlane]

Douweegbertje schreef op zaterdag 12 april 2014 @ 01:10:
Met als resultaat dat je 1 lap code hebt die werkt en waar je nooit meer naar om kijkt. Famous last words "ik refactor dit zo wel"

Bollox, het hoort bij het proces. Zeker als je begint met programmeren kun je niet werken op de manier die jij schetst want je hebt nog geen flauw idee hoe het in zijn werk gaat. Jij maakt mij niet wijs dat jij alle functies die je gaat bouwen van tevoren in kaart brengt, en als als dat wel zo is ben je hopeloos lang bezig met nadenken voordat je laat zien dat het ook echt gaat werken wat je van plan bent te bouwen.

De functies die je vooraf "vastlegt" zijn de externe interfaces, en ook die zijn vaak aan aan verandering onderhevig.

NMe schreef op zaterdag 12 april 2014 @ 01:57:
Tijdens het leerproces zul je inderdaad zo te werk gaan maar als je wat meer ervaren bent gaat het uiteindelijk toch vooral automatisch. Niet alleen de meest voor de hand liggende functies schrijf je dan vanzelf, maar alle functies. Dat neemt niet weg dat je bij voortschrijdend inzicht later alsnog zou kunnen of moeten refactoren, maar ik kan me niet herinneren dat ik in de laatste 10 jaar nog een grote lap code heb geschreven waarvan ik pas na meer dan 5 minuten doorhad dat ik 'm beter kon uitsplitsen naar losse functies. Waar het wél regelmatig bij voorkomt is tijdens het refactoren: een kort stukje code dat je al had moet worden uitgebreid waardoor het handig is omdat hele stuk code te verplaatsen naar een functie.

Dat is waar je uitkomt met veel oefening/ervaring, en exact wat ik beschrijf. En je geeft al aan dat je zelfs als je veel ervaring hebt door voortschrijdend inzicht later de structuur gaat aanpassen.

[ Voor 39% gewijzigd door farlane op 12-04-2014 20:20 ]

[NMe]

farlane schreef op zaterdag 12 april 2014 @ 20:15:
[...]

Dat is waar je uitkomt met veel oefening/ervaring, en exact wat ik beschrijf.

Jouw post leek, hoewel ik wéét dat je dat niet op die manier bedoelde, te impliceren dat je ook nadat je al wat ervaring opgedaan hebt nog een groot deel van de functies niet direct uit je mouw schudt. Het punt dat ik wilde maken is dat je als programmeur naar een punt toe moet waarop je 99% van de tijd direct je code uitsplitst in duidelijk afzonderlijke brokken, oftewel functies (en classes/methods/etc). Dat je later door vooruitschrijdend inzicht of veranderde specs alsnog de functies herindeelt doet niet af aan het feit dat je voor de op dat moment geldende inzichten en specs altijd een net gecategoriseerd systeem kan schrijven.

In short: wat ik wilde voorkomen is dat de topicstarter jouw post zou interpreteren als "wanneer ik meer functies direct uit mijn mouw schud dan dat ik later nog uitsplits zonder nieuwe inzichten/specs zit ik goed." Je zit dan inderdaad op de goeie weg maar kan op dat punt nog altijd meer leren.

En je geeft al aan dat je zelfs als je veel ervaring hebt door voortschrijdend inzicht later de structuur gaat aanpassen.

Klopt, maar er is een verschil tussen je code herschrijven waardoor er dán ineens noodzaak is voor een functie en missen dat een bepaald stuk code dat er al staat beter een functie had kunnen zijn. Dat eerste gebeurt behoorlijk vaak, dat laatste gebeurt bij ervaren programmeurs beduidend minder.

Een goeie manier om te voorkomen dat je dingen niet goed uitsplitst is door omgekeerd te werken. Je zou kunnen overwegen om niet eerst de functie of class te schrijven die je nodig hebt, maar eerst de code die daadwerkelijk gebruik gaat maken van die functie of class. Je definiëert dan de interface en hebt alles dus al uitgesplitst nog voordat je een letter code voor de benodigde functionaliteit zelf op je scherm hebt staan.

[MrMonkE]

@OP: Dit wat voor je?
https://www.kickstarter.c...for-young-kids?ref=footer

[HuHu]

Haas_nl schreef op zaterdag 12 april 2014 @ 10:40:
Ik heb action script in flash geleerd uit mezelf, en wat cnc en robot programma's.
Maar iemand die niet in staat is om lange tijd te concentreren op saaie teksten is niet in staat om te leren programmeren.
En in mijn ogen zijn dat heeeeeeeeel veel mensen.

Voor welke (universitaire) opleiding geldt niet dat je je moet kunnen concentreren op lange, saaie teksten? Dat is niet echt een onderscheidende eigenschap.

[Caelorum]

HuHu schreef op zondag 13 april 2014 @ 12:47:
[...]
Voor welke (universitaire) opleiding geldt niet dat je je moet kunnen concentreren op lange, saaie teksten? Dat is niet echt een onderscheidende eigenschap.

Mja, als je de goede studie kiest met een boeiend onderwerp valt het bijzonder mee

[Lethalis]

Hydra schreef op vrijdag 11 april 2014 @ 12:12:
[...]
Het ligt ook aan wat voor'n programmeerwerk je precies doet. Het gaat niet eens zozeer om wiskunde zelf, als het 'zien' van het resultaat van een wiskundige functie. Ik ben erg visueel ingesteld en had op de middelbare geen problemen met Meetkunde. Algebra daarentegen was helemaal mijn ding niet. Dat zie ik ook terug in mijn HIO studie: alle programmeervakken gingen super goed, vertalerbouw en statistiek was weer mijn ding helemaal niet.

Als ik in mijn werk met data aan de slag moet; super. Ga ik proberen een shader te maken dan loop ik vrij snel aardig vast; op een of andere manier ligt het me helemaal niet. Kennelijk hebben m'n hersentjes een soort complexiteitslimiet. Wat niet helpt is dat ik erg ongeduldig ben

Ik denk sowieso wel dat wiskundig inzicht erg kan helpen. Wat dat betreft had ik een streepje voor, want ik was berucht op de middelbare school om mijn wiskunde B en stond een 9 gemiddeld tot en met het eindexamen.

Statistiek lag mij overigens ook niet, maar dat is meer wiskunde A.

Ik herken wel je verhaal van vastlopen, omdat ik zelf dus ook heel erg ongeduldig ben Soms helpt het gewoon om rustig te gaan zitten en dingen uit te schrijven / tekenen. Niet teveel in 1 keer willen.

Laatst heb ik nog een stuk code geschreven dat VBScript vertaalt naar PowerShell. Toen moest ik ook eerst netjes de stappen door van een (bestaande) tokenizer gebruiken en daarna pas zelf een vertaalslag doen. Maar in eerste instantie wou ik alles zo snel mogelijk zelf doen en dat ging uiteraard niet goed

Maar dat soort dingen vind ik wel stoer om te doen. Onze software op de zaak is door mijn toedoen niet meer afhankelijk van VBScript en zit dus ook niet meer vast aan een oud 32 bit script control. Ik heb nu een class waar je VBScript tegen kan praten die er intern PowerShell van maakt en het goede antwoord terug geeft

(we gebruiken het voor formules in een eigen reporting module en het zou een enorme crime zijn om alle formules bij klanten om te zetten, dus we hadden iets nodig dat nog steeds VBScript ondersteunt)

[ Voor 3% gewijzigd door Lethalis op 14-04-2014 10:28 ]

[NMe]

Lethalis schreef op maandag 14 april 2014 @ 10:22:
[...]

Ik denk sowieso wel dat wiskundig inzicht erg kan helpen. Wat dat betreft had ik een streepje voor, want ik was berucht op de middelbare school om mijn wiskunde B en stond een 9 gemiddeld tot en met het eindexamen.

Ik denk dat het compleet losstaat van elkaar. Wat betreft probleemoplossend vermogen komen de twee misschien overeen, maar wiskunde en informatica zijn allang niet meer zo synoniem als ze vroeger deels nog waren. Ik hoef doorgaans geen ingewikkeldere berekeningen te maken dan wat optelsommetjes en wat delingen om met name de styling van elementen netjes te maken.

[Haan]

Ik wil aan de discussie toevoegen dat het helemaal niet noodzakelijk hoeft te zijn om vaardigheid in wiskunde te hebben. Als ik naar mijn eigen situatie kijk, heb ik in de afgelopen 7 jaar als developer altijd aan business logica, datalaag, web frontend/back e.d. gewerkt, waarbij wiskunde (of natuurkunde) geen enkele rol speelt.

Het afgelopen jaar werk ik aan fiscale software, en ook daar gaat het zelden verder dan optellen/aftrekken, vermenigvuldigen/delen.

edit:
en dan komt Nme er even tussendoor met ongeveer dezelfde opmerking

[ Voor 8% gewijzigd door Haan op 14-04-2014 11:28 ]

[Onbekend]

Haan schreef op maandag 14 april 2014 @ 11:27:
Ik wil aan de discussie toevoegen dat het helemaal niet noodzakelijk hoeft te zijn om vaardigheid in wiskunde te hebben. Als ik naar mijn eigen situatie kijk, heb ik in de afgelopen 7 jaar als developer altijd aan business logica, datalaag, web frontend/back e.d. gewerkt, waarbij wiskunde (of natuurkunde) geen enkele rol speelt.

Het ligt ook misschien net aan wàt je ontwikkelt. Ik ben veelal betrokken bij het maken van basislagen waarbij transport, coderen en decoderen van data bij komt kijken, en daar is wiskunde (inclusief booleaanse algebra) wel erg handig. Andere programmeurs die uiteindelijk mijn basislagen gaan gebruiken hoeven inderdaad weinig wiskunde te gebruiken. Oftewel, wat ik in een eerdere post heb beschreven, het is niet per sé noodzakelijk maar wel handig.

[.oisyn]

NMe schreef op maandag 14 april 2014 @ 11:25:
Ik hoef doorgaans geen ingewikkeldere berekeningen te maken dan wat optelsommetjes en wat delingen om met name de styling van elementen netjes te maken.

Niet om het een of ander, maar wiskunde gaat veel verder dan alleen rekenen en algebra (waar iedereen aan denkt als het om wiskunde gaat). Algoritmiek en logica zijn ook gewoon onderdelen van de wiskunde.

[Lethalis]

Het ligt sowieso aan wat je ontwikkelt, maar losstaand daarvan vind ik ook dat het iets zegt over iemand zijn probleemoplossend vermogen, zoals NMe al voorzichtig opmerkt.

Sowieso is "programmeren" nogal een breed begrip.

Ik ben persoonlijk wat meer een backend developer dan frontend developer, en daar horen andere persoonlijke eigenschappen bij.

Ingewikkeld database / concurrency probleem? Een planningsalgoritme wat niet helemaal doet wat je ervan verwacht? Dan moet je bij mij zijn Wil je een mooie user interface dan kom ik zwaar in de problemen

Dan heb ik het nodig dat iemand anders die ontwerpt en dan kan ik hem daarna zelf wel implementeren. Dat is het nadeel van een beta persoon zijn. Goed in wiskunde en natuurkunde, maar zo creatief als een wc bril.

[ Voor 4% gewijzigd door Lethalis op 14-04-2014 13:13 ]

[NMe]

.oisyn schreef op maandag 14 april 2014 @ 13:07:
[...]

Niet om het een of ander, maar wiskunde gaat veel verder dan alleen rekenen en algebra (waar iedereen aan denkt als het om wiskunde gaat). Algoritmiek en logica zijn ook gewoon onderdelen van de wiskunde.

Klopt, maar de meeste scholen zullen dat bij wiskunde niet behandelen. Daarbij zijn het IMO andere denkwijzes. Logica en algoritmiek doe ik uit de losse pols, maar goniometrie wordt al moeilijker en algebra is ronduit niks voor mij. Ik herken datzelfde bij een paar andere programmeurs die ik ken.

Ik zal mijn opmerking wat bijstellen: handigheid in programmeren en handigheid in de wiskunde die op middelbare scholen gegeven wordt staan los van elkaar.

[Rmg]

Anoniem: 350934 schreef op vrijdag 11 april 2014 @ 22:38:
[...]

Dat gaat mij nog de pet te boven. Met dicts werken doen we overigens wel, maar ik zou hier nooit op gekomen zijn. Het is een stuk efficienter dan wat ik er van gemaakt heb in ieder geval. Het zet me wel aan het denken: moet ik stapje voor stapje toe gaan werken naar functies of moet ik direct beginnen met functies en van daaruit verder leren?

Waar loop je eigenlijk op vast? Het programmeren zelf of het bedenken van de 'logische' oplossing?

Je aminozuren opdrachtje bijvoorbeeld, je maakt wat aannames en keuzes die ik anders zou doen maar je oplossing is simpel en zou ook moeten werken (Even daargelaten of het een efficiënte of goeie oplossing is)

Het berekenen van percentages is ook gewoon basisschoolwerk, dus ik vat niet helemaal waar je dan vast loopt

[Lethalis]

NMe schreef op maandag 14 april 2014 @ 13:53:
[...]
Ik zal mijn opmerking wat bijstellen: handigheid in programmeren en handigheid in de wiskunde die op middelbare scholen gegeven wordt staan los van elkaar.

Toen ik net op de middelbare school kwam, had ik al meerdere screensavers geprogrammeerd. Daarbij was het belangrijk dat blokken bijvoorbeeld van richting veranderen als ze de rand van het scherm raken enzovoorts. Ook veranderde de snelheid afhankelijk van meerdere factoren.

Hiervoor had ik allerlei formules bedacht en toegepast. Ook vond ik het op die leeftijd (jaar of 12 / 13) hartstikke leuk om basic code te analyseren, bijvoorbeeld van Gorilla.bas en Nibbles.bas (good times ).

Toen ik eenmaal op school algebra kreeg, had ik even zo'n aha-moment nodig, maar daarna liep ik er doorheen alsof het niks was. En ik heb zelf toch het idee dat dit komt omdat ik zoveel programmeerde in mijn vrijetijd en daarvoor dus steeds al allerlei berekeningetjes maakte en abstract moest nadenken over dingen.

Overigens kon ik het ook niet laten om code te schrijven die zaken als een ABC formule gewoon voor mij oploste Huiswerk maken was op die manier wel erg makkelijk.. en zo rond mijn 16e hoefde ik dat ook niet meer te doen van de wiskunde docent en mocht ik tijdens de les bijvoorbeeld aan Handelswetenschappen of huiswerk voor Nederlands werken (2 vakken waar ik niet zo'n held in was en die tijd goed kon gebruiken).

Dus ik ben het niet helemaal eens met jou

Maar goed, ik ben dan misschien ook wel de enige middelbare scholier geweest die bij een parabool moest denken aan een vliegende banaan die door een gorilla werd geworpen

[ Voor 5% gewijzigd door Lethalis op 14-04-2014 14:32 ]

[NMe]

Lethalis schreef op maandag 14 april 2014 @ 14:23:
[...]

Toen ik net op de middelbare school kwam, had ik al meerdere screensavers geprogrammeerd. Daarbij was het belangrijk dat blokken bijvoorbeeld van richting veranderen als ze de rand van het scherm raken enzovoorts. Ook veranderde de snelheid afhankelijk van meerdere factoren.

Ik was niet anders hoor. Ik heb in groep 7 voor mijn leraar geen verjaardagskaart gemaakt maar een LOGO-programmaatje dat zijn leeftijd op een schoolbord tekende en daarna een felicitatieberichtje liet zien. Ik heb geklooid met batch, BASIC en zelfs een beetje geprogrammeerd op de Commodore 64 al raakte die net wat uit de tijd toen ik begon te programmeren. Ik maakte in de derde klas op de middelbare school games voor zowel de PC als de grafische rekenmachine.

Tóch is algebra evenals meetkunde e.d. niet echt aan mij besteed. Het ligt me gewoon niet, ongeacht hoe vaak ik het geprobeerd heb. Simpele berekeningetjes die ik nodig heb voor 2D-spellen zijn nog wel te doen, maar maak het ingewikkelder dan dat en ik kom nergens. Zoals ik al zei zie ik datzelfde bij een aantal andere programmeurs die ik ken. Het zal best kloppen dat je als je goed bent in het een vast ook goed bent in het ander, maar dat hoeft helemaal niet zo te zijn.

Dus ik ben het niet helemaal eens met jou

Dat jij toevallig in allebei goed bent wil niet zeggen dat er een causaal verband is.

[Lethalis]

NMe schreef op maandag 14 april 2014 @ 14:32:
[...]
Dat jij toevallig in allebei goed bent wil niet zeggen dat er een causaal verband is.

Toch is het meer dan n = 1 hoor. Meerdere klasgenootjes van toen die goed waren in wiskunde zijn inmiddels programmeur, consultant of software architect.

Zo'n redenering hoeft natuurlijk ook niet beide kanten op te gaan.

Misschien hoef je niet goed te zijn in wiskunde om te kunnen leren programmeren, maar helpt het wel (en dan staat het dus niet helemaal los van elkaar).

[ Voor 4% gewijzigd door Lethalis op 14-04-2014 14:41 ]

[RayNbow]

Maar wat nu als je algebra en calculus toepast op datastructuren?

[.oisyn]

Lethalis schreef op maandag 14 april 2014 @ 14:41:
Misschien hoef je niet goed te zijn in wiskunde om te kunnen leren programmeren, maar helpt het wel (en dan staat het dus niet helemaal los van elkaar).

Nee hoor

[NMe]

Lethalis schreef op maandag 14 april 2014 @ 14:41:
[...]

Toch is het meer dan n = 1 hoor. Meerdere klasgenootjes van toen die goed waren in wiskunde zijn inmiddels programmeur, consultant of software architect.

Dat zegt nog steeds niks over een causaal verband. Ik had bijvoorbeeld alleen autochtone Nederlanders in mijn klas. Ook nu werk ik niet met "buitenlanders". Wil dat zeggen dat autochtone Nederlanders beter zijn in programmeren dan (bijvoorbeeld) Marokkanen? Of wil dat zeggen dat er toevallig minder allochtonen in mijn omgeving zaten/zitten en dat niets te maken heeft met hun kwaliteiten op mijn vakgebied?

Correlatie is dan weer een van de weinige onderdelen van wiskunde waar ik wel goed in was, en daar heb ik geleerd dat je op moet passen met het toeschrijven van één feit aan de aanwezigheid van een ander feit omdat dat niets met elkaar te maken hoeft te hebben.

Het beste voorbeeld dat ik heb gehoord was dat van een gebied waarin er meer baby's geboren werden in een periode waarin er ook veel ooievaars overvlogen vanwege de vogeltrek. Je zou dan kunnen concluderen dat ooievaars inderdaad baby's brengen, of je zou kunnen bedenken dat het misschien toch komt doordat negen maanden vóór die vogeltrek de dagen langer en kouder worden.

[Anoniem: 296939]

Het verbaast mij overigens dat dit stukje leesvoer hier nog niet voorbij is gekomen: Teach Yourself Programming in Ten Years.

[Lethalis]

NMe schreef op maandag 14 april 2014 @ 15:06:
[...]
Dat zegt nog steeds niks over een causaal verband.

Het is niet gebaseerd op een serieus onderzoek, maar gewoon mijn mening / idee erover.

Je hebt gelijk dat mijn referentiekader misschien te nauw is.

Anoniem: 296939 schreef op maandag 14 april 2014 @ 17:37:
Het verbaast mij overigens dat dit stukje leesvoer hier nog niet voorbij is gekomen: Teach Yourself Programming in Ten Years.

Hier zit een kern van waarheid in.

Toen ik 20 was, had ik al enorm veel programmeeruren achter de rug. Het is logisch dat wanneer iemand op zijn 20ste er net mee begint dat het voor hem veel zwaarder zal zijn dan voor mij op die leeftijd.

Maar uit het artikel blijkt ook dat mensen die er aanleg voor hebben, vanzelf meer tijd er aan gaan besteden. Heb je die aanleg niet, dan is het veel moeilijker om het vol te houden.

De enige reden dat ik al zoveel had geprogrammeerd, was omdat ik het leuk vond en het grotendeels "vanzelf" ging. Had het mij meer moeite gekost om het te leren, had ik het misschien eerder opgegeven, of er sowieso minder tijd aan besteed. Kortom: dan was het wellicht niet haalbaar geweest.

Ik heb bijvoorbeeld ook enorm veel uren gitaar gespeeld en daar word ik niet echt beter in. En dan mis ik het doorzettingsvermogen om er echt wat van te maken. Ik blijf ermee aanprutsen. Bij het programmeren ging dat toch even anders

PS:
Het was niet eens de bedoeling dat ik programmeur zou worden.. mijn vader wou eigenlijk veel liever dat ik Werktuigbouwkunde ging doen en ik was ook lang in die veronderstelling. Programmeren was echter het enige dat ik uit mezelf elke keer bleef doen en uiteindelijk alsnog in ben gerold (na 5 jaar bij mijn vader op kantoor gewerkt te hebben als CAD tekenaar/constructeur.. daar was ik middelmatig in, maar bij de programmeeropdrachten die we ook hadden, daar ging ik helemaal in op ).

[ Voor 21% gewijzigd door Lethalis op 15-04-2014 11:27 ]

[farlane]

Anoniem: 296939 schreef op maandag 14 april 2014 @ 17:37:
Het verbaast mij overigens dat dit stukje leesvoer hier nog niet voorbij is gekomen: Teach Yourself Programming in Ten Years.

Het boek dat daar gelinked wordt begint met:

Bad programming is easy. Idiots can learn it in 21 days, even if they are Dummies.

Good programming requires thought, but everyone can do it and everyone can experience the satisfaction that comes with it.