Padroneggiare un linguaggio di programmazione non programmando?

Lo scienziato informatico Peter Norvig ha affermato nel suo saggio Insegnare a programmare in 10 anni che sono necessarie circa 10.000 ore di pratica.

Ma Jeff Atwood ha sostenuto nel suo post Come diventare un programmatore migliore non programmando che crede che l'unico modo per diventare un programmatore migliore sia non programmando.

Questi articoli sono in opposizione. Esistono prove scientifiche per dimostrare l'approccio di Jeff Atwood?

self-improvement

— bywronski
fonte

Non riesco a vedere come siano affatto contrari, guardando oltre i titoli. Entrambi sono importanti, ma in realtà programmano e lavorano anche su abilità di non programmazione utilizzate sul lavoro. Nessuno dei due sta dicendo che non dovresti fare l'altro. Stanno entrambi dicendo che l'una cosa è importante oltre all'altra.

— Servito il

Spostiamo i meta commenti in meta, per favore. meta.programmers.stackexchange.com/q/6137/53019

Risposte:

Ti manca il punto.

Jeff Atwood afferma che essere un programmatore eccellente richiede molto più che capacità di programmazione. Richiede anche di essere un buon designer, lavorare bene con altre persone e in generale diventare un pensatore e un risolutore di problemi migliori.

La più grande abilità mancante è qualcuno che sia bravo a comprendere l'ingegneria e che abbia buoni rapporti con gli ingegneri più esperti e che li colleghi al lavoro con i clienti.

- Bill Gates

Il punto di Peter Norvig è che non puoi semplicemente prendere una copia di "Diventa un programmatore master in 24 ore" e aspettarti che funzioni. Ma è esattamente quante persone che fanno domande a Stack Overflow sembrano avvicinarsi alla programmazione. Pensano di poter caricare Eclipse, imparare alcune parole chiave e scrivere il prossimo Angry Birds. Ci vuole un po 'di più.

— Robert Harvey
fonte

No, gli uccelli arrabbiati sono probabilmente come 2 o 3 parole chiave ripetute fino alla nausea con divertenti fotografie di uccelli. Sì. È un database per ornitologi giusto?

— Jimmy Hoffa,

Bene, ma in qualche modo il punto di Peter Norving si riferisce al fatto di "padroneggiare" non conoscendo in modo superficiale (che è il punto centrale del suo articolo) il linguaggio di programmazione. In effetti, Peter e Jeff Atwood si riferiscono ad un "maestro". Allo stesso modo in cui descrivi la postura di Jeff Atwood, descrivo che Peter Norving sta dicendo che essere un programmatore eccellente richiede molta programmazione (con argomenti di apprendimento implicito) e pratica.

— bywronski,

@Wronski: Ah, sei tornato, capisco! Che bello rivederti. Mentre eri via, discutevamo della tua domanda, la chiudevamo e la riaprivamo. Ad ogni modo, allora cosa stai dicendo esattamente? Il punto di Peter Norving è che non puoi essere un maestro in 24 ore, o anche in 21 giorni. Il punto di Jeff Atwood è che non puoi essere un maestro scrivendo solo codice. Hanno entrambi ragione.

— Robert Harvey,

@RobertHarvey Perché chiuderlo e riaprirlo ?. Dovrei interpretare l'articolo di Peter Norving come qualcosa di un buon "codice" e l'articolo di Jeff Atwood qualcosa di essere un buon "ingegnere"? Sono un po 'confuso.

— bywronski,

@Wronski: i maestri sono sia buoni programmatori che buoni ingegneri.

— Robert Harvey,

La parte "Non programmazione" dovrebbe venire dopo una buona dose di pratica di programmazione.

the only way to become a better programmer is by not programming

Devi essere un programmatore prima di poter diventare uno migliore. La prima barriera di apprendimento del linguaggio di programmazione richiederà un grande sforzo da sola e la parte di risoluzione dei problemi sarà banale rispetto ai problemi che dovrai affrontare in seguito.

AGGIORNARE:

_{Come suggerito nei commenti, puoi comunque trarre vantaggio dal "non programmare aka: (pensando)" quando inizi come programmatore, ma non mi allontanerei dalla tastiera solo perché qualcuno dice che dovrei farlo per migliorare, piuttosto dovresti farlo perché sai che devi pensarci di più.}

— Korey Hinton
fonte

Forse. Ma le capacità di progettazione non sono così lontane, anche quando si inizia per la prima volta; e le abilità delle persone sono preziose, indipendentemente dalle tue capacità di programmazione.

— Robert Harvey,

@RobertHarvey Sì, ma l'articolo di Jeff Atwood sembra riguardare la risoluzione dei problemi e allontanarsi dal computer per pensare a ciò che si sta programmando.

— Korey Hinton,

@KoreyHinton Qualcosa che sarebbe del tutto appropriato per qualcuno quando risolve il suo primo problema di programmazione. Puoi e dovresti farlo dal primo giorno, non una volta che sei già competente, è quello che dice Robert.

— Servito il

@KoreyHinton Ecco perché nessuno (né l'articolo, né nessuna delle persone che rispondono qui) sta dicendo che dovresti fare solo l'uno o l'altro. Stanno dicendo che è importante fare entrambe le cose, perché le abilità si completano a vicenda.

— Servito il

@Wronski Penso che Robert stia sostenendo il punto opposto secondo cui le abilità di non programmazione possono essere apprese durante il primo apprendimento della programmazione. Sono d'accordo anche con questo, ma sono contento di non aver complicato troppo il processo di apprendimento all'inizio. La mia attenzione è stata come hai menzionato in ordine di priorità con le abilità di programmazione prima, le capacità di pensiero in secondo luogo e ora mi impegno costantemente per migliorare entrambi.

— Korey Hinton,