"Ehi, hai apportato questa modifica X alla funzione Y. Questa modifica interrompe il mio codice perché non tiene conto di Z, e Z è ciò che accade dalla mia parte. Ti va bene fare K per risolverlo? "

Devi renderlo meno personale. Non ci sono il mio codice e il tuo codice . Entrambi siete dipendenti di un'azienda e quella società possiede il codice. L'hai semplicemente scritto, ma hai trasmesso la proprietà intellettuale al tuo datore di lavoro. Assumere la proprietà è importante, ma non parlarne in questo modo.

Invece, pensa a tutto il codice come il nostro codice e formulalo in questo modo. O lasciarlo fuori. Quando non ti concentri su ciò che hanno fatto, ma piuttosto su quello che è lo stato attuale, ti sembrerà molto meno un attacco personale.

Come risultato della modifica da X a Y, quest'altra funzionalità si è rotta . Ho dato un'occhiata e ho visto che dobbiamo pensare anche a Z.

Puoi quindi vedere cosa dicono. Potrebbero rispondere con qualcosa come "mostrami" o "vai avanti e aggiustalo" o "oh, non ci ho pensato" e si offrono di aggiustarlo da soli.

Idealmente non è così importa chi risolve il problema, però. È importante che ci sia un dialogo e tutti collaborino per rendere il prodotto nel suo complesso stabile e funzionale. Avere solo una persona responsabile di un particolare pezzo del prodotto è di per sé pericoloso, e questo tipo di situazione è una buona occasione per assicurarsi che tutti siano a conoscenza degli altri pezzi del prodotto.

Su una nota più tecnica, sembra che tu voglia davvero test unitari o un'altra forma di test automatizzato almeno per quel particolare pezzo di software. Se c'è un'infrastruttura generale che li esegue e mostra i risultati, sarà evidente se qualcosa (non qualcuno (!), Anche se ovviamente c'è git blame ) ha rotto i test. Sono lì come una rete di sicurezza e perché tutti notino se le cose vanno male.

Un ulteriore vantaggio di avere test unitari per parti critiche del sistema è che non hai davvero bisogno di sottolineare che le cose non funzionano. Non esiste più una persona di polizia di codice . Se la catena degli strumenti si occupa di questo, nessuno sta fornendo cattive notizie e ci sono meno vibrazioni negative nel team poiché c'è meno spazio per discutere.

D'altra parte, viene con la necessità di aggiorna anche i test. Discutere i pro e i contro di ciò è fuori portata qui.

Per prima cosa: non è insolito che il codice di dipendenza interrompa il codice a valle. Esistono pratiche di sviluppo che possono mitigare questo problema, come una buona specifica, documentazione e test. Ma questa non è la risposta alla tua domanda.

Ehi, hai fatto questa modifica X a quella funzione Y. Questa modifica interrompe il mio codice perché non tiene conto di Z e Z è ciò che accade dalla mia parte. Ti va bene fare K per risolverlo?

Quello che dici può sembrare un'accusa - stai essenzialmente dicendo "hai violato il mio codice" - e questo farà sì che le persone sulla difensiva.

Un modo migliore è mantenere meno "hai rotto il mio codice" e più "ti dispiacerebbe dare un'altra occhiata a X? Penso che sia necessario fare K per lavorare con Z".

Poi di nuovo, se questa persona è un brontolone, non importa come ti avvicini, devi far sapere al tuo capo che il tuo lavoro sta subendo ritardi a causa della necessità di aggiustare il lavoro del burbero. Ancora una volta, non puntare il dito, ma lascialo così "il lavoro su Z è stato ritardato dai cambiamenti in X e dovevo prima fare K".

