Ri-guadagnando la fiducia del programmatore anziano [chiuso]

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

Come sviluppatori, dovremmo usare 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 aveva una buona ragione.

Il fatto che inizialmente abbia apprezzato il prodotto è una prova sufficiente per farti fare bene e sono abbastanza "intelligenti".

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

Non mi sembra molto "senior" per fare una battuta d'arresto come quella. Io tendo sempre ad usare una struttura adeguata invece del modello anti-pattern "Reinvent the square wheel". Se fosse veramente anziano, comprenderebbe e conoscerà il valore di una buona struttura. Nella migliore delle ipotesi mi aspetterei che metta in discussione la scelta di Backbone.js su un altro framework MVC JavaScript e molto prima nel processo. Ha fallito nel mentoring e nel controllarti come junior e ti aiuta lungo il percorso di sviluppo appropriato (nella sua mente).

Sembra che tu abbia fatto la scelta giusta nello sviluppo del progetto data la mancanza di direzione da parte sua (assunto) e stai lavorando per diventare uno sviluppatore più competente. Penserei che ci potrebbe essere un valore nel spiegargli la tua scelta del framework, perché hai sentito che un framework era appropriato, e sottolineare che il progetto è stato fatto e per la sua soddisfazione in parte a causa dell'utilizzo di un framework ben documentato e supportato. Se non riesci a progredire, forse non ha più valore apparire nei suoi occhi. Solo tu puoi rispondere a questo.

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

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

Mi piacerebbe vedere se i miei sviluppatori più giovani possono alzarsi in piedi e difendere le sue decisioni, anche se una lieve delusione. Se fossi felice con il prodotto ma non con l'implementazione, mi aspetterei che i juniors indicassero che avrei dovuto essere più specifico nelle mie specifiche quando davo loro il prodotto. Mi piacerebbe che fossero in grado di resistere, ma anche ammettere che non avrebbero potuto fare la scelta giusta in quel caso.

PS: Devo dire che sono un anziano che ama essere smentito a livello professionale in quanto 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 / compito.

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 viene, cosa deve accadere per rimettere tutto in pista e cose simili.

In secondo luogo, se consideri questo come un errore corrente o se 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.

