Come gestire il comportamento poco professionale degli stagisti?

Non credo che ridere sia l'approccio giusto. Devono imparare che non sono più a scuola. Detto questo, non credo che si debba andare troppo oltre.

Vi consiglio di essere fermi con lui/lei e di dire qualcosa del tipo:

Il motivo per cui siamo andati oltre le convenzioni sui nomi è perché sono molto importanti. Questo codice deve poter essere mantenuto in futuro. Molte persone qui intorno hanno lavorato sodo per arrivare dove sono, e potrebbero non apprezzare questo tipo di scherzi. Vi preghiamo di astenervi dall'usare questo tipo di nomi in futuro, perché potrebbe indurre le persone a mettere in dubbio la vostra professionalità.

Prima di tutto, questo sembra uno scherzo che è stato messo in codice che sono ben consapevoli che non sarà mai più usato per niente o letto. Penso che lei stia leggendo troppo in questo incidente. La cosa importante è che lei ha parlato loro della convenzione di denominazione e loro non l'hanno ignorata, hanno usato nomi più lunghi e descrittivi (anche se sarcasticamente).

Dopo aver visto questo video Io posso vedere che i lavoratori desiderano 3 cose:

1. 1. Autonomia
2. 2. Padronanza
3. Scopo

Ciò che chiedete loro di fare non è autonomo, è probabilmente di banale difficoltà per alcuni di loro, e non serve a nulla ai loro occhi.

Fissare l'incarico, e i lavoratori seguiranno.

Qualche esempio:

1. Ecco questo progetto, lavorate insieme e fatelo fare da ________, fatemi sapere se vi bloccate.

2. So che non sembra importante, ma per valutare le vostre capacità e assegnarvi un lavoro che pensiamo vi aiuterà a crescere abbiamo bisogno di voi per portare a termine questo compito.

