Cursus foutanalyse/debugging?

[Cass Casey]

Ondanks dat het op GoT over van alles en nog wat gaat, zijn er volgens mij nog steeds veel technische ICT'ers en aanverwanten actief. Wellicht kunnen jullie me helpen.

Ik ben momenteel projectleider/teamcoördinator van een BI-team. Eén van de teamleden, een DWH Developer, lijkt wat moeite te hebben met het analyseren van foutmeldingen, bugs, analyse van data/datamodellen, etc. Ze is heel enthousiast over Azure en het bouwen van pipelines, maar zodra ze ergens tegenaan loopt, mist ze de structuur en de aanpak om een juiste oplossing te vinden.

Nu gaan we haar als teamleden wel hierbij coachen (bijv. middels "rubber duck debugging"), maar ik vroeg me af of er cursussen, trainingen of workshops zijn (online of fysiek) die ze zou kunnen volgen om hier wat meer over te leren. Probleemoplossend vermogen is ook iets wat in je moet zitten, maar je kan het ongetwijfeld ook ontwikkelen.

Iemand advies voor me?

[Furion2000]

Dit vind ik wel leuke onderwerpen, waar veel fout gedaan kan worden in zo'n situatie. Dingen kunnen backfiren en averechts werken

Mijn mening:
- Als het initiatief van een cursus vanuit hogerhand komt is voor mij een red flag
- Probleemoplossend vermogen van hoge kwaliteit zit misschien in je, maar bijna elke persoon kan een acceptabel niveau leren.

Mijn 2 cents:
Ga in het gesprek met die persoon en je kunt opsommen wat je verwacht van een teamlid en probeer met wat nuance de persoon zelf laten realiseren dat het bij die zelfredzaamheid nog beter kan. Als dat lukt en deze persoon wil verbeteren, ga samen een plan maken (waarin je alleen vragen stelt zodat die persoon zelf met ideeen komt | ownership) en als er tijd nodig is van een bepaalde collega, maak dit dan kenbaar in het team en zorg dat er ook echt tijd voor is.

Monitor dat er tijd word gemaakt en verzin een manier om de voortgang an sich te monitoren. Bijv. als het beter gaat zal die persoon minder momenten met collega y nodig hebben.

Je kunt het zelfs nog genuanceerder opzetten door gewoon eens dit stukje van het werk te gaan beschrijven. Wij als team werken zus en zo en als we vastkomen te zitten dan pakken we dat zo aan. Tijdens zo'n sessie kunnen senior collega's soms nog wel eens wat leren van de junior collega's. Een persoon in het team het zichtbaar moeite, maar kan ook zijn dat iedereen zomaar wat doet en is het een kans om het hele niveau in 1x op te krikken en iets te beschrijven wat elke nieuwe collega zo gepresenteerd kan krijgen. triple win

Talloze ideeen waar jij als manager niet de boel gaat dicteren of gaat verzinnen voor een collega, dat werkt niet en heeft nooit gewerkt imo. Het initiatief moet altijd bij de collega blijven, jij kunt alleen de verwachtingen blijven herhalen, initiatief aanmoedigen en hulp bieden als het er is.

Maar om even extra duidelijk te zijn, dat je wil helpen en de moeite neemt om naar GoT te gaan vind ik kudos waard. Top!

[ Voor 17% gewijzigd door Furion2000 op 12-07-2023 12:45 ]

[Hydra]

Cass Casey schreef op woensdag 12 juli 2023 @ 11:46:
Ik ben momenteel projectleider/teamcoördinator van een BI-team. Eén van de teamleden, een DWH Developer, lijkt wat moeite te hebben met het analyseren van foutmeldingen, bugs, analyse van data/datamodellen, etc. Ze is heel enthousiast over Azure en het bouwen van pipelines, maar zodra ze ergens tegenaan loopt, mist ze de structuur en de aanpak om een juiste oplossing te vinden.

Ik zou beginnen met een gesprek en gewoon vragen aan haar waar ze zelf denkt dat het misgaat, waarbij je duidelijk maakt dat de insteek is om haar daarin te helpen. Het kan gewoon prima ook gewoon om technische inhoud gaan, dat ze net genoeg weet van het platform om gevaarlijk te zijn, maar eigenlijk niet genoeg technische achtergrond heeft om er diep in te duiken.

Probleemoplossend vermogen is ook iets wat in je moet zitten, maar je kan het ongetwijfeld ook ontwikkelen.

Nouja, problemen oplossen is letterlijk alles dat je doet als developer. Dus als een developer dat niet kan, is 'ie eigenlijk geen developer. En er zijn er nogal wat die als 'developer' werken maar volledig afhankelijk zijn van andere en alleen de uitwerking in code kunnen doen. En dat is eigenlijk maar 10% van 't werk.