Questa è in realtà una grande opportunità sotto mentite spoglie. La maggior parte degli ingegneri non apprezza quanto sia enorme per un datore di lavoro attuale o potenziale datore di lavoro. Al pari delle capacità tecniche è la tua capacità di collaborare con le persone, accettare la responsabilità degli errori, lavorare con gli altri attraverso i propri e sostenere con tatto i tuoi pensieri. Il consenso comune è che questo è meglio dimostrato durante l'intervista condividendo una storia aneddotica. di solito le persone mettono insieme queste storie in retrospettiva, ma potresti essere molto strategico e realizzare che hai l'opportunità di scrivere una grande storia proprio qui che risponderebbe a domande come "come gestisci i conflitti" e probabilmente aprirebbe sorprendenti opportunità al tuo attuale datore di lavoro .

Bisogna quindi considerare le tue tattiche vs strategia.

Tattiche

Le tue tattiche sono sistemi e azioni che scegli per risolvere il tuo problema. Quindi, ad esempio, scegliere una formulazione migliore che sia meno personale, scegliere il momento giusto, essere consapevoli del pubblico / spettatori, aiutare la persona a cui ti rivolgi a salvare la faccia o utilizzare test automatici per rilevare l'errore. Dedica del tempo all'apprendimento e alla pratica di buone tattiche. Questa sarà la tua cassetta degli attrezzi che potrai sfruttare per la tua strategia.

Strategia

Il problema che stai affrontando è sintomatico di un problema ancora più grande: questa persona non mi piaci davvero. Questo è ciò che vuoi sistemare strategicamente.

Sul posto di lavoro, soprattutto in un team, è al di fuori del tuo controllo avere un rapporto personale con ognuno dei tuoi compagni di squadra. Forse a qualcuno non piaci e non ti piacciono, peccato, sei costretto a una relazione essendo in una squadra. È una tua scelta se quelle relazioni sono buone o cattive. Puoi scegliere di impegnarti o meno nelle altre persone. La vera crescita professionale arriva quando vai oltre a pensare a te stesso solo come un cruncher di codice (che porta a problemi di arroganza del codice), ma come un membro funzionante di un team, e vuoi dimostrare che, con te in un team, quel team è maggiore della somma delle sue parti. Ciò significa una grande consapevolezza relazionale.

La decisione strategica è chiedersi come vuoi che sia quella relazione? È possibile? Cosa manca o quali sfide potrebbero ostacolare la relazione? Cosa devi fare per farlo accadere? Ad esempio, molti problemi di relazione si riducono alla fiducia. Quindi una strategia sarebbe quella di mostrare a questo sviluppatore che stai pensando ai suoi interessi e non solo ai tuoi, e portare il tuo rapporto al punto in cui questa persona si fida di te. Non essere un sapientone stoico, questo non porta le persone dalla tua parte anche se hai ragione e giustificato. La strategia è capire che vuoi che le persone siano dalla tua parte e pensare a come ciò avvenga. Cosa funziona e cosa no. È anche importante rendersi conto che una strategia di successo spesso richiede pazienza. Potrebbe essere necessario lavorare e sfidare te stesso più di quanto desideri per fare progressi reali.

La cosa bella di questo è che, se sviluppi un rapporto davvero solido con questo sviluppatore senior, le tattiche che ti hanno portato lì diventano molto meno necessarie ed è più facile essere più efficienti e avere più successo nel tuo lavoro. Una buona strategia può portarti a un buon rapporto, e con un buon rapporto troverai molto più facile raggiungere i tuoi obiettivi. Quindi pensa di lavorare sul tuo rapporto con questa persona quando non c'è un problema e questo renderà più facile quando sorgeranno problemi come questo.

Come dovrei comunicargli che vengo con buoni mezzi, ma anche fargli capire (e concordare) che è lui che dovrebbe apportare le modifiche necessarie per riparare il codice / modulo rotto?