TL;DR : Obietto il nome del metodo perché (secondo me!) esprime disprezzo per il capo e/o per le “regole” (qui: linee guida di stile). Sul posto di lavoro mi aspetto che la gente si attenga alla regola “amarlo, cambiarlo o lasciarlo”. In questo caso, lo stagista, che sembra essere dell'opinione che la linea guida non sia necessaria, dovrebbe o accettarla comunque; o continuare la discussione su di essa; o smettere di fare quello che fa. Non mettere l'equivalente di qualche sbavatura sul water. Non avrei avuto alcuna obiezione contro un nome di metodo veramente divertente e creativo. Se voi (l'OP) trovate il nome del metodo divertente e non “cattivo” come lo trovo io, allora ignorate questa risposta per favore.

Come sfondo, ho supervisionato alcuni stagisti altamente intelligenti e (auto)motivati in passato, e non mi sono mai chiesto se si sarebbero comportati in modo professionale o meno. Portare la stupidità a livello scolastico in un posto di lavoro come stagista è così lontano dall'essere accettabile, che suggerirei di non scherzare. Per i vostri e soprattutto per il loro bene.

Vorrei sapere come gestire correttamente questa situazione.

Innanzitutto, dimenticate le convenzioni di codifica. Il problema non è legato ai computer o alla programmazione.

• Non mentire. Non fare battute, non ridere, perché non è davvero una cosa da ridere.

• Non andare sul personale. Non si tratta di te, né del tuo rapporto con l'OP, né del tuo rapporto con loro. Si tratta puramente e strettamente del loro comportamento.

• Spiegare le cose così come sono. Puoi assolutamente dire al trasgressore che capisci come ha avuto l'idea di fare quello che ha fatto, e che non sei personalmente arrabbiato con lui o altro (tieni fuori le emozioni), ma che stai vedendo il tirocinio come una proiezione di chi prendere in considerazione in seguito.

Se vuoi trasmettere qualsiasi emozione a riguardo, stai lontano dalla rabbia. Potete mostrare una leggera tristezza (e francamente, sarebbe esattamente quello che proverei io) e mostrare loro che siete rimasti abbastanza delusi.

Tuttavia, la loro performance durante lo stage influenzerà le loro possibilità di essere assunti e situazioni come questa possono avere un ruolo in seguito.

Assolutamente! Non siate frivoli sul fatto che “possono avere un ruolo più tardi”. Comportamenti come questo possono, dovrebbero e faranno sì che la loro possibilità di ricevere un'offerta dopo lo stage sia pari a zero. Potete dire che, in qualsiasi modo vi rivolgiate normalmente a loro, in modo chiaro e chiaro.

Cercate di trovare la causa alla radice. Se scoprite che…

• …sono qui contro il loro libero arbitrio (forse i loro genitori, o la loro scuola o qualsiasi altra cosa, li hanno costretti a scegliere un tirocinio e hanno scelto la vostra azienda)…
• …non sono affatto interessati allo sviluppo di software in stile “business”…

…allora offrire di interrompere il tirocinio non sarebbe il peggio che potreste fare. Il problema non è che il vostro tempo è sprecato (in ogni caso avevate assegnato molto del vostro tempo per supervisionarli, in realtà non vi hanno peggiorato la situazione), il problema è che il loro tempo è sprecato.

O dovrei dire loro qualcosa in questo modo per renderli più motivati ad imparare davvero qualcosa?

Io direi “ogni umano può imparare, ma non si può insegnare a nessun umano”. Penso che troverete molto difficile motivare quella persona ad imparare l'utilità delle convenzioni di codifica, poiché ha già dimostrato di non avere alcun interesse in esse. Puoi insegnare a coloro che sono interessati a ciò che hai da dire; ma se qualcuno è disinteressato, non c'è nulla che tu possa fare, davvero.

Se vuoi davvero aiutare quella persona a “vedere la luce”, allora chiedi loro di provare a stare al gioco per il loro bene, forse impareranno ad apprezzare ciò che puoi offrire, in seguito. I tirocini sono uno scambio di servizi limitati che possono offrire, contro l'esperienza di lavorare in un posto di lavoro vero e proprio. Se non sono interessati ad assimilare l'esperienza, allora è davvero inutile. Presumibilmente, la vostra azienda non dipende dal fatto di avere il loro “potere dell'uomo” per qualche progetto reale.

Tutti odiamo farlo, ma a volte bisogna risolvere i problemi con l'autorità. Chiamare gli stagisti a un incontro e chiedere di sapere perché le convenzioni di denominazione non sono state seguite.

Ho spiegato le convenzioni di denominazione da seguire nel nostro precedente incontro. Mi sono imbattuto in una serie di casi in cui la convenzione di denominazione non è stata seguita. Ad esempio, convertToMillilitersBecauseIAmUsingSuchCleanCode. Potrebbe spiegare perché è stato scelto questo nome?

La loro “risposta” è irrilevante, questo dovrebbe servire come “primo avvertimento” che andare contro le indicazioni del loro supervisore (che presumo lei sia) e fare battute a sue spese non è accettabile in un ambiente professionale. Questo si adatta bene anche ad uno degli obiettivi del tirocinio, che è quello di mostrare agli studenti come lavorare in un ambiente professionale.

Se continuano con il loro comportamento infantile, allora bene, penso che siate arrivati alla conclusione di questo:

Alcuni degli stagisti saranno assunti in futuro in azienda in base alle loro prestazioni.

Oh, un bel po’ di vite, eh?

Prendete un po’ di codice di lavoro e fate qualcosa per romperlo deliberatamente. Poi passatelo attraverso un offuscatore che cambia tutti i nomi di classe, di variabili e di metodi in cose come “a___1318798_” e “xy23_7a963”; o peggio, nomi di variabili con molti caratteri di lettera O, lettera I, numero 0 e numero 1. Fanno in modo che il loro compito sia quello di documentare ciò che il codice sta facendo, e di correggerlo.

Questo risolverà il problema dello scherzo.

So che probabilmente non è un grosso problema, ma è la prima volta che aiuto gli stagisti e vorrei sapere come gestire correttamente questa situazione. Tuttavia, le loro prestazioni durante lo stage influenzeranno le loro possibilità di essere assunti e situazioni come questa possono avere un ruolo in seguito. O dovrei dire loro qualcosa di simile per renderli più motivati ad imparare davvero qualcosa?

Quando incontri una tale stupidità durante le tue revisioni del codice, ridi, interrompi la revisione del codice e dì loro di tornare una volta che hanno tolto l'umorismo.

Presumo che non siano stupidi, e che sappiano già che il nome troppo lungo è inappropriato, anche se ne prendono un po’ in giro. In caso contrario, spiegatene il motivo una volta sola.

Speriamo che stiate tenendo traccia delle loro prestazioni e che possiate notare quanto spesso ciò accada.

Avrei un cuore a cuore con ognuno di loro, in privato, in tono franco e serio ma non severo, qualcosa del genere:

“Stagista, ho visto il nome del tuo metodo scherzoso. Capisco perché l'hai fatto, ma io stesso non pensavo fosse così divertente. Quindi mi viene in mente di chiederti: cosa sei venuto a fare? Cosa vorresti realizzare?”

Se lo stagista dice che è lì solo per scopare, allora parla con la direzione per terminare il suo tirocinio. Stai sprecando il tuo tempo.

Se dice che è lì per imparare, allora di’ qualcosa del genere:

“Mi rendo conto che può essere difficile prendere sul serio qualcosa che sai che non verrà usato in produzione. Ma si renda conto che non si sta solo prendendo il suo tempo, ma anche il mio. Il tirocinio che ti è stato offerto dall'azienda è, in sostanza, una sorta di colloquio. L'unica cosa che impedisce che sia una vera e propria beneficenza da parte nostra è la speranza di trovare dei buoni candidati. Quindi vale il mio tempo, ma solo se fai sul serio”

“Se non riesci a prenderlo sul serio e a lavorare come se stessi scrivendo un importante codice di produzione, come possiamo valutarti adeguatamente e decidere se offrirti un lavoro? E anche se non ti offriamo un lavoro, se non lo prendi ancora sul serio, in che altro modo acquisirai queste capacità e sarai in grado di esercitarti sotto la preziosa guida di qualcuno con più esperienza di te?”

“Se fossi in te, farei del mio meglio per seguire la guida delle persone che ti guidano, che, in qualche modo caritatevolmente, stanno sottraendo tempo non redditizio al loro lavoro per investire su di te. Considera che trarrai beneficio da questo tirocinio sia che ti assumiamo o meno! Personalmente apprezzerei se prendessi la cosa un po’ più seriamente. Fallo per te stesso! Se non vuoi farlo per te stesso, fallo per rispetto, o solo per gratitudine, per il tempo che ho sottratto al mio normale lavoro produttivo per investire su di te e sul tuo futuro”

Probabilmente è opportuno affrontare in qualche modo direttamente il comportamento in sé, e il motivo per cui ne stai facendo un po’ un problema. Si potrebbe prendere in considerazione una cosa del genere:

“Per quel che vale, questo tipo di azione è considerato una mancanza di rispetto, o addirittura una presa in giro, nel mondo aziendale. Sono sicuro che non intendevi dire questo [anche se non ci credi, dillo], ma ti prego di seguire le mie indicazioni per il futuro senza mettere cose irrispettose nel codice”.

Dare il “fuori” dello stagista dicendo “oh, sì, non intendevo mancare di rispetto” gli permette di salvare la faccia e di riparare il rapporto nel modo più indolore possibile. Non c'è bisogno di tirar fuori una confessione che ha voluto dire in modo irrispettoso o per ottenere delle scuse enormi. Il punto qui non è il power-over, ma il successo dello stage.

Se dopo tutto questo, il comportamento negativo continua, si può affrontare più a testa alta. Non c'è motivo per cui non si possa dare un obiettivo di rendimento a un tirocinante proprio come si farebbe con un dipendente problematico, o usare qualsiasi altra strategia che si adotterebbe con un dipendente regolare. Ma ricordate che gli stagisti NON hanno esperienza nel mondo del lavoro e dovrebbero avere una o due pause mentre voi li abituate con delicatezza, ma con fermezza, agli standard del mondo del lavoro professionale.

Gli stagisti in questione stanno sprecando il vostro tempo e la vostra pazienza. Il vostro tempo e la vostra pazienza sono risorse costose e limitate per l'azienda e gli stagisti che traggono profitto dall'investimento dell'azienda in loro, un investimento che è vincolato dalle risorse dell'azienda.

La loro disponibilità a sprecare inutilmente le risorse dell'azienda è una parte rilevante della loro valutazione delle prestazioni e può portare ad una conclusione prematura del loro tirocinio al fine di spendere le risorse aziendali solo per quegli stagisti effettivamente interessati ad imparare ad essere una parte preziosa, responsabile e affidabile del posto di lavoro a cui possono essere affidati sia compiti che istruzioni.

Lo direi a tutti gli stagisti, mostrando qualche codice di esempio, non menzionarne l'autore, non spendere più di 2 minuti su di esso e, se il codice viene successivamente corretto e incidenti simili non si ripetono, non menzionarlo più.

Se il colpo di avvertimento non viene ascoltato, il passo successivo è un colloquio a porte aperte con il solo stagista in questione ed eventualmente un vostro superiore (assicuratevi però che sia nella vostra barca). Poi bisogna decidere se è tuo dovere nei confronti degli altri stagisti rimuovere quello che sta sabotando le loro possibilità di successo dello stage.

Sembra che ci siano due questioni principali: 1) Sono irriverenti e 2) Il nome della funzione fa ancora schifo anche se ora è più lungo.

