La costante ricerca di esempi di codice è un segno di un cattivo sviluppatore? [chiuso]

Sono uno studente CS con diversi anni di esperienza in C e C ++, e negli ultimi anni ho lavorato costantemente con Java / Objective C nello sviluppo di app e ora sono passato allo sviluppo web e mi concentro principalmente su ruby ​​su rails e sono arrivato alla conclusione che (come nello sviluppo di app, in realtà) faccio troppo riferimento ad altro codice. Ho costantemente funzionalità di Google per molte cose che immagino dovrei essere in grado di fare da zero e ha davvero rotto la mia fiducia un po '.

I fondamenti di base non sono un problema, odio usarlo come esempio, ma posso correre attraverso javabat sia in java / python a uno sprint - ovviamente non è un risultato e ciò che intendo dire è che ho una solida base per i fondamenti Penso?

So cosa devo usare in genere, ma faccio costantemente riferimento alla sintassi. Mi piacerebbe qualche consiglio e input su questo, dato che mi ha trattenuto abbastanza solidamente in termini di ricerca di lavoro in questo campo anche se sto finendo la mia laurea. Il motivo principale per cui mi chiedo non riguarda davvero l'occupazione, ma più che non voglio essere l'unico ragazzo di un hackathon a non scrivere codice ininterrottamente e seduto lì con 20 schede di Google / github aperte, e mi sono astenuto dal frequentare qualsiasi a causa di una leggera mancanza di fiducia ...

Una persona è un cattivo sviluppatore alla costante ricerca di esempi di codice per attività moderate o complesse?

Copia e incolla alla cieca: male.

Consulta la documentazione, leggi esempi di codice per capire meglio: bene.

Preferirei lavorare con qualcuno che cerca continuamente le cose e si assicura che tutto funzioni come previsto piuttosto che qualcuno troppo sicuro di sé che pensa di sapere tutto ma non lo fa. Ma il peggio è qualcuno che non si preoccupa di capire come funzionano le cose e copia acriticamente il codice dal Web (e quindi quando le segnalazioni di bug iniziano a piovere non è in grado di risolvere nulla in modo corretto).

Se codifichi le tue soluzioni in modo sostenibile e in realtà COMPRENDI cosa copi / incolli / modifichi, allora non ci sono problemi.

Muoio ogni volta che faccio a uno sviluppatore senior domande sul perché abbia fatto cosa e la risposta è "Non lo so, copio il codice incollato e ha funzionato in quel momento".

Proprio come con l'abilità di programmare con / fuori la documentazione dell'API , la ricerca di esempi di codice è un segno non di un cattivo programmatore, ma di uno che manca di fluidità ...

... Ecco, sto parlando di scioltezza. Sull'essere non solo capace di qualcosa ma fluente.

Sai cosa vuol dire essere fluenti? È quando per qualcuno che ti guarda sembra che tu digiti mentre digiti ...

• ... Come se il codice giusto scorresse semplicemente dalle dita allo schermo. Come se non controllassi i documenti API, tutorial e manuali. In realtà, si fa controllare tutti, ma questo è invisibile perché è tutto nella tua testa. Hai tutta la conoscenza di cui hai bisogno proprio lì nel tuo cervello: carica, caricata e pronta per l'uso.

... Questa è conoscenza fluente. È quando ti ci vuole un minuto per fare ciò che richiede novizio un'ora. Ne vale la pena, davvero. Profuma di vittoria.

... e la pratica è per me l'unico modo affidabile per acquisire fluidità.

C'è una teoria dell'apprendimento chiamata ciclo di Kolb (dopo la persona che l'ha descritta). Le voci in questo ciclo sono:

Concrete experience -> Reflective observation
    ^                        |
    |                        v
Active experimentation <- Abstract conceptualisation

A diverse persone piace iniziare in diversi punti del ciclo. Quindi è del tutto possibile per essere l'apprendimento da parte alla ricerca di campioni (la fase di osservazione riflessiva), poi lavorare fuori da quei campioni al quadro tramite astrazione.

Altre persone impareranno in modi diversi: ad alcune persone piace iniziare provando (cioè con la sperimentazione) e poi riflettendo su cosa è andato bene o male. Il punto è che questi sono solo modi diversi di attaccare il problema dell'apprendimento delle cose: nessuno di questi è errato.

Divulgazione completa - Sono una persona anziana che è stata addestrata in una pre-Internet diversa disponibile durante l'era del lavoro. Ho visto le competenze degli sviluppatori più giovani peggiorare costantemente, soprattutto perché non conservavano le informazioni o non capivano la soluzione che avevano afferrato da Internet. Ho osservato che il livello di competenza di una persona dopo 1-2 anni di esperienza, 20 anni fa, è ora il livello di competenza che qualcuno ha dopo 5-7 anni di esperienza. (Sì, è un'osservazione personale, ma ho fatto molte assunzioni, non ho dati statistici sulla questione e sì, a volte sono vecchio e irritabile, prendo questa affermazione con un granello di sale. E stai fuori dal mio cortile. )

