Hoe ga je om met het onprofessionele gedrag van stagiaires?

Ik denk niet dat lachen de juiste aanpak is. Ze moeten leren dat ze niet meer op school zitten. Dat gezegd hebbende, denk ik dat je het ook niet te ver moet laten komen.

Ik raad je aan om ferm met hem/haar om te gaan en iets te zeggen in de zin van:

De reden dat we de naamgeving van conventies hebben overgeslagen is omdat ze erg belangrijk zijn. Deze code moet in de toekomst te onderhouden zijn. Veel mensen hier hebben hard gewerkt om te komen waar ze zijn, en ze zullen dit soort grappen misschien niet waarderen. Gelieve in de toekomst af te zien van het gebruik van dit soort namen, omdat het mensen kan doen twijfelen aan uw professionaliteit.

Ten eerste lijkt dit een grap die in code werd gezet dat ze zich er terdege van bewust zijn dat ze nergens voor zullen worden gebruikt of dat ze nooit meer zullen lezen. Ik denk dat u veel te veel in dit incident leest. Het belangrijkste is dat je hen hebt verteld over de naamgevingsconventie en dat ze je niet hebben genegeerd, ze hebben wel langere en meer beschrijvende namen gebruikt (zij het sarcastisch).

Na het bekijken van deze video Ik kan zien dat werknemers 3 dingen verlangen:

1. 2. Autonomie
2. 2. Meesterschap
3. Meesterschap Doel

Wat je hen vraagt om te doen is niet autonoom, is voor sommigen van hen waarschijnlijk onbeduidend moeilijk en dient geen doel in hun ogen.

Maak de opdracht in orde, en de werknemers zullen volgen.

Sommige voorbeelden:

1. Hier is dit project, werk samen en laat het doen door___, laat het me weten als je vast komt te zitten.

2. Ik weet dat dit niet belangrijk lijkt, maar om je vaardigheden te beoordelen en je werk toe te wijzen waarvan we denken dat het je zal helpen om te groeien, hebben we je nodig om deze taak af te maken.

TL;DR : Ik heb bezwaar tegen de naam van de methode omdat deze (naar mijn mening!) minachtend is voor de baas en/of de “regels” (hier: stijlrichtlijnen). Op de werkvloer verwacht ik dat mensen zich houden aan de regel “love it, change it, or leave it”. In dit geval moet de stagiair, die van mening lijkt te zijn dat de richtlijn niet nodig is, het toch maar accepteren; of de discussie erover gaande houden; of stoppen met wat hij doet. Niet het equivalent van wat smeren op het toilet. Ik zou geen enkel bezwaar hebben gehad tegen een echt grappige, creatieve methodebenaming. Als je (de OP) de naam van de methode gewoon grappig vindt en niet “slecht” zoals ik, negeer dan dit antwoord alsjeblieft.

• *

Als achtergrond heb ik in het verleden een paar zeer intelligente en (zelf)gemotiveerde stagiaires begeleid, en nooit was er een keer de vraag of ze zich wel of niet professioneel zouden gedragen. Het brengen van schoolse domheid naar een werkplek als stagiair is zo ver uit het acceptabele, dat ik zou willen voorstellen om niet te rotzooien. Voor je eigen bestwil en vooral voor hun bestwil.

Ik wil graag weten hoe je zo'n situatie goed aanpakt.

Vergeet eerst de coderingsconventies. Het probleem heeft niets te maken met computers of programmeren.

• Lieg niet. Haal geen woorden uit, lach het niet uit, want het is echt geen lachertje.
• Word niet persoonlijk. Het gaat niet over je de OP, noch over je relatie met hen. Het gaat puur en alleen om hun gedrag.
• Leg de dingen uit zoals ze zijn. Je kunt de dader absoluut vertellen dat je een beetje begrijpt hoe hij op het idee is gekomen om te doen wat hij heeft gedaan, en dat je niet persoonlijk boos op hem bent of wat dan ook (houd emoties buiten), maar dat je de stage ziet als een vertoning van wie je later aan boord moet nemen.

Als je er enige emotie over wilt overbrengen, blijf dan ver weg van boosheid. Je kunt lichte droefheid tonen (en eerlijk gezegd zou dat precies zijn wat ik zou voelen) en laten zien dat je behoorlijk teleurgesteld bent.

Toch heeft hun optreden tijdens de stage invloed op hun kansen om aangenomen te worden en kunnen dit soort situaties later een rol spelen.

