Ci siamo imbattuti in questo e ci siamo chiesti se qualcuno ha un modo per dimostrare o smentire questa affermazione:
Something to keep in mind ... what's the half-life of knowledge in high tech? It tracks with Moore's Law: half of everything you know will be obsolete in 18-24 months.
SOURCE: Entro la risposta di Craig Trader a questa domanda " Qual è la singola cosa più efficace che hai fatto per migliorare le tue capacità di programmazione? "
Questa affermazione si applica solo alle tecnologie effimere, che comunque dovresti solo imparare, se necessario. Detto questo, imparerai molti di loro durante la tua carriera.
I principi e le tecniche di programmazione fondamentali sono eterni.
Le persone che dicono cose del genere stanno solo cercando di essere sensazionalisti, oppure stanno imparando le cose sbagliate.
Il test migliore (peggiore?) a cui riesco a pensare è di pensare a un anno. Quanta parte della conoscenza della programmazione che usi ogni giorno è stata appresa nei precedenti 18-24 mesi? Inoltre, quanto è stato inventato nei precedenti 18-24 mesi? Il principio mi sembra molto sospetto, poiché la maggior parte delle conoscenze tecniche e di programmazione che utilizzo quotidianamente sono state acquisite in 5-10 anni.
Ora, se stai sviluppando qualcosa come una piattaforma di telefonia mobile, forse è un gioco diverso.
Nella mia esperienza, c'è un'enorme disconnessione tra i media e l'immagine pubblica di cui la tecnologia è la Nuova Nuova Cosa, e ciò che viene effettivamente utilizzato nel mondo reale là fuori.
Prendi qualcosa come Visual C ++ / MFC nello spazio delle applicazioni desktop. Anche se potrebbe sembrare vecchio e obsoleto, e probabilmente non è qualcosa che un nuovo programmatore dovrebbe imparare in questo momento per lo sviluppo del desktop, ci sono ancora molti progetti e lavori nel mondo reale scritti in esso che vengono mantenuti - e probabilmente verrà mantenuto per anni e decenni a venire. Stavo per dare COBOL come esempio, ma parlerei in teoria - conosco molto bene l'esempio VC ++ / MFC personalmente.
Essenzialmente, non è che le tecnologie diventano inutili e inutilizzate quando diventano "obsolete", è più che non sono più viste come il modo più aggiornato di fare le cose e di avviare nuovi progetti. Ma la disattivazione di grandi sistemi software del mondo reale che non è rotto e non ha bisogno di essere riparato avviene molto più lentamente. Molti dei progetti di Visual C ++ / MFC su cui ho lavorato (iniziati nei primi anni '90) sono ancora molto vivi e utilizzano molti programmatori (sia in manutenzione che in sviluppo) e non sembrano andare da nessuna parte in qualsiasi momento presto. In effetti, sono sicuro che la maggior parte di quelli che sto pensando sarà ancora disponibile nel 2020 e più a lungo.
Naturalmente, questo non è nemmeno il problema principale. Il problema principale è che molti concetti sono simili, o correlati, e non stai "ricominciando da zero" quando apprendi qualche nuova tecnologia. Ad esempio: una volta compresi i linguaggi di markup e di cosa si tratta, è molto facile apprenderne di nuovi. Quindi non importa così tanto che JSON è la nuova cosa nuova e tutto ciò che hai usato per anni è XML. È solo una questione di apprendimento della nuova sintassi, piuttosto che essere un non programmatore che non sa nulla di ciò che sono i linguaggi di markup o dei concetti interni che stanno dietro ai dati che rappresentano, ecc.
TL; DR: 1) C'è un sacco di tecnologia "obsoleta" in uso là fuori, ma dal momento che non è la cosa nuova sexy, non ne senti molto - ma è tutt'altro che inutile per chi è impiegato con esso. 2) I concetti di programmazione si basano l'uno sull'altro e si evolvono. Poche cose sono veramente qualcosa che devi imparare completamente da zero e dimenticare il vecchio.
Dipende tutto da cosa ti concentri sull'apprendimento, sulla memorizzazione e, in generale, sul tuo cervello. I dettagli potrebbero diventare obsoleti rapidamente, ma i principi dovrebbero durare molto più a lungo.
Esempi di cose di cui sono stato profondamente coinvolto recentemente:
Quelle cose che ho imparato in grassetto dureranno molto più a lungo delle cose sul lato sinistro. Se vuoi evitare le insidie dell'obsolescenza nella programmazione, concentrati sui principi .
Robert Harvey inchiodato questo , ma dopo averci pensato, sono costretto a lanciare brevità al vento e rispondere.
Devo aggiungere un disclaimer, non sono andato a scavare in Perl On Rails nel momento in cui è stato annunciato. Avevo la sensazione che funzionasse bene per l'uso molto localizzato per il quale è stato progettato e ne ha preso nota per futuro riferimento.
Inoltre non ho ceduto a oltre 50 permutazioni alla libreria C standard nel corso degli ultimi due decenni, vorrei poterli collegare, ma ora sembrano essenzialmente sfidati.
Insert a long rant here about believing everything that you read or hear.
Quando esce qualcosa di nuovo, prendilo e dai un'occhiata. Se dici "cazzo", rilasciala. Se dici "wow", miglioralo. Se non puoi contemplare una simile decisione, scegli i cervelli di chi può.
Giudica tutto sul merito tecnico solo . Vale la pena il tuo tempo significa che ti fa risparmiare tempo mentre ottieni il pollice dalla maggior parte dei tuoi colleghi.
Ora, affronterò la tua domanda direttamente:
Half of everything you know will be obsolete in 18 - 24 months, true or false?
Dovrai farcelo sapere tra 18 e 24 mesi. Le aziende pagano somme ingenti per convincere la gente a parlare di quanto sia grande il loro prodotto. Dobbiamo guadare non solo avviare le aziende ma creare giganti che sborsano ingenti somme di denaro per:
Potresti, ovviamente, formare le tue decisioni in base all'esperienza precedente e le tue prove con qualcosa di nuovo. Mentre lo fai, evita i datori di lavoro che hanno manager che distribuiscono comandamenti basati sul loro lettore RSS.
Sì, tuttavia ho questa nuova straordinaria biblioteca di bridge che è abbastanza intelligente da passare da Brooklyn a Londra in base alle tue impostazioni locali. Sarà enorme, vuoi entrare al piano terra?
La mia risposta è anzi intenzionalmente sardonica e forse l'anti booleano, ma in realtà? Per motivi di gestione delle eccezioni, la mia risposta è un clamoroso falso .
Se pensi che qualcosa sia tecnicamente valido, accettalo, altrimenti è come al solito. C è la mia lingua principale, funziona altrettanto bene di quasi vent'anni fa, mentre sono stato pagato più del doppio rispetto a quasi vent'anni fa.
Ammiro la tua forma concisa e le citazioni, ma questo sembra essere un esperimento di violazione .
Ben fatto:)
Dipende da cosa passi il tuo tempo ad imparare. Ho imparato Bourne shell e C programming nel 1980. Lo uso ancora tutti i giorni. D'altra parte, il tempo che ho trascorso ad apprendere le strutture del menu Compuserve è una perdita completa, e non era poi così terribilmente utile neanche all'epoca. Poi tra cose come pin-out dei cavi RS-232 e protocolli seriali: inutili oggi, ma essenziali per circa dieci anni della mia vita. Scegli le tecnologie con cui dedichi molto tempo.
Il principio è vero. Il valore effettivo è, a mia conoscenza, molto più grande.
Ricordo una presentazione di un programmatore pragmatico in cui dicevano circa sette anni, ma non riesco a individuarlo ora, quindi il valore potrebbe essere leggermente diverso.
Pensa solo a come sono cambiate le tecnologie: quindici anni fa il web era nuovo di zecca e tutti noi abbiamo provato a scrivere pagine web - forse anche con i tavoli - e una gif animata. Sette anni fa, AJAX è decollato. Oggi alcune persone scrivono giochi tipo Doom per telefoni cellulari.
La soluzione migliore è imparare cose generali che possono essere applicabili con la tecnologia successiva, invece di dire "Begone! I solo conosci Visual Basic!" (o l'equivalente in 15 anni).
Non penso che sia affatto accurato.
Una volta più vicino a vero - molto tempo fa, avevi poca scelta ma programmare a un livello relativamente basso di astrazione, il che significava conoscere un enorme numero di dettagli che non erano più rilevanti una nuova piattaforma.
Nel corso del tempo, tuttavia, sempre più programmi vengono eseguiti a livelli sempre più alti di astrazione. Un livello più alto di astrazione si traduce più o meno direttamente in una minore preoccupazione con i dettagli che sono suscettibili di cambiare e diventare rapidamente obsoleti.
Ovviamente ci sono persone che lavorano su cose come driver di periferica o piccoli sistemi embedded che devono ancora lavorare con un basso livello di astrazione. Al di fuori di aree come queste, tuttavia, ci sono scuse relativamente scarse per queste cose. Sì, molte persone fanno imparano un sacco di curiosità di cui non hanno mai bisogno, ma se in realtà usi davvero tali cose nel tuo codice, è molto probabile che tu non stia facendo molto bene decisioni. La maggior parte di queste cose può (e, soprattutto, dovrebbe) essere generalmente evitata.
Forse vero, forse no; tuttavia, anche se le cose reali apprese diventano obsolete poco dopo averle imparate, i concetti e le idee che stanno dietro possono essere utili ancora per molto.
Gran parte delle tue conoscenze rimarranno rilevanti durante la prova del tempo (anche se potrebbe essere necessario un aggiornamento nel tempo), fondamentalmente particolari, come le strutture dati ecc.
Naturalmente, se conosci il linguaggio di programmazione X e Y, la lingua di apprendimento Z sarà più facile che se non conoscessi né X né Y, quindi puoi usare le tue conoscenze precedenti per adattare nuove conoscenze.
Vale anche la pena ricordare che molte delle competenze rilevanti decenni fa sono ancora attuali oggi, anche tecnologie specifiche, come C (all'inizio del 1970, ancora attuale).
È possibile che metà di ciò che conosci diventerà obsoleto per un po 'di tempo, e probabilmente più della metà, ma ogni 18-24 mesi sembra un po' estremo.
I singoli fatti non hanno grande rilevanza. Li prendi, li capisci, li applico solo per il momento.
Ma così facendo ti insegna il processo di gestione dei fatti o almeno la gestione di un certo sottogruppo di fatti. Ho imparato un sacco di matematica a scuola, che in realtà non ho mai usato. Tuttavia ho imparato e addestrato il pensiero matematico.
Ho lavorato come programmatore web con Ruby on Rails. E mentre al momento non scrivo siti web, ha influenzato pesantemente il mio codice di pensiero e mi ha fatto diventare un programmatore C ++ migliore. (Usind più STL per esempio).
Lo stesso vale per l'apprendimento di Racket. Non ho mai scritto alcun programma di grandi dimensioni, ma mi ha dato un nuovo punto di vista da applicare su alcuni spazi problema.
Si tratta solo di allenare la tua mente ...
Penso che puoi facilmente confutare la dichiarazione giocando con l'oggetto tu in "metà di tutto ciò che conosci".
Esiste una certa distribuzione delle conoscenze, alcune delle quali diventeranno obsolete (indipendentemente dal tasso.) Quindi, se una determinata persona contiene solo la conoscenza della metà di questo spettro che rimarrà dopo 18-24 mesi, interromperà comunicato.
Ecco una versione migliore della frase: metà di tutto ciò che hai imparato oggi (o questa settimana, o questo mese o quest'anno) sarà obsoleto in un anno o due. È vero: impari a fare qualcosa nella versione 5 di uno strumento, e quando esce 6 lo fa automaticamente, o impari a fare qualcosa in un linguaggio che non si impiglia, quindi non lo usi mai più. Ma l'altra metà di ciò che impari ogni giorno rimane con te e cresce, ed è ciò che rende uno sviluppatore di 20 anni di esperienza migliore di uno di due anni di esperienza.
C'è una pepita di verità o rilevanza qui, ma penso che sia presentata in modo inaccurato.
Un modo migliore per presentare questo sarebbe
How much of the knowledge you use today did you have 18-24 months ago?
o
In 18-24 months time, how much of the knowledge that you will applying to do you already know? How much will you need to learn from today in order to complete those tasks?
Potrebbe dipendere dal campo in cui lavori, ma so che lavoro costantemente sulla nuova tecnologia. Ogni progetto sembra avere una grande quantità di nuove cose che ho bisogno di imparare - nuovi framework e ampli; schemi, nuovi approcci a problemi leggermente diversi, o solo nuovi strumenti che sono (presumibilmente!) migliori di quelli che abbiamo usato in precedenza.
Se ogni sei mesi di progetto è richiesto solo il 12,5% di nuove conoscenze, allora oltre due anni il 50% delle conoscenze utilizzate sarà "nuovo".
Detto questo, questo non è molto significativo o accurato.
Oh Dio, una risposta così meravigliosa, molto sensata, sopra. Bel lavoro.
Detto semplicemente, se è una moda o una tendenza calda, se sei un buon programmatore, ne leggerai le informazioni, quindi tornerai a ciò che normalmente fai o lavori.
A meno che non ci sia qualcosa di vitale in ciò che fai, o nuove pratiche che abbiano senso per te.
Solo perché qualcosa è nuovo, un po 'nuovo o un po' vecchio, non lo rende la soluzione da usare per niente.
Ho una frase semplice, quella copertina è tutto questo.
"Se funziona, usalo"
Ciò significa, se questa nuova tecnologia è incredibilmente interessante, ma non tutto ciò che rende il tuo lavoro più produttivo, o di qualità superiore, o meno soggetto a errori, o risolvere problemi tecnici come soluzioni mobili o client / server. È meglio leggerlo, quindi ignorarlo fino a quando non ne hai un uso pratico.
Ho visto e letto più persone che perdono tempo, cercano di trovare la cosa nuova e calda, quindi usano la cosa nuova e calda. Che di solito finisce per essere uno spreco totale di tempo e denaro.
È importante imparare, praticare e migliorare sempre le tue abilità e abilità.
Tuttavia dovresti imparare cosa è utile o cosa ti offre prospettive diverse per risolvere i problemi che normalmente hai.
Ma a parte questo, dovresti tornare alle basi per diventare un programmatore fantastico.
Io faccio le migliori pratiche del buon senso, che tutti impariamo dalle nostre esperienze. Non perdere tempo in cose che sono semplicemente fantastiche.
Perché sinceramente, il bello non è bello.
Ho sentito questa frase attribuita ai campi di ingegneria, non alla programmazione. Più in particolare, ho sentito, "Quando si riceve una laurea in ingegneria, i primi due anni di studio si baseranno sulla vecchia tecnologia." (O qualcosa del genere.)
Non penso che si applichi alla programmazione. L'unico modo possibile con cui ho potuto vederlo è quando le funzionalità sono deprecate o rimosse da un linguaggio / libreria di programmazione / altro.
La piattaforma tecnologica media resta in agguato da qualche parte tra i 10 ei 25 anni, quindi questo mi sembra piuttosto improbabile, anche se non consideri completamente che la conoscenza dei pattern persista attraverso le tecnologie. Se sei su una qualsiasi delle principali piattaforme, puoi contare sul fatto che lo stack è popolare per almeno 5 o 6 anni prima che inizi a svanire. Conosco programmatori che codificano in RPG da 30 anni usando strumenti hardware e software quasi identici.
Leggi altre domande sui tag skills