Cercare tutto è inefficiente in termini di tempo. È anche un sintomo di qualcuno che non ha molta profondità di conoscenza. Le persone con una conoscenza approfondita possono scrivere codice più velocemente di quelle che non sanno come risolvere un problema senza cercare le cose. Quindi vale la pena imparare a gestire più cose senza doverle cercare continuamente.

Ora non sto dicendo che non dovresti mai cercare le cose, sto dicendo che dovresti imparare a conservare la conoscenza e devi solo cercare le cose che usi raramente o quando incontri un problema, una lingua o un paradigma veramente nuovi. E non sto dicendo che non dovresti leggere per stare al passo con nuove soluzioni, strumenti e lingue.

La mia vera preoccupazione per gli sviluppatori che cercano troppo spesso cose che quelle troppe (non necessariamente tu) non sviluppano mai le capacità analitiche per comprendere i problemi che hanno e le soluzioni necessarie. Leggi quante domande ci sono in cui la persona inserisce il messaggio di errore che chiaramente non comprende, ma che dovrebbe essere abbastanza chiaro per chiunque operi a livello professionale. O quelli in cui la persona dice "non funziona, perché?" senza alcun riferimento al messaggio di errore o al modo in cui non funziona e il codice è sintatticamente corretto. O quelli a cui viene dato un pezzo di codice che dovrebbe funzionare,

Quindi, se quello che stai cercando è qualcosa che fa parte delle funzionalità principali dei linguaggi (tra cui questo dovrebbe includere SQL se stai accedendo ai database) che hai usato per più di sei mesi, sospetto che anche tu stia cercando tanto. Se quello che stai cercando sono funzionalità avanzate, specialmente quelle che potresti usare raramente, allora stai andando bene.

Ma come imparare a conservare più informazioni? Per prima cosa capisci perché il codice si è rotto. Anche se qualcuno ti offre una soluzione funzionante, se non vedi perché ha funzionato e il tuo no, allora chiedi. Se non capisci il messaggio di errore, chiedi cosa significa e quindi prova a risolverlo da solo.

E mai tagliare e incollare una soluzione che non capisci. In effetti, non tagliare e incollare affatto. Se si desidera conservare le informazioni, è necessario digitarle. Scrivere fisicamente il codice da soli ti aiuta a impararlo. Questa è una tecnica di apprendimento ben nota.

Esercitati a generalizzare la tua comprensione del codice. Ho visto persone porre domande simili più e più volte nel tempo perché non capiscono che la soluzione che hanno avuto un mese fa al problema ABC è la stessa soluzione al nuovo problema DEF.

Quindi, quando hai ricercato qualcosa, prenditi del tempo per pensare a quali tipi di problemi sarebbe utile per risolvere e scrivere te stesso su questo. Quindi quando hai un problema da risolvere, controlla prima le tue note per vedere di aver già notato una possibile tecnica. Se valuti più modi per risolvere un problema, prendi nota del tipo di problema, delle possibili soluzioni che hai esaminato e dei pro e contro di ciascuno. Ancora una volta prendere appunti sta aiutando a consolidare la conoscenza nel tuo cervello, hai già il tuo processo di pensiero in termini di pro e contro elaborati e non devi farlo di nuovo (o almeno non con la stessa profondità, potresti cercare ancora più tecniche possibili) per il prossimo problema simile.