Absoluut! Niet rommelen met “kan later een rol spelen”. Gedrag als dit kan, moet en zal hun kans op een aanbod na de stage nihil maken. Je kunt zeggen dat je op welke manier je normaal gesproken ook tegen hen praat, duidelijk en duidelijk.

Probeer de hoofdoorzaak te vinden. Als je erachter komt dat ofwel…

• …ze zijn hier tegen hun vrije wil (misschien hebben hun ouders, of hun school of wat dan ook, hen een of andere stage laten kiezen en ze hebben toevallig toevallig jouw bedrijf gekozen)…
• …ze zijn helemaal niet geïnteresseerd in “zakelijke” software ontwikkeling…

…dan zou het aanbieden van het afbreken van de stage niet het ergste zijn dat je zou kunnen doen. Het probleem is niet dat jouw tijd wordt verspild (je had in ieder geval genoeg tijd uitgetrokken om ze te begeleiden, ze maakten het eigenlijk niet erger voor je), het probleem is dat haar tijd wordt verspild.

Of ik moet ze iets in die richting vertellen om ze meer gemotiveerd te maken om daadwerkelijk iets te leren?

Ik zou quip “ieder mens kan leren, maar geen mens kan worden onderwezen”. Ik denk dat je het zeer moeilijk zal vinden om die persoon te motiveren om te leren over het nut van het coderen van conventies, omdat ze al hebben aangetoond dat ze daar geen interesse in hebben. Je kunt degenen die geïnteresseerd zijn in wat je te zeggen hebt, leren; maar als iemand ongeïnteresseerd is, kun je niets doen, echt niet.

Als je die persoon echt wilt helpen om “het licht te zien”, vraag hem dan om mee te proberen te spelen voor zijn eigen bestwil, misschien leren ze later te waarderen wat je te bieden hebt. Stages zijn een uitwisseling van de beperkte diensten die ze kunnen bieden, tegen de achtergrond van de ervaring van het werken op een echte werkplek. Als ze niet geïnteresseerd zijn in het assimileren van de ervaring, dan heeft het echt geen zin. Vermoedelijk is uw bedrijf niet afhankelijk van het hebben van hun “mankracht” voor een of ander echt project.

We hebben er allemaal een hekel aan, maar soms moet je gewoon problemen oplossen met behulp van gezag. Bel de stagiaires op voor een vergadering, en eis te weten waarom de naamgevingsconventies niet werden gevolgd.

Ik heb in onze vorige vergadering de te volgen naamgevingsconventies uitgelegd. Ik kwam een aantal gevallen tegen waarin de naamgevingsconventie niet werd gevolgd. Bijvoorbeeld, convertToMillilitersBecauseIAmUsingSuchCleanCode. Kunt u uitleggen waarom deze naam is gekozen?

Hun “antwoord” is irrelevant, dit zou moeten dienen als een “eerste waarschuwing” dat het tegen de aanwijzingen van hun supervisor in gaan (wat ik veronderstel dat u dat bent) en het maken van grappen ten koste van hem niet acceptabel is in een professionele omgeving. Dat past zelfs goed bij één doel van de stage, namelijk om studenten te laten zien hoe ze in een professionele omgeving moeten werken.

Als ze doorgaan met hun kinderachtige gedrag, dan denk ik dat je tot de conclusie bent gekomen:

Een aantal van de stagiaires zal in de toekomst worden aangenomen in het bedrijf op basis van hun prestaties.

Oh, een hoop screw offs, eh?

Neem wat werkcode en doe iets om het opzettelijk te breken. Laat het dan door een obfuscator lopen die alle klasse, variabele en methode namen verandert in dingen als “a”, “1318798” en “xy23”; of erger nog, variabele namen met veel letter O, letter I, nummer 0, en nummer 1 karakters in hen. Maak het hun opdracht om te documenteren wat de code doet, en repareer het.

Dit zal die grap genezen.

Ik weet dat het waarschijnlijk niet zo erg is, maar het is de eerste keer dat ik de stagiaires help en ik wil graag weten hoe ik goed met zo'n situatie om kan gaan. Toch hebben hun prestaties tijdens de stage invloed op hun kansen om aangenomen te worden en dit soort situaties kunnen later een rol spelen. Of ik moet ze iets in die richting vertellen om ze meer gemotiveerd te maken om daadwerkelijk iets te leren?

Als je zo'n dwaasheid tegenkomt tijdens je code reviews, lach dan, stop de code review, en vertel ze dat ze terug moeten komen als ze de humor hebben verwijderd.