Faresti meglio ad assicurarti che il tuo capo / squadra sia d'accordo che questo è il modo in cui dovrebbe essere gestito. Idealmente in un ambiente di codifica esiste una sorta di sistema di test automatizzato, quindi se il codice che si tenta di fare il check-in si interrompe, viene rifiutato finché non viene risolto. Di solito questo è dalla persona che l'ha cambiato. Tutti dovrebbero essere orgogliosi del proprio lavoro, che viene fornito con un livello di responsabilità nel voler riparare le cose che si rompono.

Il tuo capo potrebbe ritenere che sia uno spreco avere il tempo degli sviluppatori senior per correggere ogni piccolo bug in cui introducono il sistema. Pensano che il compito sia lasciato agli sviluppatori junior; Non sono d'accordo con questo. Devi scoprire come dovrebbe funzionare.

Il mio approccio a questo tipo di problema consiste nell'assicurarmi che siano presenti metodologie e strumenti sufficienti per rendere il problema tecnico e non personale.

Ad esempio, assicurati di avere build automatizzate e test del fumo. Se questi si rompono, stabilisci una regola secondo la quale il demolitore deve fornire cibo alla prossima riunione del team.

A volte le persone sfideranno semplicemente lo status quo in una ricerca egoistica del progresso personale. In un certo senso, questo è normale. Nella migliore delle ipotesi è imprenditoriale. L'individuo sta andando avanti in un quadro che lo consente. Quindi, cambia il quadro. Quei tipi di persone non saranno ostacolati, faranno progressi in modi diversi. Quindi, come manager, il tuo obiettivo è sfruttare quello spirito e dirigerlo in un modo che sia positivo per il team e gli obiettivi.

Parte di quella strategia di sfruttare la volontà è assicurarsi che le persone abbiano ancora un senso di proprietà. La risposta più popolare qui finora sostiene una filosofia di rinuncia alla proprietà. Penso che questo possa essere controproducente. Lascia che le persone possiedano appassionatamente la loro area. Ma assicurati che non oltrepassino gli altri.

Questa domanda probabilmente dipende in gran parte dalla cultura dell'azienda.

Ci sono aziende in cui "gli errori non si verificano". O meglio, non ti è permesso parlare di loro e un manager che sta conoscendo qualcuno che ha commesso un errore, "osserverà quella persona da vicino".

In quella situazione sveli il problema a quella persona personalmente in un certo senso il manager ne sente parlare solo se assolutamente necessario, dicendo loro esattamente cosa vuoi che facciano o aggiustino, dopo che hai provato a risolverlo da solo. (Ofc. Dovresti anche correre, bandiere rosse yada yada.) Dovresti anche dire loro che è tra te e loro e che sei a posto.

In qualsiasi azienda funzionante, devi assicurarti che il tuo la divulgazione non suona come un'accusa.