E quando decidi cosa imparare dopo, approfondisci una delle tue principali tecnologie prima di iniziare ad imparare i primi 30 giorni di un'altra tecnologia (questo presuppone che tu abbia abbastanza ampie conoscenze per svolgere effettivamente il tuo lavoro, se hai bisogno di usa 6 tecnologie - ottieni le basi in tutti e sei prima di approfondire). Quindi vai avanti e indietro, imparando nuove cose, a livello base, imparando qualcosa in modo più approfondito, quindi imparando più nuove tecnologie a livello base. Se lo fai nel tempo, scoprirai che il tuo livello base di ciò che desideri da una nuova tecnologia è molto più profondo perché capisci domande più avanzate da porre al riguardo.

Un altro modo per imparare a conservare la conoscenza è insegnarla a qualcun altro. Rispondi a domande in posti come questo, presenta argomenti di formazione al tuo team, fai presentazioni ai tuoi gruppi di utenti locali, scrivi post di blog e aiuta a mantenere una wiki di informazioni nella tua azienda per aiutare altri sviluppatori.

Cercare esempi di codice non è un segno di cattivo sviluppatore. Raramente sono necessarie così poche cose per ricordare esattamente tutte le interfacce di cui hanno bisogno, quindi è naturale cercare le cose e gli esempi di codice sono di solito il riferimento più facile da usare.

Quello che non dovresti fare è copiare e incollare esempi perché funzionano lì, quindi devono funzionare anche qui, senza capire come funzionano. Questo di solito porta a molti bit inutili che sono stati copiati per inciso con risultato difficile da mantenere perché se non sapevi come funziona quando lo hai scritto, non lo saprai neanche sei mesi dopo e non sarai in grado di aggiustalo.

Ma finché capisci il codice che stai copiando da un esempio, è un modo valido per fare il lavoro più velocemente, e di solito è una buona cosa.

Queste risposte sono abbastanza buone. Ma tu soffri di un problema molto più profondo di copia / incolla o mancanza di "abilità".

Il confronto è letale. Più ti paragoni con le altre persone e lasci che il loro talento influenzi il modo in cui ti vedi, più ti accartoccerai e morirai all'interno. Non vai agli hackathon per paura che le persone vedano quanto sei indifferente. E l'unica ragione per cui pensi di non essere distratto è perché ti confronti con gli hacker che possono sbattere più codice da zero, più velocemente.

Anche se "Linee di codice al minuto" erano una buona metrica per misurare le abilità, devi accettare il fatto che ci saranno sempre sviluppatori migliori là fuori di te . Ed è giusto mostrare agli altri che ti manca l'abilità.

Non devi essere buono come, o meglio di, chiunque altro. Devi accontentarti del fatto che ti mancherà sempre in qualche modo e che stai imparando costantemente. Se non puoi essere felice di essere uno sviluppatore inferiore, non sarai MAI felice.

Ancora una cosa: la tua paura del rifiuto da parte di persone che ritieni "superiori" è esattamente ciò che ti impedisce di sfregarti con sviluppatori migliori e imparare da loro. Quindi la tua paura ti impedisce di crescere, il che mantiene la tua paura. Il che ti impedisce di crescere. Vedi il ciclo? Devi interrompere il ciclo da qualche parte.

Penso che molto dipenda da come funziona la tua mente. La mia memoria puzza, quindi preferirei prendere il codice il più vicino possibile a quello che voglio e rielaborarlo in modo che faccia il nuovo lavoro. Serve come esempio e promemoria di tutte le cose che devo fare. Ad esempio, ho usato SQL semplice per 20 anni, ma non ricordo mai il layout di un'istruzione SELECT o UPDATE. (Penso che uno abbia bisogno di parentesi, ma non ricordo quale.) D'altra parte, alcune poche cose che posso ricordare; Posso mettere insieme un'implementazione di Java Iterator con gli occhi chiusi.

La maggior parte del codice che copio è mio, ma certamente ne copio altri quando sto imparando qualcosa di nuovo.

Non conosco hackathon. Possono attingere a un sottoinsieme di programmatori con memorie fotografiche. Ci proverei e vedrei. Se sembrare un idiota ti disturba, non dovresti programmare.

Ti esorto a capire, a fondo, tutto il codice che copi e modifichi, ma, fino a quando non leggo alcune delle altre risposte, non mi è mai venuto in mente che qualcuno potesse copiare senza capire. (Mi sembra di imparare sempre nuovi vizi su questo sito ...)

... Sono arrivato alla conclusione che ... faccio troppo riferimento ad altro codice Wayyyy. Sono costantemente alla ricerca di funzionalità Google per molte cose che immagino che dovrei essere in grado di fare da zero e ha davvero rotto la mia fiducia un po '.

