Come si fa a sapere se i consigli di uno sviluppatore senior sono cattivi? [chiuso]

Di recente, ho iniziato il mio primo lavoro come sviluppatore junior e ho uno sviluppatore più senior incaricato di farmi da mentore in questa piccola azienda. Tuttavia, ci sono diverse volte in cui mi darebbe consigli su cose con le quali non potrei essere d'accordo (va contro ciò che ho imparato in molti buoni libri sull'argomento scritto dagli esperti, anche le domande che ho posto su alcuni siti di domande e risposte) con me) e dato il nostro fitto programma, probabilmente non abbiamo tempo per lunghi dibattiti.

Finora ho cercato di evitare il problema ascoltandolo, sollevando un contrappunto basato su ciò che ho imparato come buone pratiche attuali. Solleva nuovamente il suo punto originale (la maggior parte delle volte dirà best practice, più mantenibile ma non è andato oltre), prendo una nota (dal momento che non ha sollevato un nuovo punto per contrastare il mio contrappunto), penso a e ricerca a casa, ma non apportare modifiche (non sono ancora convinto). Ma recentemente, mi ha avvicinato ancora una volta, ha visto il mio codice e mi ha chiesto perché non l'ho modificato nel suo suggerimento. Questa è la terza volta in 2-3 settimane.

Come sviluppatore junior, so che dovrei rispettarlo, ma allo stesso tempo non posso essere d'accordo con alcuni dei suoi consigli. Eppure sono sotto pressione per apportare modifiche che penso peggioreranno il progetto. Naturalmente come sviluppatore inesperto, potrei sbagliarmi e la sua strada potrebbe essere migliore, potrebbe essere 1 di quei casi eccezionali.

La mia domanda è: cosa posso fare per giudicare meglio se il consiglio di uno sviluppatore senior è buono, cattivo o forse è buono, ma obsoleto nel contesto odierno? E se è cattivo / obsoleto, quali tattiche posso usare per non implementarlo a modo suo nonostante le sue "pressioni", pur mantenendo il fatto che lo rispetto come senior?

In primo luogo, come sviluppatore senior, mi aspetto che i giovani che guido nei progetti mi portino le loro preoccupazioni in modo diretto e diretto. Se non sono d'accordo, va bene per me. In alcuni casi, prenderò provvedimenti sulle loro preoccupazioni. Nella maggior parte dei casi, le loro preoccupazioni vengono messe da parte messe da parte con una breve spiegazione del ragionamento , non per mancanza di rispetto per lo sviluppatore, ma per altri motivi come:

1. Il junior non ha tutte le informazioni a portata di mano per capire la decisione come è stata presa. In alcuni casi, una piccola spiegazione può aiutare lo sviluppatore a superare il problema e affrontare una situazione unideale.
2. Il junior ha informazioni MALE. Non dimenticare che sei, in effetti, un giovane. Questo è l'equivalente di essere un adolescente in termini di software. Sono sicuro che hai molte idee fantastiche, ma è possibile che tu non sappia tutto. Trovo che gli sviluppatori junior più resistenti siano quelli che credono fermamente di sapere cosa è meglio per il codice, l'azienda, il mondo. Questi sviluppatori sono meglio serviti acquisendo umiltà.
3. La decisione di fare qualcosa in un modo particolare è stata presa sopra la testa dell'anziano. L'anziano lavora ancora per qualcun altro alla fine. In realtà potrebbe esserci un modo migliore per fare qualcosa, un modo più efficiente per scrivere qualcosa o un software / hardware migliore per aiutare a fare il lavoro. Tuttavia, l'azienda continua a guidare le decisioni. Dirigenti aziendali, direttori, vicepresidenti, ecc. Spesso prendono decisioni che incidono sul processo di sviluppo. Questi sono al di fuori del controllo dell'anziano, e quando i junior si lamentano, tutto ciò che fanno è aumentare lo stress dell'anziano.
4. L'anziano appena uscito non ha tempo di prenderlo in considerazione. Ci sono scadenze e talvolta cambiare schemi, pratiche e comportamenti a metà flusso è costoso per tale scadenza. Dal momento che è il suo collo sul tagliere spesso è più importante rendere il prodotto funzionale e puntuale piuttosto che "perfettamente scritto".

Queste sono solo le cose a cui riesco a pensare dalla cima della mia testa. Ci sono molte ragioni per cui un'idea, una pratica, un concetto potrebbero essere scartati o scartati da qualcuno più in alto di te. Molti di loro sono spiacevoli, ma si riducono tutti al fatto che siamo tutti umani e tutti abbiamo opinioni. La sua opinione sembra essere numericamente superiore alla tua al momento.