Het is vanuit je post heel lastig in te schatten waar het probleem zit. Problemen oplossen is niks anders dan een hypothese formuleren en deze dan toetsen. Dit doen we eigenlijk continue in ons hoofd. In het geval van complexere zaken bijvoorbeeld op een whiteboard. Dit geldt ook voor fouten die optreden; je bedenkt wat er fout kan gaan en sluit dan het een na het ander uit.

Je moet alleen wel weten wat er allemaal fout kan zijn. Als je een developer iets laat deployen en deze dev heeft geen benul van wat DNS is, dan gaat 'ie ook niet aan DNS errors denken. Dit is heel vaak waar het mis gaat met "self taught" devs die eigenlijk niet meer weten dan hoe ze code schrijven, zonder dat ze weten wat er allemaal achter zit.

[Cass Casey]

@Furion2000 en @Hydra , bedankt voor jullie uitgebreide reacties. Om wat achtergrond te geven: ik ben zelf ook ontwikkelaar, maar nu meer op de stoel gezet van beleidsmedewerker/projectleider.

Het is ook zeker niet de bedoeling om haar een cursus op te leggen. We helpen haar al waar nodig, maar er komen binnenkort opleidingsbudgetten vrij voor iedereen om soft- en hardskills te verbeteren. Voor de een is het time management, voor de andere op het communicatieve vlak en voor dit teamlid misschien iets om de developer-skills te verbeteren.

Ik kan erg goed met haar overweg, dus kan dit gewoon met haar bespreken.

@Hydra , helemaal met je eens dat debugging een kerntaak van een developer is. Vandaar dat ik me hier zorgen over maak. Om een voorbeeld te geven: ze was een Synapse Pipeline aan het bouwen die een csv-bestand moest importeren in een Data Lake. Dat ging fout en ze wist niet waarom. Dagen aan het zoeken geweest naar allerlei exotische oplossingen. Tot ze om hulp vroeg en we zagen dat er in één van de velden een multi-line value stond met CRLF erin. Dus de pipeline maakte daar een nieuwe regel van. Een kwestie van een vinkje aanzetten... Dat was te voorkomen geweest als ze terug ging naar de basis ging en stap voor stap door het probleem te gaan. Wat is nou belangrijk bij een character separated file? Het scheidingsteken, text-delimiters, new line character. En vergelijk dan eens een regel die goed gaat en een regel die fout gaat. Ik verwacht van een developer dat hij/zij dat zelf kan bedenken om dat structureel door te lopen.

Maar vraag is dus: is het een kwestie van coaching/learning on the job of zijn er lesprogramma's voor?

[TweakerVincent]

Is ze niet gewoon te junior voor haar rol?

[Cass Casey]

TweakerVincent schreef op woensdag 12 juli 2023 @ 13:49:
Is ze niet gewoon te junior voor haar rol?

Daar begint het op te lijken, maar ook een developer mag junior zijn en zich ontwikkelen. Maar ja: lijkt erop dat we haar te hoog ingeschaald hebben.

[twdikkert]

Dit is denk ik wat je zoekt. Is een standaard methode, die in elke omgeving toepasbaar is.
https://kepner-tregoe.com/training/analytic-troubleshooting/

[com2,1ghz]

Pair programmen.

[noo]

Geen cursus maar een mijns inziens goed boek: An Engineer's Guide to Solving Problems van Bob Schmidt.

https://www.amazon.com/En...ng-Problems/dp/0988747626 (voor de preview)

[ Voor 4% gewijzigd door noo op 12-07-2023 14:04 ]

[Hydra]

Cass Casey schreef op woensdag 12 juli 2023 @ 14:01:
Daar begint het op te lijken, maar ook een developer mag junior zijn en zich ontwikkelen. Maar ja: lijkt erop dat we haar te hoog ingeschaald hebben.

Dan leert ze het meest van pairen met een senior vermoed ik.

[CVTTPD2DQ]

Cass Casey schreef op woensdag 12 juli 2023 @ 13:07:
Dat ging fout en ze wist niet waarom. Dagen aan het zoeken geweest naar allerlei exotische oplossingen. Tot ze om hulp vroeg

Ik lees hier twee dingen. Ze had niet zo snel de bug gevonden, én het duurde dagen voordat ze om hulp vroeg.

Een van de belangrijkste dingen die je leert als developer is dat je fouten maakt, en dingen over het hoofd ziet. Hoe slim je ook bent, en hoe ervaren je ook bent. Daar compenseer je voor door jezelf te controleren, en door anderen je denken te laten controleren.

Maar sommige mensen hebben het gevoel dat ze geacht worden alles perfect en zelfstandig te kunnen doen. En als ze iets niet meteen kunnen oplossen, dan is dat hun gebrek.