Riprimandarli per scherzo probabilmente non li farà rispettare di più la vostra autorità, quindi mi concentrerei sulla questione come se fosse una qualsiasi altra funzione mal nominata. Non farei necessariamente il finto tonto e farei finta di non capire che si tratta di uno scherzo, ma li interrogherei sul perché hanno scelto il nome che hanno fatto:

“Sembra che ci siano alcune parole superflue in questo nome di funzione che non aiutano a spiegare cosa fa la funzione”.

In questo modo, è un'opportunità di apprendimento per loro su cosa fa un buon nome di funzione e non li stai affrontando direttamente. Come bonus aggiuntivo, potrebbero confessare il fatto che stavano solo scherzando e potrebbero provare un po’ di vergogna per aver fatto perdere tempo a tutti.

Se dovete ricordare alle persone che siete voi a comandare, allora non lo siete mai stati.

Sarebbe meglio condurre un walkthrough del codice in cui lo sviluppatore deve spiegare il proprio codice a chi ha l'autorità.

1. Questo infonde responsabilità personale per l'esito del progetto. 2. Fornisce un feedback professionale immediato
2. 1. Dare allo sviluppatore un senso di urgenza per il completamento del progetto

3. Utilizzare la vostra leadership come parte del team per sostenere gli standard della vostra organizzazione. Poi, aiutate i dipendenti più giovani a soddisfare tali standard ed evitate l'imbarazzo di presentare un lavoro al di sotto degli standard.