Ik neem aan dat ze niet dom zijn, en ik weet al dat de te lange naam ongepast is, zelfs als ze er een lachertje aan overhouden. Zo niet, leg dan eens uit waarom.

Hopelijk houd je hun prestaties bij en kun je zien hoe vaak dit gebeurt.

Ik zou met elk van hen een hart-tot-hart gesprek hebben, privé, op een openhartige en serieuze maar niet strenge toon, zoiets als dit:

“Intern, ik zag je naam voor de grapjesmethode. Ik begrijp waarom je het deed, maar ik vond het zelf niet zo grappig. Dus het komt bij me op om je te vragen, wat ben je hier aan het doen? Wat zou je willen bereiken?”

Als de stagiaires zeggen dat hij er alleen maar is om te rotzooien, spreek dan met het management om zijn stage te beëindigen. Je verspilt je tijd.

Als hij zegt dat hij er is om te leren, zeg dan zoiets als dit:

“Ik realiseer me dat het moeilijk kan zijn om iets serieus te nemen waarvan je weet dat het niet gebruikt zal worden in de productie. Maar realiseer je dat je niet alleen je tijd neemt, je neemt ook mijn tijd. De stage die je van het bedrijf hebt gekregen is in wezen een soort van interview. Het enige wat ons ervan weerhoudt om een goed doel te zijn, is de hoop om goede kandidaten te vinden. Dus het is mijn tijd waard, maar alleen als je het serieus meent.”

“Als je het niet serieus kan nemen en werkt alsof je een belangrijke productiecode schrijft, hoe kunnen we je dan goed evalueren en beslissen of je een baan krijgt? En zelfs als we je geen baan aanbieden, als je het nog steeds niet serieus neemt, hoe kun je dan deze vaardigheden verwerven en onder de waardevolle leiding van iemand met meer ervaring dan jij oefenen?”

“Als ik jou was, zou ik mijn best doen om het voorbeeld te volgen van de mensen die jou begeleiden, die, enigszins liefdadig, onrendabele tijd uit hun werk halen om in jou te investeren. Bedenk dat je baat hebt bij deze stage, of we je nu aannemen of niet! Ik zou het persoonlijk op prijs stellen als je dit wat serieuzer zou nemen. Doe het voor jezelf! Als je het niet voor jezelf wilt doen, doe het dan uit respect, of gewoon uit dankbaarheid, voor de tijd die ik van mijn normale productieve werk heb weggenomen om in jou en je toekomst te investeren”

Het is waarschijnlijk gepast om wat directer in te gaan op het gedrag zelf, en waarom je er wat van maakt. Je zou zoiets als dit kunnen overwegen:

“Voor wat het waard is, wordt dit soort acties beschouwd als oneerbiedig, of zelfs bespottelijk, in de bedrijfswereld. Ik weet zeker dat je het niet zo bedoeld [ook al geloof je dit niet, zeg het maar], maar volg alsjeblieft gewoon mijn aanwijzingen in de toekomst, zonder dat er snauwerige dingen in de code komen”

Door de “uit” van de stagiair te zeggen “oh, ja, ik bedoelde geen gebrek aan respect” kan hij zijn gezicht redden en de relatie op de meest pijnloze manier herstellen. Het is niet nodig om een bekentenis af te nemen dat hij het oneerbiedig bedoelde of om een grote verontschuldiging af te dwingen. Het gaat hier niet om power-over, maar om een succesvolle stage.

Als het negatieve gedrag na dit alles doorgaat, kun je het meer frontaal aanpakken. Er is geen enkele reden waarom je geen prestatiedoel aan een stagiair kunt geven zoals je dat aan een probleemmedewerker zou doen, of een andere strategie kunt gebruiken die je bij een gewone medewerker zou gebruiken. Maar vergeet niet dat de stagiaires NIET ervaren zijn in de werkomgeving en dat ze een pauze of twee uur moeten krijgen terwijl u ze voorzichtig, maar stevig, gewend bent aan de normen van de professionele werkomgeving.

De stagiaires in kwestie verspillen je tijd en geduld. Uw tijd en geduld zijn duur en beperkt voor het bedrijf en de stagiaires die profiteren van de investering van het bedrijf in hen, een investering die wordt beperkt door de middelen van het bedrijf.

Hun bereidheid om bedrijfsmiddelen onnodig te verspillen is een relevant onderdeel van hun prestatiebeoordeling en kan leiden tot een voortijdige beëindiging van hun stage om bedrijfsmiddelen alleen te besteden aan die stagiairs die daadwerkelijk geïnteresseerd zijn in het leren hoe ze een waardevol, verantwoordelijk en betrouwbaar deel van de werkplek kunnen zijn die kan worden toevertrouwd met zowel taken als instructies.