Anche se sono d'accordo con duggieawesome che vuoi avere una conversazione, non è abbastanza. Devi essere preparato per entrare, discutere le tue idee di progettazione, spiegare perché hai fatto quello che hai fatto e difendere il ragionamento. Devi anche accettare che non c'è solo una risposta giusta e che il programmatore senior può avere validi motivi per preferire un design diverso e quindi vuoi essere disposto ad ascoltare queste ragioni senza ammettere che le tue decisioni sono state cattive su quello che sapevi (a meno che tu non decida che avresti dovuto saperlo meglio, e poi questa è un'altra questione).

Ricorda che il design è solitamente una questione di compromessi. Volete essere disposti a discutere di quali sono i compromessi e vedere cosa entrambi potete fare per assicurarvi di poter discutere dei compromessi di progettazione in futuro. Forse voi due vi state solo aspettando di essere più sulla stessa pagina di voi? Forse il tuo capo è un idiota (potrebbe succedere qualche volta)? Forse hai davvero preso una decisione sbagliata visto quello che sapevi sui requisiti? Entra con una mente aperta e con sicurezza, tuttavia, e sii disposto a parlarne veramente.

Modifica: voglio aggiungere qualcosa sull'essere intelligente. 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 ci sia solo un modo giusto non finiscono per prendere decisioni fantasiose in aree come il design e non possono collegare le cose insieme come possono fare le persone che desiderano imparare da tutti. Entrare ed essere disposti a condividere e persino rimbalzare idee avanti e indietro è un segnale sia di essere intelligenti che fiduciosi. Le differenze nel design non diventano necessariamente la questione di un essere migliore dell'altro. Supponendo che i progettisti competenti, diversi disegni saranno ottimizzati in modo diverso.

Sono dell'opinione pubblica qui che non hai fatto nulla di sbagliato. Come sviluppatore senior, avrebbe dovuto interessarsi a come stavi sviluppando l'applicazione e ai risultati. Entrare 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 riesci a riconquistare l'opinione di un anziano di te dopo che potrebbe essere stato perso? Prima di tutto, chiedi come sentono che dovresti averlo fatto. Fai domande se non capisci e prendi appunti. Mostra che vuoi imparare.

In secondo luogo, nel tuo prossimo compito, se c'è qualcosa che è stato escluso dalla descrizione, fai emergere le tue idee e poi eseguile con lo sviluppatore senior. Non esitare a chiedere come si fa, b / c questo non aiuterà la loro opinione su di te. Ma se trovi le tue idee e le tue soluzioni, chiedi loro se sei sulla strada giusta, mostrerà loro che stai provando e che hai le capacità per portare a termine il lavoro. Questo può essere semplice come una veloce e-mail che dice "Ehi, sto pensando di usare x quando faccio y .

In terzo luogo, quando scoccano la testa 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 da te o il tuo codice, quindi devi fare il passo e essere la persona da comunicare. È meglio per tutti coloro che sono coinvolti scoprire che qualcosa non è esattamente 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 come valutare e selezionare il codice di terze parti da includere in un progetto e sapere come articolare tale decisione nei confronti dei propri superiori ed essere pronti a supportarlo con giustificazione. Questa è un'abilità difficile da imparare, ma è accompagnata dall'esperienza. È anche una buona abilità da imparare perché non appena includi una libreria di terze parti in un progetto, presenti un componente che potrebbe non essere completamente compreso dagli altri sviluppatori, che non hanno il pieno controllo e possono contenere bug, buchi di sicurezza e altre cose di cui hanno bisogno di essere a conoscenza.

Se è deluso perché non lo hai scritto da zero, allora è un problema completamente diverso. Può darsi che abbia buone ragioni per scoraggiare l'uso di framework (come quelli descritti sopra), o forse c'è una politica aziendale contro di loro o limitare la scelta dei framework che si possono fare. In ogni caso, lui avrebbe dovuto comunicartelo e il fatto che non indicasse un fallimento da parte sua. D'altra parte, potrebbe avere solo un caso di pregiudizio quadro, perché nonostante le problematiche che possono portare i quadri, hanno anche importanti benefici, come sono sicuro che tu sappia. Potrebbe pensare che dovresti fare tutto da solo, anche se questo significa rifare il lavoro che è già stato fatto e reso pubblicamente disponibile a causa della "sindrome non inventata qui".

Il fatto che non abbia spiegato perché è deluso da te per aver utilizzato un framework è certamente un fallimento da parte sua nel comunicare in modo efficace. Ti ha lasciato chiedersi cosa hai fatto di sbagliato, quando la risposta potrebbe essere "nulla". Ti ha anche fatto dubitare di 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 anche se sono sicuro che non è intenzionale, il suo atteggiamento è dannoso per il morale, perché improvvisamente si è ritirato dalla lode per un lavoro ben fatto su un piccolo dettaglio di come hai svolto il compito.

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

Il tuo commento di follow-up che dice che il capo è sconvolto che deve imparare qualcosa di nuovo ....

A meno che non ci sia qualcosa che non hai menzionato, sarei seccato per LUI.

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

MA, la gestione ha altre cose di cui preoccuparsi. Hanno scadenze da rispettare, hanno un budget di formazione limitato o nullo.

Dal punto di vista della gestione uomo, potrebbe essere qualcun altro a lavorare sulla fase 2 del tuo progetto al posto tuo. Il tuo capo potrebbe avere 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 del tuo capo. Se sei nuovo e junior, dovrebbe aver fornito almeno una guida. In misura minore, avresti potuto chiedere indicazioni sulla tecnologia da usare.

If you're a senior programmer and have lost confidence in the ability of your junior programmer, what would you like to see from your junior to gain the confidence back?

Dato che hai detto che non voleva imparare come usare il framework che hai usato, penso che la domanda dovrebbe essere: " Se sei un programmatore esperto 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 potrebbe andare bene in alcune aree. Il settore bancario ha un sacco di sistemi legacy in funzione che devono essere mantenuti, quindi la conoscenza dei vecchi sistemi che si muovono molto lentamente va bene. Un mio amico stava modificando COBOL per una banca per scoprire che il codice sorgente che stava fissando non era stato toccato in 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 nei nuovi sistemi.

Torna al tuo sviluppatore senior. Hai detto " era sconvolto per aver dovuto imparare qualcosa di nuovo ", e secondo me è un anello di campane piuttosto strong.

Sto sempre imparando. Anche se mi piacerebbe che il mio datore di lavoro prendesse la mia bolletta per l'istruzione ogni anno è raro che spenda qualcosa di simile a quello che sento di aver effettivamente bisogno, eppure so che devo rimanere impiegabile, quindi spendo da qualche parte nella regione di £ 2000 GBP (circa $ 3000 USD) sulla mia istruzione ogni anno.

Se il tuo senior non sta imparando cose nuove, inizieranno a prendere decisioni sbagliate (forse lo sono già) e la qualità del codice che hai a che fare andrà verso il basso perché sono bloccate in una carreggiata e non sentono il bisogno di uscire da quel solco.

Uno dei migliori sviluppatori con cui abbia mai lavorato era uno sviluppatore junior che conosceva tutti i tipi di cose che non avevo mai avuto la possibilità di guardare. Ha portato così tanto al tavolo che ero spesso sopraffatto. Ma ho apprezzato i suoi sforzi e non sono mai stato "disapprovato" da nessuno di questi. Mi ha fatto piacere che si sia preso il tempo per apprezzare tutte le possibilità e presentarle alla squadra. Adesso è a capo di una squadra e continua a raccontarmi di sviluppatori che portano cose in tavola e che cosa sta imparando da loro.

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