Quindi fermati. Dirigiti nella direzione opposta per un po '. Implementa tutto da solo, anche se sai che potresti trovare esattamente ciò di cui hai bisogno in molto meno tempo.

Quello che è successo è che il tuo muscolo problem solving (nome latino gluteus mojo ) si è atrofizzato dal disuso, e ora eviti di usarlo perché sai quanto è debole. Devi iniziare a costruire e tonificare quel muscolo proprio mentre lavoravi sui bicipiti in palestra. Inizia con ripetizioni elevate e bassa resistenza - molti problemi facili. Man mano che aumenti la fiducia, passa a problemi più lunghi e più difficili.

Sentirai gradualmente il ritorno del tuo mojo e il tuo bisogno di fare affidamento su Google diminuirà. Continua ad esercitare quel muscolo, però, e assicurati di non ricadere nei tuoi vecchi modi. Sfida te stesso per risolvere prima un problema e solo successivamente cerca altre soluzioni. A volte scoprirai che altri hanno trovato un modo migliore per fare la stessa cosa, altre volte deciderai che la tua soluzione è migliore.

Una persona è un cattivo sviluppatore alla costante ricerca di esempi di codice per attività moderate o complesse?

Una persona che non è in grado di fare nulla senza trovare esempi è un cattivo sviluppatore. Il fatto è: non saprai se sei in grado o meno finché non ci provi.

Sei giovane e hai lavorato con molti linguaggi di programmazione. Immagino che probabilmente imparerai le nuove lingue più velocemente di quelle vecchie. Non hai ancora dedicato abbastanza tempo a una singola lingua su un'applicazione abbastanza grande da sviluppare fluidità.

Sei alla ricerca di soluzioni ampie ogni volta come: l'intero processo di connessione di una griglia Web a una tabella di database o una parte più piccola come la formattazione della stringa di connessioni (devo cercarla ogni volta da quando scrivo circa quattro all'anno. )?

Sarai sempre alla ricerca di riferimenti alla sintassi di diverse righe di codice o funzioni. Più programmi, più sfide e diversi ambienti e cambi di lingua ti imbatti. Se hai bisogno di un intero tutorial ogni volta che fai qualcosa, allora hai un problema.

Avevo un professore che diceva che odiava fare test basati sul tentativo di conservare un mucchio di informazioni che hai stipato la sera prima perché in seguito te ne dimenticavi molte. È meglio conoscere le tue risorse e che puoi usarle correttamente per trovare le informazioni che non conosci. Mi piace applicare un principio simile a tutto ciò che faccio, compreso il lavoro.

Penso che gli strumenti più importanti che hai siano le tue risorse, purché le usi correttamente. Quindi, quando scrivo codice, ottengo il più possibile con le mie conoscenze esistenti e poi faccio ricerche chiedendo ad altri programmatori o cercando in Internet, al fine di comprendere meglio la soluzione appropriata. Le conoscenze aumenteranno nel tempo e dopo un po 'conoscerai e capirai meglio le abilità. Cerco costantemente le cose, sia che io abbia effettivamente bisogno delle informazioni o meno, e posso onestamente dire di imparare qualcosa di nuovo ogni giorno.

Se capisci il problema che stai cercando di risolvere e capisci come vuoi risolverlo, cercare la sintassi corretta non è un grosso problema secondo me.

Mi sono laureato circa due anni fa e sono stato gettato dai lupi quando ho ottenuto il mio lavoro. Ho dovuto imparare, mantenere e aggiornare una grande applicazione scritta in una lingua che non avevo mai toccato prima. Vorrei ricevere una segnalazione di bug, scorrere il codice e scoprire come volevo correggerlo, quindi dovrei cercare su Google esempi di come fare le cose che volevo in quella lingua.

Se stai facendo le cose e le capisci abbastanza da non produrre sfornamento non necessario, allora probabilmente stai bene.

La copia e incolla pura e acritica, come affermato più volte in queste risposte, è negativa. Ma anche scrivere tutto da zero. Se non è un componente critico che è fondamentale per la tua attività, cerca prima una libreria o uno snippet di codice. L'eccezione alla ricerca di uno snippet sarebbe che il problema è molto semplice, hai un quadro molto chiaro su come farlo e se non stai usando una libreria: è improbabile che tu debba fare altro.