Iets wat je als senior kunt doen om een junior dat vertrouwen te geven is juist die junior om hulp vragen als je vast zit. Dan maak je de hulp wederkerig, je maakt duidelijk dat iedereen wel eens vast komt te zitten, en je stelt je ook als senior wat kwetsbaarder op.

[Furion2000]

Cass Casey schreef op woensdag 12 juli 2023 @ 13:07:
We helpen haar al waar nodig, maar er komen binnenkort opleidingsbudgetten vrij voor iedereen om soft- en hardskills te verbeteren.

En vergelijk dan eens een regel die goed gaat en een regel die fout gaat. Ik verwacht van een developer dat hij/zij dat zelf kan bedenken om dat structureel door te lopen.

Die fouten moet je maken toch? Dan word je beter. (weten we allemaal al, maar even onderstrepen) Misschien ook kijken hoe je haar helpt? Zeg je het voor of laat je het kwartje bij haar vallen door ze in jouw proces mee te nemen? Zoals ik al zei als team eens dat proces goed doorlopen via een georganiseerde sessie of pair programming kan al oplossing geven. Vaak hebben devs zelfs niet zo'n trek in pair programming of het organiseren van een sessie

Ik heb ongelimiteerd opleidingsbudget, maar zoals jij het zegt zit het in je organisatie niet helemaal snor. Leuk hoor zo'n budget, maar er moet een mindset zijn dat er altijd tijd is om leren en dat je altijd wanneer nodig ad hoc om een cursus kan vragen. Het leren toejuichen.

Zoals het nu neergezet word is dat management van hogerop het op de heupen krijgt dat ze iets moeten doen aan skills en dan budget ineens vrijmaken, vervolgens moet iedereen geforceerd gaan participeren en doe je dit niet dan is het een stok om mee te slaan op je functioneringsgesprek. Zowel van diegene die het niet doen zowel de projectleiders die het budget niet uitgeven (wereld op zijn kop).

Zo werkt leren imo niet, CLRF dingetje en is de source hiervan competentie dan pak je even een halve dag waar je paar experimentjes gaat doen en antwoord geeft op je vraag: "Wat is nou belangrijk bij een character separated file?". Huppake een kleine kennisgap in 4 uurtjes getackled.

Zou helemaal cool zijn als teamleden dit zelf durven te zeggen, ik pak vanmiddag even om dit en dit verder uit te diepen en kom dan terug met de resultaten en deel dat in het team.

Slag om de arm, ik leer het beste door te doen en geef mijn budget meestal uit aan conferenties:+

[ Voor 3% gewijzigd door Furion2000 op 12-07-2023 14:37 ]

[PB-powell]

CVTTPD2DQ schreef op woensdag 12 juli 2023 @ 14:07:
[...]


Ik lees hier twee dingen. Ze had niet zo snel de bug gevonden, én het duurde dagen voordat ze om hulp vroeg.

Een van de belangrijkste dingen die je leert als developer is dat je fouten maakt, en dingen over het hoofd ziet. Hoe slim je ook bent, en hoe ervaren je ook bent. Daar compenseer je voor door jezelf te controleren, en door anderen je denken te laten controleren.

Maar sommige mensen hebben het gevoel dat ze geacht worden alles perfect en zelfstandig te kunnen doen. En als ze iets niet meteen kunnen oplossen, dan is dat hun gebrek.

Iets wat je als senior kunt doen om een junior dat vertrouwen te geven is juist die junior om hulp vragen als je vast zit. Dan maak je de hulp wederkerig, je maakt duidelijk dat iedereen wel eens vast komt te zitten, en je stelt je ook als senior wat kwetsbaarder op.

Ik lees hier drie dingen, naast de 2 dingen die jij leest lees ik ook gebrek aan aandacht van een senior/leidinggevende. Geen idee hoe lang ze in dienst is maar bij ons wordt bijna elke dag en anders minimaal om de dag gevraagd of het lukt bij deze en gene of dat ze ergens klem lopen.
Uiteindelijk moet zo'n persoon leren en ervaren dat zelf dingen eerst uitzoeken noodzakelijk is, maar men moet ook niet bang zijn om om hulp te vragen als ze echt niet verder komen. En of er hier cursussen oid voor zijn geen idee, ik heb het mijzelf aardig aangeleerd in ieder geval.

[Cass Casey]

Och hemel. Dit topic gaat nu een compleet eigen leven leiden op basis van allerlei aannames die volkomen onjuist zijn. Ik dank jullie voor de antwoorden. De genoemde cursus en het boek ga ik bekijken. Verder lossen we het hier gewoon op, zoals we altijd doen: collegiale ondersteuning. Ik ga verder niet in op de aannames die ik verder hier lees.

Merci!