Ik zou dit aan alle stagiaires vertellen, waarbij ik een voorbeeldcode laat zien, de auteur niet noem, er niet meer dan 2 minuten aan besteed en, als de code vervolgens wordt gerepareerd en soortgelijke incidenten zich niet herhalen, niet meer vermelden.

Als het waarschuwingsschot niet wordt opgevolgd, is de volgende stap een open gesprek met alleen de stagiair in kwestie en mogelijk een overste van u (zorg er wel voor dat hij in uw boot zit). Dan moet je beslissen of je het aan de andere stagiaires verschuldigd bent om degene die hun kansen op een succesvolle stage saboteert, te verwijderen.

Het klinkt alsof er twee belangrijke zaken zijn: 1) Ze zijn oneerbiedig en 2) De naam van de functie is nog steeds waardeloos, ook al is die nu langer.

Hen voor de gek houden zal er waarschijnlijk niet toe leiden dat ze je autoriteit meer respecteren, dus ik zou me op de kwestie concentreren alsof het een andere slecht benoemde functie is. Ik zou niet per se dom spelen en doen alsof ik niet besef dat het een grap is, maar ik zou ze vragen waarom ze de naam hebben gekozen die ze hebben gekozen:

“Het lijkt erop dat er een aantal overbodige woorden in deze functienaam zitten die niet helpen uit te leggen wat de functie doet.”

Op die manier is het een leermogelijkheid voor hen over wat een goede functienaam is en je confronteert ze niet direct met elkaar. Als extra bonus kunnen ze het feit verzwijgen dat ze gewoon aan het rotzooien waren en zich misschien schamen voor het verspillen van ieders tijd.

Als je mensen eraan moet herinneren dat je de leiding hebt, dan ben je dat nooit geweest.

Het zou beter zijn om een code walkthrough uit te voeren waarbij de ontwikkelaar zijn code moet uitleggen aan de gezagsdragers.

1. Dit geeft een persoonlijke verantwoordelijkheid voor het resultaat van het project
2. 2. Biedt onmiddellijke professionele feedback
3. 1. Geef de ontwikkelaar een gevoel van urgentie voor het voltooien van het project

4. Gebruik uw leiderschap als onderdeel van het team om de standaarden van uw organisatie te handhaven. Help vervolgens de jongere medewerkers om aan die normen te voldoen en voorkom verlegenheid om werk te presenteren dat niet aan de normen voldoet.

Vertel de dader (persoonlijk of via e-mail) dat de stage nauwelijks een geschikte plaats is voor dergelijke grappen en dat ze het serieus moeten nemen als ze een carrière willen beginnen.

Vraag hen om de code te repareren, of (als je enige autoriteit wilt tonen) gewoon hun wijzigingen in de versiecontrole terug te draaien.

Het is duidelijk dat je ze moet laten stoppen, maar ze gewoon zeggen dat ze niet moeten laten zien waarom.

Ik weet dat de 80 karakter-per-lijn richtlijn geen harde regel is, maar het is een goede gewoonte om er aan vast te houden, dus het hebben van een 48 karakter variabele naam is behoorlijk dom.

Ik stel voor om ze te vertellen dat ze deze richtlijn vanaf nu moeten proberen te volgen, maar ze ook niet toe te staan om de variabele namen die ze hebben gekozen te veranderen. Een soort van “je hebt je bed opgemaakt, ga er nu in liggen”.

Je kunt proberen een nieuwe oefening in hun hoofd te hameren (ervan uitgaande dat ze de regels niet al kort houden), stagiaires die niet begrijpen waarom lange variabele namen slecht zijn staan op het punt om erachter te komen, en de “slimme” stagiaires zullen al snel ontdekken dat ze niet zo slim zijn als ze dachten.

Het is duidelijk voor meer ervaren programmeurs waarom convertToMillilitersBecauseIAmUsingSuchCleanCode bijzonder slecht is, maar in plaats van hen te vertellen “dat is slecht”, dwingen ze hen om erachter te komen waarom. Ik durf te wedden dat je veel minder verbale namen zult tegenkomen, en met een beetje geluk ook minder toekomstige pogingen om snarky te zijn.

Dit hoeft niet “One Size Fits All” te zijn. All Sizes Fit Some:

