I senior programmers consigliano di usare sempre i libri una buona idea? [chiuso]

Ti imbatterai in programmatori come questo per tutta la tua carriera. Non c'è niente di sbagliato nella sperimentazione e nell'apprendimento da soli. Certo, i libri sono fantastici. Molte volte gli esempi funzionano in un ambiente pulito, ma se sei uno sviluppatore 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 quello che puoi dallo sviluppatore senior, mescolalo con le tue conoscenze che impari da solo. Alla fine, sarai uno sviluppatore senior e tratterai da queste esperienze e insegnando agli sviluppatori junior.

Basta non essere un idiota a riguardo.

Ti ha davvero chiamato tu stupido, o ha semplicemente denigrato il codice? Chiamare qualsiasi cosa stupida è priva di tatto, ma ciò non inficia il suggerimento. Penso che Infestus abbia dato un suggerimento prezioso, 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. La sua implementazione consigliata è più efficiente e più semplice della tua e garantisce il funzionamento.

He is always trying to give me books to read so that I may "learn" which ways to program.

Questo è gentile da parte sua. Sta cercando attivamente di aiutarti, ma sembra che lasci che il tuo ego si intrometta. Non criticare personalmente il tuo codice. Il codice è economico da produrre e facile da modificare. Se qualcuno ti mostra un modo più semplice di fare qualcosa, ringraziali.

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

Leggere un libro non dovrebbe essere cieco: l'autore dovrebbe cercare di convincerti del merito del suo approccio mentre lo presenta. È ragionevole che il tuo anziano ti indichi un libro che spiega il suo approccio preferito, piuttosto che chiedergli di spiegarlo da sé: anche se dovrebbe essere in grado di spiegare i benefici delle sue preferenze senza fare affidamento sul libro, è anche una duplicazione di sforzi che l'autore del libro l'ha già fatto.

Quindi, leggi il libro, guarda cosa dice l'autore del libro, e se ti confonde, o vuoi confermare la tua comprensione, o non sei d'accordo, parla con i tuoi superiori a riguardo, ma ora tu Sarò in grado di avere una discussione più produttiva.

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

Se non capisci le sue ragioni per sostenere un determinato design, allora digli che . Digli che non hai letto il libro e che ti piacerebbe capire perché il suo modo di farlo sia migliore. La chiave è che dovrebbe cercare di capire il suo modo di fare le cose.

Penso che dovresti trattare questa persona con più rispetto. Nella tua testa, tu lo chiami nomi denigratori e critichi il suo approccio a ciò che pensi di "apprendere". Attenzione per quello. D'altra parte, hai detto che ha chiamato tu stupido. Non è bello, e dovresti dirgli che non è bello chiamare qualcuno stupido.

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

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

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

Nell'azienda in cui lavori, probabilmente lo è. Questo è quello che ti chiedono di fare.

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

Ti incoraggerei a parlare con gli sviluppatori esperti della tua azienda, a porre loro domande sui pro e contro delle diverse tecniche di programmazione, ecc. Insieme alla lettura di 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 idiota, che ti chiama nomi e semplicemente perché può (è anziano, non lo sei, se qualcuno di voi si lamenta dell'altro, otterrà il beneficio del dubbio ) è semplicemente un comportamento da bullo e semplicemente cattivo.

Cerca di non abbassarti al suo livello con questo. Non cercare di rimproverarlo 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 influisce sulla tua produttività e così via) dovresti fare qualcosa al riguardo.

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

Molte volte ho avuto qualcuno che correggeva quello che inizialmente pensavo fosse "il mio codice perfetto" e mi sono solo infastidito dal fatto che il ragazzo mi stesse dicendo cosa fare solo per rendermi conto in seguito che aveva ragione, la mia versione era cattiva , era buono, e grazie a Dio l'ha visto! :) Così ho imparato a smorzare i miei impulsi iniziali di "hey, tu no dirmi cosa fare, scambiare!" e invece, ogni volta che qualcuno mi corregge, in primo luogo, oggettivamente, ricontrollo il mio codice, poi controlla il suo, e mi assicuro che non abbia davvero ragione ed è io che sto facendo lo svarione. Se è stata colpa mia, lo ringrazio per l'aiuto, e mi assicuro di capire veramente come funziona la sua soluzione (piuttosto che copiare / incollare).