So personalmente che se scrivo qualcosa che è comune, probabilmente avrò alcuni bug sottili e forse uno o due non così sottili senza molti test. Quindi cerco una soluzione simile, la modifico e la collaudo per risparmiare un po 'di tempo sui test e lo sviluppo su tutto. Perché alla fine sono responsabile della consegna di un prodotto che funziona, è estensibile, è in bilancio o sotto budget e rispetta le scadenze. Riutilizzare il codice e le librerie è un buon passo verso tale obiettivo.

Penso che leggere esempi di codice, e semplicemente leggere il codice sorgente di ciò che altre persone hanno sviluppato in generale, sia il modo migliore per migliorare le tue abilità. Penso davvero che ti apra le porte del cervello che altrimenti non sarebbero state aperte.

Se pensi a una soluzione A e qualcun altro pensa a una soluzione B, quando ognuno di voi condivide le proprie soluzioni, è possibile realizzare la soluzione C che potrebbe essere persino migliore di A o B.

Penso che ci siano molti livelli di competenza nello sviluppo di software. Proprio così, perché ci sono anche molti livelli di competenza nella documentazione di sviluppo software . Francamente, oggigiorno, i sistemi sono ordini di grandezza più complessi rispetto a quando ho iniziato a programmare i computer a metà degli anni '80.

Quindi, dovevi sapere cosa volevi che facesse il computer e avevi scritto una documentazione di 6 pollici di spessore che ti diceva come il computer faceva certe cose più basilari. Mettere ciò che volevi in ​​una forma che il computer poteva prendere era una questione di conoscere il contenuto degli indici di quei libri e un linguaggio di programmazione (o due. In realtà, dopo aver appreso quattro o cinque lingue gli altri sono solo dialetti).

Oggi, tale compito richiede la conoscenza di una lingua, la conoscenza di un sistema, la conoscenza di un paradigma, un modello di programmazione e almeno un set di API, tutti obiettivi in ​​movimento.

Quindi, una persona con un certo livello di conoscenza di base che chiede in giro non è un buon tipo di programmatore. È il miglior tipo di programmatore, dati gli ambienti di oggi e le aziende disinteressate come Microsoft hanno effettivamente applicato qualsiasi tipo di rigore alla propria documentazione sui fondamentali. La maggior parte delle loro cose è materiale di riferimento autoreferenziale e un codice di esempio molto scadente . (Due casi al punto che ho riscontrato sono "Windows Installer" e le API per la creazione di file di filmati WMV.)

Perché Microsoft, Google e, in misura minore, Apple, fanno tutti affidamento sulla "comunità" per compensare quella carenza molto reale, chiedere in giro non è solo importante, è vitale. Ed essere una persona a cui è possibile chiedere e che può dare risposte e feedback solidi nell'ambiente di oggi è altrettanto vitale. Ecco perché siti come i siti stackexchange.com sono utili quanto lo sono.

Quindi fai delle domande, (chiedi intelligentemente!) Per i campioni, e rispetta le persone che forniscono le risposte, e così facendo non sarà visto come un segno di un "cattivo sviluppatore".

E un'altra cosa: fornire campioni cattivi è davvero il segno di un cattivo sviluppatore. Rende più facile individuare i cattivi sviluppatori, ma gumma anche le ricerche su Google. Se non hai fiducia in esempi di codice semplici, chiari e specifici, non darglielo.

E, per favore, non deridere quelli che chiedono.

Mi sembra che il problema per te sia meno nella comprensione di ciò a cui ti riferisci e più con problemi di facilità e memoria. Se sta indebolendo la tua fiducia, allora sì, è un problema, ma può sicuramente essere risolto!

Per me, questo tipo di sfide si presenta in molti aspetti diversi della mia vita. Ad esempio, per diventare bravo nell'esecuzione di un brano musicale, devo sviluppare la mia indipendenza dagli spartiti che mi viene dato: come puoi davvero sentire la musica se il tuo naso è ancora sepolto nel tuo opuscolo? A volte, se ho tempo, memorizzerò l'intero brano musicale, anche se non è richiesto per il mio concerto. Perché? Con lo spartito sparito, è molto più facile per me concentrarmi sugli aspetti più impegnativi e generali della musica che devo ottenere, ed è molto più facile per me entrare in quella incredibile zona di pura musica. Quindi trovo che spesso valga la pena di avere problemi extra.