Basta dire al trasgressore (personalmente o via e-mail) che il tirocinio non è proprio il luogo adatto per queste battute e che deve prenderlo sul serio se vuole iniziare una carriera.

Chiedetegli di aggiustare il codice, o (se volete mostrare un po’ di autorità) semplicemente rollback le loro modifiche nel controllo di versione.

Ovviamente, bisogna farli smettere, ma semplicemente dire loro di smettere potrebbe non dimostrarne il motivo.

So che la linea guida di 80 caratteri per linea non è una regola difficile e veloce, in ogni caso, ma cercare di rispettarla è una buona pratica, quindi avere un nome di variabile di 48 caratteri è piuttosto stupido.

Suggerirei di dire loro di provare a seguire questa linea guida d'ora in poi, ma anche di non permettere loro di cambiare i nomi delle variabili che hanno scelto. Una specie di “hai fatto il tuo letto, ora giacicici dentro”.

Proveranno a piantare una nuova pratica nella loro testa (supponendo che non stiano già tenendo le righe corte), gli stagisti che non capiscono perché i nomi di variabili lunghe sono cattivi stanno per scoprirlo, e gli stagisti “intelligenti” scopriranno presto di non essere così intelligenti come pensavano.

È ovvio per i codificatori più esperti il motivo per cui convertToMillilitersBecauseIAmUsingSuchCleanCode è particolarmente brutto, ma piuttosto che dire loro “è brutto”, li costringe a scoprire il perché. Scommetto che incontrerete molti meno nomi verbosi e, con un po’ di fortuna, anche meno tentativi futuri di essere sarcastici.

Questo non deve essere necessariamente “Una taglia va bene per tutti”. ** Tutte le taglie vanno bene per alcuni:**

