È una buona idea un consiglio dei programmatori senior sull'uso sempre dei libri? [chiuso]

Sono uno sviluppatore junior e sono stato nel settore per 5 anni. Nella mia attuale compagnia c'è un anziano, chiamiamolo Infesto. A volte mi viene data l'opportunità di brillare e fare qualcosa di completamente nuovo da zero.

Uno degli esempi più recenti è stato che ho dovuto creare un singleton nell'applicazione multithread. Ho deciso di utilizzare questo metodo. Non appena lo vide Infesto, cominciò rapidamente a chiamarmi stupido e mi disse di usare questo approccio . Dopo avergli chiesto perché lo ha appena spazzato via perché è meglio ed è così che questo e questo libro su Java dicono che è meglio.

Ed è uno schema comune: ogni volta che ho la possibilità di fare qualcosa di nuovo, vengo rapidamente abbattuto da Infestus e l'unico motivo per cui il suo metodo è migliore è perché quei libri sono stati scritti da famosi programmatori. Cerca sempre di darmi libri da leggere in modo che io possa "imparare" quali modi programmare.

Sto programmando denaro da 5 anni, ma è sempre una buona idea seguire ciecamente il libro sui modi migliori per risolvere un problema o dovrei provare a sperimentare di tanto in tanto? La costante raffica di lamentele da parte dell'Infesto sta iniziando a farmi non provare mai nulla di nuovo e seguire esempi nei libri.

EDIT : sono completamente perso. Sì, lo so che seguire qualcosa alla cieca è una cattiva idea. Ma questo programmatore divino Infesto che sembra sapere molto, mi dice che l'unico modo per programmare correttamente è leggere libri e seguire tutto fino a un T. Tutte le regole che impone sono quelle scritte nei libri, quindi mi sto solo chiedendo se i libri sono l'unico modo corretto.

EDIT2 : Infestus non è il mio capo. È solo uno degli sviluppatori senior incaricato di rivedere il codice. E la maggior parte dei suoi commenti dopo le recensioni consistono in nomi di libri in cui tale e tale metodo sono sbagliati.

Incontrerai programmatori come questo per tutta la tua carriera. Non c'è nulla di sbagliato nella sperimentazione e nell'apprendimento da soli. Sicuramente i libri sono fantastici. Molte volte gli esempi funzionano in un ambiente pulito, ma se si è sviluppatori per un'altra azienda non esiste un ambiente pulito (senza interferenze da parte di altri).

È sempre bello sapere come fare le cose nel modo "giusto", ma le opinioni cambiano di anno in anno. Quindi impara cosa puoi. Prendi ciò che puoi dallo sviluppatore senior, fondilo con la tua conoscenza che impari da solo. Alla fine, sarai uno sviluppatore senior e trarrai vantaggio da queste esperienze e insegnando agli sviluppatori junior.

Basta non essere un coglione a riguardo.

Ha davvero chiamare voi stupidi, o ha fatto solo denigrare il codice? Chiamare qualcosa di stupido è senza tatto, ma ciò non invalida il suggerimento. Penso che Infesto abbia dato un prezioso suggerimento e in futuro dovresti considerare seriamente i suoi suggerimenti. Sembra leggere molto, e almeno in questo caso la sua opinione è ben informata. La sincronizzazione è sia costosa che complicata. L'implementazione raccomandata è più efficiente e più semplice della tua ed è garantita per funzionare.

Cerca sempre di darmi libri da leggere in modo che io possa "imparare" quali modi programmare.

È gentile da parte sua. Sta attivamente cercando di aiutarti, ma sembra che tu stia lasciando che il tuo ego si frapponga. Non prendere sul personale le critiche al tuo codice. Il codice è economico da produrre e facile da cambiare. Se qualcuno ti mostra un modo più semplice di fare qualcosa, ringrazialo.

E sì, la lettura ti renderà un programmatore molto migliore. Tutti gli esperti che ho conosciuto hanno letto ampiamente. Se non stai leggendo molto, allora sei mediocre, e in altri cinque anni potresti scoprire che non sei più commerciabile.

Leggere un libro non dovrebbe essere cieco: l'autore dovrebbe cercare di convincerti dei meriti del suo approccio mentre lo presenta. È ragionevole per il tuo senior indicarti un libro che spiega il suo approccio preferito, piuttosto che chiedergli di spiegarlo da solo: anche se dovrebbe essere in grado di spiegare i benefici delle sue preferenze senza fare affidamento sul libro, è anche una duplicazione degli sforzi che l'autore del libro ha già realizzato.