Devi comunque assicurarti di dire loro esattamente cosa vuoi da loro e perché non puoi farlo da solo (perché se riesci a risolverlo, allora perché ti lamenti, risolvilo rapidamente e vai avanti, non l'hanno fatto per creare lavoro per te, hanno dovuto risolvere il loro problema).

Assicurati inoltre che il loro manager o capo del progetto è consapevole e ha dato loro il permesso di risolverlo.

Non possono decidere cosa fare con il loro tempo e ottenere il lavoro assegnato dal loro manager / capo progetto.

Andare avanti e parlare di un bug in un ticket che dovrebbe essere fatto ormai, senza fare quelle cose prima e indirizzarle direttamente creerà stress e l'impressione che tu voglia che lavorino in tempo in cui sono assegnati a qualcos'altro o nel tempo libero.

La maggior parte dei conflitti o dei problemi con le persone sono dovuti a problemi di base del processo. Questo è certamente il caso qui.

Tu, i tuoi colleghi, la tua azienda e peggio ancora i tuoi clienti finali siete tutti vittime di processi fallimentari che dovrebbero essere messi in atto per gestire la qualità e l'integrità del vostro codice combinato.

e agire da quella prospettiva è la chiave per risolvere i problemi di qualità sottostanti che hanno portato direttamente ai problemi che stai vivendo. È anche la chiave per trovare un terreno comune con i tuoi colleghi (ad esempio, troverai facile concordare i problemi del processo che ti stanno causando tutto il dolore).

Anche se probabilmente vuoi solo portare a termine il lavoro e progredire nella tua carriera, se ti sembra che tu abbia voglia di unirsi a colleghi più esperti, danneggerai il tuo rapporto di lavoro con coloro che si trovano nella posizione migliore per aiutarti.

Il mio consiglio sarebbe quello di proporre una soluzione, in dettaglio (come una richiesta pull, per esempio) o uno schema dell'approccio generale che proporresti come soluzione. Portalo alla persona il cui codice ritieni sia rotto e chiedi la sua opinione. E, cosa più importante, ascolta la risposta .

Questo presenta al collega, che potresti aver appena interrotto, una soluzione, piuttosto che un problema e quindi un lavoro aggiuntivo. Non solo probabilmente imparerai qualcosa dalla risposta che riceverai, ma sarai considerato utile e un giocatore di squadra.

Come altri hanno suggerito, devi de-personalizzare questo. Dovrebbe esserci una proprietà collettiva del codice. Meno di "hai rotto i miei cambiamenti!" e più come "come possiamo fare in modo che entrambe le modifiche funzionino bene insieme?"

Potresti anche valutare se c'è spazio per migliorare la comunicazione durante gli standup quotidiani (se li hai - o suggerire di introdurli se non), in modo che generalmente vi sia più consapevolezza di ciò su cui le persone stanno lavorando e quindi meno possibilità di conflitti o modifiche interrotte.

Fornire il giusto livello di dettaglio agli standup è complicato, ma se i colleghi non lo sono t consapevole dell'ampia area del codice in cui stai lavorando, potresti prendere in considerazione la possibilità di fornire qualche dettaglio in più.

Qualcos'altro da tenere a mente: come sviluppatore più giovane, ma con meno esperienza, è del tutto possibile che tu possa programmare più velocemente dei tuoi colleghi più esperti (un cervello più giovane e più acuto è una vera risorsa a volte!), Tuttavia dovresti riconoscere anche che i tuoi colleghi più anziani hanno un vantaggio in termini di esperienza e possono essere più considerati nel loro approccio, in base ai loro anni di esperienza. In effetti, la maggior parte dei progetti di sviluppo sono più simili a maratone che a sprint sui 100 metri. Le migliori squadre attingono a tutti i livelli di esperienza.

Come dovrei comunicargli che vengo con buone intenzioni, ma anche fargli capire (e concordare) che è lui che dovrebbe apportare le modifiche necessarie per riparare il codice / modulo rotto?

Concordo con gran parte di quanto è già stato detto. Persone diverse interpretano lo stesso messaggio in modi diversi e ciò che una persona percepisce come una comunicazione completamente normale ed efficace, un'altra persona lo trova irritante o intimidatorio, per qualsiasi motivo. Quella persona sta probabilmente comunicando (implicitamente) che trova il tuo stile sgradevole. La prossima volta prova qualcos'altro. Prova a cambiare l'impostazione: prendilo alla fontana piuttosto che al suo posto. Siediti accanto a lui prima di iniziare la conversazione, invece di stargli sopra. Prova approcci diversi: usa il tuo buon senso.

E un'altra cosa che posso suggerire, cerca di bilanciare la tua comunicazione con lui. Se è sensibile al fatto che tu sottolinei i suoi errori, trova l'opportunità di complimentarti (sinceramente) con lui per un design intelligente o un'esecuzione efficace: questo fa molto per la maggior parte delle persone.

Il modo più semplice per gestirlo è non gestirlo. Consenti invece allo sviluppatore di discutere con un test fallito. Chiedi loro come dovrebbe funzionare il codice, quindi crea un test attorno ad esso. Consegnagli il test e digli che fallisce.