Tenendo a mente questi concetti, dovresti continuare a portare le tue preoccupazioni allo sviluppatore senior. Trova un altro sviluppatore senior che potrebbe essere in grado di riempire gli spazi vuoti. Molti sviluppatori senior sono lì perché sono migliori con il software che con le persone. Alcuni sono dove sono perché sapevano di chi baciare il culo quando erano stagisti. Trova qualcuno che capisca davvero cosa significa fare da mentore a qualcuno e ottenere la sua opinione onesta. Potrebbero non essere d'accordo con te e riempire gli spazi vuoti che non hai. Possono essere d'accordo con te e aiutarti a raccogliere la tua causa o a migliorare la tua situazione.

Non devi mai montare alcun tipo di insurrezione. Anche se credi nel tuo cuore che la tua strada è giusta, ti è stata data un'istruzione da seguire e dovresti seguirla (a meno che non sia illegale ovviamente). Se hai problemi a seguire queste istruzioni, potresti provare a capire perché, perché scoprirai che questo modello di comportamento è molto diffuso in molte aziende che producono qualsiasi tipo di software.

La tua migliore opzione è quella di continuare a fare il tuo lavoro eticamente e professionalmente. Ottieni il software che ti viene chiesto di completare in modo esemplare e fuggi dalla situazione venendo promosso da esso. Se le promozioni non arrivano, avrai molte referenze ed esperienze per perseguire opportunità in altri dipartimenti o aziende.

Rispetta lo sviluppatore senior. È più in linea per il successo del progetto di te. Dal momento che ha la responsabilità, ottiene anche l'autorità. Se dice cambia qualcosa, allora fallo.

Detto questo, non esitare a presentare le tue preoccupazioni, quando incontri un problema come già hai.

Infine, siediti con lui e spiegagli la stessa domanda che hai pubblicato qui. Forse ti stai perdendo qualcosa di grosso, forse si aprirà di più ai tuoi suggerimenti, in entrambi i casi, non tenerlo al buio se pensi che il suo consiglio sia scadente.

Quando ciò accade, è necessario conversare con lo sviluppatore senior . Forse sa qualcosa che non conosci sul codice o sui requisiti tecnici / aziendali. Se è così, dovresti impararlo.

Fallo in privato. Potrebbe essere visto come un'autorità sfidante, e queste cose dovrebbero essere fatte una a una. Mostra la volontà di scendere a compromessi e di collaborare riconoscendo e rispettando la sua anzianità, ma sii costante nel rispondere alle tue domande. Affronta la situazione da una cornice collaborativa, non combattiva. Potresti considerare di chiedergli di fare da mentore.

Alla fine della giornata, devi bilanciare le tue idee (che, per essere onesti, sono relativamente nuove e non testate) con le sue. Forse hai davvero ragione, ma dovresti fare del tuo meglio per imparare da persone più esperte in modo da poter prendere una decisione più informata. Un buon sviluppatore senior accoglie con favore l'opportunità di collaborare, fare da mentore e apprendere, anche con sviluppatori junior, e si compiace che le loro idee vengano sfidate in modo costruttivo perché anche loro sanno che a volte sbagliano.

Il modo in cui lo dici spesso è attraverso un approccio di buon senso. Tieni presente che lo sviluppatore senior potrebbe sapere di più sul progetto, ma potrebbe non sapere di più sul modo giusto di fare le cose. Devi valutare ciò che ti dice di fare: ti sta dando dei cattivi consigli se ciò che dice vola di fronte a ciò che affermano i suoi scommettitori (cioè persone più più anziane di lui; non necessariamente nella tua compagnia ... Sto parlando di noti sviluppatori di "celebrità" che spesso pubblicano o scrivono libri sul modo corretto di fare lo sviluppo del software, o almeno sulle migliori pratiche accettate dal settore).

Ecco un esempio di "cattivo consiglio" da parte di uno sviluppatore senior (o di qualsiasi sviluppatore): se sono totalmente ignoranti di cosa sia l'accoppiamento lento e perché sia ​​una buona cosa, e ti viene detto di scrivere tutto il codice, diciamo, il codice - dietro un file ASPX, è ovvio che lo sviluppatore senior non ha idea e i suoi consigli non dovrebbero essere ascoltati.

Se, d'altra parte, ti sta dicendo come funziona un modulo specifico nel sistema, spesso è meglio ascoltare fino a quando, di nuovo, ciò che ti sta dicendo non sputa di fronte a principi di sviluppo adeguati.