Quindi, leggi il libro, vedi cosa dice l'autore del libro, e se ti confonde, o vuoi confermare la tua comprensione, o non sei d'accordo, allora parla con il tuo senior, ma ora sarai in grado di avere una discussione più produttiva.

Ci sono tre elementi chiave per ogni relazione sana. Comunicazione, onestà e fiducia. Ciò vale per tutte le relazioni, anche quelle lavorative. Dovresti parlare con il tuo supervisore di queste preoccupazioni.

Se non capisci le sue ragioni per sostenere un certo disegno, allora diglielo . Digli che non hai letto il libro e che vorresti capire perché il suo modo di farlo è migliore. La chiave è che dovresti cercare di capire il suo modo di fare le cose.

Penso che dovresti anche trattare questa persona con più rispetto. Nella tua testa, lo stai chiamando nomi sprezzanti e criticando il suo approccio a ciò che pensi di "apprendimento". Attenzione per quello. D'altra parte, hai detto che ti ha chiamato stupido. Non è bello, e dovresti dirgli che non è bello chiamare qualcuno stupido.

Le idee possono essere stupide. Tutti commettiamo errori e perdiamo cose, anche i ragazzi più anziani. Quando c'è un difetto in un design, la migliore domanda da porsi è "Perché lo stai facendo in questo modo? Non si romperà nella situazione X, Y, Z? Il design B non sarà migliore?"

Tieni presente che stai lavorando a questo software con altre persone. È un'abilità difficile da imparare. Non importa che non stai scrivendo nulla da zero, c'è sempre spazio per brillare rendendo il tuo codice il miglior codice possibile.

E "migliore" molto spesso significa leggibile e comprensibile . Noi programmatori passiamo molto tempo a leggere il codice di altre persone. Se quel codice è chiaro e leggibile, ciò rende il codice davvero prezioso. Uno dei modi in cui impariamo a scrivere un ottimo codice è leggere un sacco di buon codice. Molto spesso trovi un ottimo codice nei libri. Quindi leggere uno o due buoni libri di programmazione probabilmente ti renderà un programmatore migliore.

Nella società in cui lavori, probabilmente lo è. Questo è ciò che ti richiedono di fare.

Questo ingegnere Infesto fa un pessimo lavoro educando gli sviluppatori junior dicendo loro "questo è scritto nel libro, ed è per questo". Non è un predicatore, è un ingegnere e dovrebbe essere in grado di scomporlo e presentare i concetti in modo che i giovani possano imparare dalla sua esperienza.

Ti incoraggio a parlare con sviluppatori esperti nella tua azienda, porre loro domande sui pro e contro di diverse tecniche di programmazione ecc. Questo insieme a leggere libri e blog (consiglierei Joel su Software - solo Google, è un must) dovrebbe darti una migliore comprensione.

IMHO, ci sono 2 aspetti qui, che dovresti trattare separatamente:

• Il fatto che il ragazzo sia un coglione, ti chiama nomi e semplicemente perché può (è più anziano, non lo sei, se uno di voi si lamenta dell'altro, otterrà il beneficio del dubbio) è semplicemente comportamento da bullo e semplicemente cattivo.

Cerca di non abbassarti al suo livello con questo. Non cercare di maltrattarlo o di "dirlo" al capo o altro. Fai del tuo meglio per ignorare questo aspetto del suo comportamento, tenendo presente che diventa troppo estremo (cioè se influenza la tua produttività e simili) dovresti fare qualcosa al riguardo.

• Il fatto che ti sta dicendo che il tuo codice è errato (e come farlo nel modo giusto). Onestamente da ciò che descrivi, ignorando il tono del ragazzo, questo aspetto del suo comportamento non è poi così male. Impari le cose molto più velocemente e riesci a vederle nel giusto contesto quando hai qualcuno più esperto che ti corregge e ti dice non solo cosa hai fatto di sbagliato, ma anche come farlo nel modo giusto (rispetto al solo impararle tutte da solo da esperimenti personali di prova / errore e simili).

Molte volte ho avuto qualcuno corretto quello che inizialmente pensavo fosse "il mio codice perfetto" e mi sono solo arrabbiato che il ragazzo mi stesse dicendo cosa fare solo per poi rendermi conto che aveva sempre ragione, la mia versione era cattiva, la sua era bene, e grazie a Dio l'ha visto! :) Quindi ho imparato a mitigare i miei impulsi iniziali di "hey, non puoi dirmi cosa fare, errore!" e invece, ogni volta che qualcuno mi corregge, per prima cosa ricontrollo davvero, oggettivamente, il mio codice, quindi controllo il suo, e mi assicuro che non sia davvero giusto e sono io a fare l'errore. Se è stata colpa mia, lo ringrazio per l'aiuto e mi assicuro di capire davvero come funziona la sua soluzione (piuttosto che semplicemente copiarla / incollarla).

E hey, a volte trovo che la correzione offerta fosse in realtà peggiore di quella che ho fatto inizialmente, a quel punto provo a parlare tutto questo con l'altro ragazzo. Onestamente, ho notato che nulla guadagna il rispetto degli altri per te più velocemente di quando vedono che puoi accettare di essere corretto quando hai fatto un errore, ma allo stesso tempo, non hai paura di dire che sei tu chi ha ragione quando pensi che sia così, dato che puoi immediatamente dimostrare di basare la tua affermazione su qualche ricerca reale, e non solo sull'ego.

Su questo punto, penso che dovresti davvero provare a parlare con il ragazzo di ciò che propone, di ciò che proponi e così via. Mostragli ciò che pensi, come sei arrivato a una soluzione particolare e perché pensi che sia meglio del suo (quando pensi onestamente e obiettivamente che lo sia). Oppure, se scopri che la sua proposta è migliore della tua, diglielo, esprimi il tuo apprezzamento per l'aiuto. Questo potrebbe ricostruire alcuni ponti bruciati.

Sperimenta da solo e impara tutto ciò che puoi. Dopo aver letto abbastanza libri, scoprirai che ci sono più libri su argomenti particolari e che potrebbero contraddirsi a vicenda. Prova quello che ritieni migliore e provali entrambi se hai tempo o vuoi confrontare / contrastare.

Trattare con il tuo capo è un argomento e un approccio completamente diversi. Se volessi che qualcuno facesse qualcosa esattamente come in un libro, glielo direi. Sono solo io perché non mi associo ai lettori della mente. Il tuo capo lo rende un'abitudine, chiedi solo se ti consiglia libri o riferimenti quando ricevi un nuovo progetto.

Qualunque cosa tu faccia, non smettere di lavorare su nuovi progetti. So che è facile per tutti noi dare consigli su come affrontare questa situazione e possono o meno funzionare, ma tu sei colui che deve conviverci e subire la negatività. Stai andando a migliorare, ma di solito viene dalla scrittura di più codice su cose nuove, dall'apprendimento di successi e fallimenti.

Seguire i libri alla cieca è una cattiva idea, ma c'è una differenza tra seguire esattamente un libro e seguirlo alla cieca .

Quando stai cercando di capire le cose in un libro, in genere è opportuno seguirle esattamente all'inizio, mentre hai un'idea di ciò che sta cercando di insegnarti. Le probabilità sono che non capirai ancora tutto quando hai finito, ecco come vanno le cose come questa di solito, ma seguire il libro esattamente all'inizio ti darà qualcosa da sperimentare, mentre cerchi di capire le tue domande. Le probabilità sono di nuovo buone che troverai modi in cui non sei d'accordo con ciò che è nel libro, ma avrai una comprensione dei problemi che il libro stava cercando di affrontare, in modo che quando arriva il momento di scrivere il tuo codice, puoi affrontali a modo tuo (o forse a modo loro, almeno in parte) piuttosto che lasciare questi problemi per morderti in seguito.

Un'altra cosa che non è intrinsecamente specifica per Java, ma è particolarmente comune in quella comunità. Penso di poter indovinare di quali libri stai parlando, e formano una parte importante del lessico della comunità Java. Comprenderli e i modi in cui descrivono le cose, aiuteranno immensamente quando è necessario comprendere altro codice Java che si trova. È un'abilità preziosa a sé stante.

Leggere libri e post di blog è molto utile nella programmazione. Ci sono alcuni libri che tutti gli sviluppatori dovrebbero leggere.

Tuttavia i libri non sono l'unica fonte per apprendere concetti e tecnologie di programmazione diversi. Oggi la formazione basata su video on demand sta diventando molto popolare. Puoi controllare Pluralsight , che offre formazione di alta qualità ai professionisti.

In effetti, se leggi solo libri che non aiuteranno neanche. Oltre a leggere ci sono anche altre cose che dobbiamo fare. Puoi trovare maggiori dettagli qui .

Dovresti chiedergli cosa c'è di sbagliato in particolare nel tuo metodo. Se non è in grado di rispondere chiaramente, potresti essere abbastanza sicuro che sia solo un ragazzo comune a cui piace sentirsi superiore.

La cosa sui libri è che, per lo più, passano attraverso le revisioni, che hanno maggiori possibilità di individuare cattive pratiche e idee sbagliate. Inoltre, i "grandi nomi" sono persone con esperienza che si affidano all'essere bravi per guadagnare soldi extra vendendo libri, quindi, ci sono alcune garanzie di qualità minima su ciò che dicono.

Detto questo, leggere libri, documenti e altre fonti è un buon modo per crescere come professionisti, ovviamente, quando confermato dalla pratica. Quindi, è bene che tu legga quei libri (anche quelli consigliati da Infestus). Tuttavia, i libri devono principalmente ampliare la tua comprensione sull'argomento, poiché quasi sempre ci saranno altri modi per risolvere lo stesso problema.

Riguardo al tuo approccio "vai da solo", il punto è: puoi sostenere il tuo punto di vista? Come dimostrate che la vostra soluzione è migliore di qualsiasi altra? Alcune volte puoi escogitare soluzioni brillanti da solo, ma, rispetto ad altre soluzioni conosciute, devi essere in grado di discutere il motivo per cui le tue sono migliori, poiché gli altri hanno a loro favore, almeno, i casi d'uso. Quindi, sii creativo e riflessivo, ma soprattutto, sii efficace.

Se lo fossi, leggeresti quei libri. Questo ti aiuterà dandoti più argomenti e, allo stesso tempo, potresti scoprire che Infesto - forse - sta prendendo erroneamente quei libri come argomenti, e non è stato ancora individuato perché nessuno conosce il contenuto di quei libri. Oppure potresti scoprire che in realtà k

La mia esperienza è che, quando si è preoccupati della programmazione dell'argomento, la qualità e la presentazione delle informazioni con spiegazioni adeguate nei libri è di gran lunga migliore rispetto alla ricerca delle stesse informazioni sull'argomento su Internet. Internet spesso manca di spiegazioni, contesti e qualità adeguati.

La quantità di tali informazioni su Internet è maggiore.

Quindi la mia strategia generale è quella di imparare dai libri per ottenere una comprensione più profonda e successivamente imparare da Internet per essere esposto a diverse installazioni e ampliare la mia esperienza (e spesso vedere come non fare cose).

Vorrei ricercare i meriti di ogni approccio e giungere al tuo giudizio. Se ritieni che il tuo approccio sia migliore, discuterne con Infestus fino a quando uno di voi non convince l'altro. Se non riesci a raggiungere un accordo, puoi chiedere un secondo parere o semplicemente accettare l'approccio di Infestus, a seconda di quanto ti senti fortemente a riguardo.

Nel caso dei singoli, un argomento che potresti fare contro l'approccio enum è che gli enum non possono estendere le classi. Scrivo spesso codice in questo modo:

public class DateSerializer extends AbstractSerializer<Date> {
  public static final DateSerializer SINGLETON = new DateSerializer();

  private DateSerializer() {}

  public byte[] serialize(Date date) { ... }
}

Questo non può essere fatto con enumerazioni. Poiché l'approccio enum non funziona in tutti i casi, si potrebbe sostenere che, per motivi di coerenza, dovrebbe essere evitato anche quando non è necessaria una extendsclausola.

Alcuni altri argomenti che potrebbero essere fatti contro l'uso di enum:

• è un trucco - sta usando enum per qualcosa a cui non erano destinati
• è fonte di confusione per i lettori che non l'hanno mai visto prima

Faccio fortemente affidamento sui libri come fonte di conoscenza - queste sono basi eccellenti e penso che Infesto abbia ragione nel fatto che dovresti consumare quantità significative di libri nel tuo tempo libero poiché accelerano davvero le tue abilità. I libri non sono l'unica fonte di informazioni che penso che dovresti consumare: partecipa al tuo gruppo di utenti locali, ricevi le newsletter tecnologiche pertinenti nella tua casella di posta, leggi i blog.

Non sono d'accordo, tuttavia, con l'affermazione che, poiché è scritto in un certo modo in un libro, è come deve essere fatto. Sì, i libri forniscono ottimi consigli e sono scritti da esperti e sottoposti a revisione paritaria da parte di esperti, ma essendo stato coinvolto in un libro relativamente semplice, posso dirti che in genere ci vogliono almeno due anni per finire per scrivere, modificare e pubblicare un libro . Il ritmo del cambiamento tecnologico è rapido e i consigli di due anni fa potrebbero non essere più consigli corretti per oggi. Le entità generiche spesso resistono alla prova del tempo, ma l'ottimizzazione di un'attività specifica può essere invalidata con un nuovo bit di hardware o una nuova versione del software.

Il suggerimento di chiedere a Infestus di esaminare i suggerimenti con te è eccellente: vai via, leggi tutto e torna con una serie di domande ponderate a cui hai già provato a rispondere / risolvere insieme a prove a sostegno del tuo metodo.

Ci sono state domande sul fatto che dopo 5 anni perché eri ancora un giovane. Per me, la misura chiave del fatto che qualcuno sia un minore non è anni di esperienza, ma quanto richiedono l'alimentazione con il cucchiaio. Mi aspetto che uno sviluppatore di medio livello sia relativamente autosufficiente, un consumatore attento di fonti di conoscenza che può agire su di esso ed estenderlo alla sua situazione. Dovrebbero anche essere nella fase in cui possono iniziare a insegnare ai giovani perché hanno una solida comprensione del loro argomento in modo da poter spiegare chiaramente le cose. L'altra competenza fondamentale è la fiducia: se hai svolto il lavoro, letto le cose e prodotto qualcosa di decente, non aver paura di difenderla in un tribunale di dibattito poiché un junior richiede una convalida, uno sviluppatore richiede consenso.

Mettere da parte le maniere sul posto di lavoro, mettere da parte la realtà di un ruolo di mentore che gli sviluppatori senior hanno, mettere da parte il tuo desiderio di esplorare, mettere da parte il comportamento offensivo e mettere da parte i feticci per i libri ...

Gli scopi di una revisione del codice in un team sono 1) per convalidare il codice e 2) per garantire che la persona che scrive il codice comprenda il significato alla base del miglioramento del codice. Non è il posto dove dire "cambia questo perché Martin Fowler lo ha detto nel libro GoF". Tuttavia, è il posto dove dire "cambia questo perché [breve spiegazione]; ci sono più dettagli che ne discutono nel libro del GoF".