Elk van de voorgestelde benaderingen kan goed werken, en kan de beste aanpak zijn, afhankelijk van de omstandigheden. Hier is mijn antwoord op elk van de benaderingen die gevraagd worden over:

Moet ik reageren door

• lachend (“Ja, het is grappig, maar verwijder het alsjeblieft”)

Dit is een geweldig idee wanneer: Je hebt een uitstekende verstandhouding met deze collega’s, die goede vrienden zijn geworden met

• gewoon beleefd vragen om het te verwijderen

Dit is een geweldig idee wanneer: Je wilt direct zijn zodat er geen misverstand ontstaat

• vertellen dat ik het niet leuk vind als iemand mijn tijd verspilt en ze de code review serieuzer moeten nemen

Dit is een geweldig idee wanneer: Je wilt irritatie communiceren, en vasthouden aan een autoritaire aanpak.

(Ik ben geneigd te denken dat je misschien al die benaderingen kunt combineren tot een niet-offensieve, beleefde, grappige manier die wel een beetje irritatie communiceert. “Dit soort dingen moeten stoppen, want het laat me gewoon [mock-scream] ” gaan, misschien is het gewoon een humoristische manier om dat te bereiken.)

Persoonlijk hou ik van de vriendelijke methode. Ik ben een gelovige in die manier van doen. Ik zal echter gemakkelijk toegeven dat er momenten zijn dat dergelijke benaderingen minder effectief zijn.

** Maar wat is het beste? ** Uw basisvraag is: “Hoe moet ik hierop reageren?”

In principe komt deze vraag neer op het zeggen: “Ik moet ergens heen. Moet ik een eenwieler, pogostick, fiets of bus gebruiken?”

Een van die vervoersmethoden kan het beste zijn. Op dezelfde manier, om de vraag te beantwoorden hoe je moet reageren: Je beste reactie is misschien niet mijn beste reactie.

Dit is een belangrijke reden waarom, ook al lijken de verschillende antwoorden overeen te komen dat het gedrag van de stagiaires niet geschikt is voor productieresultaten, de verschillende antwoorden de voorkeur lijken te geven aan verschillende benaderingen. Zoals opgemerkt, hebben we misschien geen enkele “one size fits all” aanpak die universeel het beste werkt voor iedereen.

We hebben hier te maken met mensen, dus wat het beste werkt in sommige scenario’s werkt misschien niet zo goed in andere scenario’s. Een van de belangrijkste factoren is u. Kun je streng zijn zonder brandende bruggen? Kun je bevriend raken met de mensen door lichtvoetig te zijn en toch te zorgen voor voldoende compliance en inspiratie om de gewenste resultaten te behalen? Wat voor mij het beste werkt, werkt misschien gruwelijk slecht voor jou. Uiteindelijk moet je een oordeel vellen over welke van die benaderingen je moet nemen.

Flexibel Onderwijs: Bind je niet vast aan slechts één benadering.

Kies gewoon de methode waarmee je je het meest op je gemak voelt. Zorg ervoor dat je niet overboord gaat (slechte/aanstootgevende humor, of het creëren van een ongemakkelijke bedreigende omgeving in een poging om streng te zijn).

Het maakt niet uit met welke van je uitstekende suggesties je verder gaat, hou de resultaten goed in de gaten.

Het is heel goed mogelijk om een oordeel te vellen dat niet werkt zoals gehoopt. Zolang je geen grote problemen hebt veroorzaakt, kan dit, mits positief en snel afgehandeld, zeer goed te herstellen zijn. Dat is een van de redenen waarom je je niet te veel zorgen moet maken over het nemen van de meest perfecte beslissing. Als het niet goed gaat, kan uw situatie goed uitpakken. Mensen zijn anders, en leren kan onvoorspelbaar zijn, en er hoeft geen schaamte te zijn in een eerste aanpak die moet worden aangepast. Zolang je maar snel herstelt, kan dit een non-issue zijn.

De sleutel is om veranderingen aan te brengen zodra je ongewenste resultaten begint te vinden. Verwacht dat u zich snel aanpast. Als een bepaalde aanpak niet werkt, wees dan klaar om de aanpak snel aan te passen, of zelfs helemaal uit het raam te gooien. Als wat u doet niet werkt, bepaal dan of u op het punt staat om door te breken, of dat u iets anders moet proberen. (Het krijgen van feedback zal helpen bij deze bepaling.) Als je iets anders moet proberen, doe dat dan. Blijf dat doen totdat je werkresultaten krijgt.

