ELE Competenties

In het eerste jaar van de opleiding elektrotechniek heb ik veel moeten analyseren. Gelukkig was ik daar niet wereldvreemd van, omdat ik dat zelf al veel doe door persoonlijke (programmeer)projecten. Ik ben in labs en bij projecten meermaals tegen problemen aangelopen waarbij een probleem geanalyseerd moest worden, zodat deze opgelost kon worden. In mijn ogen ben ik daar dit jaar wel in gegroeid, omdat het analyseren wat ik heb gedaan op een kundigere manier moest gaan.

Voordat ik aan de opleiding begon kon ik al ontwerpen en dan voornamelijk op het gebied van games en software. Wat ik nog helemaal niet kon waren dingen zoals 3D modelleren en schakelingen maken. Ook het hele ontwerpproces vastleggen doe ik tegenwoordig veel meer secuur dan voorheen.

Realiseren is een competentie die ik altijd al wel onder de knie heb gehad. Zo ben ik altijd in de weer met een of ander project, en heb ik daardoor dus super veel ervaring met van niets tot íéts komen. Wel is mijn realisatieproces gestroomlijnder geraakt, doordat ik in groepsverband producten moest gaan realiseren. Zo maak ik nu standaard gebruik van BOMmen en strookplanningen, terwijl dat voorheen nooit zo was. Ook is mijn methodiek minder onorthodox geworden, doordat ik heb geleerd alles goed te testen door middel van unittesten, integratietesten en acceptatietesten.

Ik heb voorheen al in groepsverband in verschijdende projecten gewerkt en probeer altijd een teamspeler te zijn. Ook als projectlid doe ik dan aan managen: ik wijs mensen op hun taken, beheer zaken die het project ondersteunen zoals onder andere de planning, richtlijnen voor de documentatie en zorg ervoor dat de deadlines gehaald worden. Ik sta op dat vlak grotendeels op hetzelfde punt.

Een project leiden is altijd leuk, maar ik vind het zelf belangrijker om in groepsverband er altijd voor te zorgen dat er een goede structuur aanwezig is: zonder structuur kan je namelijk zo het doel uit het oog verliezen. Daarom had ik mij als notulist en planner geprofilieert voor PEE10 en als planner voor PEE20. Voor PEE10 hield ik bijna alle notules, de strookplanning en de BOMmen. Voor PEE20 heb ik de notules uit handen laten nemen door Ismail, waardoor ik me meer kon focussen op het in acht houden van de planning en de verzorging van de BOMmen. Tussen de twee projecten zit maar een halfjaar verschil, maar op documentatievlak ben ik veel verbetert. Ook stelde ik mezelf voorop als Code Quality Engineer of Code Maintainer bij de Bitbucket repository voor PEE20. Ik heb voorheen al in teams gewerkt voor bijvoorbeeld het ontwikkelen van games en simulaties, en weet daardoor hoe belangrijk is dat de code goed gedocumenteerd wordt, de code conventies gevolgd worden en commit messages zo gestructureerd zijn dat alles terug te vinden is. Op die manier blijft de code base gezond, en omdat dit het eerste project is waarbij programmacode kwam kijken, was het nog niet duidelijk hoe groot de repository uiteindelijk zou kunnen groeien. Ook hierbij heb ik grote stappen gemaakt, doordat wij formele afspraken in de README.md hadden gemaakt en code conventions hadden opgesteld. 

Al jaar en dag ben ik bezig met het adviseren van mensen. Of het nou voor school is of een persoonlijk project; het geven en krijgen van adviezen staat mij dagelijks bij. Ik heb dit jaar daarom ook voolop zitten adviseren, binnen de opleiding, maar ook daarbuiten. Zo werd ik laatst nog om advies gevraagd door een oud schoolgenoot over problemen die zij houden met bluetoothtransmissie. Dikwijls wordt ik ook door andere studenten gevraagd over diverse problemen, van het berekeken van waardes tot het debuggen van programmacode. Ik heb daarom ook niet het idee dat ik veel heb kunnen groeien in deze competentie, omdat hier al een redelijk grote basis voor was.

Onderzoeken is misschien nog wel de competentie die mij het meest ligt. Niet omdat ik er per sé goed in ben, maar vooral omdat ik het leuk vind om te doen. Ik vind het altijd een goed excuus om vooral nog meer kennis op te doen. Zo heb ik voor PEE10 voor de equaliser niet een eerste orde filter ontworpen, maar waren het 4e orde Butterworth filters. Deze had ik met een tool ontworpen, maar ik wilde zelf begrijpen hoe zij de waardes hadden berekent. Dus heb ik meerdere papers van Texas Instruments en verschillende boeken over (audio)filters gelezen. Uiteindelijk kon ik de berekengingen voor de waardes reproduceren, en had ik het onderzoek in de documentatie gestopt. Voor PEE20 heb ik ook aardig wat extracurriculair onderzoek gedaan. We wilden een tank bouwen, dus moest er een custom behuizing ontwikkeld worden. Voor de aandrijflijn moest er toen gekozen worden wat voor motoren we zouden gebruiken, dus had ik in python een simulatie op basis van gewicht, snelheid en een  kleine helling geschreven met behulp van natuurkundige vergelijkingen. Ik was tot deze vergelijkingen gekomen na heel wat speurwerk over berekeningen voor wielen, dozen en rolbanden. Uiteindelijk kwam ik op een forum met een post over berekeningen voor robotauto's op wielen die op een helling moet kunnen rijden, en dit was perfect voor mijn situatie. Het leren lezen en gebruiken van datasheets telt natuurlijk ook mee, maar naar mijn mening minder dan het voorgenoemde. Ook in deze competentie heb ik grote stappen genomen.

Ik heb stappen gezet om mezelf te professionaliseren. Zo ben ik op eigen initiatief met Rik en Badi op snuffelstage geweest bij Yokogawa in Amersfoort, nadat Rik en ik op de WOTS een stage aangeboden kregen. Ik zag het moeten bijhouden van een portfolio dan ook vooral als een manier om mij voorgaande en persoonlijke projecten onder de aandacht te brengen, om te laten zien wat ik allemaal kan. Ik heb alleen het idee dat ik hier nog geen grote slag in heb gemaakt, omdat enige structuur in professionalisatie afwezig was. Ik bedoel, wat is dat überhaupt?