Ecco la mia regola empirica: uno sviluppatore senior in un'azienda potrebbe semplicemente essere lo sviluppatore con il mandato più lungo; potrebbe non avere alcuna vera abilità. Sta dicendo cose che vanno contro ciò che dicono alcuni degli sviluppatori più rispettati nel tuo campo (persone con molta più esperienza di lui e che sono molto più competenti e rispettate)? Se lo è, è probabile che il suo consiglio sia negativo a meno che non ci siano circostanze molto estreme.

Aspettarsi pienamente voti / disaccordi per un punto di vista estremamente distorto.

Potrebbe essere difficile capire il punto di vista dello sviluppatore senior, e sì, potrebbe guidare le cose sulla strada sbagliata, tuttavia, quando si tratta di grandi progetti, la coerenza è più importante.

Avere 50 sviluppatori tutti seguendo i propri stili di codifica, standard, metodologie e schemi di progettazione sarebbe un vero caos. Se le cose vengono fatte male, è sempre meglio essere costantemente sbagliate rispetto a molti tipi diversi di cose sbagliate e alcune cose che sono state fatte bene.

Quando arriva il momento di eseguire la manutenzione, aggiungere funzionalità o correggere ciò che è "sbagliato", è molto più semplice se i problemi con il progetto esistente sono noti in anticipo.

È bene essere in disaccordo con rispetto, ma alla fine è meglio mettersi in fila. Chiunque faccia parte di una squadra che non va bene non viene visto come un giocatore di squadra.

Se il senior non può darti buoni motivi per cui stanno ignorando le migliori pratiche del settore, allora non perdere tempo lì. Non avanzerai mai perché sei troppo minaccioso e, comunque, vuoi passare il tempo a mantenere un mucchio di codice cattivo?

La maggior parte degli sviluppatori smette di leggere quando lasciano il college. Non l'hai fatto, quindi sei già tra i primi 10%. Ci sono molte opportunità in questi giorni. Se non c'è mercato del lavoro nella tua città, cerca una città migliore.

Wow, questa è una meravigliosa opportunità per brillare e mostrare le tue abilità. All'inizio della mia carriera, avevo qualcuno che era il mio supervisore che non era in grado di prendere una decisione, nessuna decisione, quindi ho approfittato di questa opportunità per imparare a fare il lavoro del livello superiore successivo. Mi ha promosso. Dovresti fare lo stesso.

Come sviluppatore senior questo tipo di aggressività passiva mi farebbe impazzire e dopo avermi confrontato mi spingeresti a darti una brutta recensione. La soluzione perfetta è quella con cui il team può convivere insieme.

Per quanto riguarda lo stile, questo dovrebbe essere dettato dalla tua guida di stile e dalle migliori pratiche determinate dalla tua origine. Se sei un appassionato, discuterne, ma una volta presa una decisione, convivi e lavori con i limiti della squadra in cui ti trovi.

Sei in una situazione non così buona ma, come ha sottolineato HLGEM, puoi trasformare queste posizioni in benedizioni sotto mentite spoglie. La tua domanda è multiforme, quindi la affronterò in parte.

Sospetto che non lo sappia. Allo stesso tempo, prova a mostrarmi che l'arroganza può essere così che io non mi presenti molto per domande.

Questo potrebbe benissimo essere vero. Esiste un'eruzione di sviluppatori che opera nel settore da decenni e non è in grado di guidare il software, dal punto di vista dello sviluppo o del tutoraggio (c'è una differenza). L'esperienza deriva dall'affrontare nuove sfide e provare nuove idee e apprendere nuove competenze, ma la maggior parte dei programmatori trascorre la vita in un'ala di The Corporate Office, lavorando sull'applicazione Payroll con i suoi fedeli strumenti di Visual Basic e Java, senza mai vedere il mondo correre dal loro freddo, grigio ufficio.

Non c'è niente di sbagliato in questo . Per molti sviluppatori tutto ciò che hanno sempre desiderato e si accontentano perfettamente della situazione - non è, tuttavia, una situazione ideale per favorire una futura generazione di programmatori, per non parlare degli sviluppatori principali.

Bravado e arroganza possono essere un meccanismo di difesa, che cerca di coprire le inadeguatezze. Come lo gestisci? Non affrontarlo direttamente: se il tuo vantaggio è incompetente e il capo non è disposto a correggere la situazione, dovrai conviverci . Ciò non significa ribaltarsi e morire, ma non puoi forzare qualcuno a essere un buon vantaggio.

Tuttavia, esamina solo il mio codice e la maggior parte dei suoi commenti sono correlati alle linee guida per la codifica