Zolang je snel handelt (voordat lange termijn gevoelens zoals bitterheid beginnen aan te slaan), kunnen kleine onvolkomenheden gemakkelijk terzijde worden geschoven als onbeduidend in vergelijking met de positieve resultaten die je in het algemeen bereikt. (Zorg er wel voor dat als de dingen niet perfect gaan, de problemen klein zijn. Grote fouten kunnen iets moeilijker te vergeten zijn. Bijvoorbeeld, poging tot humor kan gevaarlijk zijn.)

Bijvoorbeeld, als je merkt dat ze je beginnen te haten, het milieu vrezen, etc., zorg ervoor dat je elk misverstand uit de weg ruimt. Zorg ervoor dat ze weten dat je aan hun kant staat. Stimuleer gewenst gedrag. etc.

Twee jaar geleden zat ik in een vergelijkbare positie als de stagiaires van uw bedrijf. Ik kan me een scenario voorstellen waarin ik iets dergelijks zou hebben gedaan. Ik denk dat sommige stagiaires een probleem hebben met je autoriteit; pedant en onprofessioneel zijn. Dit is vooral te wijten aan een gebrek aan respect van mijn generatie voor de ouderen en de mensen in een hogere functie. Ik zou de volgende methoden proberen om de situatie op te lossen.

• Respect verdienen voor de stagiaires door de “leider”, “alpha” te slim af te zijn.

• Gebruik de naam van de pedagogische functie als les voor iedereen, optimale functienaam lengte: goldilock’s zone.

• Wijs een fout aan in de functie “convertToMillilitersBecauseIAmUsingSuchCleanCode” en stel een hernoeming voor naar iets gepast(/bedoeld)

• Let niet op, negeer de functienaam; focus je tijd op de personen die willen leren.

Ik zou de namen van de onprofessionele stagiaires als voorzorg noteren.

Moet ik reageren op

• lachen (“Ja, het is grappig, maar verwijder het alsjeblieft”)
• gewoon beleefd vragen om te verwijderen > - zeggen dat ik het niet leuk vind als iemand mijn tijd verspilt en ze de code review serieuzer moeten nemen

Hoe zit het met “ *Opgepast waarom ze dit gedaan hebben? *”

Wanneer iemand iets doet wat je niet verwacht of verlangt, kun je er ofwel op reageren om hem te laten doen wat jij wilt of je kunt proberen te begrijpen waarom hij dat precies gedaan heeft.

Het kan nuttig zijn om te begrijpen waarom. Als ze van nature speels zijn, maar hun frustraties over iets niet kunnen uiten, kan iemand het op deze manier kanaliseren. We kunnen het er allemaal over eens zijn dat dit geen positieve manier is om het te kanaliseren.

Een alternatieve aanpak

Wat is dus een positieve manier om frustratie en speelsheid te kanaliseren? Ik heb bij bedrijven gewerkt waar mensen soms 10% van de tijd projecten deden, zoals het programmeren van een microcontroller om een selfie met een dslr te nemen. Ze kregen niet alleen de vrije hand om dat te doen, maar ze kregen ook de verantwoordelijkheid om dat om te zetten in een verzendbaar product. Het ging van een eendaagse hackathon naar codevoorbeelden die nu op de website van het bedrijf worden gepubliceerd. Mensen kunnen dat voorbeeld nemen en er een afstandsbediening voor diepzeecamera’s van maken die met een druk op de knop kan worden aangezet.

Mijn punt is dat grappen als deze kan indicatie zijn voor onbenutte mogelijkheden. Als je stagiaires wilt die voldoen aan de standaard die je in je bedrijf hebt, is dit potentieel niet voor jou en in dat geval kun je overwegen om ze te laten gaan. Echter, als u de waarde ziet van het opschudden van dingen, laat deze grappenmakers dan iets nuttigs maken met hun grappen. Uiteindelijk is het aan u. **Wie wil je dat deze stagiaires zijn?

Als professional sinds bijna 30 jaar zou ik zeggen dat de hooggewaardeerde antwoorden het meestal goed hebben.

Echter, als professionele softwareontwikkelaar sinds bijna 30 jaar zal ik zeggen dat de coderingsrichtlijnen bijna altijd over-prescriptief zijn. Erger nog, vaak wordt dit aangegrepen door mensen die zich meer bezig houden met hun Authoritah dan met het produceren van leesbare code. Dit soort passief-agressief gedrag van junior ingenieurs is precies wat je normaal gesproken ziet als dat gebeurt.

