De Devschuur Coffee Corner - Iteratie ➓

[.Gertjan.]

F.West98 schreef op vrijdag 09 september 2016 @ 21:38:

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Wat een aardige Tweaker
Probleem blijft altijd dat er meerdere wegen naar Rome leiden en je in software development al snel verzandt in een discussie over persoonlijke voorkeuren. Veel codereviews die men onderling doet gaan over guidelines, dan lopen collegae elkaar af te kraken dat het schijnbaar moeilijk is om je aan de standaarden te houden en je daarom slechte en onleesbare code maakt. Dat soort reviews gaan bij mij in de vuilnisbak, want die slaan nergens op. Zolang het maar consistent is, dan wen je echt wel aan de codeer standaard van een developer. Geloof me, ik heb genoeg code gezien die 100% voldeed aan de guidelines, maar echt technisch om te janken was en zwaar instabiel bleek te zijn.

Een review moet meer zien op het naleven van bepaalde principes en het maken van code die begrijpelijk is. Of een accolade op de goede regel staat boeit in principe geen moer voor de onderhoudbaarheid.

Zelf ben ik veel bezig met de kwaliteit van code, aangezien ik een team van 9 man aanstuur, met verschillende niveau's. Daar is het belangrijk dat ze een standaard kader hebben waarbinnen ze kunnen werken en dat ze kunnen vertrouwen dat de code om hen heen stabiel genoeg is (en ze dat ook als referentie mogen gebruiken). Daarnaast werken we ook samen met Fontys Hogescholen op een aantal projecten, waarbinnen wij zwaar inzetten op kwaliteit en good-code-craftmanship. Heb diverse interessante gesprekken gehad met mensen daar en het blijft lastig om in die 4 jaar mensen echt te leren programmeren op een goede manier. Je kan niet meteen aankomen met een HelloWorldFactoryBuilderProxyDecorator in het eerste jaar, maar je wil ze het ook niet onthouden tot hun afstuderen, dus moet je binnen je curriculum best rare sprongen maken. Daarnaast verwacht de business heel andere zaken dan een docent op een opleiding. Wat kan mij een strak technisch design nou boeien, dingen veranderen toch binnen no-time.

[Hydra]

Firesphere schreef op zaterdag 10 september 2016 @ 13:04:
Ik weet niet of "het juiste bedrijf" het correcte antwoord is hier. Zoals ik in m'n vorige post beschreef ben ik van werkgever gewisseld, beginnende bij een bedrijf dat "absoluut geen idee had hoe het moet", naar nu in een positie waar ik team lead ben, me totaal niet druk hoef te maken over deployments etc., een geweldig operations team om directe issues op te vangen en constant leer over hoe je team dynamics moet benaderen en ben ik veel meer bezig met anderen uit te leggen hoe dingen het beste gedaan kunnen worden etc.
Mijn tijd bij mijn eerste werkgever is enorm waardevol geweest voor mij, als leerschool.
Een slechte leerschool waar je goede kennis uit opdoet, is ook een leerschool geweest achteraf.

Ik ben het hierin helemaal met je eens hoor, maar bedrijfscultuur is vaak niet makkelijk te veranderen. Jij zat dus ook bij het 'juiste' bedrijf in de zin dat er nog wat veranderd kon worden. Als je in een team komt waar alle devs vinden dat unit tests tijdsverspilling zijn ga je dat in je eentje meestal niet naar binnen krijgen. Ik heb dit zelf meegemaakt (vandaar dat ik er wat allergisch voor ben); uiteindelijk vallen alle developers onder het mom van "tijdsdruk" weer terug in hun oude patronen.

F.West98 schreef op zaterdag 10 september 2016 @ 14:05:
Ja dat klopt. Het probleem is dat de serieuzere bedrijven vaak geen zin hebben in studenten die niet voorspelbaar beschikbaar zijn. Ik werk tot nu toe altijd volgens een 0-urencontract en echt alleen zodra ik tijd heb. Serieuzere, grotere bedrijven hebben harde deadlines en dan kan ik daar moeilijk(er) aankomen met "ja sorry ik kon écht niet meer want heb vorige week 5 tentamens gehad".
Ik ga denk ik wel voor volgende zomer het goed aanpakken bij een serieuzer bedrijf, want zo'n periode van enkele weken/maanden constante beschikbaarheid werkt een stuk beter in dat geval.

Ik raad je aan om ook gewoon lekker van je tijd nu te genieten. Werken kan je je hele leven nog.

[incaz]

.Gertjan. schreef op zaterdag 10 september 2016 @ 17:23:
[...]
Heb diverse interessante gesprekken gehad met mensen daar en het blijft lastig om in die 4 jaar mensen echt te leren programmeren op een goede manier. Je kan niet meteen aankomen met een HelloWorldFactoryBuilderProxyDecorator in het eerste jaar, maar je wil ze het ook niet onthouden tot hun afstuderen, dus moet je binnen je curriculum best rare sprongen maken. Daarnaast verwacht de business heel andere zaken dan een docent op een opleiding.

Maar het is dus wel zonder meer een probleem met de kwaliteit van de opleiding als de docenten zich hierin niet bewust zijn van die 'rare sprongen' die ze (moeten) maken, en niet duidelijk zijn over wat ze willen beoordelen.