E hey, a volte trovo che la correzione offerta sia in realtà peggiore di quello che inizialmente ho fatto, a quel punto provo a parlare di tutto questo con l'altro ragazzo. Onestamente, ho notato che nulla ottiene il rispetto degli altri per te più velocemente di quando vedono che puoi accettare di essere corretto quando hai commesso un errore, ma allo stesso tempo, non hai paura di dire che tu sei l'unico 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, e di ciò che proponi e così via. Dimostragli cosa pensi, come hai ottenuto una soluzione particolare e perché pensi che sia migliore della sua (quando pensi che sia onesto e oggettivo). 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 possono contraddirsi l'un l'altro. Prova quello che ritieni migliore e prova entrambi se hai tempo o vuoi confrontare / contrastare.

Affrontare il tuo capo è un argomento e un approccio completamente diversi. Se volessi che qualcuno facesse qualcosa nel modo esatto in un libro, direi loro. Sono solo io perché non mi associo ai lettori della mente. Il tuo capo fa diventare un'abitudine, basta chiedere se raccomanda qualche libro o riferimento quando ottieni 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 lavorare, ma tu sei colui che deve convivere con essa e subire la negatività. Stai andando meglio, ma questo di solito viene da scrivere più codice su cose nuove, imparando dai successi e dai fallimenti.

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

Quando stai cercando di capire qualcosa in un libro, generalmente è appropriato per seguirlo esattamente all'inizio, mentre stai provando ciò che sta cercando di insegnarti. Le probabilità sono che non riuscirai a capire tutto quando hai finito, è così che di solito vanno le cose, ma seguendo il libro esattamente all'inizio ti daranno qualcosa da sperimentare, mentre cerchi di capire le tue domande. Le probabilità sono di nuovo buone che troverai i modi in cui non sei d'accordo con quello che c'è nel libro, ma avrai una comprensione dei problemi che il libro stava cercando di risolvere, 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) invece di lasciare questi problemi a morderti più tardi.

Un'altra cosa che non è intrinsecamente specifica di Java, ma è tuttavia particolarmente comune in quella comunità. Penso di poter indovinare di quali libri stai parlando e costituiscono una parte importante del lessico della comunità Java. Comprenderli e il modo in cui descrivono le cose, aiuterà immensamente quando è necessario capire altro codice Java che trovi. È un'abilità preziosa a sé stante.

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

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

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

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

La cosa sui libri è che essi - per lo più - passano attraverso le revisioni, che hanno una migliore possibilità di individuare cattive pratiche e idee sbagliate. Inoltre, i "grandi nomi" sono persone esperte che si affidano ad essere bravi per guadagnare denaro 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 professionista, naturalmente, quando confermato dalla pratica. Quindi, è bene per te leggere quei libri (anche quelli raccomandati da Infestus). Tuttavia, i libri devono principalmente ampliare la tua comprensione sull'argomento, poiché ci saranno quasi sempre 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 te, ma, se confrontato con altre soluzioni note, devi essere in grado di argomentare il motivo per cui il tuo è migliore, poiché gli altri hanno a loro favore, almeno, i casi d'uso. Quindi, sii creativo e premuroso, ma soprattutto, sii efficace.

Se lo fossi, avresti letto quei libri. Questo ti aiuterà fornendoti più argomenti e, allo stesso tempo, potresti scoprire che Infestus - 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 ci si preoccupa di programmare gli argomenti, la qualità e la presentazione delle informazioni con spiegazioni adeguate nei libri è una grandezza migliore di quando si cercano le stesse informazioni sull'argomento su Internet. Internet spesso manca di adeguata spiegazione, contesto e qualità.

La quantità di dette informazioni su Internet è più alta.

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

Cercherò i meriti di ciascun approccio e arriverò al tuo giudizio. Se pensi che il tuo approccio sia migliore, parlane con Infestus finché uno di voi non convince l'altro. Se non riesci a raggiungere un accordo, potresti chiedere un secondo parere o semplicemente accettare l'approccio di Infestus, a seconda di quanto strongmente ti senti a riguardo.

Nel caso dei singleton, un argomento che potresti fare contro l'approccio enum è che le enumerazioni non possono estendere le classi. Scrivo spesso codice come questo:

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. Dal momento che l'approccio enum non funziona in tutti i casi, si potrebbe obiettare che, per motivi di coerenza, dovrebbe essere evitato anche quando non c'è bisogno di una clausola extends .

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

• è un hack - utilizza le enumerazioni per qualcosa per cui non erano destinate
• è fonte di confusione per i lettori che non l'hanno mai visto prima