Het plaatsen van domme dingen in codecommentaren, of zelfs het benoemen van identifiers, is echt een eeuwenoude traditie onder softwareontwikkelaars. Hier is een voorbeeld van door standaarden geinduceerde protest naamgeving van mijn eigen junior dagen (die 48 upvotes kregen).

Als er hier een probleem is, zou het moeten zijn dat er legitieme leesbaarheids-/onderhoudsproblemen zijn met hun broncode in jouw omgeving. Ik zeg niet dat de top antwoorden hier verkeerd zijn. Dat zijn ze niet. Maar als je dit soort gedrag van meerdere junior engineers ziet, dan zou je na het opschonen van de body’s echt moeten kijken of ** er een onderliggende reden is dat je kanaries blijven sterven**.

Het einddoel moet de kwaliteit van de code zijn. De coderingsrichtlijnen moeten gewoon deze tool zijn om ze te helpen er te komen, gebouwd door ontwikkelaars voor ontwikkelaars, niet een of ander autoritair programma voor het schrijven van programma’s.

Het klinkt alsof je een heel goed voorbeeld hebt om hen te laten zien waarom het gebruik van dit soort coderingsconventies ongepast is, zelfs voor kleine projecten als deze.

Je hebt het gezien.

Zelfs als hun project niet direct door het bedrijf wordt gebruikt, is het bedoeld als een beoordeling van hun vaardigheid en, gedeeltelijk, als een leerervaring voor deze stagiaires die op zoek zijn naar hun weg naar uw bedrijf.

Ik zou niet te hard voor ze zijn - dit is tenslotte is slechts een beproeving voor ze - maar ik wil er zeker op wijzen dat dergelijke coderingspraktijken ze in de toekomst in de problemen kunnen brengen, vooral als hun volgende baas niet zo geduldig met ze is als u.

Ten eerste, ik denk niet dat dit dat slecht is. Ze zetten een grapje in de code over een onderwerp (naamconventies) dat ze waarschijnlijk niet helemaal begrijpen. Het plaatsen van wat interne grappen in de code is niet iets nieuws. Ook kunnen ze de code beschouwen als een “intern blad”.

Ik ben het ook niet eens met de opvatting dat ze je tijd hiermee verspillen. Als ze een toezegging doen om alleen maar een methode te hernoemen, dan ja, dan verspillen ze je tijd, en de wijziging moet worden afgewezen. Maar als ze een nieuwe methode nodig hadden en een slechte naam kozen, dan zou de tijd om te herzien vergelijkbaar zijn met beide namen. Ik weet niet of je pre-commit of post-commit bekijkt, maar als iemand de code wil laten goedkeuren of samenvoegen, dan werkt dat eigenlijk tegen zichzelf, omdat ze gewoon rondvluchten toevoegen om de code daadwerkelijk geaccepteerd te krijgen.

Het is ook triviaal voor je om negatief te beoordelen met verkeerde namen, zonder daadwerkelijk te kijken naar wat de code doet. Het probleem is dat je je ergert aan die namen.

Nu, naaiend aan de eigenlijke vraag over wat te doen, raad ik aan om op te merken dat ze wat problemen hadden met naamconventies en hen te vragen om het werk van vorige week te herzien om te zien of ze de juiste namen hebben gebruikt en te denken of ze het gemakkelijk zouden begrijpen in een paar jaar / als ze nieuw kwamen voor dat project. Laat ze een kort verslag opstellen over de functies die ze in die week hebben toegevoegd en het binnenkort rechtvaardigen.

Idealiter zou dat ongeveer een regel per functie zijn, bijv.

convertGalToml: Converteert Gallons naar Milliliters. Kameel geval werd niet gebruikt op milliliters afkorting om niet verward te worden met megaliters.

Het is te verwachten dat ze tijdens het bekijken van de code nieuwe problemen opmerken of een betere naam bedenken, bijv. hernoemen convertGalToml naar convertGal2ml.

Ik vermoed dat je grappenmaker het punt krijgt en het stilletjes hernoemen.

Het punt is, functienamen zijn documentatie. Hoewel het een meer technisch publiek is dan bv. de handleiding, moeten ze zich comfortabel voelen om hun keuze te rechtvaardigen ten overstaan van hun collega’s.

Ik ga er van uit dat de stagiaires te goeder trouw zijn, maar mijn gevoel zegt me dat ze dit hebben gedaan omdat ze geen enkel probleem zien met namen als convert. Ik durf te wedden dat de sarcastische namen niet voortkomen uit een verlangen om opstandig te zijn, maar uit frustratie dat ze niet weten hoe ze met een betere naam moeten komen, alleen een langer naam. En dat soort sorta is wat je ze verteld hebt, toch? Kort slecht, lang goed.