Questo è ciò che mi fa pensare che tu abbia ragione nel non essere un buon programmatore. Questo non vuol dire che al momento non sia un programmatore migliore di te (per lo meno avrà più esperienza ed esposizione dall'essere nel settore per così tanto tempo) ma, di nuovo, ciò non si traduce in essere un piombo efficace. Le linee guida vanno bene e sono buone, ma sono seconde alla funzione, efficacia ed efficienza del codice.

Cosa dovrei fare in tale situazione?

Ho informato il mio manager di questa situazione e gli ho chiesto di cambiare il mio esempio, anche se lui dice "sì" ogni volta, ma non intraprende alcuna azione seria.

Hai elencato tutti questi punti specifici per il gestore e con esempi specifici per eseguirne il backup? Se sei semplicemente andato da lui e hai detto: "Ho bisogno di un nuovo vantaggio", non ti prenderà sul serio e lo percepirà come un "problema interpersonale" piuttosto che un problema tecnico. La reazione di molti boss in questa situazione è di ignorarlo nella speranza che si "risolva da solo".

Ecco alcuni suggerimenti.

1. Non preoccuparti della tua situazione : la prova a fuoco, sebbene non divertente, ti insegna alcune abilità di ricerca fondamentali per la tua carriera.
2. Inizia a spingere al comando per essere più coinvolto. Fallo con attenzione e rispetto . Continua a spingere ed essere persistente fino a quando non si arrende (questo in realtà funziona per molte situazioni della vita).
3. Se il tuo lead non viene coinvolto, controlla se ci sono altri che potrebbero aiutarti. A meno che tu non stia lavorando in un negozio di sudici che si occupa solo delle ore di mungitura, la tua azienda non si preoccuperà di un altro sviluppatore con più esperienza che ti mostra alcune corde e rivede il tuo codice.
4. Inizia a tenere d'occhio un nuovo lavoro. Non direi che sei in una situazione "da lasciare", ma non sarebbe male per la tua carriera trovarsi in un posto che prende più seriamente il tuo sviluppo come programmatore.

Se si dispone di un modo migliore per fare risolvere un particolare problema, basta FARLO .

Lascia che il tuo codice / soluzione sia il miglior argomento. Altrimenti attenersi a ciò che è stato detto.

Caso in questione

quando ero un giovane ho avuto una situazione in cui una particolare sezione di codice non era la migliore che potesse essere. Piuttosto che discutere a questo proposito, ho semplicemente migliorato ALLORA ha mostrato i risultati al mio anziano. Lo ha accettato, perché il codice è sempre re.

Ovviamente come sviluppatore inesperto, potrei sbagliarmi e la sua strada potrebbe essere migliore, quindi la mia domanda è quali modi posso fare per giudicare meglio se un consiglio di uno sviluppatore senior è buono o cattivo / obsoleto.

Puoi diventare uno sviluppatore esperto. Fino a quando non lo farai, sarai mal equipaggiato per giudicare se la tua intuizione da junior era giusta o no, e per allora non avrà importanza.

Nel frattempo, leggi la risposta di Joel Etherton.

Consiglio vivamente di non provare a "non implementarlo a modo suo".

Finora sembra che tu abbia fatto la cosa giusta. Sei stato umile e hai sollevato un contrappunto. Non saprei dire dalla tua domanda se non sei semplicemente d'accordo con il suo metodo o se non sei d'accordo e hai presentato un'alternativa. In conclusione, offri sempre un'alternativa chiara e ponderata quando cerchi di abbattere l'approccio di qualcun altro . Come potrebbe vederlo, hai una buona idea che potrebbe funzionare e ha un'idea che funziona.

In qualsiasi posizione, siamo costretti a fare sempre cose non ottimali. Se davvero non ti piace, allora puoi fare come hai fatto e tirarlo su. Dopo di che, è la strada del capo o l'autostrada. Sul lato più luminoso, sei isolato da gran parte del rischio di decisioni sbagliate come junior.

Scegli te battaglie. Se stai parlando di un'ora di lavoro dovrai cambiare il tuo codice a volte fino a quando non salirai. La prossima volta che ricevi un grande progetto chiedi in anticipo la possibilità di presentare le tue idee prima di iniziare. Dedica un po 'di tempo extra e realizza una demo o un prototipo sorprendenti.

Abbastanza scioccamente quello che ho fatto è semplicemente smettere di chiedere. Quando mi viene data un'altra opzione, sto divagando e lo faccio a modo suo, ma aggiungo il mio talento. Usalo come esperienza di apprendimento per costruire le tue abilità e pacificare ancora il suo bisogno di tenerlo alla vecchia scuola.

Alla fine non tutti gli sviluppatori senior prestano attenzione a nuovi modi di fare le cose. A volte hanno modi di vecchia scuola che erano fantastici per la lingua che avevano iniziato 20 anni fa ma sono considerati hacky, o "hanno un cattivo odore" nel mondo di oggi.

Questo può sembrare un modo terribile di andare avanti, e lo è. Ma ho anche imparato molto dai miei anziani come fare le cose. Ma questa è davvero solo la mia opinione. Alla fine devi essere felice nel tuo lavoro e mantenere le distrazioni e le tensioni a un livello basso. E non obiettando alle cose vedrai che lo stress diminuisce.

Non fidarti degli anziani a causa della loro anzianità. Sfida l'autorità il più spesso possibile. Un'autorità competente dovrebbe essere in grado di rispondere in modo convincente a qualsiasi domanda. Questo è ciò che lo rende un'autorità in primo luogo, non è vero?

Perché qualcuno ha credenze superstiziose per tutta la sua vita non significa che abbia ragione. Ricorda, nel Medioevo la gente credeva che la terra fosse piatta e che alcuni di quegli asini retti si sentissero giustificati a uccidere i dubbiosi. Si è scoperto che i dubbiosi avevano ragione. Questo per quanto riguarda le recensioni negative.

Non temere mai una recensione negativa. Ti fideresti di un cieco che giudica il colore?

buone risposte sopra, aggiungerebbero che una risposta come "migliori pratiche" o "più mantenibili" è un'opportunità per imparare qualcosa . Tu dici: "Puoi darmi un esempio del perché in questo modo è meglio così posso capire la differenza?" o "In quali situazioni in questo modo sarebbe più gestibile che in qualche altro modo, così posso imparare a pianificare in anticipo in quel modo?"

Se l'anziano ha ragione, darti un esempio sarà facile. Se è un pappagallo ... dagli un cracker per fermare lo squawkin, e fai quello che pensi sia meglio. Fino a quando non ordinato diversamente.

Se il ruolo del senior è quello di mentore, spiegherà perché, quando richiesto.

Come HLGEM e Jarrod hanno detto prima, questa è davvero una benedizione sotto mentite spoglie. Entrambe le loro risposte sono fantastiche e voglio aggiungere alcuni punti.

Poiché il tuo lead non è nel tuo dominio, puoi prendere alcune delle decisioni importanti per la tua parte dell'applicazione poiché il tuo lead non conosce molto sul middleware. Hai anche la chiusura con il tuo manager su come dovrebbe andare l'applicazione, cosa vogliono gli utenti del prodotto e come il tuo manager vorrebbe affrontare una situazione presentata dal team del prodotto. Dimmi quante persone otterranno quel tipo di conoscenza su un'applicazione.

Quando fai parte di una grande squadra avrai sicuramente aiuto dai tuoi compagni di squadra e / o dal tuo vantaggio, ma non avrai la conoscenza di come pensa il tuo manager o il team del prodotto perché quel genere di cose generalmente passa attraverso il tuo esempio e può essere alcuni sviluppatori senior in una squadra. Concordo sul fatto che i progetti di una persona sono piuttosto difficili da trasportare, ma se l'altro lato della medaglia è così bello perché perdere un'occasione. Scopri cosa puoi imparare, divertiti mentre puoi e se diventa troppo difficile convincere il tuo manager come ha detto Jarrod o trovare un nuovo lavoro / progetto a seconda della situazione.

Avrai a che fare con persone del genere per tutta la tua carriera. E ce ne saranno molti con i quali non sarai d'accordo sull'approccio migliore a qualsiasi problema di codifica. La cosa migliore che penso che abbia funzionato per me nel corso degli anni è che se continuano a insistere su un problema, mettiti in contatto con loro e dì loro che hai considerato la loro soluzione tra le varie soluzioni possibili e che hai sentito che la soluzione deciso su quello che pensavi fosse l'approccio migliore in questa situazione.

Ora, se scegli contro il loro consiglio ogni volta, allora di tanto in tanto potresti dover cedere e usare il loro "consiglio" di tanto in tanto solo per lisciare alcune piume arruffate. Finché non sentono che stai respingendo il loro contributo ogni volta, allora questo farà molto per mantenere la pace tra di voi.

Considera anche che sono uno sviluppatore senior e hanno lavorato in quell'ambiente per più tempo di te. La codifica della vita reale spesso non coincide con le migliori pratiche o gli standard accettati dalla comunità. Potrebbe esserci una ragione per cui ti hanno raccomandato di fare qualcosa in un certo modo che non sono in grado di articolare completamente. Quindi, anche se non sei d'accordo con loro, assicurati di non scartare i loro consigli in maniera diretta solo perché credi che la tua soluzione sia migliore.

Si tratta di equilibrio. E non solo l'equilibrio dei codici, ma l'equilibrio delle squadre. Molti progetti non sono andati a buon fine non perché gli sviluppatori non erano in grado di farlo, ma perché non riuscivano a trovare modi di lavorare amichevolmente insieme.

Vorrei fornire alcune cose della mia esperienza personale, che dovrebbero essere considerate come una risposta supplementare a quella pubblicata qui da jzd ...

1. Chiedi a un altro sviluppatore senior,
2. Fai ricerche per conto tuo.

In un appuntamento professionale, avrei dovuto essere guidato da qualcuno di alto livello. Conosceva alcune cose, ma onestamente non molto, sfortunatamente non lo sapeva, quindi era estremamente fiducioso nelle sue risposte. In qualche modo ho sentito che quello che aveva detto era sbagliato. Ho avuto alcune prove quando le cose che ha fatto erano contro le migliori pratiche menzionate nella certificazione MS che ho preso :-). Dopodiché ho iniziato a chiedere ad altre persone che lavoravano in altre società (stackexchange non era attivo e funzionante all'epoca) e ho iniziato a leggere blog per confrontare le risposte.

Sarebbe bello se mi sbagliassi, perché cambierei il mio comportamento, ma non lo ero.

Ho notato qualcosa negli ultimi anni, quasi tutte le aziende in cui mi trovo, con quasi tutti i progetti a cui lavoro, quasi ogni nuovo assunto (indipendentemente dal livello di abilità / esperienza) vuole fare qualcosa di "diverso".

Potrebbe essere gli standard di codifica o l'architettura generale o il linguaggio o la metodologia. Ma è sempre qualcosa. Molte volte, sta solo affermando l'ovvio, "Non dovrebbe essere tutto documentato meglio, per i nostri utenti finali?"

Il mio consiglio è di non essere quel ragazzo .

Un giorno, sarai un ragazzo di livello senior che viene assunto e pagato per prendere quelle decisioni. Quando arriverà quel giorno, andateci! Fino a quel giorno, renditi conto della tua posizione. Ho un capo, per quanto mi riguarda il mio intero lavoro è rendere felice il mio capo. Non serve a indovinare le decisioni prese al di fuori del mio grado di remunerazione. Se non sei davvero sicuro, parla con il tuo capo / supervisore e scoprilo.

In generale, tuttavia, è molto meglio avere tutti a bordo con un approccio obsoleto rispetto a metà del team che segue un approccio obsoleto, 1/4 del team che segue un nuovo approccio e 1/4 del team che cerca di sviluppare un approccio all'avanguardia , approccio nuovo di zecca.

C'è una corrente sotterranea in tutti questi che penso dovrebbe essere messa in evidenza in modo chiaro: non essere combattivo . Preserva il tuo rapporto con lui. È bello prendere il suo consiglio con un granello di sale e convalidarlo in libri e in siti come questi, ma non attaccarlo. Se è uno sviluppatore senior e ha passato molti progetti, non è un idiota e c'è molto da imparare da lui. Come sembra che tu abbia già fatto, esprimi il tuo desiderio di capire il suo punto di vista. Anche se sei sicuro che abbia torto e hai ragione, accetta la possibilità del contrario (sembra che tu lo capisca già). Cerca di chiarire che stai discutendo perché vuoi capire meglio il suo punto di vista, non perché stai provando a dimostrargli che ha torto.

Se non ti risponde immediatamente quando gli fai una domanda, o se la sua risposta è vaga e / o inutile, non dare per scontato che ti stia facendo saltare. Come è già stato menzionato qui, potrebbe essere impegnato e / o stressato.

È anche bello essere pazienti. Tieni un elenco di cose che ritieni debbano essere fatte diversamente e presentale al momento opportuno. Assicurati di avere una giustificazione per il suggerimento oltre a "è la migliore pratica". E fai attenzione a fare le cose bene e a non commettere errori, in modo da avere credibilità quando fai le tue discussioni in seguito.

Finora ho cercato di evitare il problema ascoltandolo, sollevando un contrappunto, innalza nuovamente il suo punto originale (il più delle volte dirà best practice, più mantenibile ma non è andato oltre), I. .. pensaci a casa, ma ... non sono ancora convinto. Ma recentemente ... ha visto il mio codice e mi ha chiesto perché non l'ho modificato nel suo suggerimento. Questa è la terza volta in 2-3 settimane.

(Leggermente modificato per le azioni.)

Questa parte mi riguarda. Un modo per vedere se hai ragione o no è capire cosa sta dicendo. Quello che leggo (con la mia storia, altri potrebbero essere diversi) è uno sviluppatore junior che non capisce cosa dice il mentore e non chiede chiarimenti. Un modo per capirlo è chiedergli di chiarire: come è una pratica migliore di quella? Oppure perché è più gestibile di quello per il nostro codice? Se non conosci le sue risposte a questo, non sai davvero se sta dando buoni consigli o no.

La parte che mi preoccupa davvero è che ti ha chiesto di cambiarlo più volte e tu no. Ecco un modo in cui potrebbe apparire dalla sua parte: ti chiede di apportare il cambiamento, ti chiedi perché, ti dà una ragione (valida, secondo lui) e ti rifiuti di fare il cambiamento. Non chiedi chiarimenti, quindi suppone che tu capisca il motivo e che sia troppo pigro o troppo testardo per cambiarlo - né una cosa buona per uno sviluppatore senior da pensare a te. Fidati di me, è molto meglio fare domande piuttosto che ottenere una reputazione in questo modo.

Alcuni pensieri:

1 / Funziona? Sta lavorando o no? C'è qualche ragione oggettiva per cui la sua strada sarebbe inferiore?

Per ragione oggettiva, intendo qualcosa che può essere misurato senza ambiguità (prestazioni, bug, lunghezza del codice ...) Se le sue soluzioni funzionano e non esiste una metrica oggettiva che indichi che è una soluzione scadente, fallo a modo suo. La sua strada è migliore ... perché probabilmente è più coerente con il resto della base di codice e perché sarà più facile per lui usare / riutilizzare il tuo lavoro. Potrebbe non piacerti, ma non è di questo che si tratta, vero?

Se non funziona o non funziona correttamente su metriche importanti, implementala, confronta la sua soluzione con la tua soluzione, quindi digli che hai provato a fare la sua strada, ma non riesci a farla funzionare bene (fornisci le metriche) e chiedigli se hai commesso un errore nella tua implementazione o se c'è un requisito di cui non eri a conoscenza

I programmatori 2 / Star dicono ... Perché me ne frega niente? Troverai programmatori famosi profondamente in contrasto tra loro su molti argomenti fondamentali come pianificazione, progettazione, OOP vs procedurale, unit test, gestione delle eccezioni, controllo del codice sorgente, e così via.

Se l'unica differenza nella lavorabilità tra 2 soluzioni è chi la favorisce, saltala. Potresti trarre beneficio dall'allenamento mentale richiesto lavorando in un paradigma che non ti piace

Sulla base dell'idea che dovresti ricevere consigli solo dalle persone che vuoi diventare, la risposta è che il consiglio senior è buono se vuoi diventare come lui / lei.

La maggior parte dei miei problemi che ho risolto inviando messaggi ai forum e ricevendo risposte da altri, e sono sopravvissuta per circa 1 anno in questo modo.

Cosa devo fare in tale situazione?

Ad essere onesti, ecco come sono molti lavori tecnici. Devi essere un auto-iniziatore che può risolvere da solo i problemi difficili (con l'aiuto se Internet e i suoi abitanti) se devi.

Dal punto di vista di ottenere revisioni del codice e ottenere aiuto con i progetti architettonici, anche quando ho avuto dei bravi gestori non ho mai avuto gran parte di una revisione del codice al di là di "le variabili statiche dovrebbero essere precedute da un s_".

Cogliere l'occasione per imparare e imparare come imparare; quelle saranno abilità che puoi usare in futuro.

Se pensi per un secondo che la direzione non capisce quanto sei davvero DAVVERO capace di portare a termine il lavoro, allora probabilmente ti sbagli. Il management probabilmente capisce anche che il tuo vantaggio in questo momento sarebbe completamente inutile se ti sostituisse e prendesse il posto del tuo lavoro.

Le ragioni REALI che non ti hanno trasferito sono perché, nonostante tutte le sfide che ti presentano, sei ancora la persona migliore per il lavoro. Ovviamente apprezzano troppo il tuo lavoro per rischiare di consegnarlo a chiunque altro.

Non sottovalutare l'intelligenza del management ...

Sono molto più intelligenti di quanto la maggior parte degli sviluppatori attribuisca loro credito. Non l'ho capito fino a quando non ho iniziato a gestirlo. Probabilmente sono anche consapevoli di quanto sia davvero inutile il tuo vantaggio, ma probabilmente non sono in grado di affrontare questo problema.

Lascia che ti faccia un quadro, il Lead A con 5 anni di esperienza in azienda è incompetente. Il manager lo sa, raccomanda al suo superiore di licenziare il capo A. Il dirigente superiore chiede perché non è stato trattato anni fa se è così incompetente. Il manager sembra male adesso soprattutto perché il Lead A ha uno stipendio gonfio che è stato pagato per nessun beneficio ...

Ecco un altro scenario potenziale, il Lead A è stretto amico di qualcuno importante. È troppo caldo politicamente per affrontare,

Ad ogni modo, con un errore di lunga data come quello che è più facile per le grandi organizzazioni spazzare sotto il tappeto persone non competenti, dare loro un lavoro impegnato e un potere falso che è appropriato per i loro anni di "esperienza" in cui non possono fare TROPPO MOLTO danno . Sfortunatamente molte organizzazioni preferirebbero fare questo, quindi effettivamente affrontare i problemi.

Ovviamente la ragione di ciò è che il manager in questo tipo di organizzazione è sempre meglio a breve termine per affrontare i cattivi talenti in questo modo piuttosto che affrontare i problemi a lungo termine che questo tipo di persone possono portare all'organizzazione.

Quindi, sebbene sia miope e potenzialmente non etico, devi ammettere che è un po 'più intelligente di quanto molti sviluppatori riconoscano effettivamente.

eh ahhh. Questa domanda mi ricorda molte cose. Prima di tutto dirò che non potrei andare d'accordo con uno dei dirigenti del mio ultimo posto di lavoro. Non è stato un problema di personalità. Era un problema di comunicazione. Ho detto XYZ e quel manager specifico avrebbe interrotto quello che stavo dicendo come ABC. Non sarei in grado di comunicare bene se non avessi lavorato con quel manager per più di un anno.

Lo scorso weekend. Un ragazzo ha discusso / non è d'accordo con me sui singoli. Ho detto che non sono buoni e non dovrebbero MAI essere usati e assolutamente nessun motivo per usarli. L'ho collegato a http://www.gmannickg.com/?p=24 e all'articolo più approfondito a cui si collegapochi giorni dopo l'argomento. Il giorno in cui un altro programmatore (DudeB) menziona che usa i singleton solo quando è appropriato (a cui ho aggiunto "mai"). DudeB non ha detto nulla a riguardo, ma DudeB ha detto che DudeB era in un progetto che aveva una contesa di memoria perché tutti i thread stavano accedendo al singleton. Dopo aver menzionato questo, mostrando l'articolo e menzionando la contesa con la memoria, il ragazzo con cui ho discusso ha detto che dovremo essere d'accordo sul fatto che non sono d'accordo perché non mi piace parlare di singoli (ma sto scrivendo questo d'oh)

Il punto è. A volte potresti avere torto come questo (forse qualcuno non sarà d'accordo con i singoli in un commento). Nella mia situazione con il mio manager che era il mio programmatore senior, ho appena fatto ciò che mi è stato esplicitamente chiesto di fare e non ho mai più preso seriamente la qualità in quel posto di lavoro. Ho fatto quello che preferivo fare quando mi è stato permesso, ma ho sempre fatto quello che mi era stato chiesto di fare, ma se non fossi d'accordo, lo farei almeno una volta.

Ho un'opinione completamente diversa / controversa su questo.

Spesso le persone perdono traccia dell'obiettivo finale che per la maggior parte dei settori si tratta di massimizzare i profitti e minimizzare le perdite. So che sembra senza cuore (quindi i punti negativi) ma l'esperienza e la sagacia contano molto poco se non si producono risultati.

Le persone possono rimanere coinvolte in cose estremamente indirette di cui discutere, che hanno un impatto molto scarso sui risultati diretti dell'azienda.

Se pensi di avere ragione su qualcosa, la soluzione migliore è mostrare come ciò produrrà risultati misurabili migliori .

Inizialmente proverei a metterlo in evidenza, alla fine della giornata la resistenza all'anziano sarà probabilmente futile almeno fino a quando non acquisirai più esperienza e rispetto. Usalo come esperienza di apprendimento e tra 2+ anni se ti senti ancora allo stesso modo - passa a un'altra azienda. Questo è quando puoi usare una combinazione delle tue buone idee e dei tuoi anziani per impressionare il tuo nuovo datore di lavoro. Ovviamente potresti iniziare a capire alcune delle ragioni di quelle che hai percepito come decisioni sbagliate all'inizio della tua carriera e ad un certo punto potresti avere uno sviluppatore junior che lavora per te.

[Repost: perché in qualche modo ho creato un secondo account qui]

Ma recentemente, mi ha avvicinato ancora una volta, ha visto il mio codice e mi ha chiesto perché non l'ho modificato nel suo suggerimento .

Dovresti essere chiaro se si tratta di suggerimenti o ordini / istruzioni / direttive / qualunque cosa.

Suggerimento = Penso che sia meglio farlo in questo modo; ma è una tua scelta.

Ordine / etc. = Voglio che sia fatto in questo modo; ed è la MIA scelta.

Se è davvero un suggerimento, fai come desideri e lascia che il tuo codice rimanga. Se è un ordine (e questo mentore ha autorità su di te in questo modo), fai come si dice.