Mi baso molto sui libri come fonte di conoscenza - queste sono basi eccellenti e penso che Infestus abbia ragione nel ritenere che si debbano consumare quantità significative di libri nel proprio tempo libero poiché accelerano davvero le vostre capacità. I libri non sono l'unica fonte di informazioni che penso che dovresti consumare: partecipa al tuo gruppo di utenti locali, ricevi i bollettini tecnologici 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, è così che deve essere fatto. Sì, i libri forniscono ottimi consigli, sono scritti da esperti e sottoposti a peer review da parte di esperti, ma essendo stati coinvolti in un libro comparativamente semplice, posso affermare che in genere occorrono almeno due anni per scrivere, modificare e pubblicare un libro . Il ritmo del cambiamento tecnologico è rapido e il consiglio di due anni fa potrebbe non essere più un consiglio corretto per oggi. I principi generici spesso superano la 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 ad Infestus di dare suggerimenti con te è eccellente - vai via, leggi tutto e torna con un sacco di domande ponderate che hai già provato a rispondere / a risolvere per te stesso insieme al tuo sostegno prova per il tuo metodo.

Ci sono state domande sul fatto che dopo 5 anni perché eri ancora un junior. Per me, la misura chiave del fatto che qualcuno sia un junior non è anni di esperienza, ma quanto richiedono l'alimentazione del cucchiaio. Mi aspetto che uno sviluppatore di livello medio sia relativamente autosufficiente, un consumatore attento di fonti di conoscenza che possono agire su di esso e estenderlo alla loro situazione. Dovrebbero anche essere nella fase in cui possono iniziare a insegnare ai ragazzi perché hanno una solida comprensione del loro argomento in modo che possano spiegare le cose chiaramente. L'altra competenza di base è la fiducia: se hai fatto il lavoro, leggi il materiale e prodotto qualcosa di decente, non aver paura di difenderlo in una corte di discussione quando un giovane richiede la convalida, uno sviluppatore richiede il consenso.

Metti da parte le maniere del posto di lavoro, mettendo da parte la realtà di un ruolo di mentore che gli sviluppatori senior hanno, mettendo da parte il tuo desiderio di esplorare, mettendo da parte il comportamento offensivo e mettendo 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 assicurare che la persona che scrive il codice capisca il significato dietro il miglioramento del codice. Non è il caso di dire "cambia questo perché Martin Fowler ha detto così nel libro dei GoF". Tuttavia, è il luogo in cui si dice "cambia questo perché [una breve spiegazione], c'è più dettaglio nel discutere questo nel libro del GoF".

Se il tuo sviluppatore senior non è, almeno in modo semplice e subdolo, fornire una spiegazione per un cambiamento, e insistendo sull'uso della verbosità di "causa di [libro]", è un po 'uno scemo e un idiota. Come lo gestisci? Menzionalo in una riunione di gruppo, verbalmente, e chiedi ai tuoi compagni di squadra di fornire una dichiarazione o due che spieghino brevemente il vantaggio o la necessità del cambiamento, insieme a quello utile riferimento bibliografico. Assicurati di ringraziarlo per il riferimento del libro.

Affrontalo, il tuo obiettivo è quello di apprezzare il suggerimento del cambiamento e di non essere demotivato per il tuo compito o il tuo lavoro. Diglielo. "Apprezzerei molto il suggerimento sul cambiamento se potessi descrivere brevemente il vantaggio o la necessità del cambiamento quando rileggi il mio codice, poiché sto trovando i tuoi riferimenti di libri da solo per essere un po 'demotivanti."

Se continua a rifiutarsi di fornire una spiegazione semplice con i suoi riferimenti al libro, se puoi fornire un altro libro o risorsa di notorietà uguale o maggiore nel settore con un parere diverso e corrisponde al tuo scenario, potresti essere in grado di aggiungere il tuo riferimento libro nel commento di revisione in considerazione del mantenimento del codice originale. Fai questo abbastanza volte, potrebbe tornare indietro. State molto attenti che la contro-argomentazione sia giusta e significativamente più importante; va bene lasciare che uno sviluppatore anziano si sbaglia e continua a fare a modo suo, questo è qualcosa che ho imparato e continuo a dover imparare.

Direi che imparare solo la programmazione da un libro è impossibile, ma quelli buoni ti daranno un enorme impulso. È come il karate: non otterrai la cintura nera solo a leggerlo;) Credo che in questo caso particolare il sig. 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.