Als je wilt dat deze mensen beter worden, moet je in de dagelijkse vergadering gewoon bespreken waarom** convert een slechte naam is en convertInchesToCentimeters een betere naam. Als je een voorbeeld hebt uit je ervaring van een slechte naamkeuze die problemen veroorzaakt, zal dat hen helpen. Dat “waarom” zal hen in staat stellen om vanaf nu goede namen te kiezen - of die goede namen nu lang of kort zijn.

Laat hen ook weten dat het OK is om jou of hun collega’s om hulp te vragen of met hen te overleggen binnen de rede, dat dit geen test is waarbij iedereen alleen moet werken, dit is een samenwerking. (Ik hoop dat dit waar is!) Misschien dat dit hen in staat stelt om vragen te stellen en met elkaar te praten, en frustraties vroeg op te lossen, in plaats van te wachten tot passief-agressieve dingen als deze in de code review verschijnen.

Alleen als dergelijk gedrag doorgaat zou ik het nodig vinden om uit te leggen, ja dit is geen echte toepassing, maar deze oefening en de stijlrichtlijnen moeten om meerdere redenen serieus genomen worden:

• Het is de moeite waard om mijn tijd met jou te besteden aan deze inspanning, wanneer ik zou kunnen werken aan “echte” applicaties, dus doe ook je best
• Deze oefening bereidt je voor op het werken aan een echt project dat serieus is en waarin je de stijlrichtlijnen moet volgen - Deze oefening stelt ons in staat om te beslissen wie van jullie, indien van toepassing, om aanbiedingen van werk uit te breiden naar nadat je stage is afgerond

Hoewel niet precies verkeerd, denk ik dat het beschuldigen van oneerbiedigheid, enz. op dit punt zal het gedrag waarschijnlijk het zwijgen opleggen, maar zal hen ook niet helpen begrijpen waarom ze betere namen nodig hebben of hoe ze met betere namen kunnen komen. Als je deze weg inslaat, kan het zijn dat ze gewoon met langere slechte namen komen en je stalen blik vermijden.

Je bent hun manager niet, het maakt zelfs niet uit of je ze interviewt of niet. Je bent een ingenieur zoals ik,

Dus je weet wat je moet doen, Praat met je manager en stel dan een code-review voor. Adviseer hen dan om niet zo'n code te schrijven via een systeem als code medewerker. Je hoeft ze niet eens te e-mailen of met ze te communiceren of deze dingen persoonlijk te nemen. Introduceer een beoordelingssysteem op basis van die code-review. Probeer ze niet te controleren of hun manager te zijn, en probeer ook niet people management. Dat is niet uw zaak.

Praat met uw manager en houd dat privilege om te weigeren of goed te keuren verbindt zich na een beoordeling aan uzelf. Stel dat elke stagiair een eerste 10 punten heeft, en hij/zij zou 100 punten moeten verdienen door je beoordeling, en als ze echt bij je team willen komen, zullen ze gemotiveerd zijn om het te scoren. Niet om punten te verliezen.

Als ik een stagiair was en ik werk onder jou en jij gewoon een senior ingenieur, dan haat zelfs ik het als je mijn people management doet. Het is NIET jouw werk.

Het klinkt me alsof je te ver bent gegaan en het is uit de hand gelopen. Leer die les als ingenieur. Je bent een ingenieur, niet hun manager om mensen te leiden.

Hoewel het gedrag van de stagiairs onprofessioneel kan zijn, is het ook onprofessioneel voor het management om niet te overwegen dat ze misschien verkeerd zijn. Het is duidelijk dat convert in veel contexten te kort komt, maar convertGallonsToMilliliters is weg te lang voor een identificatienaam. In plaats van het opleggen van willekeurige naamsvereisten over de hele linie, zou je je stagiaires moeten uitdagen om te rechtvaardigen wanneer een naam die ze kiezen echt dubbelzinnig is (wat ze niet kunnen) en met iets redelijks komen dat de leesbaarheid van het programma verbetert in plaats van het te belemmeren.

Dit voelt voor mij echt als een geval van het gemeenschappelijke patroon van “waarom hebben mijn ondergeschikten geen respect voor mij?” echt een kwestie van “hoe zit het met mijn eigen houding is het maken van het zo dat mensen mijn positie niet respecteren?