Ciascuno degli approcci proposti può funzionare alla grande, e può essere il migliore a seconda delle circostanze. Ecco la mia risposta a ciascuno degli approcci proposti:

Dovrei reagire con

• ridendo (“Sì, è divertente ma per favore rimuovilo”)

Questa è una grande idea quando: Hai un ottimo rapporto con questi colleghi, che sono diventati buoni amici di

• solo chiedendo gentilmente di rimuoverlo

Questa è un'ottima idea quando: Vuoi essere diretto, così non ci saranno fraintendimenti

• dicendo che non mi piace quando qualcuno mi fa perdere tempo e che dovrebbe prendere la revisione del codice più seriamente

Questa è una grande idea quando: Volete comunicare il vostro fastidio, e attenervi ad un approccio autoritario.

(sono incline a pensare che potreste essere in grado di combinare tutti questi approcci in un modo non offensivo, educato, divertente che comunichi un po’ di vero fastidio. “Questo genere di cose deve finire, perché mi fa solo andare [mock-scream] ” potrebbe essere un modo umoristico per farlo.)

Personalmente, mi piace il metodo amichevole. Sono un credente in questo modo di fare le cose. Tuttavia, ammetterò prontamente che ci sono momenti in cui tali approcci sono meno efficaci.

** Ma cos'è meglio? ** La tua domanda di base è: “Come dovrei reagire a questo?”

Fondamentalmente, quello che si riduce a questa domanda è come dire: “Devo andare da qualche parte. Dovrei usare un monociclo, un pogostick, una bicicletta o un autobus?”

Uno qualsiasi di questi approcci di trasporto può essere il migliore. Allo stesso modo, per rispondere alla domanda su come dovreste reagire: la vostra migliore reazione potrebbe non essere la mia migliore reazione.

Questo è un motivo fondamentale per cui, anche se le diverse risposte sembrano concordare sul fatto che il comportamento degli stagisti non è adatto ai risultati della produzione, le diverse risposte sembrano favorire approcci diversi. Come notato, potremmo non avere un unico approccio “one size fits all” che universalmente funziona meglio per tutti.

Abbiamo a che fare con le persone qui, quindi ciò che funziona meglio in alcuni scenari potrebbe non funzionare altrettanto bene in altri scenari. Uno dei fattori chiave siete voi. Si può essere severi senza bruciare i ponti? Potete fare amicizia con loro essendo spensierati, ma garantendo al tempo stesso la conformità e l'ispirazione necessarie per ottenere i risultati desiderati? Ciò che funziona meglio per me potrebbe funzionare in modo atrocemente terribile per voi. In ultima analisi, devi decidere quale di questi approcci adottare.

** Insegnamento flessibile:** Non impegnarti in un solo approccio.

Scegli il metodo con cui ti senti più a tuo agio. Assicuratevi di non esagerare (umorismo cattivo/offensivo, o creare un ambiente minaccioso nel tentativo di essere severi).

Indipendentemente da quali dei vostri eccellenti suggerimenti decidete di procedere, tenete d'occhio i risultati.

È molto probabile che possiate esprimere un giudizio che non funzioni come sperato. Finché non avete causato grossi problemi, questo può essere molto recuperabile, se gestito in modo positivo e rapido. Questo è uno dei motivi per cui non dovreste preoccuparvi troppo di cercare di prendere la decisione più perfetta. Se le cose non vanno bene, la vostra situazione può funzionare bene. Le persone sono diverse, e l'apprendimento può essere imprevedibile, e non c'è bisogno di vergognarsi di un primo approccio che necessita di modifiche. Finché ci si riprende in fretta, questo può non essere un problema.

La chiave è apportare modifiche non appena si cominciano a trovare risultati indesiderati. Aspettatevi di aver bisogno di adattare rapidamente. Quando un approccio non funziona, siate pronti a modificare rapidamente l'approccio, o addirittura a gettarlo completamente fuori dalla finestra. Se quello che state facendo non funziona, determinate se è probabile che siate sull'orlo di una rottura, o se dovete provare qualcosa di diverso. Se avete bisogno di provare qualcosa di diverso, allora fatelo. Continuate a farlo fino a quando non otterrete risultati di lavoro.

