Riacquistare la fiducia del programmatore senior [chiuso]

Il mio capo ha scoperto che non sono intelligente come pensava.

Un esempio della mia esperienza:

Sono un programmatore junior e lavoro in una squadra di due, il mio capo (programmatore senior) e me stesso.

Mi è stato assegnato il compito di sviluppare un'applicazione web interna per l'azienda in cui lavoriamo. Ho scritto il back-end sul front-end (il design del database era già in atto e la tecnologia del server era stata scelta). Controllava periodicamente i miei progressi osservando l'applicazione web in azione ed era contento che fosse successo. Quando ho finito l'app Web, è rimasto soddisfatto del risultato finale del prodotto finale.

Qualche giorno fa si è interessato al codice, quindi gli ho detto quali tecnologie ho usato (per il front-end), ed è qui che è andato a sud. Per il front-end dell'app Web ho usato un framework Javascript (Backbone.js). Alla domanda sul perché dovrei fare una cosa del genere. La mia risposta è stata perché ho sentito che il framework si adattava abbastanza bene a questa app e mi avrebbe aiutato a strutturare il codice meglio che se lo avessi scritto da zero .... "Beh, questo è scoraggiante" è stata la sua risposta.

Quindi, dato questo esempio, la mia domanda è:

Se sei un programmatore senior e hai perso la fiducia nelle capacità del tuo programmatore junior, cosa ti piacerebbe vedere dal tuo junior per ritrovare la fiducia?

EDIT : grazie a tutti per le grandi risposte e feedback di supporto!

Se gli è piaciuto il prodotto che hai creato, ma è bloccato sul tuo uso di Backbone, entrambi devi avere una conversazione sullo stack tecnologico desiderato.

Come sviluppatori, dovremmo utilizzare strumenti prontamente disponibili e, di conseguenza, spostare agevolmente il nostro flusso di lavoro. Se si aspettava che costruissi il front-end da zero, avrebbe dovuto essere esplicito e avere buone ragioni.

Il fatto che inizialmente abbia apprezzato il prodotto è la prova che hai fatto bene e sei abbastanza "intelligente".

tl; dr Hai fatto bene. Parla con il tuo anziano e vedi cosa si aspetta da te.

A me non sembra molto "anziano" per fare una chiamata così rapida. Tendo sempre a utilizzare un framework adeguato anziché l'anti-pattern "Reinvent the wheel wheel". Se fosse veramente più anziano, comprenderebbe e conoscerebbe il valore di una buona struttura. Nella migliore delle ipotesi, mi aspetto che metta in dubbio la scelta di Backbone.js su un altro framework JavaScript MVC e molto prima nel processo. Ha fallito nel mentoring e nel controllo corretti su di te da giovane e ti ha aiutato lungo il giusto percorso di sviluppo (nella sua mente).

Sembra che tu abbia fatto la scelta giusta nello sviluppo del progetto data la mancanza di direzione da parte sua (presupposto) e stai lavorando per diventare uno sviluppatore più competente. Penso che potrebbe essere utile spiegargli la scelta del framework, il motivo per cui ritenevi appropriato un framework e sottolineare che il progetto è stato realizzato e in parte la sua soddisfazione grazie all'uso di un framework ben documentato e supportato. Se non riesci a fare progressi, forse non ha valore apparire meglio ai suoi occhi. Solo tu puoi rispondere a questo.

La maggior parte delle risposte e dei commenti ha l'idea giusta in quanto tu e il senior dovreste avere una sorta di discussione e che potrebbe essere importante per voi intensificare e difendere le vostre decisioni, anche se il vostro senior non è d'accordo con le vostre scelte .

Per rispondere alla tua domanda su cosa vorrei vedere come senior:

Vorrei vedere se i miei sviluppatori junior sono in grado di alzarsi e difendere le sue decisioni, anche se deboli delusioni. Se fossi soddisfatto del prodotto ma non dell'implementazione, mi aspetterei che i junior segnalino che avrei dovuto essere più specifico nelle mie specifiche quando ho dato loro il prodotto. Vorrei che fossero in grado di resistere, ma anche di ammettere che forse non avrebbero fatto la scelta giusta.

PS: Devo dire che sono un anziano che ama essere smentito a livello professionale in quanto ciò mi dà l'opportunità di imparare qualcosa di nuovo. E mi piace essere consapevole di come gli altri membri del mio team fanno le cose in modo che non ci siano / meno sorprese alla fine di uno Sprint / attività.

Prima di tutto, penso che questo debba essere visto come un'opportunità, non un fallimento. C'è ovviamente una discrepanza nelle aspettative e non è chiaro da dove provenga, cosa debba succedere per riportare tutto in pista e simili.

In secondo luogo, se lo prendi come un fallimento attuale o non sei intelligente come pensi che crei relazioni di potere che non vuoi. Quindi, se hai preso decisioni che ritieni siano difendibili, devi essere disposto a difenderle fino a un certo punto.