La mia esperienza con la programmazione è stata simile. Penso che le chiavi siano:

1. esercita la lingua - digitala, eseguila, parla se aiuta; fallo ripetutamente.
2. costruisci la tua struttura - usa la stessa funzione o lo stesso modello in diverse situazioni; mettere insieme le caratteristiche; fare programmi.
3. concedi abbastanza tempo tra le ripetizioni per assicurarti che le cose si stiano davvero facendo strada nella tua memoria a lungo termine.

Questi principi sembrano applicarsi nell'apprendimento di qualsiasi lingua, in realtà! Vedi Come ricordare nuove parole per esempio. Anche il metodo Pimsleur funziona in questo modo.

Ho scoperto che quasi tutti i principi, la sintassi e le librerie comuni del linguaggio e delle tecnologie che utilizzo regolarmente possono essere completamente memorizzati, usando questi tasti. Anche così, scruto costantemente Internet per esempi e saggezza! Ma quel punto, sto cercando una convalida sul problema che sto cercando di risolvere, vari approcci che sono stati adottati, strumenti che possono aiutare e consulenza per le biblioteche utilizzate meno frequentemente. È un tipo di ricerca molto diverso da quello che uso quando apprendo per la prima volta una lingua e approfondimento in tutorial e manuali.

Dalla tua storia, ecco alcuni specifici ostacoli che penso che potresti incontrare.

1. Se stai lottando con la sintassi, potresti non avere abbastanza pratica. Questo è particolarmente vero se stai copiando e incollando direttamente nel tuo codice, invece di sviluppare la ripetizione e - posso dire? - memoria muscolare che ti aiuterà a diventare davvero bravo. Per contrastare questo, sviluppa semplicemente esercizi e disciplina, concentrandoti sulla ripetizione e sul tempo, che miglioreranno la tua struttura nelle aree che desideri. suggerimenti:
   • Scrivi un semplice programma nella stessa lingua una volta al giorno, tutti i giorni.
   • Digita esempi invece di copiarli e incollarli.
2. Se stai lottando con la costruzione di soluzioni a problemi di medie dimensioni, potresti non avere abbastanza esperienza con la costruzione. Prova questi:
   • Avvia un progetto di medie dimensioni in una tecnologia o un linguaggio in cui vuoi migliorare. Oppure prova a utilizzare una funzionalità più complessa di un progetto open source che ti interessa. Fai a pezzi un po 'ogni giorno. (Ricorda, quando insegui questi progetti più grandi: vai su di loro mattone per mattone. Non cercare di costruire tutto in una volta!)
   • Usa la stessa nuova funzionalità per quattro giorni consecutivi, in quattro contesti diversi.
   • Sfida te stesso a codificare qualcosa con il browser web disattivato!
   • In realtà prendi appunti sulle cose che stai imparando. Sintetizza ciò che stai imparando e scrivi le tue osservazioni. (In realtà scrivere le cose e costringermi ad esprimere qualcosa con le mie stesse parole, mi aiuta molto.)
   • Scrivi le risposte e verificale per le domande StackOverflow sulla tecnologia che stai assorbendo. (Questo spesso ha l'ulteriore vantaggio di guadagnarti un po 'di reputazione mentre stai imparando. :-))
3. Potresti diffondere la tua pratica in modo troppo sottile. Sembra che tu stia lavorando in molte lingue diverse. Questo ha molti vantaggi, ma ha lo svantaggio di diluire la tua esperienza. Se trascorri del tempo a lavorare in cinque lingue diverse, memorizzerai meno che se passi lo stesso tempo in una lingua. Peggio ancora, ci sono molti affini non abbastanza simili tra lingue diverse (era questo se if, elsif o elif ??) per farti inciampare. Per contrastare questo, affina la tua attenzione. Scegli una cosa da imparare e impararla a freddo. Quindi passa alla prossima cosa.

Penso che se ti concentri sul trovare tu stesso un codice moderato, la tua efficienza e produttività aumenteranno. Probabilmente ci vuole più tempo per cercare il codice, leggerlo / comprenderlo, copiarlo come sorgente, modificarlo di conseguenza, ecc.