Finché agite rapidamente (prima che i sentimenti a lungo termine come l'amarezza comincino a prendere piede), le piccole imperfezioni possono essere facilmente messe da parte come insignificanti rispetto ai risultati positivi che ottenete nel complesso. (Assicuratevi solo che se le cose vanno in modo imperfetto, i problemi sono minori. Le imperfezioni maggiori possono essere un po’ più difficili da dimenticare. Per esempio, un tentativo di umorismo può essere pericoloso)

Per esempio, se vi accorgerete che cominciano ad odiarvi, a temere l'ambiente, etc., assicuratevi di chiarire qualsiasi malinteso. Assicurati di essere dalla loro parte. Incoraggiate il comportamento desiderato, ecc.

Due anni fa ero in una posizione simile a quella degli stagisti della vostra azienda. Posso immaginare uno scenario in cui avrei fatto qualcosa di simile. Credo che alcuni stagisti abbiano un problema con la sua autorità: essere pedanti e non professionali. Questo è dovuto principalmente alla mancanza di rispetto che la mia generazione ha nei confronti degli anziani e di coloro che occupano posizioni più elevate. Proverei i seguenti metodi per risolvere la situazione.

• Guadagnarsi il rispetto degli stagisti superando il “leader”, “alfa”.

• Usare il nome della funzione pedante come lezione per tutti, lunghezza ottimale del nome della funzione: zona goldilock.

• Segnalate un difetto nella funzione “convertToMillilitersBecauseIAmUsingSuchCleanCode” e suggerite una rinomina a qualcosa di appropriato(/demeaning)

• Non fate caso, ignorate il nome della funzione; focalizzate il vostro tempo sulle persone che vogliono imparare.

Prendo nota dei nomi degli stagisti non professionisti per precauzione.

Dovrei reagire con

• ridendo (“Sì, è divertente ma per favore rimuovetelo”)
• chiedendo gentilmente di rimuovere
• dicendo che non mi piace quando qualcuno mi fa perdere tempo e che dovrebbe prendere più seriamente la revisione del codice

Che ne dite di “ *Capire perché l'hanno fatto? *”

Ogni volta che qualcuno fa qualcosa che non ti aspetti o che non desideri, puoi reagire per fargli fare la cosa che vuoi o puoi cercare di capire perché l'ha fatto.

Potrebbe essere utile capire il perché. Se sono giocherelloni per natura, ma non riescono ad esprimere la loro frustrazione per qualcosa, è così che qualcuno può incanalarla. Possiamo essere tutti d'accordo che questo non è un modo positivo di incanalarla.

Un approccio alternativo

Allora, cosa è un modo positivo per incanalare la frustrazione e la giocosità? Ho lavorato in aziende dove a volte le persone hanno fatto progetti per il 10% del tempo, come programmare un microcontrollore per prendere un selfie con un dslr. Non solo hanno avuto la libertà di farlo, ma è stata data loro la responsabilità di trasformarlo in un prodotto che può essere spedito. Si è passati da un hackathon di un giorno a esempi di codice che ora sono pubblicati sul sito web dell'azienda. La gente può prendere quell'esempio e trasformarlo in un telecomando per telecamere d'alto mare che può essere attivato con un semplice clic.

Il mio punto di vista è che scherzi come questo può essere indice di un potenziale non sfruttato. Se volete degli stagisti che siano conformi allo standard che avete nella vostra azienda, questo potenziale non fa per voi e in tal caso, considerate la possibilità di lasciarli andare. Tuttavia, se vedete il valore di scuotere le cose, fate in modo che questi burloni creino qualcosa di utile con i loro scherzi. In definitiva, dipende da voi. **Chi volete che siano questi stagisti?

Come professionista da quasi 30 anni, direi che le risposte ad alta valutazione hanno per lo più ragione.

Tuttavia, come professionista sviluppatore di software da quasi 30 anni, dirò che le linee guida di codifica sono quasi sempre sopraprescrittive. Ancora peggio, spesso questo viene colto da persone più interessate al loro Authoritah che alla produzione di codice leggibile. Questo tipo di comportamento passivo-aggressivo da parte dei giovani ingegneri è esattamente quello che si vede di solito quando ciò accade.

Mettere cose stupide nei commenti sul codice, o anche nella denominazione degli identificatori, è davvero una tradizione antica tra gli sviluppatori di software. Ecco un esempio di denominazione di protesta indotta dagli standard da my junior days (che ha ottenuto 48 upvotes).

Se c'è un problema qui, dovrebbe essere che ci sono problemi di leggibilità/mantenibilità legittimi con il loro codice sorgente nel vostro ambiente. Non sto dicendo che le risposte in alto qui sono sbagliate. Non lo sono. Ma quando si vede questo tipo di comportamento da parte di più ingegneri junior, allora dopo aver ripulito i corpi si dovrebbe davvero indagare se ci potrebbe essere una ragione di fondo per cui i vostri canarini continuano a morire.

L'obiettivo finale deve essere la qualità del codice. Le linee guida per la codifica dovrebbero essere solo il loro strumento per aiutarli ad arrivarci, costruito dagli sviluppatori per gli sviluppatori, non un qualche tipo di programma autoritario per scrivere programmi.

Sembra che abbiate un ottimo esempio per mostrare loro perché l'utilizzo di questo tipo di convenzione di codifica è inappropriato, anche per piccoli progetti come questo.

**Lo avete visto.

Anche se il loro progetto non viene utilizzato direttamente dall'azienda, è inteso come una valutazione delle loro competenze e, in parte, come un'esperienza di apprendimento per questi stagisti che cercano di farsi strada nella vostra azienda. Non sarei troppo duro con loro - dopo tutto, questa è solo una prova per loro - ma vorrei sicuramente sottolineare che, in futuro, tali pratiche di codifica potrebbero metterli nei guai, soprattutto se il loro prossimo capo non è paziente con loro come lo sei tu.

Prima di tutto, non credo che questo sia questo male. Hanno messo una battuta nel codice su un argomento (le convenzioni dei nomi) che probabilmente non afferrano completamente. Mettere qualche battuta interna nel codice non è una novità. Inoltre, possono considerare il codice un “foglio interno”.

Non sono d'accordo con l'idea che stiano sprecando il vostro tempo con questo. Se si impegnano solo a rinominare un metodo, allora sì, stanno sprecando il vostro tempo, e la modifica dovrebbe essere respinta. Ma se avessero bisogno di un nuovo metodo e scegliessero un nome scadente, il tempo da rivedere sarebbe simile con entrambi i nomi. Non so se si sta rivedendo il pre-commit o il post-commit, ma quando qualcuno vuole che il codice venga approvato/membrato, quello che sta facendo è in realtà lavorare contro se stesso, in quanto sta semplicemente aggiungendo dei roundtrips per far accettare il codice.

È anche banale per voi votare negativamente con nomi sbagliati, senza guardare cosa fa il codice. Il problema è che vi sentite infastiditi da quei nomi.

Ora, inchiodando alla domanda reale su cosa fare, vi consiglio di far notare che hanno avuto qualche problema con le convenzioni sui nomi e di chiedere loro di rivedere il lavoro della scorsa settimana per vedere se hanno usato nomi propri e pensare se lo capirebbero facilmente in pochi anni / se sono arrivati nuovi a quel progetto. Fagli preparare un breve rapporto sulle funzioni che hanno aggiunto in quella settimana e giustificarlo in breve tempo.

Idealmente, si tratterebbe di una linea per funzione, ad es.

convertGalToml: Converte Galloni in Millilitri. Il caso del cammello non è stato usato sull'abbreviazione millilitri per evitare di essere confuso con i megalitri.

Ci si aspetta che durante la revisione del codice, possano notare nuovi problemi o pensare ad un nome migliore, ad es. rinominare convertGalToml in convertGal2ml.

Sospetto che il vostro jolly otterrà il punto e lo rinominerà silenziosamente.

Il punto è che i nomi delle funzioni sono documentazione. Anche se si tratta di un pubblico più tecnico rispetto, ad esempio, al manuale d'uso, dovrebbero essere a loro agio a giustificare la loro scelta di fronte ai loro pari.

Partendo dal presupposto della buona fede, il mio istinto mi dice che i tirocinanti hanno fatto questo perché non vedono davvero alcun problema con nomi come convert. Scommetterei una piccola somma di denaro che i nomi sarcastici non nascono dal desiderio di ribellarsi, ma dalla frustrazione di non saper trovare un nome migliore, solo un nome più lungo. E questo, in un certo senso, è quello che hai detto loro, giusto? Breve cattivo, lungo buono.

Se vuoi che questi individui migliorino, devi semplicemente discutere, nella riunione quotidiana, esattamente perché convert è un nome povero e convertInchesToCentimeters è un nome migliore. Se avete un esempio dalla vostra esperienza di cattiva scelta del nome che causa problemi, questo li aiuterà. Questo “perché” permetterà loro di scegliere d'ora in poi i buoni nomi, sia che siano lunghi o corti.

Fate anche sapere loro che va bene chiedere aiuto a voi o ai loro pari o consultarsi con loro all'interno della ragione, che questo non è un test in cui tutti devono lavorare da soli, questa è una collaborazione. (Spero che sia vero!) Forse questo permetterà loro di fare domande e di parlare tra di loro, e di risolvere le frustrazioni in anticipo, piuttosto che aspettare che cose passive-aggressive come questa si presentino nella revisione del codice.

Solo se tale comportamento continua, trovo necessario spiegare, sì, questa non è una vera e propria applicazione, ma questo esercizio e le linee guida di stile dovrebbero essere prese sul serio per molteplici ragioni:

• Vale la pena spendere il mio tempo con voi per questo sforzo, quando potrei lavorare su applicazioni “reali”, quindi vi prego di fare del vostro meglio anche
• Questo esercizio vi prepara a lavorare su un progetto reale che è serio e nel quale dovete seguire le linee guida di stile
• Questo esercizio ci permette di decidere chi di voi, se del caso, estendere le offerte di lavoro a dopo la conclusione del vostro stage

Anche se non è esattamente sbagliato, penso che accusarli di mancanza di rispetto, ecc. a questo punto probabilmente metterà a tacere il comportamento, ma non li aiuterà anche non li aiuterà a capire perché hanno bisogno di nomi migliori o come inventarsi nomi migliori. Se prendete questa strada, potreste trovarli che se ne escono con nomi cattivi più lunghi e che evitano il vostro sguardo d'acciaio.

Non sei il loro manager, non importa se li intervisti o meno. Tu sei un ingegnere come me,

Quindi sai cosa fare, parla con il tuo manager e poi suggerisci un code-review. Poi consigliate loro di non scrivere codice in quel modo attraverso un sistema come il code collaborator. Non c'è nemmeno bisogno di mandargli un'e-mail, di interagire con loro o di prendere queste cose sul personale. Introducete un sistema di classificazione basato su quella revisione del codice. Non cercate di controllarli o di essere il loro manager, né provate a gestire le persone. Questo non è il vostro business.

Parlate con il vostro manager e mantenete il privilegio di rifiutare o approvare gli impegni dopo una revisione a voi stessi. Supponiamo che ogni tirocinante abbia un punteggio iniziale di 10 punti, e dovrebbe guadagnare 100 punti durante la tua valutazione, e se vuole davvero entrare a far parte del tuo team, sarà motivato a segnare il punteggio. Se fossi uno stagista e lavorassi sotto di voi e voi foste solo un ingegnere senior, anche io odierei se faceste la gestione del mio personale. Non è il tuo lavoro.

Mi sembra che tu ti sia spinto troppo oltre e che la cosa sia andata fuori controllo. Impara questa lezione da ingegnere. Tu sei un ingegnere, non il loro manager per le persone che li gestiscono.

Mentre il comportamento dei tirocinanti può essere poco professionale, è anche poco professionale per il management non considerare che potrebbe essere sbagliato. Chiaramente convert può essere troppo poco ambiguo in molti contesti, ma convertGallonsToMilliliters è troppo lungo per un nome identificativo. Piuttosto che imporre requisiti arbitrari di verbosità di denominazione a tutti i livelli, dovreste sfidare i vostri stagisti a giustificare quando un nome che scelgono è davvero ambiguo (cosa che non saranno in grado di fare) e trovare qualcosa di ragionevole che migliori la leggibilità del programma piuttosto che ostacolarlo.

Questo mi sembra davvero un caso del modello comune di “perché i miei subordinati non mi rispettano?” essendo davvero una questione di “che ne è del mio stesso atteggiamento che fa sì che le persone non rispettino la mia posizione?