Eric Leenman is senior digital designer bij Seecubic.
Een goede field application engineer (fae) is goud waard, heb ik onlangs nog ervaren. En dan bedoel ik echt alleen de goede, niet diegenen die ‘consultancy-adviezen’ uitdelen, maar niets doen. Of antwoorden dat jouw probleem bij hen niet optreedt.
Ik heb de projecten overgenomen van een collega die een andere uitdaging heeft gezocht. Het werk is overgedragen en de code staat in de repository, de code bouwt en de tests geven allemaal ‘pass’. Van het ene project weet ik meer dan van het andere omdat ik daar nauwer bij betrokken was. En zoals het gaat bij een overdracht ken je de hoofdlijnen, maar de details, de redenen waarom iets juist zo gedaan is of de specifieke implementatiekeuzes, die raak je met vertrekkende collega’s kwijt.
Dat is nog niet zo erg, als je niet gelijk iets met de projecten van je ex-collega hoeft te doen. Maar als er direct doorontwikkeld moet worden, is het een ander verhaal. Dan moet je de code snappen en aan kunnen passen zodat nieuwe requirements geïmplementeerd kunnen worden. Of als blijkt dat juist net na haar vertrek het gebruikte pcb niet meer is te verkrijgen en je over moet naar een nieuwe revisie. Dan moet je ook ineens in de code duiken omdat het nieuwe bord niet werkt met de oude code.
Al ken je de projecten en is er documentatie, nu komt het aan op de details. Als dan bij kleine wijzigingen je builds al breken, of de testresultaten failures geven, terwijl de change die je gedaan hebt eigenlijk niets hoort te veranderen, word je nog voorzichtiger. Dan schiet het door je hoofd: dit had ze toch werkend? Dan wordt het spitten, analyseren, opnieuw code genereren, logging toevoegen en constraints nalopen.
Device lifecycle management for fleets of IoT devices
Microchip gives insight on device management, what exactly is it, how to implement it and how to roll over the device management during the roll out phase when the products are in the field. Read more. .
Dan merk je pas welke detailkennis niet is opgeschreven en je ex-collega uit haar hoofd wist. Heb ik een inputklok? Waarom heb ik geen outputklok? Waarom werkt het wel op dit bord, maar niet op dat bord? Wat had ze hierover ook alweer gezegd?
Vaak zit je zelf al diep in het probleem voordat je een fae erbij roept. Je wilt ze niet om hulp vragen en dan als oplossing moeten melden dat de stekker er niet in zat. En als fae-support via een ticketsysteem wordt gegeven, dan bedenk je je wel drie keer voordat je ze vraagt.
Ik heb veel bewondering voor hoe echte fae’s dat doen. Ze tonen echt interesse, willen jouw probleem begrijpen, zoeken actief mee naar de fout en blijven scenario’s analyseren. Die fae’s moeten het vaak doen met een paar zinnen, en in een half uur laat je ze het probleem zien. Zonder de context van het project te kennen, worden ze dan diep in de details van de functie getrokken. Hopelijk kennen ze het vakgebied, maar dat is ook niet altijd het geval. En dan vraag je ze: ‘Waarom stallt deze pipeline, terwijl er genoeg data is om te processen?’ Niks inleren of documentatie doornemen van de functie. Nee, dit is het probleem en we gebruiken jouw tooling en waarom werkt het niet?
Als je dan ziet hoe de fae er zich in vastbijt, de juiste kritische vragen stelt, heel snel de context oppikt, dan weet je dat je de goede hebt. Diegene wil je helpen en het technische probleem oplossen.
Een fout kan vele oorzaken hebben. Soms mis je kennis, soms ligt het aan een fout statement in de code of een constructie die niet mag. Soms ligt het aan de scripting of incompatibele versies van diverse toolpakketten, of is het een bug in de tool. Als je samen de fout uiteindelijk hebt gevonden, dan weet je dat een echte fae een zegen is.