Mentre sono d'accordo con duggieawesome sul fatto che tu voglia avere una conversazione, non è abbastanza. Devi essere pronto ad entrare, discutere le tue idee di design, spiegare perché hai fatto quello che hai fatto e difendere il ragionamento. Devi anche accettare che non esiste una sola risposta corretta e che il programmatore senior potrebbe avere validi motivi per preferire un design diverso e quindi vuoi essere disposto ad ascoltare quei motivi senza ammettere che le tue decisioni erano sbagliate su ciò che sapevi (a meno che non decidi che avresti dovuto saperlo meglio, e quindi questa è un'altra questione).

Tieni presente che il design è di solito una questione di compromessi. Vuoi essere disposto a discutere quali sono i compromessi e vedere cosa entrambi puoi fare per assicurarti di poter discutere dei compromessi di progettazione in futuro. Forse voi due vi aspettate di essere più sulla stessa pagina di voi? Forse il tuo capo è un idiota (potrebbe succedere a volte)? Forse hai davvero preso una decisione che era sbagliata dato ciò che sapevi sui requisiti? Entra con una mente aperta e con sicurezza, tuttavia, e sii disposto a parlarne davvero.

Modifica: voglio aggiungere qualcosa sull'essere intelligenti. Le persone più intelligenti che conosco sono persone che pensano di avere qualcosa da imparare da tutti. Le persone che sono chiuse e credono che esista un solo modo giusto non finiscono per prendere decisioni fantasiosamente buone in settori come il design e non possono collegare le cose nel modo in cui le persone che sono disposte a imparare da tutti possono. Entrare ed essere disposti a condividere e persino far rimbalzare idee avanti e indietro è un segno di essere intelligenti e sicuri. Le differenze nel design non diventano necessariamente una questione che l'una sia migliore dell'altra. Supponendo che i progettisti competenti, i diversi design saranno ottimizzati in modo diverso.

Sono dell'opinione generale qui che non hai fatto nulla di male. Come sviluppatore senior, avrebbe dovuto interessarsi al modo in cui stavi sviluppando l'applicazione e ai risultati. Arrivare dopo che un progetto è stato completato e dire che non gli piace come è stato fatto non è molto professionale da parte sua.

Ma, per rispondere alla tua domanda principale: come riacquistare l'opinione di un anziano su di te dopo che potrebbe essere andata persa? Prima di tutto, chiedi come pensano che avresti dovuto farlo. Poni domande se non capisci e prendi appunti. Mostra che vuoi imparare.

In secondo luogo, nel tuo prossimo compito, se c'è qualcosa che è stato lasciato fuori dalla descrizione, trova le tue idee e gestiscile dal senior dev. Non chiederti come farlo, b / c questo non aiuterà la loro opinione su di te. Ma, se ti vengono in mente le tue idee e le tue soluzioni, chiedi loro se sei sulla strada giusta, mostrerà loro che stai provando e che hai le competenze per svolgere il lavoro. Questo può essere semplice come una e-mail veloce che dice "Ehi, sto pensando di usare x quando faccio y . Qualche idea?"

Terzo, quando fanno capolino per vedere come stai, non lasciarli andare senza guardare il tuo codice.

Fondamentalmente, apri le linee di comunicazione. Il tuo sviluppatore senior non sembra essere il tipo che si trova su di te o sul tuo codice, quindi devi intensificare ed essere la persona a comunicare. È meglio per tutti i soggetti coinvolti scoprire che qualcosa non è stato pensato in origine prima o poi.

Una cosa che devi scoprire subito è se è scoraggiato perché non puoi dare una difesa completa della tua scelta di framework, o se è perché hai usato un framework.

Nel primo caso, è importante imparare a valutare e selezionare il codice di terze parti per l'inclusione in un progetto e sapere come articolare tale decisione ai propri superiori e prepararsi a sostenerlo con giustificazione. Questa è un'abilità difficile da imparare, ma arriva con l'esperienza. È anche una buona abilità da imparare perché non appena includi una libreria di terze parti in un progetto introduci un componente che potrebbe non essere completamente compreso dagli altri sviluppatori, che non hanno il pieno controllo e che può contenere bug, falle di sicurezza e altre cose di cui devono essere consapevoli.

Se è deluso perché non l'hai scritto da zero, allora è un problema completamente diverso. Può darsi che abbia buone ragioni per scoraggiare l'uso dei framework (come quelli che ho descritto sopra), o forse c'è una politica aziendale contro di loro o che limita la scelta dei framework che puoi fare. In ogni caso avrebbe dovuto comunicartelo e il fatto che non ha indicato un fallimento da parte sua. D'altra parte, potrebbe avere solo un caso di pregiudizio del framework, perché nonostante i problemi che i framework possono portare, hanno anche grandi vantaggi, come sono sicuro che tu sappia. Può solo pensare che dovresti fare tutto da solo, anche se ciò significa rifare il lavoro che è già stato fatto e reso pubblicamente disponibile a causa della "Sindrome di non inventato qui".

