Leren te denken als een programmeur

[FixDeluxe]

Hallo allen,

Ik ben op zoek naar een paar tips om "beter te leren programmeren".

even een snelle achtergrond.
Ik ben vorig jaar een deeltijdstudie HBO ICT gestart.
Echter heb ik besloten om een tussenjaar te nemen dit 2e jaar omdat ik merk dat ik achterloop op mijn mede studenten.

Dit komt omdat ik nog niet werkzaam ben binnen de ICT (mee bezig),
en dus alleen via school kennis opdoe omtrent softwareontwikkeling.
Nu merk ik dat we op school vooral bezig zijn met de syntax en niet zozeer de denkwijze om deze te implementeren.

Dit resulteert er dus in dat ik de taal zelf wel begrijp, alleen wanneer er een casus neer wordt gegooid ik het het moeilijk vind hier mee te beginnen omdat ik eigenlijk niet weet hoe. (vaag)

Dit tussenjaar wil ik dus gebruiken om werk te zoeken maar ook thuis verder te leren om zo volgend jaar vol frisse moed het 2e jaar te gaan doen.

mijn vraag...
Zijn er boeken, of hebben jullie misschien goede tips om een goede SE mindset te creëren.
dit betekend dus niet de syntax, maar hoe los ik problemen op, hoe ontwerp ik goede code.

[Toxic_Dreams]

Pfoe, ik denk dat daarvoor vooral ervaring belangrijk is. Gewoon proberen, kijken welke oplossing het beste werkt, misschien 3 oplossingen voor hetzelfde probleem bedenken?

Je code wordt naarmate je meer code schrijft ook beter; tenminste, dat merk ik in mijn geval wel.

Zelf zou ik gewoon een paar projecten starten, die ergens iets hebben wat je nog nooit hebt gebruikt zodat je dat kan leren en ook weer meer mogelijkheden krijg om dingen op te lossen.

[BCC]

Ik zou beginnen met test driven development opdrachten of misschien daar wat YouTube filmpjes van kijken - dat forceert je meer in dit proces, maar dan met je tests als vangnet.

[CH4OS]