Se ce la fai tu stesso, molto probabilmente è più adattato alla tua situazione specifica, e dopo un po 'queste soluzioni ti arriveranno più velocemente che cercarle.

Il modo in cui lo guardo è che è come se volessi un secondo parere su una determinata soluzione, quindi dai un'occhiata a come lo fanno gli altri (su Internet). Se ti ritrovi a fare / desiderare troppo, pensalo come chiedere a un collega cosa pensa di una soluzione. Se fai una domanda al tuo collega ogni 15 minuti, sarà probabilmente infastidito. Pertanto farai meno domande e proverai a inventarlo da solo.

Visualizzalo quando vuoi cercare cose su Internet.

Il modo migliore per imparare ciò che non conosci: cercalo su Google! Sento che sei alla pari con la maggior parte degli sviluppatori. Metti il ​​complesso di inferiorità nello zaino ed entra con una mente aperta.

Non abbiate paura di porre domande, fare ricerche su Google, provare e fallire. Fa tutto parte di esso.

Lo sviluppo del software in un ambiente aziendale richiede una buona dose di riutilizzo del codice. Perché riscrivere una funzione / metodo se un'API esiste già ed è ampiamente utilizzata? Molto probabilmente sarà altrettanto efficace di qualsiasi cosa tu scriva e impieghi meno tempo.

Naturalmente, riuscire nello sviluppo del software richiede anche una pausa dalla tastiera, in modo da poter leggere e comprendere ciò che sta realmente accadendo. Prendi qualsiasi framework web. Dovresti sapere cosa sta succedendo sotto in modo da capire il codice che stai scrivendo, ma probabilmente non dovrai mai scrivere un framework web da zero.

Devi solo scrivere un codice che sfrutti il ​​tipo di framework (diciamo che un framework basato su componenti richiede un certo stile) e questo deriva dalla comprensione del quadro più ampio. Impara l'immagine più grande e starai bene.

Dalle risposte già fornite risulta chiaramente che non c'è nulla di sbagliato nella ricerca del problema, invece di scrivere alla cieca. Ma la domanda che non è stata affrontata, perché non l'hai posta direttamente, è perché ti senti così insicuro ... e cosa puoi fare al riguardo? Dopotutto, molte persone si fanno strada attraverso i problemi e hanno molta fiducia (anche quelli che non dovrebbero ...)

Quindi che si fa? Forse hai solo bisogno di qualche centinaio di pacche sul retro, che hai appena ottenuto, e ora puoi programmare con fiducia. Ma se ciò non ha funzionato, ti suggerisco di esaminare i test automatizzati e lo sviluppo guidato dai test. Nulla dice "ben fatto" come un "Tutti i test superati" dalla tua suite di test: quando arrivi lì, sai di aver fatto bene.

Dovresti anche provare a metterti alla prova un po ': dici che stai sempre cercando la sintassi che già conosci; quindi forzati a scrivere un po 'di codice senza cercare la sintassi e (presto, se non immediatamente) scoprirai che stai facendo tutto bene dopo tutto.

Gli sviluppatori non nascono "grandi", ma la grandezza non viene automaticamente con l'esperienza. Al contrario, la mancanza di esperienza non rende uno sviluppatore "cattivo". La differenza tra un grande sviluppatore e un cattivo sviluppatore non sta nelle loro conoscenze di dominio, ma nella loro metodologia. Il segno distintivo di un grande sviluppatore è che codifica consapevolmente. In altre parole, un buon sviluppatore sa sempre perché sta facendo qualcosa. Dal punto di vista dell'etica personale, ciò richiede coraggio intellettuale e integrità.

È così importante prendere un po 'di tempo e capire le basi, cose più complesse praticamente costruite sopra a ciò. Se non ci sono fondamenta per comprendere la lingua e cosa sta succedendo dietro le quinte, la programmazione sarà semplicemente hacking ...

Quindi leggere libri con esempi e fare riferimento ad essi è una cattiva programmazione è il contesto della tua domanda. Visto che poche persone documentano la loro API, tutto ciò che ci resta è un libro.

Non so quali siano le tue ragioni per porre questa domanda, forse puoi rispondere tu stesso dopo aver letto la mia situazione, poiché mi riferisco a molti esempi di codice.