Als men het gebruik van de FactoryBuilderProxyDecorator wil beoordelen (of iets algemener: bouw iets waarin 4 patterns tot z'n recht komen) dan moet je dat zeggen en goed duidelijk maken vantevoren. Dan kun je als docent ook beslist aangeven: ja, ik weet dat het voor een hello-world-app grote zware belachelijke overkill is, maar dit vak gaat over Factories en Decorators en dus ligt de nadruk daarop.

Want het is in elk geval niet fair om de ene keer kritiek te geven op overengineeren en de andere keer voor shortcuts, en dan te verwachten dat de student/junior een magische kristallen bol heeft waarin niet alleen staat wat de perfecte balans is tussen overengineeren en hacken, maar vooral ook wanneer die balans ineens totaal een andere kant opschuift.

Iedere docent zou moeten beginnen met 100 keer op te schrijven (en daarna nog minstens 3 maal dagelijks) dat het onderwijs tot doel heeft om hun studenten te ontwikkelen, niet alleen maar om ze cijfers te geven of werkstukken in te leveren die volslagen zielloos zijn en vooral niks buiten de lijntjes kleuren. Die bureaucratische werkelijkheid is na de opleiding al treurig genoeg (strict je function specs uitvoeren maar vooral niet proactief meedenken is een bedrijfsmodel bij die gezellige techbedrijven toch? Maar dat kost ons al meer dan genoeg, aangezien het voor een deel projecten van de overheid zijn. Ik heb liever dat dat niet de basis is van onze opleidingen.)

[Skyaero]

incaz schreef op zaterdag 10 september 2016 @ 18:06:
[...]
Iedere docent zou moeten beginnen met 100 keer op te schrijven (en daarna nog minstens 3 maal dagelijks) dat het onderwijs tot doel heeft om hun studenten te ontwikkelen, niet alleen maar om ze cijfers te geven of werkstukken in te leveren die volslagen zielloos zijn en vooral niks buiten de lijntjes kleuren.

Ik denk dat je docenten (in ieder geval het merendeel) daar niet voor verantwoordelijk moet houden, maar eerder de wijze van accreditatie (met name Hogescholen). Want die accreditatie kijkt namelijk wel of de student binnen de lijntjes heeft gekleurd, en zodra dat niet het geval is, of de school dan ook een correct (laag) cijfer heeft gegeven. En die accreditatie is behoorlijk verscherpt na het InHolland debacle.

Uiteindelijk is een Hogeschool bezig met zijn eigen voortbestaan en dat betekent zoveel mogelijk geld van de overheid bij elkaar sprokkelen. Dat krijg je door goed door je accreditatie heen te komen en zoveel mogelijk studenten af te laten studeren. Dat ze vervolgens niet klaar zijn voor de arbeidsmarkt, is niet de school zijn probleem.

Maar goed, we zijn al heel wat jaartjes bezig met het afbreken van het Nederlands onderwijsstelsel.

[Caelorum]

Hydra schreef op zaterdag 10 september 2016 @ 17:33:
[...]Als je in een team komt waar alle devs vinden dat unit tests tijdsverspilling zijn ga je dat in je eentje meestal niet naar binnen krijgen. Ik heb dit zelf meegemaakt (vandaar dat ik er wat allergisch voor ben); uiteindelijk vallen alle developers onder het mom van "tijdsdruk" weer terug in hun oude patronen.[...]

Tja soms heb je er ook geen ene klap aan. Blijkbaar vond dat team snelheid van ontwikkelen belangrijker dan eventuele bugs die ergens inslopen. Is dat dan fout? Ben je dan als team/bedrijf ineens minder? (of niet goed?)

[incaz]

Skyaero schreef op zaterdag 10 september 2016 @ 19:45:

Ik denk dat je docenten (in ieder geval het merendeel) daar niet voor verantwoordelijk moet houden, maar eerder de wijze van accreditatie (met name Hogescholen). Want die accreditatie kijkt namelijk wel of de student binnen de lijntjes heeft gekleurd, en zodra dat niet het geval is, of de school dan ook een correct (laag) cijfer heeft gegeven. En die accreditatie is behoorlijk verscherpt na het InHolland debacle.

Het nog verder abstraheren van de verantwoordelijkheid is altijd een goede oplossing (not).

Ik ben daar dus echt heel erg tegen: Hogescholen en Uni's dienen goed onderwijs te leveren en dat inhoudelijk te kunnen verantwoorden.
Bij het InHolland-debacle hadden er een heel aantal managers en bestuurders op de pijnbank moeten komen - maar meer regels en bureaucratie en toezicht dat niet de diepte in durft te gaan geeft geen kwaliteit maar eenheidsworst. Dat hoeven we niet te willen. De docenten in het hoger onderwijs zouden hun vak weer moeten opeisen, stukken meer dan ze doen. En de universiteit moet ook weer teruggeclaimd worden. Opleiding, kennisverspreiding, diepe intrinsieke kwaliteit, inzicht, dat soort dingen zijn belangrijk. Oppervlakkige streefcijfers niet, dat zijn alleen maar slechte benaderingen en na een paar jaar weten degenen die geen zin hebben om de diepte in te gaan feilloos hoe ze zo'n oppervlakkig systeem kunnen bespelen. Terug naar de kern, dat is veel belangrijker.

(Overigens - ik vind 'klaar voor de arbeidsmarkt' dus eigenlijk niet echt het hogere doel, ik vind onderwijs en de ontwikkeling van mensen en hun kennis en vaardigheden op zich belangrijk. Lijkt me meer dan prima dat de arbeidsmarkt zelf investeert in de specifieke arbeidsgerelateerde zaken. De verwachting dat het onderwijs dat allemaal op moet knappen is volgens mij redelijk onrealistisch.)

Maar goed, dat is wel vrij rigoreus, dus laten we het voor nu iets simpeler houden: dat docenten zich in elk geval bewust worden van hun eigen perspectief, erkennen dat een onderwijssetting in allerlei opzichten fundamenteel anders is dan een arbeidssetting, en daar rekening mee houden in hun verwachtingen en beoordelingen.

(Overigens nog een punt dat ik nu bedenk: als we geen zin hebben om het menselijke, creatieve deel te aanvaarden en alleen maar eenduidige paden en scoring willen, waarom investeren we dan niet tijdelijk wat geld in het opzetten van een paar goede lesmethodes en schrappen we de hele docent? Ik denk dat de meeste docenten bij de vakken vervangen kunnen worden door een goedopgezette spelvorm. Enne... dit is beslist serieus.)

[jip_86]

Eerlijk gezegd vind ik niet dat ik slecht afgeleverd ben door mijn opleiding. In het tweede jaar al meteen stage gelopen, meteen gezien dat je pas echt begint met leren als je met je voeten in de bagger (al dan niet van andermans code). Je komt met een ideaalbeeld van de opleiding af met mooie code en designpatterns en alles. Maar de werkelijkheid is dat je misschien wel aan een pakket gaat werken wat al tientallen jaren aan het evolueren is naar de huidige staat. Dan zul je ook wel eens baggercode moeten schrijven omdat er op dat moment geen tijd is of het risico te hoog is om de spaghetti uit elkaar te gaan trekken. Dat is niet echt te leren op een opleiding volgens mij.

[Skyaero]

incaz schreef op zaterdag 10 september 2016 @ 21:33:
Bij het InHolland-debacle hadden er een heel aantal managers en bestuurders op de pijnbank moeten komen - maar meer regels en bureaucratie en toezicht dat niet de diepte in durft te gaan geeft geen kwaliteit maar eenheidsworst. Dat hoeven we niet te willen. De docenten in het hoger onderwijs zouden hun vak weer moeten opeisen, stukken meer dan ze doen.

Het probleem bij InHolland lag veel dieper. Het gedrag van de bestuurders kwam voort uit het feit dat de Hogeschool werd afgerekend op het aantal studenten dat een diploma verkreeg. Niet op het niveau van de student. Als je op verkeerde wijze beloont, dan stimuleer je fout gedrag. Dat hebben we ook in de bankensector gezien. Dat degene die fout gedrag hebben vertoont er zo makkelijk af zijn gekomen is een heel ander verhaal...

En de universiteit moet ook weer teruggeclaimd worden. Opleiding, kennisverspreiding, diepe intrinsieke kwaliteit, inzicht, dat soort dingen zijn belangrijk. Oppervlakkige streefcijfers niet, dat zijn alleen maar slechte benaderingen en na een paar jaar weten degenen die geen zin hebben om de diepte in te gaan feilloos hoe ze zo'n oppervlakkig systeem kunnen bespelen. Terug naar de kern, dat is veel belangrijker.

Volgens mij is dat bij de meeste universitaire studies wel in orde. Universiteiten hebben immers nog een tweede belang: meedoen met de top van het wereldwijde academisch onderzoek. En daarvoor heb je masterstudenten nodig die voldoende competent en kundig zijn om als PhD verder te gaan. Een deel van de arbeidsmarkt voor universiteitsstudenten, is de universiteit zelf.

(Overigens - ik vind 'klaar voor de arbeidsmarkt' dus eigenlijk niet echt het hogere doel, ik vind onderwijs en de ontwikkeling van mensen en hun kennis en vaardigheden op zich belangrijk. Lijkt me meer dan prima dat de arbeidsmarkt zelf investeert in de specifieke arbeidsgerelateerde zaken. De verwachting dat het onderwijs dat allemaal op moet knappen is volgens mij redelijk onrealistisch.)

Je hebt niets aan het financieren van een student, als hij/zij met zijn hoogopgeleide kennis en kunde niets in de arbeidsmarkt kan. Uiteindelijk draait de Nederlandse economie op commerciële bedrijven, welke hun concurrentiepositie veelal wordt bepaald door onze kennis. Moet zo'n student natuurlijk wel bij zo'n bedrijf aan de slag kunnen.

Daarmee bedoel ik niet dat er allerlei hele specifieke zaken worden geleerd, dat past niet in 4-5 jaar. Maar aandacht voor de niet-technische kan (projectmatig werken, presenteren, rapporten schrijven) is wel van belang. Daarnaast willen universiteiten nog wel eens nadruk leggen op kennis in plaats van vaardigheden. Je hebt veel meer aan iemand met een goed analytisch denkvermogen die snel nieuwe domeinkennis kan opdien, dan iemand met domeinkennis, dat waarschijnlijk al verouderd is. Zie de eerder discussie in het topic: niet alle design patterns die nog in de theorieboeken staan, worden in de praktijk gezien als 'good practice'

(Overigens nog een punt dat ik nu bedenk: als we geen zin hebben om het menselijke, creatieve deel te aanvaarden en alleen maar eenduidige paden en scoring willen, waarom investeren we dan niet tijdelijk wat geld in het opzetten van een paar goede lesmethodes en schrappen we de hele docent? Ik denk dat de meeste docenten bij de vakken vervangen kunnen worden door een goedopgezette spelvorm. Enne... dit is beslist serieus.)

Omdat studenten (en mensen in het algemeen) informatie op andere wijze opnemen. Sommigen voelen zich beter bij een geschreven iets, anderen bij een gesproken. Daarnaast vereist een lesprogramma zonder docent veel zelfstudie en zelfdiscipline. Op de universiteit wordt dat al van je verwacht, maar dat ga je op de Hogeschool niet redden.

[ard1998]

.Gertjan. schreef op zaterdag 10 september 2016 @ 17:23:
[...]
Heb diverse interessante gesprekken gehad met mensen daar en het blijft lastig om in die 4 jaar mensen echt te leren programmeren op een goede manier. Je kan niet meteen aankomen met een HelloWorldFactoryBuilderProxyDecorator in het eerste jaar, maar je wil ze het ook niet onthouden tot hun afstuderen, dus moet je binnen je curriculum best rare sprongen maken.

Dan zal ik hen nog mooier maken. Op het albeda college waar ik nu het eerste jaar Applicatie ontwikkelaar doe, zouden we in het eerste jaar 3 programeertalen krijgen (exclusief HTML en CSS) namelijks : PHP, JavaScript en (My)SQL. Doordat een van de docenten development niet kan coderen krijgen we van hem fotobewerking ?!?!! En blender ?!?!! In mijn kostbare uren, en ik vind het ook zonde van mijn studiegeld. Tijdens de lessen web development is achteraf Jquery en de docent werkomgeving heeft c toegevoegd aan de opleiding (waar ik eigenlijk blij mee ben IVM de opleiding die ik hierna wil doen).

Dus 5 programmeertalen, 2 scripttalen en 2 vakken waarvan ik voor fotobewerking ergens in een klein verborgen hoekjes een beetje nut zie, maar wat ik met blender moet, geen idee. En dat allemaal in het eerste leerjaar. Ben benieuwd hoe het afloopt.

[jip_86]

Docent die niet kan coderen? Wat doet die daar?

[Caelorum]

ard1998 schreef op zondag 11 september 2016 @ 07:31:
[...]. Doordat een van de docenten development niet kan coderen krijgen we van hem fotobewerking ?!?!! En blender ?!?!! In mijn kostbare uren, en ik vind het ook zonde van mijn studiegeld. [...]

Goed dat je dat inziet. Heb je dit ook al bij je opleiding aangegeven? Je zou er namelijk bijna een deel van je collegegeld voor terug eisen.
Op het HBO ook wel eens een docent gehad die dacht het zich gemakkelijk af te maken. Die is nadat we heb duidelijk maakten dat wij (en de overheid) hem betaalden van gedachten verandert.

[incaz]

Skyaero schreef op zaterdag 10 september 2016 @ 22:39:
[...]

Het probleem bij InHolland lag veel dieper. Het gedrag van de bestuurders kwam voort uit het feit dat de Hogeschool werd afgerekend op het aantal studenten dat een diploma verkreeg. Niet op het niveau van de student. Als je op verkeerde wijze beloont, dan stimuleer je fout gedrag.

Quatsch, die bestuurders hadden gewoon zelf de keuze. Zij kozen ervoor om outputcijfers en dergelijke leidend te maken, te willen streven naar een grote en niet een goede onderwijsinstelling, zoveel mogelijk geld binnen te halen ter meerdere eer en glorie van zichzelf en niet voor de kern van hun taak: goed onderwijs geven.

Het was en is zonder meer mogelijk om daar andere keuzes in te maken. Zeker zijn er nadelen aan het bekostigingssysteem - maar die nadelen *dwongen* de bestuurders niet om daar misbruik van te maken, ze maakten het alleen maar mogelijk.

In heel algemene zin valt er wel wat voor te zeggen dat foute systemen fout gedrag aanmoedigen, maar dat ontslaat de topmensen niet van hun verantwoordelijkheid. Als het systeem niet deugt moeten ze dat systeem aan de orde stellen, openlijk, en niet er misbruik van maken en dan zeggen dat ze er niks aan konden doen.

Dat hebben we ook in de bankensector gezien. Dat degene die fout gedrag hebben vertoont er zo makkelijk af zijn gekomen is een heel ander verhaal...

Ja, en een van de aspecten is ook daar dat we doen alsof men willoos slachtoffer was van het systeem. Maar dat systeem is voor het grootste gedeelte ZELF zo ontstaan: omdat de mensen met veel invloed doen alsof ze weinig invloed hebben en alleen maar volgend zijn.

Daarmee bedoel ik niet dat er allerlei hele specifieke zaken worden geleerd, dat past niet in 4-5 jaar. Maar aandacht voor de niet-technische kan (projectmatig werken, presenteren, rapporten schrijven) is wel van belang.

Mwah. Veel liever zou ik aandacht willen hebben voor kritisch denken, helder argumenteren, bij de kern van de zaak blijven, en een basis in kennisleer (hoe kun je dingen weten en vooral ook hoe niet) en ethiek. Daar hebben we wat aan. Meer mensen die glad kunnen praten en rapporten schrijven die toch niemand leest omdat goed lezen zowel niet geleerd is als niet goed wordt ingepland... nee dank je.

Omdat studenten (en mensen in het algemeen) informatie op andere wijze opnemen. Sommigen voelen zich beter bij een geschreven iets, anderen bij een gesproken.

En dus bieden we het aan op de manier die de docent wil, zonder dat dat ook maar iets te maken heeft met de student? Natuurlijk kan een goedontwikkelde lesmethode juist meer wegen bewandelen dan een (1) docent voor een zaal vol studenten, waarbij het tempo en de aanbieding voor al die studenten dus exact gelijk is. (Met een beetje mazzel heb je nog de mogelijkheden om de slides zelf thuis te bekijken, maar dat is het ook wel in het tegemoet komen aan verschillende leerstijlen toch?)

[Avalaxy]

jip_86 schreef op zondag 11 september 2016 @ 08:26:
Docent die niet kan coderen? Wat doet die daar?

Op mijn ex-Hogeschool ook, we hadden voor programmeren een docent die voorheen docent Nederlands was. Kon ook niet programmeren. Hij vroeg in jaar 1 aan ons of wij wisten wat exceptions zijn (want zelf had hij geen idee).

[gekkie]

incaz schreef op zondag 11 september 2016 @ 09:19:
[...]
Quatsch, die bestuurders hadden gewoon zelf de keuze. Zij kozen ervoor om outputcijfers en dergelijke leidend te maken, te willen streven naar een grote en niet een goede onderwijsinstelling, zoveel mogelijk geld binnen te halen ter meerdere eer en glorie van zichzelf en niet voor de kern van hun taak: goed onderwijs geven.

Het was en is zonder meer mogelijk om daar andere keuzes in te maken. Zeker zijn er nadelen aan het bekostigingssysteem - maar die nadelen *dwongen* de bestuurders niet om daar misbruik van te maken, ze maakten het alleen maar mogelijk.

In heel algemene zin valt er wel wat voor te zeggen dat foute systemen fout gedrag aanmoedigen, maar dat ontslaat de topmensen niet van hun verantwoordelijkheid. Als het systeem niet deugt moeten ze dat systeem aan de orde stellen, openlijk, en niet er misbruik van maken en dan zeggen dat ze er niks aan konden doen.

Je zou zeggen dat je ze precies daarvoor betaald en dat dat een groot onderdeel is van die "oh zo verantwoordelijke baan" die vervolgens dat salaris zou moeten rechtvaardigen. Helaas "verantwoordelijkheid hebben en nemen" al enige decennia aan een nogal grote inflatie onderhevig dat we ondertussen wel op nihil te lijken zijn aangekomen.

Vervelende is ook dat het steeds meer "generieke" managers zijn zonder veel kennis van de werkvloer met als gevolg een hoop geintroduceerde "meetmethodieken" voor kwaliteit en "performance" de ene nog waardelozer dan de andere. Waar vervolgens helaas wel een groot deel van tijd, middelen, aandacht en waardering heen gaan.

Wat dat betreft heb ik wel eens het gevoel dat we als samenleving onderhand een stuk faillieter zijn als we ons doen voorkomen.

[ Voor 14% gewijzigd door gekkie op 11-09-2016 11:32 ]

[Blue-eagle]

Over code reviews: M'n eerste klus bij nieuwe werkgever leidde tot een codereview met 15 opmerkingen. Erg leerzaam, natuurlijk, maar ik weet niet zo goed of de kritiek terecht is. Bijvoorbeeld:

Ik heb een array met daarin JSON objecten die op hun beurt weer een array met kleuren bevatten. Om alle unieke kleuren eruit te halen kan je een paar dingen doen:

code:

const uniqueColors = [...new Set(product.variants.map(variant => variant.color))];

Of natuurlijk gewoon door alle product.variants loopen, in die loop door de kleuren loopen, en dit in een nieuwe array stoppen als de waarde er nog niet in bestaat.

Ik bedoel, ja, dat kan je inderdaad ook oplossen door bovenstaande code te gebruiken (javascript, ES6), maar dit vind ik een stuk minder leesbaar en zeker minder goed te debuggen.

Ja, mijn code is soms 10 regels, en de andere oplossing zijn er maar 3, maar moet dat nou de voorkeur krijgen?

What say you, Tweakers?

[jip_86]

Uit oogpunt van leesbaarheid zal ik ook eerder een regel meer gebruiken ja. Met C# heb je ook Linq waar je extreem veel in een regel weg kan werken, maar dat is ook verre van handig bij het debuggen.

[DevWouter]

F.West98 schreef op zaterdag 10 september 2016 @ 14:05:
[...]

Ik deel hier weinig omdat dit het topic daarvoor niet is. Maargoed, je bent natuurlijk vrij om op mijn GitHub profiel te kijken.

Als een regel negeer ik ongevraagd advies en daarom probeer ik het ook zo min mogelijk te geven. Echter dat is wel wat je hier een beetje om vraagt

Bovendien heeft het geen zin om op dingen te schieten waar jij al weet van hebt of niks meer gaat doen. Dat is zonde van jou tijd maar ook van mij tijd.

Als jij een keer iets van werk gedaan hebt en je wilt dat daar iemand een keer naar kijkt dan mag je me rustig een PM sturen. Dat is namelijk leuker voor jou en voorkomt frustratie.

Verder (en hier komt dus ongevraagd advies ) moet je veel geduld hebben om werkprocessen binnen een bedrijf te veranderen. Het werkproces veranderen is namelijk een risico en kan namelijk veel tijd (en geld) kosten. Mijn favoriete tactiek is dan ook om mensen één op één te overtuigen door het goeie voorbeeld te geven. De meeste ontwikkelaars zijn toch het soort "Oh, dat is cool, dat wil ik ook" om vervolgens te reageren met "maar dat is zeker complex of niet".
En in sommige gevallen kan je de opdracht krijgen om er mee te stoppen en te concentreren op wat je eigenlijk moet doen "code kloppen", maar goed was zowiezo iemand die het niet helemaal begreep

Echter dat verschilt van persoon tot persoon en bedrijf tot bedrijf.

[Skyaero]

gekkie schreef op zondag 11 september 2016 @ 11:28:
Vervelende is ook dat het steeds meer "generieke" managers zijn zonder veel kennis van de werkvloer met als gevolg een hoop geintroduceerde "meetmethodieken" voor kwaliteit en "performance" de ene nog waardelozer dan de andere. Waar vervolgens helaas wel een groot deel van tijd, middelen, aandacht en waardering heen gaan.

En dit is dus de kern van het probleem. Bestuurders die streven naar goed onderwijs, moeten dat als ideaal hebben, of op de juiste KPI's worden afgerekend. het eerste prefererend boven het tweede. Echter, van het tweede is geen sprake, en van het eerste inmiddels ook al enige tijd niet.

Toevallig las ik vanochtend een reddit post die het goed samenvatte: https://www.reddit.com/r/...us_workers_after/#d7go9ys

Het antwoord van DeepGreen:

The long and the short of it, is if you have managers who don't know what they are doing, they manage from the accounts department and focus on pushing their KPIs in a direction that appears to be an improvement. Cutting costs makes a manager look good, and then they bail out to a higher paid job somewhere else before the true effects are felt.

De afgelopen twee decennia zijn we in Nederland naar het Amerikaanse managementmodel toegegroeid, niet alleen in het hoger onderwijs, maar ook in veel bedrijven. En daar moeten wij mijn inziens zo snel mogelijk weer van af.

Bedrijven staan in dienst van de maatschappij, niet andersom.

[Hydra]

Caelorum schreef op zaterdag 10 september 2016 @ 20:29:
Tja soms heb je er ook geen ene klap aan. Blijkbaar vond dat team snelheid van ontwikkelen belangrijker dan eventuele bugs die ergens inslopen. Is dat dan fout? Ben je dan als team/bedrijf ineens minder? (of niet goed?)

Ligt er aan wat je aan het bouwen bent. Als je een prototype bouwt dat weggeflikkerd wordt, of een MVP die perse binnen een week af moet en er daarna in de planning ruimte is genomen om het gebrek aan tests te fixen, prima. Maar je weet best dat dat niet het soort bedrijven is waar ik het over heb. Als in normale dev practices geen goeie test coverage meeneemt is die dev wat mij betreft gewoon een prutser die de titel "software engineer" niet waard is.

incaz schreef op zaterdag 10 september 2016 @ 21:33:
Ik ben daar dus echt heel erg tegen: Hogescholen en Uni's dienen goed onderwijs te leveren en dat inhoudelijk te kunnen verantwoorden.
Bij het InHolland-debacle hadden er een heel aantal managers en bestuurders op de pijnbank moeten komen - maar meer regels en bureaucratie en toezicht dat niet de diepte in durft te gaan geeft geen kwaliteit maar eenheidsworst. Dat hoeven we niet te willen. De docenten in het hoger onderwijs zouden hun vak weer moeten opeisen, stukken meer dan ze doen. En de universiteit moet ook weer teruggeclaimd worden. Opleiding, kennisverspreiding, diepe intrinsieke kwaliteit, inzicht, dat soort dingen zijn belangrijk. Oppervlakkige streefcijfers niet, dat zijn alleen maar slechte benaderingen en na een paar jaar weten degenen die geen zin hebben om de diepte in te gaan feilloos hoe ze zo'n oppervlakkig systeem kunnen bespelen. Terug naar de kern, dat is veel belangrijker.

Helemaal mee eens. Ik kom zelf van Saxion Enschede (toen nog HEN) af en dat stond in die tijd nog goed aangeschreven, ook in het buitenland. Maar met de fusie en nieuw management was er alleen nog maar oog voor targets halen; en dat is gewoon zo veel mogelijk studenten binnen 4 jaar af laten studeren.

Informatica is daarin lastig omdat veel mensen aan informatica beginnen die vooral computer spelletjes spelen leuk vinden en het dan toch wat minder vinden als informatica vooral toegepaste wiskunde blijkt te zijn. Die vallen en-masse in het eerste jaar uit. Dus tja; dan wordt door het management het instituut gedwongen om de moeilijkheidsgraad hard naar beneden te schroeven en bovendien het mogelijk te maken dat lapswanzen meeliften op anderen in "Project Gestuurd Onderwijs".

Ik heb een tijd geleden zo'n groep van 6 man mogen mentoren: 2 kwamen uberhaupt niet opdagen (en ik moest er aan mentor HARD aan trekken dat ze uit de groep gekiept werden!) en van de andere 4 hebben 2 man al het werk gedaan en er was er maar eentje die wat mij betreft echt potentie had.

Tja. En je dan maar afvragen waarom zo'n papiertje niet meer instant baangarantie bij een topclub is. De inflow in de opleiding is door de 2e fase hard naar beneden gegaan (te weinig tieners met vooral exacte vakken), van de instroom gaat er relatief gezien nu meer door maar van de mensen die afstuderen zijn er gewoon een hoop die tussen de wal en 't schip belanden. Die beginnen dan maar als tester.

ard1998 schreef op zondag 11 september 2016 @ 07:31:
Dan zal ik hen nog mooier maken. Op het albeda college waar ik nu het eerste jaar Applicatie ontwikkelaar doe, zouden we in het eerste jaar 3 programeertalen krijgen (exclusief HTML en CSS) namelijks : PHP, JavaScript en (My)SQL.

Ik hoop van harte dat je hierna door gaat stromen naar HBO. Naar mensen met alleen een dergelijke achtergrond is steeds minder behoefte. Je zit op hetzelfde niveau als een hoop mensen uit een stuk goedkopere landen.

Walgelijk dat dergelijke instituten management hebben die denken dat je ook gewoon met Blender aan de slag kan want dan maak je ook wat op de computer.

[ Voor 9% gewijzigd door Hydra op 11-09-2016 14:09 ]

[ard1998]

Hydra schreef op zondag 11 september 2016 @ 14:06:
[...]


[...]


Ik hoop van harte dat je hierna door gaat stromen naar HBO. Naar mensen met alleen een dergelijke achtergrond is steeds minder behoefte. Je zit op hetzelfde niveau als een hoop mensen uit een stuk goedkopere landen.

Walgelijk dat dergelijke instituten management hebben die denken dat je ook gewoon met Blender aan de slag kan want dan maak je ook wat op de computer.

Het wil ik technische ict doen en daar ga ik me heel goed voor inzetten. Het is gewoon onbegrijpelijk dat dik kan op een beroepsopleiding. Ik zit nu met "Ach, het moet maar zo. Straks kan ik de opleiding doen die ik echt wil"

[mrc4nl]

leuk die nederlandse vertalingen, er is alleen niet nagedacht om de knop ook groter te maken...

[RayNbow]

mrc4nl schreef op zondag 11 september 2016 @ 16:20:
leuk die nederlandse vertalingen, er is alleen niet nagedacht om de knop ook groter te maken...

[afbeelding]

Zo'n probleem ben ik zelf een keer tegengekomen in een simpele utility dat ik moest maken. Oplossing was om *niet* de grootte op te geven voor de knop.

[Caelorum]

Hydra schreef op zondag 11 september 2016 @ 14:06:
[...]
Ligt er aan wat je aan het bouwen bent. Als je een prototype bouwt dat weggeflikkerd wordt, of een MVP die perse binnen een week af moet en er daarna in de planning ruimte is genomen om het gebrek aan tests te fixen, prima. Maar je weet best dat dat niet het soort bedrijven is waar ik het over heb. Als in normale dev practices geen goeie test coverage meeneemt is die dev wat mij betreft gewoon een prutser die de titel "software engineer" niet waard is.
[...]

Mja ik werk in een bedrijf waar het team zo zou kunnen worden verdubbelt en er nog door de klant betaald werk voor minstens een jaar open zou staan. Dan zijn wat minder belangrijke zaken, maar ook dingen die de klant liever een jaar geleden al had gehad. Dat er bugs in zitten nemen zij veelal voor lief als daardoor de features er sneller zijn. In 95% van de gevallen werkt het na introductie (+max een dag) ook gewoon prima. De overige 5% werkt het na een week alsnog goed. Dan kan je in zo'n geval wel tests gaan maken enz. Maar daar zit vrijwel niemand op te wachten.
Overigens hebben wij goede logging en worden kritieke bugs die er wel eens insluipen (onverwachte input, veelal van derde partij via apis) vaak binnen het uur opgelost. Wij monitoren dit in ieder geval actief (er zit altijd 1 iemand op die ook tweedelijns support doet)

Vind jouw stelling in ieder geval wat kort door de bocht. Het is een beetje op het niveau van je bent geen software engineer als je niet object georiënteerd programmeert.

[ Voor 5% gewijzigd door Caelorum op 11-09-2016 16:58 ]

[gekkie]

Skyaero schreef op zondag 11 september 2016 @ 13:58:
[...]
En dit is dus de kern van het probleem. Bestuurders die streven naar goed onderwijs, moeten dat als ideaal hebben, of op de juiste KPI's worden afgerekend. het eerste prefererend boven het tweede. Echter, van het tweede is geen sprake, en van het eerste inmiddels ook al enige tijd niet.

Toevallig las ik vanochtend een reddit post die het goed samenvatte: https://www.reddit.com/r/...us_workers_after/#d7go9ys

Het antwoord van DeepGreen:
[...]
De afgelopen twee decennia zijn we in Nederland naar het Amerikaanse managementmodel toegegroeid, niet alleen in het hoger onderwijs, maar ook in veel bedrijven. En daar moeten wij mijn inziens zo snel mogelijk weer van af.

Bedrijven staan in dienst van de maatschappij, niet andersom.

Mwah ik ben wat genuanceerder denk ik, ze hebben een duidelijke wisselwerking en in een harmonieuze symbiose kom je een stukje verder dan als het parasiteren wordt .. maar dat wel in beide richtingen. Het is alleen geen heel stabiel evenwicht (al was het maar door externe factoren en verleidingen, oorspronkelijk buiten het originele werkveld, zie alle (semi-)overheidsinstellingen die ineens (voor de managers dan) geld moeten gaan uitgeven aan dezelfde zaken als bedrijven (marketing, bling bling, salarissen, bonussen en andere ongein)).

Achja met zoveel mogelijk zelfsturing, gericht meten en weten (waarbij de helft impliciet is doordat je gewoon eens door de tent loopt en dingen *ziet* en *hoort*) en vooraf gewoon eerlijk en duidelijk zijn, en ook tijdens over je eigen falen en je eigen shit ook zelf fixen.
Werkt over het algemeen een stuk prettiger en problemen los je vervolgens ook met elkaar op ipv dat alles star aan regeltjes gebonden is.

Helaas lijkt zo werken alleen steeds lastiger te worden gemaakt omdat de overheid en justitia generieke concepten als redelijkheid en billikheid meer en meer heeft afgeschaft omdat ook die tereinen ogenschijnlijk "geobjectiveerd" moeten worden.
Vrees alleen dat het afbreken van de wijze waarop de samenleving werkte ten gunste van de geobjectiveerdheid nog wel eens semi eenrichting kan zijn en bijzonder lastig om te keren proces.

[F.West98]

.Gertjan. schreef op zaterdag 10 september 2016 @ 17:23:
[...]

Wat een aardige Tweaker

Enorm ja

[...]
Zelf ben ik veel bezig met de kwaliteit van code, aangezien ik een team van 9 man aanstuur, met verschillende niveau's. Daar is het belangrijk dat ze een standaard kader hebben waarbinnen ze kunnen werken en dat ze kunnen vertrouwen dat de code om hen heen stabiel genoeg is (en ze dat ook als referentie mogen gebruiken). Daarnaast werken we ook samen met Fontys Hogescholen op een aantal projecten, waarbinnen wij zwaar inzetten op kwaliteit en good-code-craftmanship. Heb diverse interessante gesprekken gehad met mensen daar en het blijft lastig om in die 4 jaar mensen echt te leren programmeren op een goede manier. Je kan niet meteen aankomen met een HelloWorldFactoryBuilderProxyDecorator in het eerste jaar, maar je wil ze het ook niet onthouden tot hun afstuderen, dus moet je binnen je curriculum best rare sprongen maken. Daarnaast verwacht de business heel andere zaken dan een docent op een opleiding. Wat kan mij een strak technisch design nou boeien, dingen veranderen toch binnen no-time.

Ik ben nu ook studentassistent bij het eerste programmeervak voor informatica- en AI-studenten op de RuG. Het is Imperative Programming in C en daarmee voor velen een struikelblok, direct al in het begin. En het is inderdaad erg lastig om studenten in zo'n korte periode (8 weken) alles aan te leren wat nodig is voor de basis van programmeren. We proberen de kwaliteit direct zo hoog mogelijk te houden en we zijn dan ook vrij streng op gebrek aan indentation, onoverzichtelijke code en onnodig complexe oplossingen. Dit zorgt helaas ook voor vrij hoge uitval (meer dan 50% eerste jaar als ik het goed heb), maar zorgt er wel voor dat in mijn ogen de rest van de opleiding een goed hoog niveau heeft waar je wat aan hebt als je dan ook aan de slag gaat daarna.

[ard1998]

F.West98 schreef op zondag 11 september 2016 @ 17:49:
Ik ben nu ook studentassistent bij het eerste programmeervak voor informatica- en AI-studenten op de RuG. Het is Imperative Programming in C en daarmee voor velen een struikelblok, direct al in het begin. En het is inderdaad erg lastig om studenten in zo'n korte periode (8 weken) alles aan te leren wat nodig is voor de basis van programmeren. We proberen de kwaliteit direct zo hoog mogelijk te houden en we zijn dan ook vrij streng op gebrek aan indentation, onoverzichtelijke code en onnodig complexe oplossingen. Dit zorgt helaas ook voor vrij hoge uitval (meer dan 50% eerste jaar als ik het goed heb), maar zorgt er wel voor dat in mijn ogen de rest van de opleiding een goed hoog niveau heeft waar je wat aan hebt als je dan ook aan de slag gaat daarna.

In principe denk ik dat c in +/- 8 weken redelijk te doen is, (ervanuitgaande dat er enige voorkennis is in de vorm van een andere programeertaal). Met het volgende zou je naar mijn inzien al een goede basis hebben om op te bouwen

- Declareren en initialiseren van variabelen
- c keywords
- loops
- functies maken
- extra benadrukken wanneer een ; te gebruiken
- en voor overzichtelijke code is het nodig om exstra witruimte te gebruiken op de regel na een { en een witruimte minder na een }. Behandel ook hoe je goede namen aan je variabele Geef.

En misschien enkele basis libaries als de studio.h en de math.h ondanks dat het niet onderdeel is van de c taal, maar wel op bijna alle systemen waarin je c Han programmeren onderdeel is van de c omgeving.

[Caelorum]

Mja ik vermoed dat het hier ook gaat om mensen die nog geen voorkennis hebben. En dan is c of java in 8 weken al best lastig.

[Hydra]

Caelorum schreef op zondag 11 september 2016 @ 16:56:
Mja ik werk in een bedrijf waar het team zo zou kunnen worden verdubbelt en er nog door de klant betaald werk voor minstens een jaar open zou staan. Dan zijn wat minder belangrijke zaken, maar ook dingen die de klant liever een jaar geleden al had gehad. Dat er bugs in zitten nemen zij veelal voor lief als daardoor de features er sneller zijn.

Totdat je ontwikkelsnelheid compleet inkakt omdat er links en rechts dingen om gaan vallen iedere keer als je ook maar naar de codebase kijkt. Ik heb dergelijke excuses vaak genoeg gehoord. Geen tests schrijven werkt eigenlijk alleen maar voor de meest simpele soorten software. Dan vind je me maar kort door de bocht; da's gewoon m'n ervaring met bedrijven die op die manier werken.

Overigens hebben wij goede logging en worden kritieke bugs die er wel eens insluipen (onverwachte input, veelal van derde partij via apis) vaak binnen het uur opgelost.

Oh vast. Maar ik heb wel wat beters te doen dan op een zaterdag bugs te gaan fixen.

[Woy]

Zo vanochtend een fijne verrassing, het oude koffie apparaat is vervangen door een fijne Jura

[Ryur]

Woy schreef op maandag 12 september 2016 @ 09:39:
Zo vanochtend een fijne verrassing, het oude koffie apparaat is vervangen door een fijne Jura

Dat is een leuke verrassing! Ben jaloers

[DevWouter]

Hydra schreef op maandag 12 september 2016 @ 08:59:
[...]


Totdat je ontwikkelsnelheid compleet inkakt omdat er links en rechts dingen om gaan vallen iedere keer als je ook maar naar de codebase kijkt. Ik heb dergelijke excuses vaak genoeg gehoord. Geen tests schrijven werkt eigenlijk alleen maar voor de meest simpele soorten software. Dan vind je me maar kort door de bocht; da's gewoon m'n ervaring met bedrijven die op die manier werken.


[...]


Oh vast. Maar ik heb wel wat beters te doen dan op een zaterdag bugs te gaan fixen.

Ik onderschrijf wat Hydra hier zeg. Dit is gewoon technische schuld. Elke keer dat dit ten sprake komt en er geen progressie geboekt wordt verliezen jullie manuren en elk manuur kan je vertalen naar euro's dat het bedrijf verliest.

Dat gezegd te hebben kan technische schuld ook acceptabel zijn, net zoals dat je een schuld bij de bank hebt wanneer je een huis koopt. Zolang je maar een haalbaar plan hebt om de schuld af te lossen hoeft het geen ramp te zijn.

[ThomasG]

DevWouter schreef op maandag 12 september 2016 @ 10:27:
[...]


Ik onderschrijf wat Hydra hier zeg. Dit is gewoon technische schuld. Elke keer dat dit ten sprake komt en er geen progressie geboekt wordt verliezen jullie manuren en elk manuur kan je vertalen naar euro's dat het bedrijf verliest.

Dat gezegd te hebben kan technische schuld ook acceptabel zijn, net zoals dat je een schuld bij de bank hebt wanneer je een huis koopt. Zolang je maar een haalbaar plan hebt om de schuld af te lossen hoeft het geen ramp te zijn.

Het ligt er aan wat voor systemen er gebouwd worden. Als het enkel wat frontend websites voor de lokale bakker zijn, kom je er wel mee weg dat je geen tests hebt. Wanneer het grote systemen zijn waar veel werknemers van afhankelijk zijn, dan heb jij als ontwikkelaar een aardig probleem als blijkt dat er op de cowboy manier wordt gewerkt..

[Caelorum]

Het probleem is dat tests alleen maar helpen bij voorziene problemen. Als ontwikkelaars rustig ontwikkelen en alles zelf en door anderen laten testen heeft het weinig toegevoegde waarde IMO. Bij ons gaat het juist fout op zaken waar we niet hadden voorzien dat het een probleem zou zijn. Het komt zelden voor dat iets fout gaat en een andere ontwikkelaar zegt "dat had ik je ook wel kunnen vertellen". En die manuren voor tests weven daar gewoonweg niet tegenop.
En wederom vind ik het zwartwit denken hier nogal opmerkelijk. Juist bij jullie had ik enige nuance nog wel verwacht.

[jip_86]

Caelorum schreef op maandag 12 september 2016 @ 13:22:
Het probleem is dat tests alleen maar helpen bij voorziene problemen. Als ontwikkelaars rustig ontwikkelen en alles zelf en door anderen laten testen heeft het weinig toegevoegde waarde IMO. Bij ons gaat het juist fout op zaken waar we niet hadden voorzien dat het een probleem zou zijn. Het komt zelden voor dat iets fout gaat en een andere ontwikkelaar zegt "dat had ik je ook wel kunnen vertellen". En die manuren voor tests weven daar gewoonweg niet tegenop.
En wederom vind ik het zwartwit denken hier nogal opmerkelijk. Juist bij jullie had ik enige nuance nog wel verwacht.

Dat klopt wel. Maar denk wel dat als je 100 voorziene problemen kan afdekken met tests kan je wel garanderen dat die 100 voorziene problemen ook nog zo werken en er niet stiekem eentje is omgevallen. Valt er een keertje wel iets om maak je test nummer 101 om er voor te zorgen dat het niet nog eens gebeurd.

[RobertMe]

Caelorum schreef op maandag 12 september 2016 @ 13:22:
Het probleem is dat tests alleen maar helpen bij voorziene problemen. Als ontwikkelaars rustig ontwikkelen en alles zelf en door anderen laten testen heeft het weinig toegevoegde waarde IMO. Bij ons gaat het juist fout op zaken waar we niet hadden voorzien dat het een probleem zou zijn. Het komt zelden voor dat iets fout gaat en een andere ontwikkelaar zegt "dat had ik je ook wel kunnen vertellen". En die manuren voor tests weven daar gewoonweg niet tegenop.
En wederom vind ik het zwartwit denken hier nogal opmerkelijk. Juist bij jullie had ik enige nuance nog wel verwacht.

Het schrijven van tests helpt wel om meer stil te staan bij je code. Daardoor denk, in ieder geval ik, meestal ook meer na over de rand scenarios waardoor de code dus wel meteen beter word. In die zin helpen tests dus ook.

Daarnaast helpt het schrijven van tests natuurlijk niet alleen bij het voorkomen van problemen in nieuwe code, maar ook regressions in bestaande code. Op het moment dat je een fout fixed in een onvoorzien randgeval is de kans groot dat zo'n randgeval bij een refactor/aanpassingen aan die code weer over het hoofd wordt gezien. Op het moment dat je unit tests hebt die dat randgeval afdekken kom je dus meteen erachter dat die regression er is.

Waar ik werk zijn nooit tests geschreven en was het zeker toen ik hier begon nog meestal zo dat alleen de developer zijn eigen werk deed testen en verder werd er vrijwel niet getest buiten dat iemand functioneel naliep of het deed wat het moest doen. Nu schrijf ikzelf in ieder geval wel vaker unit tests tijdens het ontwikkelen (meestal dan wel nog eerst code en daarna de test, en dus geen TDD), waarbij ik normaliter toch meer stilsta bij de mogelijke randgevallen waarbij ik daar ook tests voor schrijf. Daarnaast moet iedere developer van eigen gemaakt werk zelf een stapsgewijs "script" maken wat de andere developers/testers bij het testen doorlopen. Ook daarbij merk ik dat ik tijdens het schrijven daarvan langer stilsta bij bepaalde dingen en ook daardoor de randgevallen beter zijn afgedekt. Het maken van tests (of unit tests, of stapsgewijs de applicatie/functionaliteit doorlopen) zorgt er dus in ieder geval in mijn geval voor dat ik nog meer stil sta bij de gebouwde functionaliteit. Waar ik tijdens het ontwikkelen meestal kleine stukjes achter elkaar programmeer en die "test" en op het eind het totaal doorloop. Alleen sta je op het moment van ontwikkelen nog niet stil bij alle randgevallen, bijvoorbeeld omdat het totaalplaatje er nog niet is en ik echt beetje bij beetje iets ontwikkel waarbij elke keer weer "iets" werkt. Maar daarbij sta ik nog niet altijd stil bij alle mogelijke randgevallen. Door of tegelijk/kort daarna unit tests te schrijven, of op een later moment zo'n stapsgewijze "procedure" op te zetten ben ik me wel veel meer bewust van het totaalplaatje en denk ik meer na over de randgevallen.

[ThomasG]

Caelorum schreef op maandag 12 september 2016 @ 13:22:
Het probleem is dat tests alleen maar helpen bij voorziene problemen. Als ontwikkelaars rustig ontwikkelen en alles zelf en door anderen laten testen heeft het weinig toegevoegde waarde IMO. Bij ons gaat het juist fout op zaken waar we niet hadden voorzien dat het een probleem zou zijn. Het komt zelden voor dat iets fout gaat en een andere ontwikkelaar zegt "dat had ik je ook wel kunnen vertellen". En die manuren voor tests weven daar gewoonweg niet tegenop.
En wederom vind ik het zwartwit denken hier nogal opmerkelijk. Juist bij jullie had ik enige nuance nog wel verwacht.

Tests (en documentatie) zijn juist essentieel bij software, vooral bij grote meerjarige projecten. Allemaal leuk en aardig dat je die paar uur bespaart tijdens het initieel ontwikkel proces, dat geeft heel veel nadelen en veel meer manuur op de langer termijn. Systemen moeten onderhouden worden, de oorspronkelijke programmeurs werken er misschien niet meer aan. Als je een systeem hebt van miljoenen regels code, zonder enige vorm van tests, wordt je daar echt niet vrolijk van. Vooral omdat je dan niet kunt garanderen dat na het toevoegen van een nieuwe feature de rest nog naar behoren werkt. En dat gaat echt minimaal een factor 10 meer geld kosten dan dat je bespaart door het weglaten van tests.

[DevWouter]

Caelorum schreef op maandag 12 september 2016 @ 13:22:
Het probleem is dat tests alleen maar helpen bij voorziene problemen. Als ontwikkelaars rustig ontwikkelen en alles zelf en door anderen laten testen heeft het weinig toegevoegde waarde IMO. Bij ons gaat het juist fout op zaken waar we niet hadden voorzien dat het een probleem zou zijn. Het komt zelden voor dat iets fout gaat en een andere ontwikkelaar zegt "dat had ik je ook wel kunnen vertellen". En die manuren voor tests weven daar gewoonweg niet tegenop.
En wederom vind ik het zwartwit denken hier nogal opmerkelijk. Juist bij jullie had ik enige nuance nog wel verwacht.

Ligt er aan hoe je test. Unit tests zijn er voornamelijk om ontwikkelaars vertrouwen te geven zodat ze zonder zorgen met een zaag kunnen opereren op de code. Gewoon een complete functie herschrijven zonder je te hoeven in te lezen op allerlei gerelateerde zaken is best wel fijn.

Overigens is er wel een verschil tussen unit-tests en test-driven-development. 100% test coverage is een statistiek die je makkelijk kan faken.

Dat het niet zo zwart-wit gezien moet worden ben ik met je eens (echter denk ik wel dat de meeste het doen, maar niet zodanig beschrijven). En als het meer tijd kost dan dat oplevert dan heeft het ook geen meerwaarde, maar juist waardeverlies.

Het vervelende met unit test is dat het een kostenpost is die pas rendabel is op lange termijn. Pas wanneer je goeie unit-tests in bulk heb (denk in de honderdtallen) dan worden ze pas zeer lucratief.

Bij korte hit-and-run projecten hebben ze inderdaad veel minder nut, omdat unit-test een besparing zijn op onderhoudskosten.

[Hydra]

Caelorum schreef op maandag 12 september 2016 @ 13:22:
Het probleem is dat tests alleen maar helpen bij voorziene problemen.

Als je zo denkt verklaart het ook waarom je weinig in testen ziet. Dat is gewoon niet waar. Testen doen namelijk twee dingen; bewijs leveren voor je design en aannames en waarborgen dat als dat design / die aannames niet waar blijken of veranderen er dan een licht op rood gaat. Zo pakken tests dus heel veel cases die je vooraf niet voorzien had. Tests zijn dus ook safeguards tegen regressies. En dat is waar ik het vrijwel altijd mis zie gaan bij bedrijven als dat van jou. Iedereen kan iets bouwen en ff de happy flow handmatig testen. Dat doe ik ook. Maar daarna ga je safeguards bouwen voor zowel de happy als de unhappy flow zodat een developer over 6 maanden gewoon die code aan kan passen op de back-end zonder de mobiele app stuk te maken.

Ik denk dat jij gewoon ervaring met echt complexe systemen mist. Ik zit hier op een project bij een bank met in totaal zo'n 18 developers die samen aan een back-end + mobiele app werken en zonder verschillende lagen tests zou het hier een grote teringzooi zijn. Er zijn regelmatig issues (zoals vandaag een met URL encoding) die met de unit tests niet en met de integration tests wel aan 't licht komen.

En wederom vind ik het zwartwit denken hier nogal opmerkelijk. Juist bij jullie had ik enige nuance nog wel verwacht.

Volgens mij heb ik meerdere malen uitgelegd dat er cases zijn waar testen weinig toevoegen / uitgesteld kunnen worden. Dus ik weet niet hoeveel meer nuance je denkt te kunnen vinden hier.

ThomasG schreef op maandag 12 september 2016 @ 13:44:
Tests (en documentatie) zijn juist essentieel bij software, vooral bij grote meerjarige projecten. Allemaal leuk en aardig dat je die paar uur bespaart tijdens het initieel ontwikkel proces, dat geeft heel veel nadelen en veel meer manuur op de langer termijn.

Om nog maar niet te spreken over de verloren goodwill van de gebruiker. Als onze app onstabiel en buggy is kunnen we hier de tent wel opdoeken.

[ Voor 13% gewijzigd door Hydra op 12-09-2016 14:06 ]

[Caelorum]

Hydra schreef op maandag 12 september 2016 @ 14:04:
[...]En dat is waar ik het vrijwel altijd mis zie gaan bij bedrijven als dat van jou. Iedereen kan iets bouwen en ff de happy flow handmatig testen. Dat doe ik ook. Maar daarna ga je safeguards bouwen voor zowel de happy als de unhappy flow zodat een developer over 6 maanden gewoon die code aan kan passen op de back-end zonder de mobiele app stuk te maken. [...]

ik test alleen zeker niet alleen de happy flow. Als je dat doet heb je zeker unit tests nodig ja.

[...] ik denk dat jij gewoon ervaring met echt complexe systemen mist. [...]

Let's not go there. Ik werk overigens aan een saas oplossing met 6 man, waarvan de meeste er ook al jaren aan werken. Kennis wordt hier nauwelijks vergeten en wordt direct overgedragen. Daar hebben we geen tests voor nodig. Documentatie is iets dat wij maken voor externen, maar intern is dit ook niet nodig. Wellicht dat we daarom ook redelijk stabiele code weten te produceren. De originele ontwikkelaars zijn in 80% van de gevallen nog te raadplegen en anders wel iemand die de code ook al jaren lang heeft gezien.
Overigens is de teringzooi er bij ons ook wel, maar dat is niet door gebrek aan tests. Eerder doordat 10 jaar lang features leveren belangrijker werden gevonden dan een fatsoenlijke fundering bouwen. Gevolg is een enorm uitgebreid product (en enorm), dat op redelijk slecht gestructureerde code draait.

[..]
Volgens mij heb ik meerdere malen uitgelegd dat er cases zijn waar testen weinig toevoegen / uitgesteld kunnen worden. Dus ik weet niet hoeveel meer nuance je denkt te kunnen vinden hier.
[...]

Dat was dan niet duidelijk voor mij

[...]
Om nog maar niet te spreken over de verloren goodwill van de gebruiker. Als onze app onstabiel en buggy is kunnen we hier de tent wel opdoeken.

Dat hebben wij gelukkig niet, maar dat komt denk ik mede doordat eventuele bugs snel worden opgelost.


Overigens is regressie inderdaad wel een ding. Dat komt nog wel eens voor bij ons. Maar vergeet niet dat al die tests ook onderhouden moeten worden. Daar gaat ook gewoon werk in zitten.
In ons geval is het iig nog niet rendabel om het te doen al sluit ik het niet uit dat het in de toekomst wel gaat gebeuren. Maar dat punt zal pas komen als we meer man gaan aannemen dan waar we toezicht op kunnen houden ^^

[Hydra]

Caelorum schreef op maandag 12 september 2016 @ 14:56:
[...]
Overigens is regressie inderdaad wel een ding. Dat komt nog wel eens voor bij ons.

'Nuff said.

[Caelorum]

Hydra schreef op maandag 12 september 2016 @ 14:57:
[...]
'Nuff said.

Wel eens en is in no time opgelost. De tijd die wij er aan besteden is verwaarloosbaar. Dit is meer een last voor de klant, maar die vind het vooralsnog ok.

[whoami]

Let's agree to disagree dan, maar ik persoonlijk vind unit-testing ook noodzakelijk.

Regressie opvangen, zekerheden bij refactoring (al kan je nooit 100% zeker zijn).

Als je daarnaast dan nog eens via TDD werkt, dan schrijf je dus je testen eerst, en is het maken van een unit-test eigenlijk onderdeel van het designproces. Je denkt nl. na over de manier waarop je uw class wil gaan gebruiken / aanroepen, en dan is de resulterende test een added bonus.
(Ik moet wel toegeven dat ik ook niet altijd via TDD werk).

[Caelorum]

Kijk het is niet dat ik de voordelen niet zie hoor, maar er zijn echt 1001 situaties waarin geautomatiseerde tests (zoals unit tests) niet werken. Er werd hier met termen als cowboy programmeurs gegooid als je het niet doet en dat is gewoon te kort door de bocht, zelfs met de uitzonderingen die werden aangedragen.
Als de gevolgen van regressies niet groot zijn (in manuren/klanttevredenheid) dan wordt het al snel rendabeler om het niet te doen.
Overigens het maken van tests kan inderdaad bijdragen aan het nadenken over de code, maar ik hoop dat je dat sowieso al doet. En die zekerheid bij refactoren geldt alleen voor het introduceren van regressies. Dat is ook zeker voor een groot deel af te vangen met een goede handmatige tests.

[OkkE]

Caelorum schreef op maandag 12 september 2016 @ 14:56:
Dat hebben wij gelukkig niet, maar dat komt denk ik mede doordat eventuele bugs snel worden opgelost.

Ik ken jullie product/dienst niet, dus ik kan er weinig over zeggen, maar je moet wel oppassen met de aanname dat klanten je vergeven omdat bugs snel worden opgelost.

Wij hebben sinds een paar maanden een abonnement op een SaaS pakket/dienst. Daar zaten echt heel veel bugs in (en nog steeds een aantal), sommige zelfs critical/breaking. Het is dat we op dit moment prijs/kwaliteit niets beters kunnen vinden, maar zodra dat er wel is; grote kans dat we overstappen. Fijn dat bugs snel worden opgelost, maar het zorgt toch elke keer weer voor vertraging en ergernis. Iets dat je sowieso niet wil, maar al helemaal niet als je zelf ook deadlines hebt te halen.

[whoami]

Caelorum schreef op maandag 12 september 2016 @ 15:40:
Als de gevolgen van regressies niet groot zijn (in manuren/klanttevredenheid) dan wordt het al snel rendabeler om het niet te doen.

't Probleem hier is, dat je niet op voorhand kan weten 'hoe groot de regressie is'.

Dat is ook zeker voor een groot deel af te vangen met een goede handmatige tests.

Is dat ook geen tijdverlies ? Ga jij -als developer- handmatig alle mogelijke randscenario's gaan aftesten ? Heb je de zekerheid dat je een testteam hebt die dat telkens wel doet ?

[Voutloos]

De nuance is hoeveel testcases je maakt, af en toe grotere/grovere high level checks vs. elke regel unittest en mocks etc. Maar zonder tests ben je imo ook gewoon aan het cowboyen.

Mag je van harte niet geloven, maar zelfs spartaanse tests winnen zichzelf terug. Als je je er ooit wel toe zou zetten, komt er een punt dat je niet zal geloven dat je dit ooit geschreven hebt.

Caelorum schreef op maandag 12 september 2016 @ 15:40:
En die zekerheid bij refactoren geldt alleen voor het introduceren van regressies.

Niet alleen regressions, je happy path wordt ook voor je getest.

Dat is ook zeker voor een groot deel af te vangen met een goede handmatige tests.

No way dat iedereen altijd alle handmatige testscenario's doorloopt. Zeker met meerdere wijzigingen kort op elkaar, kan je met wat tests (en CI ) veel sneller het probleem spotten en isoleren. Of uberhaupt met hotfix stress, is het toch wel fijn als je tests een vangnet vormen.

Of met wijzigingen welke in een heel basic laag zitten (bijv. een generieke feature in je model of DB), veel succes toegewenst met alle entiteiten en _alle_ geimplementeerde operaties op elk handmatig te doorlopen.

Het hebben van steeds 'fatsoenlijker' coverage en CI (Jenkins) zou ik zonder twijfel de belangrijkste verbetering van de laatste 10 jaar bij ons noemen.

[Hydra]

Voutloos schreef op maandag 12 september 2016 @ 16:02:
No way dat iedereen altijd alle handmatige testscenario's doorloopt.

Precies. We hadden onlangs ook een bug in de registratie. De front-end heeft z'n tests niet op orde. Die registratie is sowieso een lastige flow om te testen, helemaal manual omdat je al je zooi moet weggooien. En dat werd dus een keertje teveel overgeslagen. Oops! Gelukkig stom toevallig op accept achter gekomen net voor de push naar productie.

En @Caelorum: misschien moet je toch eens gaan overwegen dat al die mensen hier misschien een punt hebben

[ Voor 9% gewijzigd door Hydra op 12-09-2016 16:12 ]

[Caelorum]

Hydra schreef op maandag 12 september 2016 @ 16:11:
[...]
En @Caelorum: misschien moet je toch eens gaan overwegen dat al die mensen hier misschien een punt hebben

Zoals ik al zei zie ik zeker voordelen en in een net iets andere situatie zou ik het ook echt wel doen. Alleen in deze situatie is het gewoon echt niet zo.

OkkE schreef op maandag 12 september 2016 @ 15:51:
[...]
Ik ken jullie product/dienst niet, dus ik kan er weinig over zeggen, maar je moet wel oppassen met de aanname dat klanten je vergeven omdat bugs snel worden opgelost.

Sterker nog, we gaan ook andere soort klanten aanboren op de midellange termijn en die vinden het wel erg. Dus we zullen uiteindelijk wel moeten.

whoami schreef op maandag 12 september 2016 @ 16:02:
[...]
Is dat ook geen tijdverlies ? Ga jij -als developer- handmatig alle mogelijke randscenario's gaan aftesten ? [...]

In zekere zin wel ja, maar een bijkomend effect is dat de code er omheen ook deels wordt gechecked op kwaliteit door anderen. Er is in die zin ook geen enkel stuk code dat we niet minstens eens per jaar te zien krijgen.

[alienfruit]

Zucht, vervelend dat deze klant alles in Windows wil doen. Nu zit al anderhalf uur te klungelen. Eerst omdat ik niet het wereldwijde web op kon op deze IIS bak. Nu heb ik de ASP.net kunnen downloaden krijg je dit soort ongein: The remote name could not be resolved: 'www.domein.com' etc.

Ik moest een proxy script invullen bij netwerkinstellingen. Blijkbaar neemt IIS deze instellingen niet over? Vermoeiend

[Swedish Clown]

Caelorum schreef op maandag 12 september 2016 @ 14:56:
[...]

Let's not go there. Ik werk overigens aan een saas oplossing met 6 man, waarvan de meeste er ook al jaren aan werken. Kennis wordt hier nauwelijks vergeten en wordt direct overgedragen. Daar hebben we geen tests voor nodig. Documentatie is iets dat wij maken voor externen, maar intern is dit ook niet nodig. Wellicht dat we daarom ook redelijk stabiele code weten te produceren. De originele ontwikkelaars zijn in 80% van de gevallen nog te raadplegen en anders wel iemand die de code ook al jaren lang heeft gezien.
Overigens is de teringzooi er bij ons ook wel, maar dat is niet door gebrek aan tests. Eerder doordat 10 jaar lang features leveren belangrijker werden gevonden dan een fatsoenlijke fundering bouwen. Gevolg is een enorm uitgebreid product (en enorm), dat op redelijk slecht gestructureerde code draait.

Even los van de hele discussie over wel of geen tests schrijven, ik zie hier een enorme bus-factor in jouw verhaal terug. Stel jullie gaan met 6 man na het werk een biertje pakken en er gebeurd ook maar iets waardoor van de 6 man, wellicht enkel jij nog overblijft, kan de tent dan nog blijven draaien?

Het hebben van tests heeft naast een regressie- en confirmatie-functie tot op zekere hoogte ook een documenterende waarde. Uit de tests valt de business logica en eventuele uitzonderingen soms gemakkelijker terug te zien dan enkel uit de code.

Niks persoonlijks, maar 10 jaar lang features bouwen in een SaaS omgeving zonder tests voelt doodeng en elke push naar productie zou voor mij een kleine hartverzakking opleveren. Zeker als nieuwe medewerker.


On a different note, nadat mijn laptop voor de 2e maal in korte tijd kuren vertoond, heeft m'n baas er genoeg van. "Jouw laptop gaat niet terug voor reparatie. Bij deze toestemming om een nieuwe uit te zoeken. Kijk maar of de volgende laptop wat voor je is want dan bestel ik hem vandaag nog en is die morgen binnen"

Dus zojuist besteld:
Merk en model: Dell E7470
CPU: i7-6600U
RAM: 16 GB DDR4 2133 MHz
SSD: 256 GB
Screen: QHD (2560x1440)

[ Voor 0% gewijzigd door Swedish Clown op 12-09-2016 16:46 . Reden: typevout ]

[PatrickH89]

Developers hebben er altijd een handje van om niet breder te zien dan hun eigen viewpoint en menen hun viewpoint op te moeten leggen aan anderen.

Er is een goede kans dat het team van Caelorum meer tijd zou besparen met wat basic tests, maar het zou gezien de complexiteit en eventuele vluchtigheid heel goed kunnen dat geautomatiseerd testen helemaal niet zo veel tijd zou besparen.

Net als 101 design patterns die je zou moeten gebruiken, anders 'ben je geen goede developer' terwijl dat wellicht helemaal niet beter is voor jouw specifieke usecase. Overigens heb ik zelf net als veel andere developers ook de neiging om zoveel mogelijk te (over)engineeren, dus wat dat betreft begrijp ik het helemaal.

[farlane]

Brakkie41 schreef op maandag 12 september 2016 @ 16:45:
[...]
Stel jullie gaan met 6 man na het werk een biertje pakken en er gebeurd ook maar iets waardoor van de 6 man, wellicht enkel jij nog overblijft, kan de tent dan nog blijven draaien?

Ik denk dat als er in 1 klap 83+% van je personeel sterft je als bedrijf sowieso een probleem hebt, ook met unit tests.

[Caelorum]

Brakkie41 schreef op maandag 12 september 2016 @ 16:45:
[...]
Even los van de hele discussie over wel of geen tests schrijven, ik zie hier een enorme bus-factor in jouw verhaal terug. Stel jullie gaan met 6 man na het werk een biertje pakken en er gebeurd ook maar iets waardoor van de 6 man, wellicht enkel jij nog overblijft, kan de tent dan nog blijven draaien? [...]

Doordraaien ja, omdat elke ontwikkelaar een vrij goede kennis heeft van het hele systeem en alle processen. Echter zou de ontwikkeling zo langzaam gaan daarna dat de klanten vanzelf weg zouden gaan.
Overigens komt het ook niet voor (zelfs bij teamuitjes) dat we in 1 bus terecht komen om die reden..

[...]. Uit de tests valt de business logica en eventuele uitzonderingen soms gemakkelijker terug te zien dan enkel uit de code. [...]

de processen hebben wij tot op zekere hoogte beschreven zodat onze klanten er gebruik van kunnen maken. Die handleidingen zijn genoeg voor ons om de logica er uit te halen. Daarnaast zijn veel dingen ook logisch als je de domeinkennis hebt.

[...]
Niks persoonlijks, maar 10 jaar lang features bouwen in een SaaS omgeving zonder tests voelt doodeng en elke push naar productie zou voor mij een kleine hartverzakking opleveren. Zeker als nieuwe medewerker. [...]

Het heeft mij een half jaar gekost voordat ik durfde te drukken ^^ niet omdat ik bang ben dat het product crasht, maar omdat ik een proces ben vergeten. Tegenwoordig check ik dat soms alsnog bij een collega.

[DevWouter]

Brakkie41 schreef op maandag 12 september 2016 @ 16:45:
[...]

Dus zojuist besteld:
Merk en model: Dell E7470
CPU: i7-6600U
RAM: 16 GB DDR4 2133 MHz
SSD: 256 GB
Screen: QHD (2560x1440)

Ik zou toch kijken of je niet een extra harde schijf er bij kan krijgen. 256 GB is tegenwoordig niet erg veel (uiteraard afhankelijk van wat je doe). Verder wel een net ding

[ Voor 3% gewijzigd door DevWouter op 12-09-2016 17:06 ]

[F.West98]

ard1998 schreef op maandag 12 september 2016 @ 07:51:
[...]


In principe denk ik dat c in +/- 8 weken redelijk te doen is, (ervanuitgaande dat er enige voorkennis is in de vorm van een andere programeertaal). Met het volgende zou je naar mijn inzien al een goede basis hebben om op te bouwen

- Declareren en initialiseren van variabelen
- c keywords
- loops
- functies maken
- extra benadrukken wanneer een ; te gebruiken
- en voor overzichtelijke code is het nodig om exstra witruimte te gebruiken op de regel na een { en een witruimte minder na een }. Behandel ook hoe je goede namen aan je variabele Geef.

En misschien enkele basis libaries als de studio.h en de math.h ondanks dat het niet onderdeel is van de c taal, maar wel op bijna alle systemen waarin je c Han programmeren onderdeel is van de c omgeving.

Alleen hebben ze dus geen ervaring. De meesten hebben nog 0,000 ervaring. Dat is best frustrerend, want die mensen vinden het ook gewoon heel moeilijk om überhaupt te beginnen met programmeren. Een Hello World lukt nog wel, maar iets als (n%500==0 ? 0 : 1) + n/500 (maar dan waarschijnlijk uitgeschreven) is voor de meesten al heel moeilijk te maken. Ze snappen het als het er staat, maar kunnen er zelf moeilijk uitkomen. Weekplanning is dan ook ongeveer:
Week 1: Variabelen, beetje types, basic I/O, if dingen
Week 2: Loops
Week 3: Functions, pointers en structs
Week 4: Arrays
Week 5: Recursion
Week 6+7: Zoek- en sort-algoritmes met bijbehorende complexity dingen

Wat het niet versimpelt is dat er ook direct vrij veel wordt ingezet op de wiskundige kant van programmeren, en vooral wiskundige problemen. Typische problemen voor week 2 zijn al het vinden van priemgetallen (en dan ook wel goed geoptimaliseerd) en oplossingen voor lineaire vergelijkingen met twee variabelen vinden. Dat alleen al is vrij lastig voor eerstejaars (dat krijg je niet altijd op VWO), en dan direct alles programmeren. Er zijn natuurlijk ook eenvoudigere dingen, dus die genoemde dingen zijn vooral de opdrachten waarmee je een 8-10 kan halen ipv een 6-7. De makkelijkere dingen zijn bijvoorbeeld factorials uitrekenen e.d.

[ard1998]

ik vind het we vreemd dat veel mensen die aan een programeeropleiding beginnen totaal geen voorkennis hebben. aa het begin van de opleiding die ik nu (+/- 2 weken geleden) begonnen ben bleek ik 1 van de 2 uit de groep van 17 te zijn die voorkennis had (de ander was overgens blijven zitten). ik doe even een de Q&a van de eerste lesdag bij enkele van mijn medestudenten na

Q: eerste vraag: warom kom je de opleiding webdevelopment doen
A: omdat ik denk dat het leuk is

Q: heb je enige ervaring met programmeren
A: nee

Q: heb je veel ervaring met computers
A: nee

???

al met al, er moet meer aandacht komen voor programeren op de lagere school (groep 7/8) en de middelbare school.

[Swedish Clown]

DevWouter schreef op maandag 12 september 2016 @ 17:06:
[...]


Ik zou toch kijken of je niet een extra harde schijf er bij kan krijgen. 256 GB is tegenwoordig niet erg veel (uiteraard afhankelijk van wat je doe). Verder wel een net ding

Mwah ik gebruik momenteel +- 100 v/d 256 GB. Ik snap niet hoe dev'vers hun disks volkrijgen tenzij je test db's draait op je laptop? Het enige wat er op m'n laptop staat is een berg repo's en docker containers. Gros van de projecten waar ik aan werk draaien in Docker containers. Verder valt het kwa installaties heel erg mee Ruby, Python, Erlang + OTP en Elixer (en hun dependencies). Dan ben ik er wel denk ik

[F.West98]

Brakkie41 schreef op maandag 12 september 2016 @ 18:05:
[...]


Mwah ik gebruik momenteel +- 100 v/d 256 GB. Ik snap niet hoe dev'vers hun disks volkrijgen tenzij je test db's draait op je laptop? Het enige wat er op m'n laptop staat is een berg repo's en docker containers. Gros van de projecten waar ik aan werk draaien in Docker containers. Verder valt het kwa installaties heel erg mee Ruby, Python, Erlang + OTP en Elixer (en hun dependencies). Dan ben ik er wel denk ik

Ik had mijn 256GB SSD op mijn oude PC toch wel snel heel vol. Kwam vooral door dingen als Adobe LR/PS/Premiere/AE en natuurlijk Visual Studio. Op mijn huidige heb ik ongeveer 300 van de 1000GB in gebruik, met bovenstaande en een paar extra VMs erbij. Hoop dat dit weer een jaar of 5-10 genoeg is

[RayNbow]

F.West98 schreef op maandag 12 september 2016 @ 17:31:
Wat het niet versimpelt is dat er ook direct vrij veel wordt ingezet op de wiskundige kant van programmeren, en vooral wiskundige problemen.

Is dat een probleem dan? Tijdens mijn studie zat het eerste jaar vol met Analyse, Lineaire Algebra, Discrete Wiskunde en in de jaren die volgden kwamen Logica, KansStat en Numerieke Wiskunde voorbij.

[Vincentio]

RayNbow schreef op maandag 12 september 2016 @ 18:31:
[...]

Is dat een probleem dan? Tijdens mijn studie zat het eerste jaar vol met Analyse, Lineaire Algebra, Discrete Wiskunde en in de jaren die volgden kwamen Logica, KansStat en Numerieke Wiskunde voorbij.

Ja verschrikkelijk
Vooral dat Logica...

[Caelorum]

ard1998 schreef op maandag 12 september 2016 @ 17:56:
ik vind het we vreemd dat veel mensen die aan een programeeropleiding beginnen totaal geen voorkennis hebben. [...]

Als je begint aan een opleiding voor architect, dokter of bedrijfskundige of whatever heb je dat meestal ook niet. Eigenlijk wordt dat vreemd genoeg alleen verwacht als je een beta opleiding doet. Best vreemd, want juist in die hoek heb je er minder kans op, omdat de aandacht op de middelbare school jarenlang naar alfa vakken is gegaan.

[...]???[...]

Weet nog mijn eerste dag. Twee meisjes in volledige roze pakken, volledig opgemaakt en echt giechelig aan het doen. Ja, die hadden een totaal ander beeld van de opleiding. Die waren na de eerste dag dan ook meteen weer weg.
De opleidingen deden, en doen misschien nog steeds wel, wel erg hun best om aan de aantallen te komen. Incl. een totaal verkeerd beeld schetsen van hoe het er op de opleiding aan toe gaat. Waaronder de complete edge cases van het vakgebied (werken bij Google) gebruiken als voorbeeld, alsof dat normaal is.

Vincentio schreef op maandag 12 september 2016 @ 18:33:
[...]
Ja verschrikkelijk
Vooral dat Logica...

Logica is nou net wat mij door het wiskunde vak van mijn Master heeft getrokken (is een verplicht vak als je van het HBO instroomt). Statistiek ben ik uiteindelijk pas vorig jaar een beetje gaan begrijpen na weken aan zelfstudie.

[ Voor 15% gewijzigd door Caelorum op 12-09-2016 18:45 ]

[F.West98]

RayNbow schreef op maandag 12 september 2016 @ 18:31:
[...]

Is dat een probleem dan? Tijdens mijn studie zat het eerste jaar vol met Analyse, Lineaire Algebra, Discrete Wiskunde en in de jaren die volgden kwamen Logica, KansStat en Numerieke Wiskunde voorbij.

Niet voor mij in ieder geval
Maar ik kan me voorstellen dat de combi nieuwe wiskunde/probleemoplossing + volledig nieuwe concepten van programmeren een grote uitdaging is voor velen.

[ard1998]

Caelorum schreef op maandag 12 september 2016 @ 18:44:
[...]

Als je begint aan een opleiding voor architect, dokter of bedrijfskundige of whatever heb je dat meestal ook niet.

Als je dokter/bedrijfskundigge of iets in die richting wilt worden neem je Biologie in je vakkenpakket op het vmbo/havo/vwo. Dan heb je voorkennis (buiten dat het bij sommige opleidingen in die richting een vereiste is)

[Caelorum]

ard1998 schreef op maandag 12 september 2016 @ 20:50:
[...]
Als je dokter/bedrijfskundigge of iets in die richting wilt worden neem je Biologie in je vakkenpakket op het vmbo/havo/vwo. Dan heb je voorkennis (buiten dat het bij sommige opleidingen in die richting een vereiste is)

Mja biologie is net zo van toepassing op doctor als wiskunde is voor een programmeur. Dus ja, voorkennis heb je inderdaad, maar heel veel is het nou ook weer niet hoor. Ik merk alleen dat sommigen* verwachten dat mensen al ervaring hebben met programmeren als ze die opleiding beginnen, maar dat is hetzelfde als verwachten dat iemand al een diagnose kan stellen voor een huiduitslag als ze beginnen aan een studie medicijnen.

* Die ik in mijn opleiding ook, vreemd genoeg.

[farlane]

Mja, operatietafel + testpatienten zijn nu eenmaal een stuk moeilijker aan te komen dan een computer.

[incaz]

Ja, juist het onderwijs is om kennis op te doen. Voorkennis eisen kan, zodra het een realistisch keuzevak is in het voortgezet onderwijs. Dat is het voor zover ik weet niet, en dus dienen de opleidingen er vanuit te gaan dat die voorkennis er niet is. Ook daar: het doel van opleidingen is om op te leiden. Verwachten dat mensen zichzelf opleiden buiten de opleiding is een beetje pronken met andermans veren.

Overigens denk ik wel dat er ruimte is om een aantal dingen in de vooropleiding op te nemen: dingen als variabelen, if-statements, loops, datatypes en verzamelingen hebben volgens mij een veel bredere toepassing dan alleen in programmeren. Het is volgens mij zowel ontzettend leuk als ontzettend leerzaam om daarover na te denken, hoe we al die dingen in het dagelijks leven allang gebruiken (maar ook hoe flexibel we daarin zijn als het nodig is.) Het later formaliseren is dan een veel kleinere stap dan uit het niets abstractie toveren.

Wat dat betreft heb ik wel eens gedacht dat ik een boek wilde schrijven om programmeren uit te leggen aan 9-jarigen en mijn familie. Gewoon omdat veel dingen juist zo ontzettend goed te koppelen zijn aan alledaagse zaken, en dat zelfs algoritmes voor een deel prima uit te leggen zijn. Vast niet alles, maar verrassend veel wel.

[RayNbow]

incaz schreef op maandag 12 september 2016 @ 21:43:
Wat dat betreft heb ik wel eens gedacht dat ik een boek wilde schrijven om programmeren uit te leggen aan 9-jarigen en mijn familie.

Momenteel op mobiel, dus kan niet zo gemakkelijk een goed plaatje vinden, maareh... zoiets?

[Sardaukar]

Goddomme, lijkt erop dat mijn eigenhandig gebouwde desktop van 5 jaar oud het begeven heeft. Rode CPU_LED op moederbord en geen POST.

Ga morgen nog wel eens proberen op te starten zonder RAM en zo. Eens even kijken of dat nog wat oplevert. Nog wel een laptop om op te werken maar dikke desktop met groot scherm werkt toch iets fijner.

Of ik ga een vervangend moederbord kopen of nadenken over een nieuwe desktop. Decisions, decisions....

[Ryur]

incaz schreef op maandag 12 september 2016 @ 21:43:
Wat dat betreft heb ik wel eens gedacht dat ik een boek wilde schrijven om programmeren uit te leggen aan 9-jarigen en mijn familie. Gewoon omdat veel dingen juist zo ontzettend goed te koppelen zijn aan alledaagse zaken, en dat zelfs algoritmes voor een deel prima uit te leggen zijn. Vast niet alles, maar verrassend veel wel.

Denk dat er wel een markt voor is!
Klinkt heel interessant.

[F.West98]

On another note, hoe meer ik met Haskell bezig ben, hoe leuker het wordt
Ik heb nog niet het idee dat ik alles erg netjes Haskellish doe maar het werkt

[Swedish Clown]

F.West98 schreef op maandag 12 september 2016 @ 18:17:
[...]

Ik had mijn 256GB SSD op mijn oude PC toch wel snel heel vol. Kwam vooral door dingen als Adobe LR/PS/Premiere/AE en natuurlijk Visual Studio. Op mijn huidige heb ik ongeveer 300 van de 1000GB in gebruik, met bovenstaande en een paar extra VMs erbij. Hoop dat dit weer een jaar of 5-10 genoeg is

Scheelt dus flink dat ik geen zware externe applicaties hoef te draaien en ook praktisch geen VM's. Heb slechts 1 VM (Kali Linux)

F.West98 schreef op maandag 12 september 2016 @ 22:48:
On another note, hoe meer ik met Haskell bezig ben, hoe leuker het wordt
Ik heb nog niet het idee dat ik alles erg netjes Haskellish doe maar het werkt

Ondanks dat ik praktisch 0 ervaring heb met Haskell heb ik inmiddels wel enige ervaring met functioneel programmeren. Mocht je een review of iets willen schreeuw maar

[F.West98]

Brakkie41 schreef op dinsdag 13 september 2016 @ 00:05:
[...]


Ondanks dat ik praktisch 0 ervaring heb met Haskell heb ik inmiddels wel enige ervaring met functioneel programmeren. Mocht je een review of iets willen schreeuw maar

Reviews komen vanzelf in de vorm van cijfers voor mijn ingeleverde opdrachten

Oh en gefeliciteerd Creepy!

[ Voor 4% gewijzigd door F.West98 op 13-09-2016 00:15 ]

[Swedish Clown]

F.West98 schreef op dinsdag 13 september 2016 @ 00:15:
[...]

Reviews komen vanzelf in de vorm van cijfers voor mijn ingeleverde opdrachten

Oh en gefeliciteerd Creepy!

Dan nog geld dat indien je tussentijdse een review wenst te hebben of vragen hebt over functioneel programmeren dan hoor ik het wel

_{Wijst op eerdere discussie waar je (bijna) nooit de gelegenheid hebt gehad om je code gere-viewed te zien.}

[F.West98]

Brakkie41 schreef op dinsdag 13 september 2016 @ 00:19:
[...]


Dan nog geld dat indien je tussentijdse een review wenst te hebben of vragen hebt over functioneel programmeren dan hoor ik het wel

_{Wijst op eerdere discussie waar je (bijna) nooit de gelegenheid hebt gehad om je code gere-viewed te zien.}

_{Subtiel hoor}
Maar wel bedankt!

[ard1998]

RayNbow schreef op maandag 12 september 2016 @ 22:14:
[...]

Momenteel op mobiel, dus kan niet zo gemakkelijk een goed plaatje vinden, maareh... zoiets?
[afbeelding]

Kinderen van 9 tot 99 jaar ?
En dan mag ik met dit lage niveau van oplettendheid de hele dag studeren (devven) op school.

F.West98 schreef op maandag 12 september 2016 @ 22:48:
On another note, hoe meer ik met Haskell bezig ben, hoe leuker het wordt
Ik heb nog niet het idee dat ik alles erg netjes Haskellish doe maar het werkt

Ach, aldoende leert men.

Ik heb de code op de voorpagina van de website geobserveerd en het ziet er al anders uit dan ik gewend ben, geen ; en geen { en }

[ Voor 47% gewijzigd door ard1998 op 13-09-2016 07:15 ]

[RayNbow]

F.West98 schreef op maandag 12 september 2016 @ 22:48:
On another note, hoe meer ik met Haskell bezig ben, hoe leuker het wordt
Ik heb nog niet het idee dat ik alles erg netjes Haskellish doe maar het werkt

Zeg maar wanneer je klaar bent om een simpele, 1-regelige spreadsheetevaluatiefunctie te kunnen schrijven.

ard1998 schreef op dinsdag 13 september 2016 @ 07:04:
[...]

Ik heb de code op de voorpagina van de website geobserveerd en het ziet er al anders uit dan ik gewend ben, geen ; en geen { en }

Layout-gebaseerde syntax is een idee uit de jaren '60. Peter Landin beschreef een systeem (ISWIM - If you See What I Mean) dat gebruikmaakt van de offside rule, geinspireerd door de gangbare manier hoe we wiskunde bedrijven.

[ Voor 38% gewijzigd door RayNbow op 13-09-2016 07:24 ]

[526735]

Brakkie41 schreef op maandag 12 september 2016 @ 18:05:
[...]


Mwah ik gebruik momenteel +- 100 v/d 256 GB. Ik snap niet hoe dev'vers hun disks volkrijgen tenzij je test db's draait op je laptop? Het enige wat er op m'n laptop staat is een berg repo's en docker containers. Gros van de projecten waar ik aan werk draaien in Docker containers. Verder valt het kwa installaties heel erg mee Ruby, Python, Erlang + OTP en Elixer (en hun dependencies). Dan ben ik er wel denk ik

Ik snap ook niet hoe devs hun disks vol krijgen. Als ik Windows gebruik, heb ik na een jaar makkelijk 250GB vol, maar als ik Linux gebruik, heb ik na een jaar nog geen 3GB vol…

ard1998 schreef op dinsdag 13 september 2016 @ 07:04:
Ik heb de code op de voorpagina van de website geobserveerd en het ziet er al anders uit dan ik gewend ben, geen ; en geen { en }

Python?

[ Voor 18% gewijzigd door 526735 op 13-09-2016 07:42 ]

[Hydra]

PatrickH89 schreef op maandag 12 september 2016 @ 16:52:
Developers hebben er altijd een handje van om niet breder te zien dan hun eigen viewpoint en menen hun viewpoint op te moeten leggen aan anderen.

Laat me raden; jullie doen ook niet aan testen?

ard1998 schreef op maandag 12 september 2016 @ 17:56:
al met al, er moet meer aandacht komen voor programeren op de lagere school (groep 7/8) en de middelbare school.

We gaan vanuit ons bedrijf in Oct een Devoxx4Kids sessie doen. Ben erg benieuwd! Het is op dit moment in ieder geval kwa lager onderwijs enorm mis aan het gaan. Geen docenten die kinderen kennis laten maken met techniek (want vooral vrouwen die het niet interesseert) en geen gelijke kansen voor meisjes en jongens.

[armageddon_2k1]

RayNbow schreef op maandag 12 september 2016 @ 22:14:
[...]

Momenteel op mobiel, dus kan niet zo gemakkelijk een goed plaatje vinden, maareh... zoiets?
[afbeelding]

code:

Set Variant Variant + 1

!!!!!

Herinneringen.... mijn pa had dat gekocht toen ik 9 was. Vond het echt geweldig. Uiteindelijk deel 2 ook gekocht met de Referentiegids

[Creepy]

F.West98 schreef op dinsdag 13 september 2016 @ 00:15:
[...]
Oh en gefeliciteerd Creepy!

Thanks! Ik moet je toch eens ontvrienden op Facebook zodat je die jaarlijke reminder niet meer krijgt
_{En die taart hier @ forum verwijderen, I know}

[ Voor 9% gewijzigd door Creepy op 13-09-2016 08:47 ]

[Ryur]

Creepy schreef op dinsdag 13 september 2016 @ 08:47:
[...]

Thanks! Ik moet je toch eens ontvrienden op Facebook zodat je die jaarlijke reminder niet meer krijgt
_{En die taart hier @ forum verwijderen, I know}

Het staat NU in mijn agenda voor volgend jaar. Dus ik ga het niet vergeten
Gefeliciteerd! Hoeveel kaarsjes staan er op je taart? _{lekker subtiel van mij}

[RayNbow]

armageddon_2k1 schreef op dinsdag 13 september 2016 @ 08:37:
[...]

code:

Set Variant Variant + 1

!!!!!

Herinneringen.... mijn pa had dat gekocht toen ik 9 was. Vond het echt geweldig. Uiteindelijk deel 2 ook gekocht met de Referentiegids

Ik weet niet meer bij welk boek het was, maar bij 1 boek zat een driver om wave files af te spelen via de PC speaker. Dat was best handig op m'n 386 die geen geluidskaart had.

(Dat het hele systeem hing tijdens het afspelen van een wave file was wel wat minder. )

[.oisyn]

Caelorum schreef op maandag 12 september 2016 @ 20:56:
Ik merk alleen dat sommigen* verwachten dat mensen al ervaring hebben met programmeren als ze die opleiding beginnen

Tja, ik vond het destijds erg raar dat 90% van mijn klas nog nooit eerder had geprogrammeerd toen ik op de opleiding begon. Ik was zelf in mijn basisschooltijd al begonnen .

[Geerrrt]

/me ontvangt mail voor stage aanvraag

Ook houd ik er van om kritisch en net te werk te gaan.

Graag hoor ik van u of dit deze periode kan ook hoop ik dat u mij uitnodigt op een stagegesprek zodat ik u mijn cv of vragen verder kan toelichten.

/me zoekt bijlage..

[Swedish Clown]

GeertJam schreef op dinsdag 13 september 2016 @ 09:19:
/me ontvangt mail voor stage aanvraag


[...]


[...]


/me zoekt bijlage..

Als het vanaf een Gmail is verstuurd helemaal lomp aangezien deze meld dat er geen bijlage is als dit wel wordt vernoemd in de email

[Geerrrt]

Brakkie41 schreef op dinsdag 13 september 2016 @ 09:23:
[...]


Als het vanaf een Gmail is verstuurd helemaal lomp aangezien deze meld dat er geen bijlage is als dit wel wordt vernoemd in de email

Outlook, geen idee of die dat ook doet

[HuHu]

.oisyn schreef op dinsdag 13 september 2016 @ 09:13:
[...]

Tja, ik vond het destijds erg raar dat 90% van mijn klas nog nooit eerder had geprogrammeerd toen ik op de opleiding begon. Ik was zelf in mijn basisschooltijd al begonnen .

De andere kant op kan ook. In mijn jaar zaten ook "autodidacten" die al heel lang programmeerden, maar vervolgens wel faalden, omdat ze niet wilden wijken van compleet fout aangeleerde zaken.

[RayNbow]

.oisyn schreef op dinsdag 13 september 2016 @ 09:13:
[...]

Tja, ik vond het destijds erg raar dat 90% van mijn klas nog nooit eerder had geprogrammeerd toen ik op de opleiding begon. Ik was zelf in mijn basisschooltijd al begonnen .

Maar aan de andere kant moet je natuurlijk wel beseffen dat niet iedereen tijdens z'n basisschool beschikking had tot een computer. Zelfs in de eerste paar jaren van m'n middelbare schooltijd had niet iedereen een pc.

[.oisyn]

Ik vind dat nu ook niet meer vreemd. Maar ik wist natuurlijk niet anders. Wie gaat er nou immers een programmeerstudie doen als je nog nooit geprogrammeerd had . Een paar mensen die ik nog kende van mijn middelbare school die ook informatica deden hadden er ook allemaal al affiniteit mee. Mijn wereldbeeld was dus dat iedereen op de hogeschool daar al lang en breed mee bezig was. Maar al snel werd duidelijk dat ík het buitenbeentje was.

HuHu schreef op dinsdag 13 september 2016 @ 09:29:
[...]

De andere kant op kan ook. In mijn jaar zaten ook "autodidacten" die al heel lang programmeerden, maar vervolgens wel faalden, omdat ze niet wilden wijken van compleet fout aangeleerde zaken.

Volgens mij stond de kwaliteit van de studenten niet echt ter discussie

[ Voor 49% gewijzigd door .oisyn op 13-09-2016 09:48 ]

[TheNephilim]

RayNbow schreef op dinsdag 13 september 2016 @ 09:41:
[...]

Maar aan de andere kant moet je natuurlijk wel beseffen dat niet iedereen tijdens z'n basisschool beschikking had tot een computer. Zelfs in de eerste paar jaren van m'n middelbare schooltijd had niet iedereen een pc.

Daarin is er denk ik niet veel veranderd. De kindertjes van nu hebben namelijk een tablet of smartphone en vaak (denk ik) geen PC of zelfs laptop meer. Dan is het toch lastig klooien en prutsen met wat programmeer-gerelateerde dingen. Sowieso zal de 'prikkeling' minder zijn omdat een tablet bijv. veel meer kan en klaar is.

[Caelorum]

TheNephilim schreef op dinsdag 13 september 2016 @ 09:46:
[...]
Daarin is er denk ik niet veel veranderd. De kindertjes van nu hebben namelijk een tablet of smartphone en vaak (denk ik) geen PC of zelfs laptop meer. Dan is het toch lastig klooien en prutsen met wat programmeer-gerelateerde dingen. Sowieso zal de 'prikkeling' minder zijn omdat een tablet bijv. veel meer kan en klaar is.

Mja, daar staat tegenover dat je tegenwoordig apps voor de mobiel hebt die je de basis van programmeren (spelenderwijs) aanleren gericht op allerlei leeftijden. Beginnend van ~4 jaar tot zowat bejaard. Dat was er vroeger ook niet. Het is in dat opzicht alleen maar makkelijker geworden om er iets mee te doen, maar het is gewoon vreemd (IMO) dat je er vanuit gaat dat mensen het al enigszins kunnen als ze beginnen met een opleiding. Is daar nou niet net die opleiding voor?

[TheNephilim]

Caelorum schreef op dinsdag 13 september 2016 @ 09:54:
[...]

Mja, daar staat tegenover dat je tegenwoordig apps voor de mobiel hebt die je de basis van programmeren (spelenderwijs) aanleren gericht op allerlei leeftijden. Beginnend van ~4 jaar tot zowat bejaard. Dat was er vroeger ook niet. Het is in dat opzicht alleen maar makkelijker geworden om er iets mee te doen [...]

Dat is waar, maar naar mijn idee is dat niet het klooien met scriptjes en weet ik wat zoals dat vroeger ging. Instappen zal wel een stukje makkelijker geworden zijn op die manier idd.

maar het is gewoon vreemd (IMO) dat je er vanuit gaat dat mensen het al enigszins kunnen als ze beginnen met een opleiding. Is daar nou niet net die opleiding voor?

Oh nee daar ga ik niet vanuit, wat al eerder gezegd is; je moet net ouders hebben die een PC kopen. Ik had dat geluk wel, dat zal zeker gescheeld hebben.

[incaz]

Ik had vanaf de basisschool beschikking over een computer, en vond dat ook ontzettend interessant - maar ben simpelweg nooit in aanraking gekomen met programmeren. En dat was denk ik toch wel omdat ik als meisje gewoon nauwelijks daarmee in aanraking kwam. De verhalen van mijn leeftijds/studiegenoten waren bv dat ze dat met vriendjes samen uitvogelden, wellicht ook eerder tijdschriften of boeken kregen voor hun verjaardag waarin dat beschreven stond... ik wist gewoon niet dat het bestond en het is er dus nooit van gekomen tot ik op de uni kwam.

Hydra schreef op dinsdag 13 september 2016 @ 08:13:
We gaan vanuit ons bedrijf in Oct een Devoxx4Kids sessie doen. Ben erg benieuwd! Het is op dit moment in ieder geval kwa lager onderwijs enorm mis aan het gaan. Geen docenten die kinderen kennis laten maken met techniek (want vooral vrouwen die het niet interesseert) en geen gelijke kansen voor meisjes en jongens.

Ik weet dus niet of het vrouwen echt niet interesseert, of dat het zo gezien wordt als gescheiden werelden waarbij zowel vanuit de technische hoek als vanuit de niet-technische hoek het idee in stand gehouden wordt dat het iets bijzonders is, dat je er aanleg voor moet hebben (zoals bij wiskunde), en dat je de denkvaardigheden maar vanaf 1 kant kunt leren (vanuit het abstracte.)

De hele omgeving van technische zaken is daardoor vaak vrij intimiderend, zo word je al snel als minder gezien als je niet uit de voeten kunt met limegroene tekst op een donkere achtergrond, niks hebt met commandline etc. Voor het systematisch en abstract denken maakt dat niet uit - maar de uiterlijkheden scheppen een bepaalde cultuur waar sommige mensen zich erg in thuisvoelen maar waar andere mensen door geintimideerd voelen, zonder dat het iets te maken heeft met wat eronder ligt.

Ik ben wel benieuwd in hoeverre de lesmethode ook ontwikkeld wordt, niet alleen met kennis van programmeren maar ook met kennis van de ontwikkeling van kinderen? Heb namelijk het idee dat daar nog wel wat te halen is: het liefst wil je de zaken zo aanbieden dat ze de denkstappen in een natuurlijke volgorde maken. Maar over didactiek en ontwikkeling van die zaken is volgens mij nog maar weinig bekend, in tegenstelling tot bv wat we weten over taalontwikkeling.

[Tjolk]

Toen ik op de havo zat (2e helft jaren '90) hadden we het vak Informatica en daar werd o.a. met Baltie gewerkt. Dat zag er ongelooflijk simpel en ietwat kinderlijk uit, maar leerde je wel een beetje stapsgewijs problemen oplossen. linkje. Het leerde je vrij eenvoudig om doelen op een efficiënte manier op te lossen. Bijvoorbeeld:

• Je had een poppetje wat je een stap vooruit kon laten zetten.
• Je kunt dat commando 10x apart geven, maar ook zeggen: 10 x (stap vooruit). Da's handig!
• Na 10 stappen kwam je bij een muur. Maar die muur staat niet altijd 10 stappen verwijderd. Dus: while (niet tegen de muur) -> zet stap vooruit.
• etc.

Er was vrij veel mogelijk en het nam je aan de hand om een programma te schrijven. En voordeel: je zag meteen een grafische weergave van het resultaat.

Tegenwoordig zijn er wel meer van zulke programma's die er ook wat professioneler uitzien.

[.Gertjan.]

RayNbow schreef op dinsdag 13 september 2016 @ 07:14:
[...]
Zeg maar wanneer je klaar bent om een simpele, 1-regelige spreadsheetevaluatiefunctie te kunnen schrijven.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[PatrickH89]

Hydra schreef op dinsdag 13 september 2016 @ 08:13:
[...]


Laat me raden; jullie doen ook niet aan testen?

Flauw en incorrect

[DevWouter]

Waarschijnlijk is één van de reden dat er zo weinig vrouwen in de techniek zitten omdat ze geen computer krijgen van de ouders maar poppen. Als je kijkt naar de historisch man-vrouw ratio in de computer industrie dan zie je dat het aantal vrouwen daalde na de introductie van de "personal computer".

[Voutloos]

Of de poppen zijn populairder geworden nadat ze met de pc beter ontworpen konden worden.

spoiler:

Of alleen de echte mannen bleven over na het verplicht stellen van unittests.

[ Voor 34% gewijzigd door Voutloos op 13-09-2016 11:22 ]

[ElkeBxl]

DevWouter schreef op dinsdag 13 september 2016 @ 11:14:
Waarschijnlijk is één van de reden dat er zo weinig vrouwen in de techniek zitten omdat ze geen computer krijgen van de ouders maar poppen. Als je kijkt naar de historisch man-vrouw ratio in de computer industrie dan zie je dat het aantal vrouwen daalde na de introductie van de "personal computer".

Echt? Dat is het eerste dat ik daar over hoor.

Eerste echte pc die ik had was gewoon een pc voor het hele gezin. Ik claimde die gewoon direct. Daarvoor had ik ooit zo'n ding van VTech gekregen:

(Niet exact hetzelfde maar je kent ze waarschijnlijk wel)
Was wel grappig, daar kon je ook in een soort van BASIC op programmeren * ElkeBxl wordt nu helemaal nostalgisch

incaz schreef op dinsdag 13 september 2016 @ 10:07:
De hele omgeving van technische zaken is daardoor vaak vrij intimiderend, zo word je al snel als minder gezien als je niet uit de voeten kunt met limegroene tekst op een donkere achtergrond, niks hebt met commandline etc. Voor het systematisch en abstract denken maakt dat niet uit - maar de uiterlijkheden scheppen een bepaalde cultuur waar sommige mensen zich erg in thuisvoelen maar waar andere mensen door geintimideerd voelen, zonder dat het iets te maken heeft met wat eronder ligt.

So true. Op unief hadden we bv. een paar Macs staan naast de vele linux desktops. Je werd bijna uitgelachen door bepaalde docenten/assistenten als je daarop ging devven. Want "echte dev" hoorde thuis op een linux, liefst met enkel een terminal voor je source control te doen en met vim om je files te editen. Microsoft werd als evil gezien omdat ze zo'n sterke marktpositie hadden en Apple was ook de duivel omdat ze wat duurder zijn en zogezegd "enkel voor hipsters" waren.

Niet moeilijk dat er dan een soort van select clubje ontstond en de studentenkring voor informatici 1 groot sausagefest was vol linux fanboys. Die konden ook alleen maar tegen mij praten als ze een kans zagen om te bashen op het feit dat ik een Macbook had gekocht. Tja, zo versterkt men dat gevoel van intimiderend alleen maar Zijzelf hebben er niet echt last van maar het schaadt wel het hele imago van de IT en versterkt het algemeen beeld dat IT een nerdfest en sausagefest is.

Als ik nu tegen mensen zeg dat ik in IT zit, krijg ik vaak genoeg de reactie dat ik "dapper" ben omdat ik 1 van de enige vrouwen ben, dat ik "raar" ben omdat ze denken dat iedere collega van mij een nerd is, ... Probeer dan maar eens jonge vrouwen te motiveren om IT te gaan doen. Zeker als HR bij ons dan ook nog eens zegt tegen mij "dat ik mee moet helpen om IT sexy te maken". Goed plan hoor om "vrouwen in IT" met "sexy" proberen te associeren. Daar ga ik nu eens lekker niet aan mee doen

[.Gertjan.]

DevWouter schreef op dinsdag 13 september 2016 @ 11:14:
Waarschijnlijk is één van de reden dat er zo weinig vrouwen in de techniek zitten omdat ze geen computer krijgen van de ouders maar poppen. Als je kijkt naar de historisch man-vrouw ratio in de computer industrie dan zie je dat het aantal vrouwen daalde na de introductie van de "personal computer".

Meh, denk niet dat het zo zeer te maken heeft met gender typische opvoeding/speelgoed. Mannen zijn sneller nieuwsgierig en neigen meer naar de analytische kant. Ook zijn "wij mannen" misschien sneller geneigd om te experimenteren en zijn we minder snel bang dat er iets kapot gaat.

Aangezien techniek snel "feedback" geeft op je actie, blijf je nieuwsgierig en wakkert je interesse aan als dat je ding is.