Il fatto che non abbia spiegato perché sia ​​deluso da te per l'utilizzo di un framework è sicuramente un fallimento da parte sua nel comunicare in modo efficace. Ti ha lasciato chiedendoti cosa hai fatto di sbagliato, quando la risposta potrebbe essere "niente". Ti ha anche fatto mettere in discussione te stesso, e questo è destinato a renderti meno incline a usare la tua iniziativa in futuro. Se c'è una caratteristica che un buon programmatore non può permettersi di avere, è una mancanza di iniziativa. E mentre sono sicuro che non è intenzionale, il suo atteggiamento è dannoso per il morale poiché improvvisamente ha ritirato gli elogi per un lavoro ben fatto su un piccolo dettaglio di come hai compiuto il compito.

Solo perché è il programmatore senior non lo rende infallibile.

Il tuo commento di follow-up che ha detto che il capo è arrabbiato deve imparare qualcosa di nuovo ...

A meno che non ci sia altro che tu non abbia menzionato, sarei infastidito da LUI.

L'apprendimento di nuove tecnologie è una parte importante del nostro lavoro e ogni squadra dovrebbe abbracciare l'apprendimento e il miglioramento di sé.

MA, la gestione ha altre cose di cui preoccuparsi. Hanno scadenze da rispettare, budget di formazione limitati o nulli.

Dal punto di vista della gestione dell'uomo, potrebbe trattarsi di qualcun altro che sta lavorando alla fase 2 del progetto anziché a te. Il tuo capo potrebbe avere l'orecchio di qualcun altro segnato per fare quel lavoro, e sa che quella persona ora ha una curva di apprendimento per qualcosa di nuovo.

E ora un MA sul precedente MA ....... questo è colpa dei tuoi capi. Se sei nuovo e giovane, avrebbe dovuto fornire almeno qualche consiglio. In misura minore, avresti potuto chiedere anche una guida sulla tecnologia da utilizzare.

Se sei un programmatore senior e hai perso la fiducia nelle capacità del tuo programmatore junior, cosa ti piacerebbe vedere dal tuo junior per ritrovare la fiducia?

Dato che hai detto che non voleva imparare a usare il framework che hai usato, penso che la domanda dovrebbe essere: " Se sei un programmatore senior e hai perso la capacità di imparare dal tuo programmatore junior, cosa dovresti fare per sistemarti? "

Come sviluppatore professionista non smetti di imparare. Mai. Se lo fai, stai per ristagnare. E ciò potrebbe andare bene in alcune aree. Il settore bancario ha molti sistemi legacy in funzione che devono essere mantenuti, quindi va bene la conoscenza dei vecchi sistemi che si muovono molto lentamente. Un mio amico stava pubblicando COBOL per una banca per scoprire che il codice sorgente che stava riparando non era stato toccato per circa 30 anni (e l'autore originale era il nostro docente COBOL all'università) ... Detto questo, deve ancora apprendere nuove cose in quanto i vecchi sistemi devono essere integrati in nuovi sistemi.

Torna al tuo sviluppatore senior. Hai detto " era sconvolto dal dover imparare qualcosa di nuovo ", e secondo me suona un campanello d'allarme piuttosto forte.

Sto sempre imparando. Anche se mi piacerebbe davvero che il mio datore di lavoro riscuotesse la mia bolletta scolastica ogni anno, è raro che spendano qualcosa vicino a ciò che sento di cui ho effettivamente bisogno, eppure so che devo rimanere occupabile, quindi spendo da qualche parte nella regione di £ 2000 GBP (circa $ 3000 USD) sulla mia educazione ogni anno.

Se il tuo senior non sta imparando cose nuove, allora inizierà a prendere decisioni sbagliate (forse lo sono già) e la qualità del codice con cui hai a che fare andrà verso il basso perché sono bloccati in una routine e non sentono il bisogno di ottenere fuori da quella carreggiata.

Uno dei migliori sviluppatori con cui abbia mai lavorato era uno sviluppatore junior che conosceva ogni genere di cose che non avevo mai avuto modo di vedere. Portava così tanto sul tavolo che spesso ero sopraffatto. Ma ho apprezzato i suoi sforzi e non sono mai stato "scoraggiato" da nessuno di essi. Mi ha fatto piacere che abbia preso il tempo per apprezzare tutte le possibilità e presentarle alla squadra. Ora guida una squadra e continua a parlarmi di sviluppatori che portano cose sul tavolo e cosa sta imparando da loro.

Il tuo sviluppatore senior deve imparare le cose. Devono imparare a non usare parole emotive (come "scoraggiante") per nascondere le proprie inadeguatezze, perché ciò metterà a repentaglio la fiducia degli altri. Devono imparare nuovi quadri (anche se non riescono a imparare tutto, imparare cosa fa e come risolve un problema, e se ne hanno bisogno in futuro, allora possono investire il tempo nell'apprendimento più approfondito). E devono imparare che hanno un lavoro in cui dovranno continuare a imparare tutto il tempo.