Programmeren is niet een kwestie van leren uit een boek tot je erbij neervalt. Je zult het ook moeten oefenen, dan komt dat echt vanzelf. Bedenk iets wat je graag zou willen programmeren, zoek daar eventueel een (of meerdere) Code Kata('s) bij en je kunt volgens mij vrij rap dat 'denken als een programmeur' leren. Een handige website hierbij is https://www.codewars.com/. Begin daarbij vooral klein en maak het jezelf niet te moeilijk en breidt dat langzaam maar zeker steeds verder uit.

[ Voor 14% gewijzigd door CH4OS op 18-10-2021 14:31 ]

[Ozzie]

Ik kan je aanraden het boek 'Code Complete' aan te schaffen. Daarin worden veel van de dingen die je vraagt behandeld.

Maar natuurlijk is het ook gewoon een kwestie van doen. In het begin kan je nou eenmaal niet veel meer dan kleine programmeer opdrachtjes maken, maar als je jezelf uit blijft dagen om dingen te programmeren word je er steeds beter in.

Een ander goed boek vind ik Head First Design Patterns, daarin worden verschillende design patterns uitgelegd en voorgedaan. Op die manier kan je leren wanneer je welk design pattern wil toepassen, dus leren op welke manier je een (programmeer) probleem wil oplossen. Head First Design Patterns is wel erg toegespitst op java-ontwikkelaars, maar de theorie is bruikbaar voor iedereen.

[jeroen3]

Er zijn software ontwerppatronen en data structuren. Met name in object oriented talen is dat vaak gebruikt.
Maar ook zonder objecten kun je veel van die structuren toepassen.

Het gaat erom dat je een idee krijgt hoe verschillende stukjes software met elkaar communiceert.
En hoe je dat kan realiseren met de tools (taal en syntax) die je nu leert.

Het ontwerpen van software staat los van de gebruikte taal.

Je kunt natuurlijk het Gang-of-Four design patterns boek opzoeken. Maar er zijn er meer, echter is dit allemaal wellicht iets te diep nog.

Ik kwam pas op youtube video's tegen van Programming With Mosh wat erg op de beginner georienteerd lijkt.
YouTube: Design Patterns in Plain English | Mosh Hamedani
Hij noemt daarin ook een andere data structures video die ik zo gouw even niet kan vinden.

Maar het belangrijkste is dat je gewoon iets gaat maken, en faalt. Want daar leer je het meeste van.

[ Voor 7% gewijzigd door jeroen3 op 18-10-2021 14:28 ]

[Kheos]

op welk punt gaat het mis?
De opdracht omzetten naar functies en algoritmes, of die functies en algoritmes aan elkaar rijgen tot een werkend programma en met elkaar laten communiceren?

[japieb]

Ik raad beginnende programmeurs vaak aan om http://people.scs.carleton.ca/~jeanpier/COMP5104F06/TDD.pdf eens door te lezen...

Het beschrijft erg goed een manier om een toch wel complex probleem (bowling scores berekenen) aan te pakken, inclusief alle overwegingen en beslissingen die je onderweg maakt.

[t_captain]

Verplaatsing naar Devschuur. Het gaat hier om het vak, niet om de baan.

[BCC]

Ik zou een beginner liever niet naar design patterns verwijzen - ik heb zulke draken van oplossingen gezien in de praktijk “omdat ze pattern a” volgen. FactoryFactoryFactory 😀

[FixDeluxe]

Tot nu toe bedankt voor de goede tips.

Ik denk dat zoals sommigen zeggen echt veel code schrijven misschien toch de beste manier is om zelf wat handigheid en handvaten voor mezelf te creëren.

Ervaring is denk ik dan ook het belangrijkste (des te belangrijk dus snel een mooi functie te vinden om te leren)

Daarnaast zal ik ook kijken of ik met de geadviseerde sites / boeken misschien wat wegwijzer kan worden.

Kheos schreef op maandag 18 oktober 2021 @ 14:29:
op welk punt gaat het mis?
De opdracht omzetten naar functies en algoritmes, of die functies en algoritmes aan elkaar rijgen tot een werkend programma en met elkaar laten communiceren?

om hier even op terug te komen.
Ik denk dat het al mis gaat bij de opdracht omzetten naar functies en algoritmes.
Vorig jaar met school moesten we een desktopapplicatie maken waarin we routes konden berekenen en klantgegevens konden bewerken. Daar merkte ik dat ik gewoon geen idee had hoe ik aan de code moest beginnen, of hoe ik de ontwerpen moest omzetten in code... Ik heb meegekeken me de mede student die wel ervaring heeft in het programmeren en hij schreef van scratch heel makkelijk. die ervaring zoek ik dan.
als ik project heb, hoe pak ik dat project aan. waar begin ik? hoe deel ik het op?

het blijft vaag

[CH4OS]

FixDeluxe schreef op maandag 18 oktober 2021 @ 14:43:
Tot nu toe bedankt voor de goede tips.

Ik denk dat zoals sommigen zeggen echt veel code schrijven misschien toch de beste manier is om zelf wat handigheid en handvaten voor mezelf te creëren.

Ervaring is denk ik dan ook het belangrijkste (des te belangrijk dus snel een mooi functie te vinden om te leren)

Daarnaast zal ik ook kijken of ik met de geadviseerde sites / boeken misschien wat wegwijzer kan worden.

Sterker nog, als je hands-on ervaring hebt en kan laten zien dat je zelf dingen geprogrammeerd hebt (al dan niet door de jaren heen) krijg je bij sollicitaties ook veel meer kans van slagen bij sollicitaties e.d!

[Toxic_Dreams]

Ja, precies dat is wat ik zeg denk ik. Gewoon echt ervaring opdoen. Nu zit ik voor m'n stagiaires en typ ik zo 'n hele functionaliteit in bijv. JavaScript voor hun neus uit zonder te Googlen, terwijl ik bij het begin moeite had met het selecteren van een DOM element.

Gewoon veel doen, veel voorbeelden op Stack Overflow bekijken ( wel alleen gebruiken als je ze snapt! ) en dan komt het echt vanzelf wel.

[BCC]

Youtube staat vol met TDD voorbeelden van problemen implementeren. Bijvoorbeeld YouTube: TDD Kata: Tennis in Ruby & RSpec - iemand die de regels van Tennis from scratch TDD implementeert. Als je dit door hebt, kun je zelf simpele dingen gaan doen als boter kaas en eieren en dat opbouwen naar complexere vraagstukken YouTube: Code Retreat - Game Of Life in 30 minutes with TDD - game of life, et cetera.

[ Voor 37% gewijzigd door BCC op 18-10-2021 14:54 ]

[Kheos]

FixDeluxe schreef op maandag 18 oktober 2021 @ 14:43:
om hier even op terug te komen.
Ik denk dat het al mis gaat bij de opdracht omzetten naar functies en algoritmes.
Vorig jaar met school moesten we een desktopapplicatie maken waarin we routes konden berekenen en klantgegevens konden bewerken. Daar merkte ik dat ik gewoon geen idee had hoe ik aan de code moest beginnen, of hoe ik de ontwerpen moest omzetten in code... Ik heb meegekeken me de mede student die wel ervaring heeft in het programmeren en hij schreef van scratch heel makkelijk. die ervaring zoek ik dan.
als ik project heb, hoe pak ik dat project aan. waar begin ik? hoe deel ik het op?

het blijft vaag

hm, je lijkt mijn vraag niet helemaal te begrijpen of jezelf tegen te spreken.

Mijn vraag is eerder:
loop je vast op het omzetten van de opdracht naar een functie of algoritme (dus bijvoorbeeld de 1e 100 priemgetallen berekenen, kijken of een bankrekeningnummer geldig is,...)
of
kun je wel de nodige functies en algoritmes maken, maar kun je ze niet met elkaar laten praten. (dus bijvoorbeeld: de logica van een parkeerautomaat of bankautomaat ofzo)

[Wahloh]

Ervaring. Werk al een aantal jaar als developer maar ook ik heb nog wel eens problemen om iets van scratch op een goede manier op te bouwen. Probeer uit te schrijven wat je wil maken, maak daar een klassediagram van (dat hoeft echt niet volledig gedetailleerd) en laat dat eens reviewen door iemand met ervaring daar leer je veel van.

Verder zijn er een aantal dingen die mij goed hebben geholpen; OOP, SOLID Principles en Design Patterns. Daar zou je via Udemy en Youtube aan kunnen werken.

Zorg er daarnaast altijd voor dat je unittests schrijft voor je code, ik kan me herinneren dat hier tijdens mijn opleiding niet heel veel mee gedaan werdt naast het 'oh je moet deze keer een unittest uitwerken', want als je makkelijk wil kunnen unittesten moeten je klassen netjes opgesplitst zijn en probeer je standaard circulaire dependencies voorkomen. I know, boring.

[aawe mwan]

@FixDeluxe Het feit dat jij jezelf realiseert dat je hier te weinig van weet en dat je dit op de opleiding ook niet zult leren, is op zich een goed teken.

Wat „de goede manier van werken” precies is, verschilt van bedrijf tot bedrijf, dit zal je leren als je in een goede werkomgeving terecht komt. En als je er dan een paar verschillende gezien hebt (en werk hebt opgeleverd in die omgevingen) ga je langzaam inzien wat het precies is dat daar voor nodig is.

Maar let op: er zijn dus ook niet-goede werkomgevingen, waar je verkeerde gewoonten aanleert.

[ Voor 3% gewijzigd door aawe mwan op 18-10-2021 15:10 ]

[FixDeluxe]

Kheos schreef op maandag 18 oktober 2021 @ 14:52:
[...]

hm, je lijkt mijn vraag niet helemaal te begrijpen of jezelf tegen te spreken.

Mijn vraag is eerder:
loop je vast op het omzetten van de opdracht naar een functie of algoritme (dus bijvoorbeeld de 1e 100 priemgetallen berekenen, kijken of een bankrekeningnummer geldig is,...)
of
kun je wel de nodige functies en algoritmes maken, maar kun je ze niet met elkaar laten praten. (dus bijvoorbeeld: de logica van een parkeerautomaat of bankautomaat ofzo)

sorry, dan gaat het inderdaad in het 2e zitten.
In principe lukt het me wel de kleine losse opdrachten om te zetten naar code en ook werkend te krijgen.
Echter wanneer inderdaad een opdracht uit meerdere functies bestaat dan vind ik het lastig om hier een begin aan te maken. dan word het een gevalletje door de bomen het bos niet meer zien. zoals dus bijvoorbeeld een bankautomaat (in c#) hoe bepaal ik welke klassen ik nodig ben, welke functies ben ik nodig.

Maar ja dat zal ervaring dus zijn

[FixDeluxe]

aawe mwan schreef op maandag 18 oktober 2021 @ 15:00:
@FixDeluxe Het feit dat jij jezelf realiseert dat je hier te weinig van weet en dat je dit op de opleiding ook niet zult leren, is op zich een goed teken.

Wat „de goede manier van werken” precies is, verschilt van bedrijf tot bedrijf, dit zal je leren als je in een goede werkomgeving terecht komt. En als je er dan een paar verschillende gezien hebt (en werk hebt opgeleverd in die omgevingen) ga je langzaam inzien wat het precies is dat daar voor nodig is.

Maar let op: er zijn dus ook niet-goede werkomgevingen, waar je verkeerde gewoonten aanleert.

Zoals je al aangeeft, "de goede manier van werken" is heel abstract en zal per bedrijf weer verschillen.
Het is dan ook vooral het krijgen van goede, betrouwbare handvaten.
Hopelijk kan ik dit tussenjaar hiervoor dan goed gebruiken.
Thuis veel ervaring op doen door zelf projecten aan te gaan.
hopelijk een mooi bedrijf vinden die mij kunnen verreiken met hun werkwijze.
en zo doende mezelf op weg te helpen.

bedankt!

[Kheos]

FixDeluxe schreef op maandag 18 oktober 2021 @ 15:15:
[...]


sorry, dan gaat het inderdaad in het 2e zitten.
In principe lukt het me wel de kleine losse opdrachten om te zetten naar code en ook werkend te krijgen.
Echter wanneer inderdaad een opdracht uit meerdere functies bestaat dan vind ik het lastig om hier een begin aan te maken. dan word het een gevalletje door de bomen het bos niet meer zien. zoals dus bijvoorbeeld een bankautomaat (in c#) hoe bepaal ik welke klassen ik nodig ben, welke functies ben ik nodig.

Maar ja dat zal ervaring dus zijn

ok, duidelijk

een deel ervaring, een deel theoretische kennis, een deel analyse, maar vooral snappen waarom.
Waarom heb je functies en klasses nodig? Je kunt toch alles gewoon in 1 functie steken en het daarin afhandelen?
Probeer eens (zoals het dus niet moet) in 1 functie die parkeerautomaat te programmeren.
Dus kijken hoeveel je moet betalen, geld erin steken en het juiste wisselgeld terug krijgen.
Als je dat gedaan hebt voeg dan eens wat zaken toe zoals: het eerste kwartier is gratis, op kerstdag krijgt iedereen 10% korting, er zitten vandaag geen briefjes van 5 euro in de automaat...
Heel snel krijg je spaghetti code waar onderhoud ontiegelijk lastig wordt en waar de fouten je om de oren gaan vliegen.
De enige manier om dat onder controle te krijgen is dat opdelen in functies.

[Windows95]

Ik vond programmeren in het eerste blok van mijn opleiding ook erg moeilijk. Toen heb ik wat hulp gehad van een tweedejaars student (2-3 keer een middagje). Opeens zag ik het licht, en vanaf toen ging alles heel makkelijk.

Zorg ervoor dat je wat voor ligt op schema i.p.v. achter. Veel programmeren, hobby projectjes maken en extra functionaliteiten t.o.v. de school opdrachten. Je komt steeds dingen tegen die je moet opzoeken omdat je voor jouw eis de kennis nog niet hebt. Maar daar leer je van. En wanneer dat behandeld wordt tijdens de lesstof, snap je het meteen al. Een ander voordeel is dat als je wat voor ligt op schema, je de opdrachten een stuk sneller af hebt. Je kunt dan tijd in stoppen in je extra functionaliteiten, en dus nog verder voor liggen op schema (sneeuwbal effect).

Hetzelfde kun je ook doen als je eenmaal aan het werk bent. Moet er iets uitgezocht worden waarvan (bijna) nog niemand kennis heeft in het bedrijf, sta dan vooraan om het zelf uit te zoeken. Hierdoor komen je collega's met vragen bij jou, i.p.v. jij bij je collega's. Krijg je een vraag die je zelf ook niet weet -> uitzoeken, zodat jij de kennis hebt.

[bwerg]

Leer ook goed debuggen. Wat ik bij veel studenten zie is dat ze ergens vastlopen (hun probeersel geeft bijvoorbeeld het verkeerde antwoord), en dan naar hun scherm staren met een idee van "wat nu?" Zelfs als iemand anders je het antwoord weet te geven loop je de volgende keer gewoon weer vast (en dat zal na 10 jaar programmeren nog steeds het geval zijn). Weten hoe je verder komt als je ergens vastloopt is een vaardigheid op zich, en veel docenten slaan dat deel helaas over... Beginnen ze het specifieke inhoudelijke probleem uit te leggen. Iets met "teach a man to fish, and you feed him for a lifetime".

Ik noem debuggen omdat dat een manier is voor jezelf om antwoord te krijgen op de vraag "waarom werkt mijn code niet", maar ook als je op andere gebieden vastloopt (een algoritme uitwerken o.i.d.), let ook dan op de methode waarop je een probleem oplost, niet alleen op de oplossing zelf.

[ Voor 3% gewijzigd door bwerg op 18-10-2021 16:45 ]

[Anoniem: 80910]

Volgens mij mis je een goed uitgeschreven functioneel ontwerp / technisch ontwerp. Als die niet beschikbaar is zal je hem zelf moeten maken. Dan komen de klassen en functies ook naar boven.

[Rmg]

Begin eens met UML te leren.

Het is niet essentieel om goed software te leren schrijven maar het geeft je handvatten om designs van anderen te leren lezen en ook om designs te leren maken op een gestandaardiseerde manier.

Dat maakt het makkelijker om te praten over software designs en niet bij elke sessie te verzanden in uit te leggen wat je nou bedoelt.

En op die manier is het ook makkelijker om een stuk software te begrijpen zonder door de code te hoeven ploegen

[moijamie]

Zoals al gezegd is gewoon doen, maar wat nog niet gezegd is en volgens mij wel belangrijk is, is refactoring. Na dat je wat hebt geschreven, ga je er weer doorheen om te kijken of je de structuur verder kan verbeteren zonder de werking aan te passen.

Ik kan Laracasts ook heel erg aanraden, duidelijk en interessante filmpjes. Het is wel op Laravel en PHP gericht maar het meeste is ook gewoon bruikbaar met andere talen / frameworks.

Ik zou beginnen met deze series https://laracasts.com/series/simple-rules-for-simpler-code.

[Janoz]

Ik hoor hier iedereen met allemaal termen smijten. Refactoren, designpatterns, algoritmes, test driven development, UML. Dat is allemaal leuk en aardig, maar uiteindelijk begint het bij de basis.

Sommige dingen kun je leren, sommige dingen kun je beter in worden, maar soms zijn er gewoon dingen die je niet kunt. Dat is niet erg. Iedereen is wel ergens goed in, maar dat betekend ook dat je ergens niet goed in kunt zijn.

Programmeren vraagt een bepaalde skill, een bepaalde manier van hoe je hoofd werkt. Je kijkt naar een groot onoplosbaar probleem en ziet daarin vervolgens kleinere deelprobleempjes die je wel stuk voor stuk op kunt lossen. Je bent in staat om die deelprobleempjes samen te voegen om vervolgens dat onoplosbare probleem toch oplosbaar te maken.

Uiteindelijk heeft dat niks te maken met je ervaring, waar je werkt of hoe slim je bent. Het vraagt gewoon een bepaald analytische skill. Dat is die SE mindset en die heb je, of die heb je niet. Als het in het eertste jaar al niet goed lukt om mee te komen zul je je toch echt even af moeten vragen of dit wel is wat je zou moeten willen.

Wanneer je de oplossing van een raadsel krijgt is deze vaak heel simpel en logisch, maar uiteindelijk is het de bedoeling dat je die raadsels zonder het antwoord op kunt lossen.

[ThomasG]

Een schaamteloze zelf-quote uit een vergelijkbaar topic van jaren geleden:

quote: https://gathering.tweakers.net/forum/list_messages/1920892

ThomasG schreef op dinsdag 30 april 2019 @ 20:05:
Wat ik zelf vaak merk als programmeurs niet weten waar ze moeten beginnen, is dat ze het probleem wat ze moeten gaan oplossen niet begrijpen, of in ieder geval niet goed genoeg begrijpen. Programmeren is in feiten niets anders dan het probleem opdelen in kleine stukken, en deze stap voor stap op te lossen; en daarmee het grote probleem te op lossen.

De eerste stap is dus het analyzeren van het probleem, en het vervolgens opdelen in kleinere problemen; en die zijn vaak ook weer op te delen in kleinere problemen. Bij het geheel weet je niet waar je moet beginnen, bij de kleinere problemen is het veel duidelijker hoe en wat. In het begin kan dat vrij lastig zijn, maar naarmate je ervaring krijgt wordt het steeds gemakkelijker.

[aawe mwan]

Ik merk op het werk dat de meeste mensen hier moeite mee hebben. Het allerhoogste niveau beschrijven is vaak gemakkelijk (gewoon overschrijven van de opdracht), het allerlaagste niveau komen de meeste mensen uiteindelijk ook nog wel uit.

Maar een proces is niet een opeenvolging van honderdduizend random stappen. Voor de duidelijkheid moet je ze groeperen functionele blokken en bijvoorbeeld lussen. Dat leer je door veel te oefenen, maar dat kan je al doen bij alle andere dingen die je doet in je dagelijks leven, of het plannen van je vakantie bijvoorbeeld.

[DaFeliX]

Janoz schreef op maandag 18 oktober 2021 @ 22:18:
Ik hoor hier iedereen met allemaal termen smijten. Refactoren, designpatterns, algoritmes, test driven development, UML. Dat is allemaal leuk en aardig, maar uiteindelijk begint het bij de basis.

Sommige dingen kun je leren, sommige dingen kun je beter in worden, maar soms zijn er gewoon dingen die je niet kunt. Dat is niet erg. Iedereen is wel ergens goed in, maar dat betekend ook dat je ergens niet goed in kunt zijn.

Programmeren vraagt een bepaalde skill, een bepaalde manier van hoe je hoofd werkt. Je kijkt naar een groot onoplosbaar probleem en ziet daarin vervolgens kleinere deelprobleempjes die je wel stuk voor stuk op kunt lossen. Je bent in staat om die deelprobleempjes samen te voegen om vervolgens dat onoplosbare probleem toch oplosbaar te maken.

[...]

Ik ben het helemaal met je eens dat 'de truc' hem zit in het oplossen van problemen (en deelproblemen als 't eerste probleem te groot is).

Je suggereert echter dat het een skill is die je hebt of niet, maar daar ben ik het niet mee eens. Ik denk namenlijk dat iedereen kan leren programmeren. Mensen met een sterk analytisch vermogen zullen hier minder moeite mee hebben (het zal natuurlijker zijn), maar anders kun je het programmeren ook wel aanleren. Het belangrijkste is volgens mij of je't leuk vind om problemen op te lossen, zodat je 't blijft oefenen in verschillende situaties.

Zie het als een muziekinstrument bespelen: Iedereen kan 't leren, het vergt gewoon onwijs veel oefening. Vind je het leuk om te oefenen, dan oefen je meer en wordt je er sneller beter in. Als je de skills hebt, én veel oefent zul je tot de top gaan behoren; heb je dat niet kun je volgens mij een prima muzikant/programmeur worden.

[FixDeluxe]

Janoz schreef op maandag 18 oktober 2021 @ 22:18:
Ik hoor hier iedereen met allemaal termen smijten. Refactoren, designpatterns, algoritmes, test driven development, UML. Dat is allemaal leuk en aardig, maar uiteindelijk begint het bij de basis.

Sommige dingen kun je leren, sommige dingen kun je beter in worden, maar soms zijn er gewoon dingen die je niet kunt. Dat is niet erg. Iedereen is wel ergens goed in, maar dat betekend ook dat je ergens niet goed in kunt zijn.

Programmeren vraagt een bepaalde skill, een bepaalde manier van hoe je hoofd werkt. Je kijkt naar een groot onoplosbaar probleem en ziet daarin vervolgens kleinere deelprobleempjes die je wel stuk voor stuk op kunt lossen. Je bent in staat om die deelprobleempjes samen te voegen om vervolgens dat onoplosbare probleem toch oplosbaar te maken.

Uiteindelijk heeft dat niks te maken met je ervaring, waar je werkt of hoe slim je bent. Het vraagt gewoon een bepaald analytische skill. Dat is die SE mindset en die heb je, of die heb je niet. Als het in het eertste jaar al niet goed lukt om mee te komen zul je je toch echt even af moeten vragen of dit wel is wat je zou moeten willen.

Wanneer je de oplossing van een raadsel krijgt is deze vaak heel simpel en logisch, maar uiteindelijk is het de bedoeling dat je die raadsels zonder het antwoord op kunt lossen.

Bedankt voor je reactie!
Ik snap heel goed wat je bedoelt hoor, en ben het ook helemaal met je eens.
Echter denk ik niet dat wat je nu schets voor mij het probleem zozeer is.
De deeltijd is toch echt vooral ingericht op studenten die vanuit het MBO werkzaam zijn in de desbetreffende branch. Daar ligt mijn achterstand dan ook vooral en dit komt in het 2e jaar dubbel zo hard binnen. Ik denk dat ik de skills wel heb, echter ze nog niet ontwikkeld heb omdat ik ze tot nu toe amper benut heb.

Dat de termen die ik voorbij hoor komen niet van toepassing zijn als de basis er niet eens is, 100% mee eens. ben daarom ook van plan de 3 C# cursussen van Mosh Hamedani van scratch af aan te volgen.
Dit keer kan ik hier ook meer tijd voor nemen omdat de tijdsdruk vanuit school dit keer niet aanwezig is.
Daarnaast wil ik geleidelijk via Codewars bezig gaan met die Kata's (top tip vanuit hier )
Neem het mezelf kwalijk dat ik nog nooit van Kata's gehoord had, want vind het principe echt super.

Al met al moet ik nogmaals zeggen dat ik echt wel blij ben met de reacties hier.
Hopelijk kan ik het ten uitvoering brengen en volgend jaar meer beslagen ten ijs komen.

[bwerg]

Janoz schreef op maandag 18 oktober 2021 @ 22:18:
Ik hoor hier iedereen met allemaal termen smijten. Refactoren, designpatterns, algoritmes, test driven development, UML. Dat is allemaal leuk en aardig, maar uiteindelijk begint het bij de basis.

Dit lijkt me zeker waar. De behoefte aan UML, refactoring of test driven development komt vanzelf als je de basis eenmaal hebt. Dan merk je vanzelf dat je weinig overzicht hebt als je programma's groeien, dus je wil misschien UML of refactoring of wat unit test coverage. Daar beginnen lijkt me een oplossing op zoek naar een probleem.

Gewoon lekker spaghetti-code schrijven is in je eerste jaar programmeren helemaal prima. Eerst maar eens kleine programmaatjes goed werkend krijgen, dan leren hoe je dingen verbetert en daarna kun je met de gestructureerde methodieken aan de slag. Er zijn heel wat van dat soort theoretische lessen aan mij voorbij gegaan omdat dat soort technieken veel minder nut hebben bij een basisopdrachtje van 200 regels code dan bij een groter project. En ik ben toch echt meer een theoreticus.

Als je na tien jaar nog steeds niks test of refactored wordt dat een ander verhaal, in dat stadium zit TS zo te lezen nog niet.

[aawe mwan]

Van spaghetti-code ga je vanzelf last krijgen als je maanden later bugs moet zoeken en oplossen in je eigen code, of (nog erger) in code die door een ander gemaakt is.

Met een beetje geluk leer je daar zo veel van, dat je fouten al gaat voorzien voordat je ze echt maakt.
Maar dat duurt jaren.

[Flapmo]

Ik zou vooral een project(je) pakken en dat gaan maken. Stoor je je aan iets kleins? Kijk eens of je daar iets voor kan schrijven. Niet teveel nadenken over hoe dat kwa architectuur prachtig in elkaar kan zitten, niet beginnen met een prachtig UML landschap, daar is het nog wat te vroeg voor denk ik.

Gewoon editor open en typen. Weet je niet hoe je start, zoek je een vergelijkbaar project met jouw taal naar keuze op Github en kijk je daar een beetje af. Pas op, niet een groot project pakken want dit zul je nog niet begrijpen. Begin gewoon klein, maak een console programma of simpele website. Bouw dat uit en ervaar eens dat je programma/website crasht en je werkelijk geen idee hebt waarom. Google de error en los hem op. Zit eens een dag vast op een enkel probleem die je alleen na veel debuggen, proberen en googlen op weet te lossen.

Gaandeweg zal je dan vanzelf stappen maken naar betere architectuur omdat je oplossingen tegenkomt die je niet zo kan copy-pasten in je code. Het eindresultaat zal een gedrocht zijn kwa code waarschijnlijk maar als het werkt heb je toch mooi iets gemaakt. Heb je ook meteen iets om te leren wat refactoren is. De dag erna, als het spul niet meer werkt terwijl het dat voor die wijziging nog wel deed kan je ook mooi je eerste test schrijven .

[Ossebol]

Herkenbaar. Het antwoord is al gegeven en het is zo waar: ervaring. In het begin vraag je je echt af hoe je in hemelsnaam alles aan elkaar weet te knopen. Gaandeweg begint alles in elkaar te vallen en later denk je er niet eens meer over na.

Het is misschien ook raadzaam om eens wat opensourceprojecten op te zoeken. Check de code eens uit, probeer de code eens te debuggen. Je leert zo veel over hoe andere mensen structuren opzetten en coderen (en je ontdekt meteen hoe je het beter kunt doen ) .

[Lethalis]

Programmeren is een kwestie van doen. Heel veel doen. En de theorie is een mooie aanvulling daar op, om te leren hoe dingen beter kunnen.

Het kan geen kwaad om het eerst "fout" te doen, want daar leer je van. Dan ervaar je het ook

[Ben(V)]

Ik zou willen opmerken dat een opleiding die aandacht besteed aan hoe je moet coderen voor je een fatsoenlijk ontwerp kunt maken zonde van de tijd is.
Syntax leren heb je geen opleiding voor nodig, dat haal je uit een boek of van het internet.

Vroeger had je ook gewoon codeurs die niets anders deden dan hapklare brokken logica die een ontwerper opschreef omzetten in code, die hadden zelfs geen idee wat ze aan het maken waren en volgden gewoon de specificaties van de ontwerper.

Zoals @ThomasG als opmerkte, analyseer het probleem en breek het op in hapklare brokken en werk van grof naar fijn.
Schrijf het eerst uit in pseudo code, stroom schemas, data diagrammen of wat je ook prettig vind en ga vandaaruit pas coderen.
Kortom begin met ontwerpen.

[farlane]

Ben(V) schreef op donderdag 21 oktober 2021 @ 14:43:
Ik zou willen opmerken dat een opleiding die aandacht besteed aan hoe je moet coderen voor je een fatsoenlijk ontwerp kunt maken zonde van de tijd is.

Wat een load of crap, skjoes my French. Hoe kun je nou een fatsoenlijk ontwerp maken als je niet weet hoe het is om dat ontwerp om te zetten in iets dat zou kunnen werken?

[Ben(V)]

Aha dus jij denkt dat je eerst moet leren hoe je een ontwerp in code om kunt zetten voor je een weet hoe je iets moet ontwerpen.
Persoonlijk lijkt mij dat de verkeerde volgorde.

Zoals ik al zei dat noemden ze vroeger codeurs die geen idee hadden hoe ze iets moesten ontwerpen, volgens mij zijn we die tijd reeds lang voorbij.

PS En het is altijd prettig als mensen een menig kunnen geven zonder scheldpartijen.

[Creepy]

Ik denk dat je eerst de basis van code moet kennen voordat je in staat bent om daar grotere structuren mee te maken en (grotere) ontwerpen uit te denken. Als je de basisblokken niet goed kent dan is de kant veel groter dat je ontwerp niet klopt.

En dat over codeurs kan ook prima andersom: architechten die hun eigen ontwerp heilig vinden maar de codeurs kunnen het niet goed maken omdat het ontwerp van de architect niet klopt. Dat gebeurde vroeger ook te vaak omdat er gedacht werd dat codeurs geen ontwerpen konden maken. Die tijd zijn we (op de meeste plekken) gelukkig al lang voorbij. Natuurlijk, niet iedereen die (goed) code kan schrijven is niet persee iemand die een goed ontwerp kan neerzetten en andersom. Maar zonder basis is het heel lastig een goed ontwerp te maken.

[bwerg]

Ben(V) schreef op vrijdag 22 oktober 2021 @ 09:53:
Zoals ik al zei dat noemden ze vroeger codeurs die geen idee hadden hoe ze iets moesten ontwerpen, volgens mij zijn we die tijd reeds lang voorbij.

En mensen die geen idee hebben hoe ze het moeten implementeren leveren vaak slechte ontwerpen op. Als beginner geen idee hebben van hoe het te implementeren betekent doorgaans dat je nog geen overzicht hebt van de basisbouwblokjes, de beschikbare (standaard-)libraries en interfaces etc. en dan kun je ook niks ontwerpen.

Een ontwerp maken vereist ook wel dat je een concreet beeld hebt van hoe een implementatie eruit zou kunnen zien, anders is het gewoon fantaseren zonder te weten of het ergens op slaat.

[ Voor 14% gewijzigd door bwerg op 22-10-2021 11:10 ]

[Titusvh]

Ik heb amper een jaar een HBO ICT Software development deeltijd opleiding achter de rug.
Daar was de toelatingseis om een "relevante baan" van tenminste 20u in de week te hebben, om zo niet volledig afhankelijk te zijn van wat je ' op school' leerde. In dat geval heb je als het goed is collega's om mee te sparren.

Voltijds studenten kunnen elkaar ook helpen door over een probleem te sparren. Maar soms is het gewoon handig iemand uit het vak te kunnen raadplegen.

Zelf vond ik mijn opleiding, die geen enkele voorvereiste had anders dan MBO/HAVO, niet zo goed voor blanco beginners. Ik deed de opleiding puur voor het papiertje terwijl ik al 15 jaar in het vak zat. Daardoor kon ik iemand een beetje op sleeptouw nemen die goede motivatie had, een goed stel hersens, en uiteindelijk op een haar na cum laude misliep.

Een fijne sparring partner vinden, liefst eentje met wat ervaring (er is in deeltijd ook veel MBO instroom van mensen die al wat ervaring hebben) lijkt me een eerste stap om te maken. En het liefst een relevante werkplek met sparbare collega's. Maar vaak is zo'n plek krijgen terwijl je net bezig ben wel wat lastiger. Hoewel mijn maatje in jaar 3 al een mooie baan kreeg met toezegging dat hij tijd aan zijn afstudeeropdracht mocht besteden.

Je opleiding kan je gewoon met succes afronden als je nog niet 'volledig denkt als een programmeur' hoor. Dat komt vanzelf als je meters maakt in een relevante werkomgeving, die ook veilig genoeg is om te experimenteren en op je bek te gaan!

Wat een valkuil bij ons was: de afstudeeropdracht. Bij de werving van de opleiding, uitgaande van de "relevante baan", werd gezegd dat je afstuderen 'gewoon je werk' was. Er bleken na anderhalf jaar echter stevige eisen aan een afstudeeropdracht te zitten, waardoor menig student niet op medewerking van zijn werkgever kon rekenen!
Zorg dus dat je hier afspraken met je huidige werkgever over maakt. Of zsm aan een relevante baan komt waar je het afstuderen ook meteen in de afspraken meeneemt. Anders heb je ruim 3 jaar gespendeerd zonder de erkenning daarvan in de vorm van een diploma te kunnen halen.

[mr.day]

@TS, kan je de vragen niet gewoon kwijt bij de docenten/studenten van je opleidingen, want daar is een opleiding toch gewoon voor? En waarom ben je eigenlijk ICT gaan studeren? Vindt je het leuk, wordt je er enthousiast van om iets te programmeren? Want als je het niet leuk vindt, ga je er ook niet meer tijd erin steken om er beter in te worden.

Daarnaast lees ik ui de reacties dat het probleem deels zit in ervaring en deels in kennis. Probeer dingen ook zo eenvoudig mogelijk te maken en in aparte functionaliteiten. Ik las hierboven dat je bv een betaalautomaat moet maken. Ik weet niet helemaal specifiek wat het is, maar dan denk ik aan een betaal automaat zoals een pinautomaat. Daarbij zou ik zoiets proberen.

1. Er moet een factuurbedrag ingevuld kunnen worden
2. Iemand moet bv een pincode in kunnen vullen die gevalideerd moet worden > tabel met accountgegevens en pincodes
3. Er moet een validatie komen dat er genoeg saldo is
4. print een bericht uit dat de betaling voltooid is of dat er niet genoeg saldo is
5. Grafische interface

Volgens mij is dit niet zo moeilijk en ik ben zelf ook iemand die nog niet zo lang programmeert. Daarnaast is het gewoon proberen, ervaring op doen en FOUTEN maken.

[farlane]

Ben(V) schreef op vrijdag 22 oktober 2021 @ 09:53:
Aha dus jij denkt dat je eerst moet leren hoe je een ontwerp in code om kunt zetten voor je een weet hoe je iets moet ontwerpen.

Nee, ik denk dat je eerst werkende code moet schrijven voordat je gaat 'ontwerpen'.

Zoals ik al zei dat noemden ze vroeger codeurs die geen idee hadden hoe ze iets moesten ontwerpen, volgens mij zijn we die tijd reeds lang voorbij.

Software engineering is designen, maar dat is niet waar je uitspraak (en mijn reactie) over ging.

PS En het is altijd prettig als mensen een menig kunnen geven zonder scheldpartijen.

Ik scheld je niet uit.

[Kontsnorretje]

Het eerste wat ik wil meegeven, is dat je niet moet willen "leren denken als programmeur". Je moet gewoon ervaring opdoen. En die krijg je maar op 1 manier: gewoon doen, en dat doe je nu volgens mij 🙂

Mijn advies is vaak om maar gewoon aan een simpel project te beginnen. Wanneer je "klaar" bent (een project is nooit klaar), of dusdanig vastloopt dat het ombouwen geen zin meer heeft, begin je gewoon helemaal opnieuw aan hetzelfde project.

Doordat je hetzelfde eerder al eens opgezet hebt, weet je bij de 2e iteratie al beter waar je rekening mee moet houden, en wordt je project vanzelf beter.

Door dit een paar keer te herhalen, kan je steeds geavanceerdere technieken toepassen, en weet je steeds beter hoe je dat project technisch kan uitwerken. Die ervaring kan je dan toepassen op volgende projecten.

Na ldat je dit een paar keer hebt gedaan, kijk je, hopelijk, lachend of schaamtevol terug op de code die je de eerste paar keer hebt geschreven

[_Peter2_]

Een tip die ik je ook kan geven:

Als een probleem / vraagstuk te groot is, probeer het dan op te delen in kleinere stukjes en werk voor die deelproblemen / -vraagstukken een oplossing uit (en als dit nog te groot is...herhaal deze stap voor het deel)

Uiteindelijk kun je een groter geheel vormen van al je deeloplossingen.

[Boermansjo]

Zoals de meeste al aangeven : ervaring.
Onlangs aan de slag gegaan met NFC tags. Ik wist er niets van en de meeste voorbeelden waren extreem vaag of in programmeer talen die niet van toepassing waren.

Belangrijk is om telkens kleine stapjes te maken. Eerst data uitlezen. Voorbeelden bekijken, specs lezen...
Uiteindelijk begonnen met data schrijven.. En paar tags kapot gemaakt omdat ik verkeerde data of bepaalde delen overschreef.
Maar al doende leert men

Hoe beginnen ? Eerst het probleem verstaan. daarna kijken wat het resultaat is. Dat kan je gerust in mensen taal uitschijven/bedenken.
Eens je dat weet, kan je kijken hoe je iets gaat maken. En dan telkens elke stap onderverdelen. Later kan je nog wijzigen en beter maken.

[armageddon_2k1]

_Peter2_ schreef op donderdag 4 november 2021 @ 09:01:
Een tip die ik je ook kan geven:

Als een probleem / vraagstuk te groot is, probeer het dan op te delen in kleinere stukjes en werk voor die deelproblemen / -vraagstukken een oplossing uit (en als dit nog te groot is...herhaal deze stap voor het deel)

Uiteindelijk kun je een groter geheel vormen van al je deeloplossingen.

Sowieso een goed advies voor vrijwel alles in het leven

[Immutable]

Wat voor mij echt gigantisch veel geholpen heeft om echt goede software te maken is Datastructures & Algoritmes.

Waarom? Omdat je leert denken in Data + Algoritmes. Leer bijvoorbeeld hoe een standaard library is gemaakt met bepaalde datastructuur zoals een Array, en leer waarom en om welke reden er allerlei algoritmes zijn om bijvoorbeeld deze Array te sorteren. Zorg dat je je mindset zo maakt dat je data en algoritmes gescheiden houdt. Helaas hebben we jaren lang geleerd om te denken in "classes" wat juist ervoor zorgt dat je data en logica in 1 object propt waar ik persoonlijk op tegen ben. (Persoonlijke mening)

Maar als je leert hoe dat in elkaar zit ga zien wat men destijds als probleem had, en hoe ze dat opgelost hebben in een abstracte manier welke dus vaker toe te passen is. Wat een belangrijke eigenschap is van software schrijven. DRY (Don't repeat yourself) Leren denken in abstracties is zeer belangrijk.

Als je echt een goede basis wilt hebben qua datastructuur en algoritmes moet je een taal pakken zonder Garbage Collector. Zo ga je ook leren wat het verschil is tussen de Heap en de Stack. Je gaat geheugen beter begrijpen, en dus ook datastructuren.

Daarnaast moet je leren wat de Big O notatie is betreffende algoritmes en hoe ze schalen qua performance ten opzichte van een bepaalde datastructuur. Er zijn bijvoorbeeld tientallen verschillende sorterings algoritmes voor een "array" of andere datastructuur. Maar wat is het verschil nou tussen deze algoritmes wat zijn de sterke punten van sorterings algoritme A of B?

Hierdoor leer je afwegingen maken, en ga je beseffen dat er niet 1 oplossing de beste is maar dat je allerlei verschillende oplossingen hebt die ieder zijn eigen sterke en zwakke punten hebben.

Dus ja mijn ervaring is wat mij geholpen heeft om echt goede abstracties te bedenken en na te denken over goede oplossingen voor mijn probleemstellingen is om te kijken hoe probleemstellingen zijn opgelost voor bestaande oude problemen betreft Datastructuren en Algoritmes. Daarnaast is het tevens een goede basis om je eigen oplossingen te bedenken voor nieuwe problemen.

Om dit "eigen oplossingen" bedenken te trainen is "doen" de enige manier. En hiervoor heb je dus Challenges zoals hier: https://edabit.com/challenges

[Digital-DNA]

Immutable schreef op zondag 7 november 2021 @ 13:03:
Verhaal over data structures en algoritmes

Sorry maar dit is precies het soort geneuzel waar je als beginner ver weg van moet blijven, gewoon lekker prutsen en fouten maken.

Sterker nog, ik ben wel bekend mee met wat jij beschrijft maar ik heb er in de praktijk werkelijk nog nooit iets aan gehad. Het is vooral leuk als je bij Google gaat solliciteren oid. Met een beetje gezond verstand snap je zo ook welke aanpak snel of minder snel is.

[ Voor 3% gewijzigd door Digital-DNA op 07-11-2021 13:56 ]

[RobIII]

Digital-DNA schreef op zondag 7 november 2021 @ 13:55:
[...]


Sorry maar dit is precies het soort geneuzel waar je als beginner ver weg van moet blijven, gewoon lekker prutsen en fouten maken.

Definieer beginner. Eerste week programmeren? Lekker wegblijven. Eerste jaar? Toch nog eens over denken.

Je hoeft echt geen quicksort uit je pols te kunnen schudden, maar weten hoe het werkt is wel handig. Weten wélke algoritmes er zijn kan je leven drastisch makkelijker maken en scheelt het wiel opnieuw uitvinden. Het verschil tussen een array, list, stack, queue, dictionary, hashset en ga zo maar door is wel dégelijk kennis waar je iets aan hebt. Ook als je niet bij Google gaat solliciteren. En misschien heb je "formeel" niks met "Algorithms and datastructures" gedaan, ik weet zeker dat je het in de praktijk constant gebruikt. Iedereen, zelfs beginners. Misschien niet "all of it", maar gebruiken doe je het zeker. Jij maakt ook de afweging: gebruik ik hier een array of een stack. Die afweging en het besluit baseer je ergens op; of dat nou op ervaring is of op "gelezen in dit-en-dat boek", érgens heb je die kennis opgedaan. Óf je prutst (nog steeds) maar wat, dat kan ook, maar daar ga ik even niet van uit

[ Voor 28% gewijzigd door RobIII op 07-11-2021 14:22 ]

[Immutable]

Digital-DNA schreef op zondag 7 november 2021 @ 13:55:
[...]


Sorry maar dit is precies het soort geneuzel waar je als beginner ver weg van moet blijven, gewoon lekker prutsen en fouten maken.

Sterker nog, ik ben wel bekend mee met wat jij beschrijft maar ik heb er in de praktijk werkelijk nog nooit iets aan gehad. Het is vooral leuk als je bij Google gaat solliciteren oid. Met een beetje gezond verstand snap je zo ook welke aanpak snel of minder snel is.

Tsja, mijn ervaring is anders. Ik heb er echt SUPER veel aan gehad. (Het was de grootste sprong qua AHA momenten.) Beetje prutsen en jezelf allerlei fouten patronen aanleren. In plaats van leren van professionele bibliotheek schrijvers zoals de STD library van C++ is toch beter. En daarnaast prutsen ok. Maar daarom benoemde ik ook de challenges om hiermee dus je vermogen op problemen op te lossen te trainen. Dat is meer als een spier, net zoals wiskunde moet je gewoon doen in plaats van wat theorie lezen.

En ja zelf een plan van aanpak en het probleem in stukjes hakken zoals iedereen hierboven zegt kan ik ook goed achterstaan. Ik hak het probleem vaak in Data & Algoritmes. En ik denk vaak aan "dataflow" van punt X naar Y. Als een pijp aan data met code die de data manipuleert. Dit is beetje mentale model wat ik persoonlijk heb gekregen door dit soort zaken zo aan te pakken.

[ Voor 17% gewijzigd door Immutable op 07-11-2021 14:37 ]

[heuveltje]

Kheos schreef op maandag 18 oktober 2021 @ 15:30:
[...]

ok, duidelijk

een deel ervaring, een deel theoretische kennis, een deel analyse, maar vooral snappen waarom.
Waarom heb je functies en klasses nodig? Je kunt toch alles gewoon in 1 functie steken en het daarin afhandelen?
Probeer eens (zoals het dus niet moet) in 1 functie die parkeerautomaat te programmeren.
Dus kijken hoeveel je moet betalen, geld erin steken en het juiste wisselgeld terug krijgen.
Als je dat gedaan hebt voeg dan eens wat zaken toe zoals: het eerste kwartier is gratis, op kerstdag krijgt iedereen 10% korting, er zitten vandaag geen briefjes van 5 euro in de automaat...
Heel snel krijg je spaghetti code waar onderhoud ontiegelijk lastig wordt en waar de fouten je om de oren gaan vliegen.
De enige manier om dat onder controle te krijgen is dat opdelen in functies.

En dat is wat ervaring.

Wat je doet is je propt alles in 1 functie. zodra je het idee krijgt "he dit is nu de derde keer dat ik hetzelfde ding wil doen" (balans veranderen, balans controleren etc) breek je dat er uit als losse functie.

Na verloop van tijd krijg je dan vanzelf wel wat gevoel over wat er in een functie zou moeten zitten, voordat je begint die te schrijjven.

[chielsen]

Goede vraag van TS. Misschien zou ik het niet willen formuleren als denken als een software engineer, want hoe denken die? Die heb je in alle soorten en maten.
Wat je vooral wilt kunnen is tot de kern komen van een probleem en stukken ophakken in stappen of subproblemen. Dit is juist iets wat veel programmeurs vaak helemaal niet zo goed kunnen. Met veel gedoe wordt er dan uiteindelijk iets opgeleverd, maar had veel simpeler, sneller, veiliger etc gekund.

Ik zie iedereen zeggen ervaring. Daar ben ik het maar deels mee eens. Als je al weet hoe je moet denken, dan helpt ervaring omdat verder aan te scherpen en het sneller te kunnen. Toch ken ik genoeg programmeurs met 10 jaar+ ervaring die het simpelste probleem nog niet fatsoenlijk kunnen oplossen.

Het heeft te maken met analytisch denken inderdaad, maar dat is te simpel. Je moet je vooral continu afvragen "waarom?". Ik ben het eens dat veel debuggen hierin helpt. Ze zeggen wel eens dat je 5 keer waarom achter elkaar moet vragen om tot de kern te komen. Probeer dat eens met alles rondom je code en evt oplossingsrichtingen.

Uiteindelijk schrijf je algoritmes en dat zijn niks anders dan stappenplannen. Probeer die stappen te vinden, dan is het alleen nog maar uitschrijfwerk.

[glorytothesun]

Veel van dit soort dingen leer je vooral door ervaringen. In het begin ga je veel fouten maken, maar na een tijdje begrijp je steeds beter hoe een programmeertaal werkt en zal je ook efficiënter programmeren. Het belangrijkste is om ook leuke dingen te programmeren, bijvoorbeeld iets dat jij wil automatiseren. Naar mijn mening leer je meer relevante wanneer je klaar bent met school en echt gaat werken. Vergeet niet dat je altijd vragen moet stellen als je iets niet begrijpt, liever 10x iets vragen iets goed dan dan 1x iets vragen en niet helemaal begrijpen hoe het werkt.

[Squixx]

chielsen schreef op zondag 28 november 2021 @ 22:47:
Goede vraag van TS. Misschien zou ik het niet willen formuleren als denken als een software engineer, want hoe denken die? Die heb je in alle soorten en maten.
Wat je vooral wilt kunnen is tot de kern komen van een probleem en stukken ophakken in stappen of subproblemen. Dit is juist iets wat veel programmeurs vaak helemaal niet zo goed kunnen. Met veel gedoe wordt er dan uiteindelijk iets opgeleverd, maar had veel simpeler, sneller, veiliger etc gekund.

Ik zie iedereen zeggen ervaring. Daar ben ik het maar deels mee eens. Als je al weet hoe je moet denken, dan helpt ervaring omdat verder aan te scherpen en het sneller te kunnen. Toch ken ik genoeg programmeurs met 10 jaar+ ervaring die het simpelste probleem nog niet fatsoenlijk kunnen oplossen.

Het heeft te maken met analytisch denken inderdaad, maar dat is te simpel. Je moet je vooral continu afvragen "waarom?". Ik ben het eens dat veel debuggen hierin helpt. Ze zeggen wel eens dat je 5 keer waarom achter elkaar moet vragen om tot de kern te komen. Probeer dat eens met alles rondom je code en evt oplossingsrichtingen.

Uiteindelijk schrijf je algoritmes en dat zijn niks anders dan stappenplannen. Probeer die stappen te vinden, dan is het alleen nog maar uitschrijfwerk.

Precies, hier zit de kern van het denken. De rest zijn (process) oplossingen voor een deel van het probleem.

Probeer het process wat je probeert te automatiseren uit te denken, en in werkbare stappen te verdelen.

Goed doorvragen, en luisteren is hierin extreem belangrijk. Simpelweg omdat je 'klant' (project manager, manager, po, whatever) meestal als een oplossing heeft bedacht voordat hij/zij tot de kern van het probleem is gekomen.

zie ook: YouTube: THIS "EXACT INSTRUCTIONS CHALLENGE" IS SO HILARIOUS


oh: en wees niet bang om fouten te maken. De beste code is code die productief is en waar klanten gebruik van maken.

Maar wees ook zeker bereid de tijd te nemen iets goed op te lossen op t moment dat er problemen ontstaan

[Titusvh]

glorytothesun schreef op zaterdag 4 december 2021 @ 13:50:
Veel van dit soort dingen leer je vooral door ervaringen. In het begin ga je veel fouten maken, maar na een tijdje begrijp je steeds beter hoe een programmeertaal werkt en zal je ook efficiënter programmeren.

M.i. ook belangrijk om regelmatig je te verdiepen in de geavanceerdere onderdelen van een taal of bestaande op te frissen. Anders blijf je hangen in de comfortzone waarmee je ook werkende spullen krijgt, maar niet per se op de beste manier.
Vaak laat je als beginner ingewikkelder zaken even liggen omdat het overweldigend genoeg is, en de kans is dat je vergeten dat die handige dingen er zijn.

Squixx schreef op zaterdag 4 december 2021 @ 14:08:
[...]
wees niet bang om fouten te maken. De beste code is code die productief is en waar klanten gebruik van maken.

Hier kan ik het toch niet mee eens zijn.
Je code moet voor jouzelf (ook na een half jaar) en collega's begrijpelijk zijn.

Volgt in het begin toch wat basisregels (bv SOLID) omdat die je echt helpen als je software later ooit moet worden aangepast. Zo'n aanpassing komt in de praktijk nog wel eens onverwacht en dan is er geen tijd erachter te komen dat je inflexibele oplossing ervoor zorgt dat je de boel zodanig moet ombouwen dat je dus juist tijdenlang géén in productie werkende software hebt.

[Squixx]

Titusvh schreef op zondag 5 december 2021 @ 21:57:
[...]

M.i. ook belangrijk om regelmatig je te verdiepen in de geavanceerdere onderdelen van een taal of bestaande op te frissen. Anders blijf je hangen in de comfortzone waarmee je ook werkende spullen krijgt, maar niet per se op de beste manier.
Vaak laat je als beginner ingewikkelder zaken even liggen omdat het overweldigend genoeg is, en de kans is dat je vergeten dat die handige dingen er zijn.


[...]

Hier kan ik het toch niet mee eens zijn.
Je code moet voor jouzelf (ook na een half jaar) en collega's begrijpelijk zijn.

Volgt in het begin toch wat basisregels (bv SOLID) omdat die je echt helpen als je software later ooit moet worden aangepast. Zo'n aanpassing komt in de praktijk nog wel eens onverwacht en dan is er geen tijd erachter te komen dat je inflexibele oplossing ervoor zorgt dat je de boel zodanig moet ombouwen dat je dus juist tijdenlang géén in productie werkende software hebt.

Het een sluit het ander niet uit. Ik zie alleen veel beginners blijven hangen in het 'perfectioneren'. Zolang je enigsinds geholpen word met de architectuur zou je er als junior van uit moeten kunnen gaan dat je 'veilig' kan falen.

blijft natuurlijk wel belangrijk dat je je eigen troep ook weer mag opruimen

[leverage010]

Abstractie. Ik kijk terug naar de skills die ik heb ontwikkeld en welke het meest relevant waren en er sprint er echt 1 naar boven, en dat is abstractie.

Binnen het Object-georienteerd programmeren draait alles om objecten (duh).
een object is een verzameling van 2 dingen:
- Kenmerken (wat IS je object)
- Gedrag (wat DOET je object).

Ik merkte op een gegeven moment hoe eigenlijk alles in de wereld op deze manier abstract te zien is, en dat alle componenten die een systeem een geheel maken niks anders zijn dan een verzameling van deze regels.

Zo kan je alles om je heen zien als een systeem van dit soort elementen. Jij bent zo'n systeem, met een haarkleur, monddroogte, en hartritme als kenmerken, en haargroei, speekselaanmaak, en hartfunctie als gedragingen binnen dat systeem. Een trein heeft een ruimtelijke inhoud (kenmerk), en transporteert mensen (gedrag). Een vogel heeft een maaginhoud en vliegt.

Er zijn een aantal concepten die je leert wanneer je leert programmeren, en wanneer je deze concepten in de echte wereld kan toepassen, leer je de echte wereld met echte problemen te vertalen naar programmeeroplossingen.

[dejeroen]

leverage010 schreef op maandag 6 december 2021 @ 16:52:
Abstractie. Ik kijk terug naar de skills die ik heb ontwikkeld en welke het meest relevant waren en er sprint er echt 1 naar boven, en dat is abstractie.

Binnen het Object-georienteerd programmeren draait alles om objecten (duh).
een object is een verzameling van 2 dingen:
- Kenmerken (wat IS je object)
- Gedrag (wat DOET je object).

Ik merkte op een gegeven moment hoe eigenlijk alles in de wereld op deze manier abstract te zien is, en dat alle componenten die een systeem een geheel maken niks anders zijn dan een verzameling van deze regels.

Zo kan je alles om je heen zien als een systeem van dit soort elementen. Jij bent zo'n systeem, met een haarkleur, monddroogte, en hartritme als kenmerken, en haargroei, speekselaanmaak, en hartfunctie als gedragingen binnen dat systeem. Een trein heeft een ruimtelijke inhoud (kenmerk), en transporteert mensen (gedrag). Een vogel heeft een maaginhoud en vliegt.

Er zijn een aantal concepten die je leert wanneer je leert programmeren, en wanneer je deze concepten in de echte wereld kan toepassen, leer je de echte wereld met echte problemen te vertalen naar programmeeroplossingen.

Dit heb je eigenlijk al op de basisschool gehad, maar toen noemden we het zinsontleding.
Nemen we het standaard voorbeeld van een bibliotheeksysteem.

De klant komt met het volgende verhaal:
Ik wil boeken kunnen uitlenen aan personen
Elk boek heeft een titel, jaar van uitgave en ik wil kunnen weten hoeveel er op voorraad zijn
Ik wil dat iemand maximaal 2 boeken tegelijk kan meenemen om te lenen.

Een programmeur komt dan waarschijnlijk met Persoon en boek als Objecten, en als functies iets als leenUit(persoon, List<Boek>) en checkBoekAantal(titel, jaarVanUitgave).

Een kind uit groep 8 komt waarschijnlijk met Persoon, en Boek als lijdend voorwerp van de zinnen, en komt met "uitlenen" en "weten hoeveel er op voorraad zijn" als het gezegde (ongeveer, ik was nooit goed in Nederlands en taal op school).

Voor het bepalen van wat je als objecten, methodes/functies en parameters gaat gebruiken, kan je terugvallen op de zinsontleding die je ooit op de basisschool hebt gehad, mocht je daar een beetje goed in zijn geweest.

[Titusvh]

leverage010 schreef op maandag 6 december 2021 @ 16:52:
Abstractie. Ik kijk terug naar de skills die ik heb ontwikkeld en welke het meest relevant waren en er sprint er echt 1 naar boven, en dat is abstractie.

Binnen het Object-georienteerd programmeren draait alles om objecten (duh).
een object is een verzameling van 2 dingen:
- Kenmerken (wat IS je object)
- Gedrag (wat DOET je object).

Ik merkte op een gegeven moment hoe eigenlijk alles in de wereld op deze manier abstract te zien is, en dat alle componenten die een systeem een geheel maken niks anders zijn dan een verzameling van deze regels.

Zo kan je alles om je heen zien als een systeem van dit soort elementen. Jij bent zo'n systeem, met een haarkleur, monddroogte, en hartritme als kenmerken, en haargroei, speekselaanmaak, en hartfunctie als gedragingen binnen dat systeem. Een trein heeft een ruimtelijke inhoud (kenmerk), en transporteert mensen (gedrag). Een vogel heeft een maaginhoud en vliegt.

Er zijn een aantal concepten die je leert wanneer je leert programmeren, en wanneer je deze concepten in de echte wereld kan toepassen, leer je de echte wereld met echte problemen te vertalen naar programmeeroplossingen.

Haal jij hier niet abstractie door elkaar met encapsulation?
Eigenschappen en gedrag samen is encapsulation.

Losknippen van de specificatie en de implementatie (het wat scheiden van het hoe) is m.i. abstractie.

Door tegen abstracties (bv interfaces in java of C#) te programmeren maak je je code veel flexibeler en testbaarder. Doordat je van implementatie kan wisselen en de aanroeper het niet kan schelen HOE je het doet, als je het maar doet.

[leverage010]

dejeroen schreef op maandag 6 december 2021 @ 17:36:
[...]
Dit heb je eigenlijk al op de basisschool gehad, maar toen noemden we het zinsontleding.

Dat parallel heb ik eerlijk gezegd nog nooit getrokken, nice!
Nu helpt het wellicht niet dat ik vreselijk slecht was in dit vak vroeger

Titusvh schreef op maandag 6 december 2021 @ 19:14:
[...]
Haal jij hier niet abstractie door elkaar met encapsulation?

Encapsulatie draait ook om properties en methods, maar er zijn meer concepten die dat doen. Encapsulatie specifiek draait om het clusteren van properties en data in een class, en het privatizeren van eigenschappen en methodes om er voor te zorgen dat de directe implementatie niet bereikbaar is van buitenaf.

Om een vergelijking te trekken zou bijvoorbeeld een baarmoeder een geëncapsuleerde class zijn, waar de methodes die te pas komen bij de ontwikkeling van de foetus "private" methods zijn.

Het feit dat je het concept van encapsulatie los kan trekken van zijn programmeer-implementatie en kan toepassen op een ander begrip is abstractie.

the act of considering something as a general quality or characteristic, apart from concrete realities, specific objects, or actual instances.

Vanuit het latijnse begrip draait het ook altijd om het "wegnemen" van iets (zo kan je ook een object weg-abstracten door het te stelen). Waar ik op doel is het wegnemen van concrete (implementatie) details, en dingen beschouwen als een set van properties en methods.

[ Voor 13% gewijzigd door leverage010 op 07-12-2021 09:58 ]

[dejeroen]

leverage010 schreef op dinsdag 7 december 2021 @ 09:55:
[...]

Dat parallel heb ik eerlijk gezegd nog nooit getrokken, nice!
Nu helpt het wellicht niet dat ik vreselijk slecht was in dit vak vroeger

Het was mij ook niet opgevallen, het was dat tijdens een stage iemand van support mij vroeg hoe wij eigenlijk tot database ontwerpen kwamen want die persoon wilde zelf ook wat meer ontwikkel taken uitvoeren en vroeg wat ik als stagiair leerde tijdens de opleiding over datamodellen maken.
Ik vertelde dat we dat niet echt hadden gehad op de opleiding, iets om te bepalen wat nu een variabele moet worden, of een database kolom en een veld.

Ik vertelde dus maar hoe ik het mijzelf had aangeleerd.
Toen pakte ik een stuk opdrachtomschrijving van mijn stage en vertelde dat ik eerst de woorden ging zoeken waar ik database kolommen van wilde maken en een kleurtje gaf en dik gedrukte maakte, en daarna met een andere kleur de woorden ging zoeken voor de velden bij de kolommen en de primary keys maakte ik ook nog eens cursief.

En dat ik daarvan wat probeerde te maken, werkt dat niet, dan verhaal opnieuw doorlezen of ik niet wat was vergeten.
De supportmedewerker viel het toen op dat ik eigenlijk bezig was met zinsontleding zonder dat ik het door had. en samen hebben we toen het datamodel gemaakt op die manier. De supportmedewerker had een achtergrond in taal, maar kon niets vinden qua werk in die richting, en was dus omgeschoold tot support medewerker.


En nu denk ik steeds meer dat het niet uitmaakt welke opleiding je hebt gehad, er is altijd plek voor je in de IT, je moet alleen weten waar je de kennis kunt toepassen. Het is niet altijd het programmeren, maar het kan dus ook zijn dat je heel goed de wensen van de klant kunt omzetten in software, dat dan door een programmeur kan worden gebouwd.

[leverage010]

dejeroen schreef op dinsdag 7 december 2021 @ 10:16:
[...]
De supportmedewerker had een achtergrond in taal, maar kon niets vinden qua werk in die richting, en was dus omgeschoold tot support medewerker.

Prachtig voorbeeld. We weten natuurlijk allemaal hoeveel resource schaarste er in IT in het algemeen, en ik denk dat dit soort dingen ons helpen met het vinden van IT talent in andere sectoren. Taalkunde als backbone voor database-modeling, who knew .

[mr.paaJ]

Je had ze vast al gevonden maar dit zijn de boeken die ik net uit heb en echt véél eerder had moeten lezen:

Refactoring (Fowler) - Veel code problemen waar je zeker tegenaan gaat lopen met de oplossingen.
Pragmatic Programmer (Thomas/Hunt) - overzicht aspecten programmeur zijn, aanknooppunt om verder te verdiepen.
Clean Code (Martin) - Wat dieper op practices.

Die laatste is ook in grote lijnen te vinden in zijn youtube presentaties, ik startte hier en was in no-time 8 uur verder, daarna krijg je natuurlijk automatisch meer soortgelijke video's.

[OB1]

Een leuke manier om de denkwijze en logica op een lager niveau onder de knie te krijgen is LightBot (https://lightbot.com/). Dit gebruikte mijn opleiding tijdens de intake als opdracht.

[retoohs]

FixDeluxe schreef op maandag 18 oktober 2021 @ 14:43:
Vorig jaar met school moesten we een desktopapplicatie maken waarin we routes konden berekenen en klantgegevens konden bewerken. Daar merkte ik dat ik gewoon geen idee had hoe ik aan de code moest beginnen, of hoe ik de ontwerpen moest omzetten in code...

Voor zo'n schoolproject wordt meestal een framework gebruikt wat van zichzelf al een MVC structuur heeft. Als je start dan begin je eerst met het opzetten van de M van de MVC, dus eerst een klassen diagram of ERD maken. Je moet adhv de beschrijving van de opdracht bedenken welke domein klassen je nodig hebt. Als je dit lastig vindt dan zou ik beginnen om daar eens een cursus of tutorial in te volgen.
Als dat eenmaal staat dan kan je met de V & C verder van MVC. Dit moet je gewoon veel gaan oefenen zodat je volgende jaar goed mee kan draaien. Als je het goed onder de knie hebt dan kan je verder kijken naar bijvoorbeeld design patterns, clean code en andere applicatie structuren dan MVC

[Scr33x0r]

Ik lees hier best veel goede dingen. Als ik kijk naar mezelf en hoe ik begonnen ben. In die tijd programmeerde (vroeger noemde ze dat nog scripten) in PHP3.. Objecten bestonden niet, object georienteerd had ik nog nooit van gehoord en design principles? Geen idee..

Wat de meesten hier echter wel zeggen, deel problemen op in kleine problemen. Vroeger zeiden veel mensen, je moet goed zijn in Wiskunde, dan kun je ook goed worden in programmeren. Ik was best ok in wiskunde, maar ik was veel beter in Economie. Dat was logisch, beredeneren, als dit gebeurd, dan gebeurd vervolgens dit. Oorzaak -> gevolg opzoeken. In mijn optiek is programmeren niet veel anders. Je bent op zoek naar een gevolg, hoe vindt je de oorzaak en hoe kan je daartoe komen. Beredeneer het helemaal terug (overigens ook een top skill om te hebben als je moet debuggen).

Ik ben dus heel procedureel begonnen, vroeger gooide ik al mijn functies in, hoe kan het ook anders: functions.php. Op een gegeven moment werden het zoveel kleine deel probleempjes, dan ging ik ze maar opsplitsen. functions.invoices.php, functions.customers.php bla bla. Nou je ziet de classes bijna ontstaan. En zo ben ik uiteindelijk doorgegroeid naar OOP. Ja, dan moet je opeens allemaal extra dingen leren, states, stateless etc. Maar in de basis, doet het er niet toe. Ja handig om te weten, maar als je begint met het op kunnen splitsen van grote problemen in kleine behapbare stukjes, dan kom je denk ik een heel eind.

Ik lees hier echt van alles over UMLs, ERDs etc. Als het je helpt bij het overzicht houden, prima, moet je doen. Maar ik vraag me af of het je helpt bij het "denken als een programmeur".

[retoohs]

Scr33x0r schreef op vrijdag 24 december 2021 @ 21:15:
Ik lees hier echt van alles over UMLs, ERDs etc. Als het je helpt bij het overzicht houden, prima, moet je doen. Maar ik vraag me af of het je helpt bij het "denken als een programmeur".

Je kan het gebruiken om na te denken over software zonder code te gebruiken. Met code ben je al met de implementatie bezig.
Het lijkt me inderdaad niet handig om super veel UML te studeren voor dit moment maar als je met OOP software gaat werken is het kunnen ontwerpen van een domein wel een goede vaardigheid lijkt me.

[CornermanNL]

Denken als een programmeur is oplossingen bedenken voor aangedragen proces problemen in de software die voor dat proces gebruikt wordt, vaak binnen kaders die lang geleden gezet zijn. En dan kom je vaak op oplossingen die niet in de theorie zouden passen.

Dat geeft niets, het leren van de theorie is zeer nuttig om de diepte verder in te gaan en te begrijpen waar bepaalde zaken vandaan komen.

Het belangrijkste aan programmeren is vlieguren maken. Daarbuiten is het belangrijk om ervaring te krijgen en te leren denken op een analytische manier. Dus meerdere kanten van een probleem kunnen belichten en daar een oplossingsrichting bij kunnen bedenken.

Het gebeurd vaak dat men al begint met programmeren als het probleem nog niet duidelijk is en de oplossing te snel gezocht wordt. Een belangrijke factor blijft de vraag waarom, iets is namelijk vaak niet zo als men verteld. De analyse van het probleem is niet zoals die in eerste instantie wordt voorgesteld.

Het is dus het gereedschap leren gebruiken , zeg maar het programmeren zelf, de omgeving waarin de software moet draaien, het eco systeem van systemen , mensen en processen. En leren omgaan met de mensen die in een bepaald verband , vaak wisselend vragen om oplossingen, verbeteringen en aanpassingen aan de software en de processen binnen het eco systeem.

[emnich]

Leuk topic. Het is duidelijk dat er mensen zijn die vooral leren van theorie en die leren van praktijk.

Ik leer vooral van de praktijk. Ik kan me niet voorstellen dat eerst leren over algoritmes en datastructuren mij had geholpen in het begin. Natuurlijk had ik dan bepaalde fouten niet gemaakt maar van fouten leer je en zolang je niet in je eentje verantwoordelijk bent voor een product, is het maken van fouten helemaal niet erg.

Mijn advies is dan ook gewoon beginnen met iets kleins en het dan langzaam uitbreiden. Deel het grote probleem op in hele kleine stukjes en begin met het oplossen van het eerste probleem. Daarna bouw je dat langzaam uit. Je hoeft ook nog niet het hele probleem uitgeschreven te hebben.

Dus als je een pinautomaat moet maken, begin je met het meest tastbare, een keyboard om je pin in te toetsen. Daarna volgen de andere stappen vanzelf.

Je gaat dan absoluut spaghetti code maken en het 30 keer opnieuw moeten doen maar net als met lopen moet je eerst 100 keer vallen voordat je het kan.

Zorg er ook voor dat er iemand met je mee kijkt en je tips geeft hoe iets beter kan.

Als je eenmaal beter kan programmeren dan ga je vanzelf meer de theorie in, letten op performance, efficiëntie en vooral veel meer/beter vóóraf plannen.

[DocktorDicking]

Ik ben van mening dat doorzettingsvermogen de grootste rol speelt bij het wel leren programmeren en het niet leren programmeren. En zoals meerdere tweakers al roepen: van praktijk leer je het meeste, hier sluit ik mij bij aan.

Tijdens mij opleiding liep ik ook vaak vast op theoretische onderwerpen en opdrachten, totdat ik er gewoon mee begon. Meestal dwaalde ik eerst een eind af maar uiteindelijk had ik een oplossing, hiervoor moest ik wel een x aantal keer de opdracht er opnieuw bij pakken. Van sommige docenten heb ik ook heel veel opgestoken, vooral de docenten die de moeite nemen om jou spagetti door te lezen en jou te voorzien van feedback zijn veel waard geweest in mijn opleiding.

Voordat mij opleiding begon had ik al een bedrijf gevonden waar ik voor een appel en een ei aan de slag kon als "noob" met de motto "ik kan niks maar ik kan alles leren". Daar werk ik nu inmiddels al een aantal jaren fulltime als applicatie ontwikkelaar.

Ik ben mijn opleiding (voltijd) blanco begonnen in 2015 en ben in het tweede jaar overgestapt naar deeltijd i.c.m. een fulltime baan als "Jr. Ontwikkelaar". Ik herinner me de eerste les programmeren nog wel, daar stapte ik 100% blanco in en had meteen me twijfels of dit wel voor mij was. De zin "Variabel difineren/initialiseren" was al magie.

Uiteindelijk na veel doorzetten en sociaal veel opzij zetten heb ik alles kunnen bijspijkeren en heb ik kunnen afstuderen met een mooie 8.0 als eind cijfer. Vooral in de eerste 2 jaren van mijn opleiding heb ik erg veel vrije tijd "opgeoffert" om kennis op te doen. Al vrij snel begon ik het ook echt leuk te vinden want progressie.

Ik liep ook heel erg aan tegen het "hoe denk je als programmeur" en achteraf kan ik zeggen dat je dat gewoon moet negeren. Lekker aankloten en rond neuzen om SO en google kom je een stuk verder mee dan twijfelen aan je mindset en of je het wel ooit gaat begrijpen.

Mocht je een keer willen sparren kan je me rustig een PBtje sturen

[ Voor 0% gewijzigd door DocktorDicking op 04-01-2022 14:58 . Reden: Tentamen nederlands heb ik 5 keer over gedaan ;) ]