Se il tuo sviluppatore senior non sta fornendo, almeno in modo semplice e sottile, una spiegazione per un cambiamento, e insistendo sull'uso della verbosità di "a causa di [libro]", sta diventando un po 'un furbo e un idiota. Come lo gestisci? Menzionalo verbalmente in una riunione di gruppo e chiedi ai tuoi compagni di fornire una o due dichiarazioni che spiegano brevemente il vantaggio o la necessità del cambiamento, insieme a quel utile riferimento di libro. Assicurati di ringraziarlo per il riferimento del libro.

Ammettilo, il tuo obiettivo è quello di apprezzare il suggerimento di cambiamento e di non essere demotivato per il tuo compito o il tuo lavoro. Diglielo. "Apprezzerei maggiormente il suggerimento di modifica se potessi descrivere brevemente il vantaggio o la necessità della modifica quando rivedi il mio codice; dato che sto trovando i riferimenti del tuo libro da solo per essere un po 'demotivante."

Se continua a rifiutare di fornire una semplice spiegazione con i riferimenti dei suoi libri, se è possibile fornire un altro libro o una risorsa di uguale o maggiore notorietà nel settore con un'opinione diversa e corrispondente al proprio scenario, si potrebbe essere in grado di aggiungere il proprio libro riferimento nel commento della recensione in considerazione del mantenimento del codice originale. Fallo abbastanza volte, potrebbe arretrare. Fai molta attenzione che la contro-argomentazione sia giusta e significativamente più importante; va bene lasciare che uno sviluppatore senior si sbagli e faccia ancora strada, questo è qualcosa che ho imparato e continuo a dover imparare.

Direi che imparare la programmazione solo dai libri è impossibile, ma quelli buoni ti daranno una spinta enorme. È come il karate: non otterrai la cintura nera solo a leggerlo;) Credo che in questo caso partucolare Mr. Infestus si riferisse a "Effective Java" di Joshua Bloch. È davvero un ottimo libro sullo sviluppo di Java e dovresti sicuramente leggerlo se non lo hai già fatto.