Non ho mai avuto la possibilità di andare all'università quando ero in strada all'età di 16 anni. In qualche modo a 24 anni ero nella posizione di studiare in un college di corrispondenza e fare certificazioni come SCJP, SCJD, SCBCD e SCWCD. Devo ammettere che a volte ho faticato e ho dovuto girare online per esempi. Inconsapevolmente, anche se in quel momento avevo un tumore al cervello che cresceva nella mia testa (nel 2010 aveva le dimensioni di un'arancia). Dopo i miei 5 interventi al cervello, 6 settimane combinano chemioterapia / radioterapia e 10 mesi di chemioterapia, sto ancora programmando con siti codificati a mano su che sono visualizzabili dal mio profilo.

Sì, ora ho bisogno di molti esempi di codice con danni cerebrali, quindi questo mi rende un cattivo programmatore?

Quindi vedo che hai detto che andrai a un hackathon. Sono stato in parecchi l'anno scorso (più di 15) e ho notato che sono fantastici per l'apprendimento. E per grande apprendimento intendo imparare a non codificare mai più così. Per lo più cerco di fare qualcosa di nuovo in ogni hackathon a cui vado solo per poter imparare nuove cose. Dato che c'è un enorme vincolo di tempo, fai affidamento sul solo incollare tutto il codice che puoi trovare e questo ti morde nel culo quando lo collaudi.

Tuttavia, ne vengono fuori delle cose buone, tu: A) IMPARA così tanto durante i test dei bug (anche piangi pesantemente) B) Sappi di non codificare mai più così e apprendi migliori pratiche di codifica. Inoltre, negli hackathon incontrerai persone che possono insegnarti così tante nuove cose che non hai mai saputo, e farai cose che non farai mai a scuola.

Quindi quello che sto dicendo è che il copia e incolla è un male, e non imparerai nulla, e il tempo che hai salvato con il copia e incolla ti morderà in seguito durante il test dei bug e non hai idea di cosa tu abbia scritto, sono le 8, e sono alimentati con tutta la caffeina. Ma penso che finché testerai il tuo codice, dovrai imparare tutto ciò che hai copiato prima.

Beh, non mi definisco un buon programmatore. Ma quello che faccio è semplice. Se non so come fare qualcosa, guardo un po 'di codice / esempio su Internet. Quindi, dopo averlo letto, provo a riscriverlo, ottimizzarlo e usare le cose che si adattano meglio al codice che voglio.

Nota: la lettura del codice da Internet non ti rende un cattivo sviluppatore. È sempre bello vedere come lo fanno gli altri e imparerai sempre qualcosa. Ma poi, copiarlo alla cieca non è buono.

Se uno sviluppatore / studente dice .. Wikipedia .. per copiare / incollare il codice nel loro progetto, quindi cerca semplicemente di farlo funzionare, le uniche abilità che questa persona sta sviluppando è 'How to google'. Ci potrebbe essere qualche processo di osmosi lì, ma non un intero gruppo. (Non crederesti a quante persone lo fanno nei corsi universitari)

TUTTAVIA, Se analizzi il codice di altre persone e pensi davvero a cosa sta succedendo nel codice stesso, allora ciò non rende una persona un cattivo sviluppatore. Li rende uno sviluppatore determinato e probabilmente indica uno stile di apprendimento più tattile o visivo. Imparo molto bene dall'esempio. Se qualcuno mi dice qualcosa o prova a spiegarmelo, di solito chiedo loro di mostrarmi di che stanno parlando.

Guardare, analizzare e apprendere dal codice li rende in realtà un buon sviluppatore nel tempo , perché stanno leggendo e imparando nella lingua che stanno usando.

Scherzo spesso che conosco i dettagli dei linguaggi informatici rispetto alla mia lingua inglese nativa. Il che pone la domanda; "Me lo spiegherai in Java, per favore?"

Penso che sia un po 'come giocare a scacchi. Controlliamo i pezzi individualmente e rintracciamo dove possono muoversi secondo le regole, e dobbiamo passare attraverso quel controllo cosciente per un certo periodo di tempo fino a quando il subconscio si unisce, rivelando schemi e sequenze ispirate.

Con la programmazione ci possono essere più pezzi e regole, spesso inciampo nella sintassi e mi incaglio su bug che impiegano un'eternità a trovare attraverso "le regole", ma alla fine il subconscio entrerà in gioco. Quando rimane abbastanza a lungo, posso leggere tornare a volte e meravigliarsi di ciò che può fare.