"La metà di tutto ciò che sai sarà obsoleto tra 18-24 mesi" = (Vero o Falso?) [Chiuso]


33

Mi sono appena imbattuto in questo e mi chiedevo se qualcuno ha un modo per provare o confutare questa affermazione:

Qualcosa da tenere a mente ... qual è l'emivita della conoscenza nell'high tech? Traccia con la Legge di Moore: metà di tutto ciò che sai sarà obsoleto tra 18-24 mesi.

FONTE: nella risposta di Craig Trader a questa domanda " Qual è la cosa più efficace che hai fatto per migliorare le tue capacità di programmazione? "


2
Non vedo come questo possa mai essere provato.
Oded,

50
Statement = (True or False)Sì.
glasnt

3
Penso che dipende da quello che sai.
LennyProgrammers

3
@glasnt: in quel caso è sempre vero: /
Simon

2
La metà di tutto ciò che so è ormai obsoleta.
JD Isaacks,

Risposte:


131

Questa affermazione si applica solo alle tecnologie effimere, che dovresti comunque imparare solo se necessario. Detto questo, ne imparerai molti durante la tua carriera.

I principi e le tecniche di programmazione fondamentali sono eterni.


5
Deliziosamente laconico. +1
Tim Post

27
@Steven A. Lowe +1 per aver ammesso di aver cercato "effimero"
Tim Post

2
È incredibile come una tecnologia effimera che hai trascorso 7 anni imparando e usando possa diventare quando perde in Oracle (o Linux). Certo, ciò che ho imparato sulla costruzione e la distribuzione di applicazioni non è svanito, ma a nessuno importa di Pick, Ultrix o di qualsiasi numero di tecnologie in perdita.
Craig Trader,

71

Senza senso

Le persone che dicono cose del genere stanno solo cercando di essere sensazionaliste, oppure stanno imparando le cose sbagliate.


8
+1 per "Stanno imparando le cose sbagliate"
Martin

4
Sai, penso davvero che dovresti lasciar perdere e .. aspettare .. SQUIRREL!
Tim Post

+1 per notare il sensazionalismo prevalente in questo settore.
Rei Miyasaka,


17

Il miglior (peggio?) Test a cui riesco a pensare è di ripensarci solo un anno. Quanta conoscenza di 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 altamente sospetto, poiché la maggior parte delle conoscenze di programmazione e tecniche che utilizzo quotidianamente è stata acquisita in 5-10 anni.

Ora, se stai sviluppando qualcosa come una piattaforma di telefonia mobile, forse è un gioco con la palla diverso.


2
No, il cellulare non è diverso da qualsiasi altra cosa. Tutte le abilità vitali che usi quotidianamente durano anni. Immagino che sia facile dimenticare le abilità quotidiane perché sono semi-automatiche.
Jim

1
I fondamenti non cambiano, ma le API e le tecniche cambiano. Se programmi un'app mobile mentre pensi a un desktop, probabilmente non avrai qualcosa di utilizzabile.
jmort253

Secondo Apple, l'85% di MacOS X e iOS sono identici.
gnasher729,

15

Nella mia esperienza, c'è una grande disconnessione tra l'immagine mediatica / pubblica di quale tecnologia è la Nuova Nuova Cosa e ciò che viene effettivamente utilizzato nel mondo reale là fuori.

Prendi qualcosa come Visual C ++ / MFC nello spazio dell'applicazione 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 un sacco di progetti e lavori del mondo reale là fuori che vengono mantenuti e che vengono mantenuti - e probabilmente sarà mantenuto per anni e decenni a venire. Stavo per dare COBOL come esempio, ma questo sarebbe teoricamente parlando - in realtà conosco molto bene l'esempio VC ++ / MFC personalmente.

In sostanza, non è che le tecnologie diventino inutili e inutilizzate quando diventano "obsolete", è più che non sono più viste come il modo più aggiornato di fare le cose e avviare nuovi progetti. Ma la disattivazione di grandi sistemi software del mondo reale che non si sono rotti e non necessitano di riparazioni avviene molto più lentamente. Molti dei progetti Visual C ++ / MFC a cui ho lavorato (che è iniziato nei primi anni '90) sono ancora molto vivi e impiegano molti programmatori (sia nella manutenzione che nei nuovi sviluppi) e non sembrano andare da nessuna parte in qualsiasi momento presto. In effetti, sono sicuro che la maggior parte di quelli a cui sto pensando sarà ancora 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 alcune nuove tecnologie. Ad esempio: una volta compresi i linguaggi di markup e di cosa parlano, è molto facile impararne di nuovi. Quindi non importa tanto che JSON sia la nuova novità e tutto ciò che hai usato per anni è XML. È solo una questione di apprendimento di una nuova sintassi - al contrario di essere un non programmatore che non sa nulla di quali siano persino i linguaggi di markup o dei concetti interni alla base dei dati che rappresentano, ecc.

TL; DR: 1) C'è molta tecnologia "obsoleta" in uso là fuori, ma dal momento che non è la cosa nuova sexy, non ne senti parlare molto - ma è tutt'altro che inutile per coloro che ne sono impiegati . 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.


4
MFC - che dolore!
Giobbe

@Job - Oh sì.
Tabelle Bobby

Lol, non è tutto un dolore: P
crosenblum

Ehi, sto lavorando anche su VC ++ / MFC!
David Thornley,

2
+1 Soprattutto per sottolineare che le cose non smettono di essere utilizzate, ma semplicemente di far parte dello zeitgeist.
Orbling

12

Tutto dipende da cosa ti concentri sull'apprendimento, la memorizzazione e in generale riempiendo il tuo cervello. I dettagli potrebbero diventare obsoleti rapidamente, ma i principi dovrebbero durare molto più a lungo.

Esempi di cose in cui sono stato profondamente coinvolto di recente:

  • Sintassi generica Java vs. contenitori tipizzati
  • Tipi di dati MySQL, limiti di archiviazione, ecc. Rispetto ai principi di scalabilità del database
  • Livello di astrazione del database leggero Ho contribuito a creare principi di rigidità / flessibilità di astrazione del database

Quelle cose che ho imparato in grassetto dureranno molto più a lungo di quelle a sinistra. Se vuoi evitare le insidie ​​dell'obsolescenza nella programmazione, concentrati sui principi .


11

Robert Harvey ha inchiodato questo , ma dopo averci pensato, sono costretto a gettare brevità al vento e rispondere.

Devo aggiungere un disclaimer, non sono andato a scavare in Perl On Rails nel momento in cui è stato annunciato. Ho avuto la sensazione che funzionasse bene per l'uso molto localizzato per cui era stato progettato e ne ho preso nota per riferimento futuro.

Inoltre non ho ceduto a oltre 50 permutazioni alla libreria C standard nel corso degli ultimi due decenni, vorrei poter collegarmi a loro, ma ora sembrano essere esistentemente messi alla prova.

Inserisci qui una lunga dichiarazione sul credere a tutto ciò che leggi o ascolti.

Quando esce qualcosa di nuovo, prendilo e dai un'occhiata. Se dici 'ick', lascialo cadere. Se dici "wow", miglioralo. Se non riesci a contemplare una tale decisione, vai a scegliere il cervello delle persone che possono.

Giudica tutto da solo sul merito tecnico . Vale la pena dedicare tempo a farti risparmiare tempo dalla maggior parte dei tuoi colleghi.

Ora affronterò direttamente la tua domanda:

La metà di tutto quello che sai sarà obsoleta tra 18 - 24 mesi, vera o falsa?

Dovrai farcelo sapere tra 18 - 24 mesi. Le aziende pagano ingenti somme per convincere le persone a parlare di quanto sia bello il loro prodotto. Dobbiamo superare non solo le start-up, ma anche i giganti affermati che sborsano ingenti somme di denaro per:

  • Hanno [sic] rispettato blogger rigurgitare un passo di vendita ai loro lettori
  • Invia costose attrezzature gratuite di marca per ottenere il posizionamento del marchio dove potrebbe essere notato attraverso il vantarsi o l'uso
  • Paga le persone per assicurarti di vedere una "soluzione funzionante" nella top 10 di Google durante la ricerca di un problema
  • Paga i "premi" dai siti delle "prime dieci directory" e fingi che siano autorevoli
  • Una vera e propria pletora di altri mezzi per convincere le persone a smettere di pensare e seguire semplicemente la folla

Ovviamente, potresti prendere le tue decisioni sulla base dell'esperienza precedente e delle prove con qualcosa di nuovo. Mentre lo fai, evita i datori di lavoro che hanno manager che distribuiscono i comandamenti in base al loro lettore RSS.

Ho, tuttavia, questa straordinaria nuova libreria di costruzione di ponti che è abbastanza intelligente da passare da Brooklyn a Londra in base al tuo paese. Sarà enorme, vuoi entrare al piano terra?

La mia risposta è davvero intenzionalmente sardonica e forse l'anti booleana, ma davvero? Ai fini della gestione delle eccezioni, la mia risposta è un falso clamoroso .

Se pensi che qualcosa sia tecnicamente valido, abbraccialo, altrimenti è come al solito. C è la mia lingua principale, funziona esattamente come quasi due decenni fa, mentre mi pagano oltre il doppio rispetto a quasi due decenni fa.

Ammiro la tua forma concisa e le citazioni, ma questo sembra essere un esperimento di violazione .

Molto bene :)


8

Dipende da cosa passi il tuo tempo ad imparare. Ho imparato la shell Bourne e la programmazione in C nel 1980. Lo uso ancora ogni giorno. D'altra parte, il tempo che ho trascorso a studiare le strutture dei menu di Compuserve è una perdita completa, e non era davvero terribilmente utile nemmeno in quel momento. Poi ci sono cose intermedie come pin-out del cavo RS-232 e protocolli seriali: inutili oggi, ma essenziali per circa dieci anni della mia vita. Scegli con attenzione le tecnologie a cui dedichi molto tempo.


Si noti che la comunicazione seriale è ancora con noi. Solo non i cavi.

RS-232 è vivo e vegeto e vive nello spazio incorporato.
Tim Williscroft,

7

Il principio è vero. Il valore reale è - per quanto ne so - molto più grande.

Ricordo una presentazione di Pragmatic Programmer in cui dicevano circa sette anni, ma non riesco a individuarla 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 abbiamo provato a scrivere pagine web - forse anche con le tabelle - e un gif animato. Sette anni fa, AJAX è decollato. Oggi alcune persone scrivono giochi simili a Doom per telefoni cellulari.

La tua scommessa migliore è imparare cose generali che possono essere applicabili con la prossima tecnologia che viene invece di dire "Inizia! Conosco solo Visual Basic!" (o l'equivalente in 15 anni).


Ho provato il buzz di fizz in VB, ma .. non è riuscito ... :(
Tim Post

@Tim, aspetta 10 anni e spero che non dovrai ...

5

Non credo sia affatto accurato.

Una volta era più vicino al vero: molto tempo fa, non avevi altra scelta che programmare a un livello di astrazione relativamente basso, il che significava conoscere un numero enorme di dettagli che non erano più rilevanti su una nuova piattaforma.

Nel corso del tempo, tuttavia, sempre più programmi vengono effettuati a livelli sempre più alti di astrazione. Un livello più elevato di astrazione si traduce più o meno direttamente in una minore preoccupazione per i dettagli che possono cambiare e diventare rapidamente obsoleti.

Ci sono ovviamente persone che lavorano su cose come driver di dispositivo o piccoli sistemi embedded che devono ancora lavorare a un basso livello di astrazione. Al di fuori di queste aree, tuttavia, ci sono scuse relativamente scarse per queste cose. Sì, un sacco di gente fare imparare un sacco di curiosità non hanno mai bisogno, ma se siete veramente utilizzare tale roba nel codice molto, le probabilità sono piuttosto buone che non sei solo facendo molto buone decisioni. Molte di queste cose possono (e, soprattutto, dovrebbero) essere generalmente evitate.


Ricordo quando GNU si avviava e diventava praticabile, e tutti i "ragazzi fighi" lo usavano. Ma quello era il giorno in cui i "ragazzi fighi" in realtà non avevano nemmeno un metodo, ma un certo grado di pensiero sulla loro follia. Devo dire che, ai giorni nostri, hai ragione.
Tim Post

4

Forse vero, forse no; tuttavia, anche se le cose reali apprese diventano obsolete subito dopo averle imparate, i concetti e le idee che stanno dietro possono essere utili per molto più tempo.


Bene, diventano un quadro di riferimento o, nel peggiore dei casi, un anti-schema. :)
ideasman42

4

Se così fosse, solo 5,39x10 -6 di Mythical Man-Month sarebbero rilevanti oggi. Dato che ci sono pochissimi principi chiave che i dettagli di Fred Brooks hanno datato in modo significativo o si sono rivelati fondamentalmente falsi.


1
Non sono così sicuro. Alcune delle cose sono superate (qualcuno usa davvero il Chief Programmer Team al giorno d'oggi?), Pochissime sono assolutamente sbagliate (la sua conclusione sul nascondere le informazioni è quella che viene in mente), e alcune cose sono state stabilite nel cultura popolare, e probabilmente non sono più rilevanti delle argomentazioni di Sigmund Freud secondo cui ci sono parti della nostra mente di cui siamo incoscienti. Vale ancora la pena di leggerlo, e ovviamente ci sono molto più di cinque parti su un milione (due lettere?) Che sono rilevanti.
David Thornley,

Buon commento, (+1) per rispondere, direi che il team del programmatore capo non è un principio ma una risposta. È vero che aveva torto sul nascondere le informazioni; ma lo ammette anche nell'edizione del 20 ° anniversario. Direi che in gran parte di ciò che Brooks ha affermato non si è affermato nella cultura dello sviluppo del software o non avremmo un tasso di fallimento così estremo nello sviluppo del software.
AlexC

Penso che mi stavo avvicinando alla domanda su quanto del libro sia rilevante oggi. Il capitolo CPT non è pertinente, ad esempio, ma il capitolo sugli orari è morto e ovviamente non fa parte della cultura attuale. L'edizione del 20 ° anniversario è quella da ottenere, ovviamente, in parte grazie al suo saggio "No Silver Bullet". (Ciò è emerso 16 anni fa, e quindi secondo il principio nel titolo dovrebbe essere rilevante circa lo 0,4%, e penso che possiamo concordare che è più pertinente di così.)
David Thornley

L'ultima volta che ho sentito, IBM non ha utilizzato i team di Chief Programmer a causa della carenza di persone che potrebbero essere Chief Programmers piuttosto che un fallimento nel metodo. Sono stato un programmatore capo che funziona abbastanza bene.
Tim Williscroft,

3

Gran parte delle tue conoscenze rimarranno rilevanti durante la prova del tempo (anche se potrebbe essere necessario un aggiornamento nel tempo), fondamenti specifici, come strutture di dati ecc.

Ovviamente, se conosci il linguaggio di programmazione X e Y, imparare il linguaggio Z sarà più facile che se non conoscessi né X o Y, quindi puoi usare le tue conoscenze precedenti per adattare nuove conoscenze.

Vale anche la pena ricordare che molte abilità rilevanti decenni fa sono ancora rilevanti oggi, anche tecnologie specifiche, come la C (inizio 1970, ancora oggi rilevante).

È possibile che metà di ciò che sai sarà obsoleto nel tempo, e probabilmente più della metà, ma ogni 18-24 mesi sembra un po 'estremo.


2

I fatti singoli non hanno grande rilevanza. Li prendi, li capisci, li applichi solo per il momento.

Ma farlo ti insegna il processo di gestione dei fatti o almeno la gestione di un certo sottoinsieme 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 fortemente influenzato il mio codice di pensiero e mi ha reso un programmatore C ++ migliore. (Usind più STL per esempio).

Lo stesso vale per l'apprendimento della racchetta. Non ho mai scritto programmi di grandi dimensioni, ma mi ha dato un nuovo punto di vista da applicare su alcuni problemi.

Si tratta solo di allenare la tua mente ...


2

Penso che puoi facilmente confutare l'affermazione giocando con l'oggetto che hai nella "metà di tutto ciò che conosci".

Vi è una certa distribuzione della conoscenza, alcune delle quali diventeranno obsolete (indipendentemente dalla velocità). Quindi, se una determinata persona contiene solo conoscenza della metà di questo spettro che rimarrà dopo 18-24 mesi, infrangerà l'affermazione.


2

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 tra un anno o due. È vero: impari come fare qualcosa nella versione 5 di uno strumento e quando 6 viene pubblicato lo fa automaticamente, oppure impari come fare qualcosa in una lingua che non si attacca, quindi non la 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 quello di due anni di esperienza.


1

C'è una pepita di verità o rilevanza qui, ma penso che sia presentato in modo impreciso.

Un modo migliore per presentare questo sarebbe

Quanta conoscenza hai usato oggi 18-24 mesi fa?

o

Tra 18-24 mesi, quante delle conoscenze a cui farai domanda conosci già? Quanto dovrai imparare da oggi per completare quei compiti?

Potrebbe dipendere dal campo in cui stai lavorando, ma so che lavoro costantemente su nuove tecnologie. Ogni progetto sembra avere una grande quantità di nuove cose che devo imparare: nuovi schemi e schemi, nuovi approcci a problemi leggermente vari o solo nuovi strumenti che sono (presumibilmente!) Migliori di quelli che abbiamo usato in precedenza.

Se ogni progetto semestrale richiede solo il 12,5% di nuove conoscenze, allora in due anni il 50% delle conoscenze utilizzate sarà "nuovo".

Detto questo, questo non è molto significativo o accurato.

  • Le cose "vecchie" non sono obsolete.
  • Le "nuove" cose si sovrappongono in modo massiccio alle cose vecchie
  • I principi sono generalmente trasferibili

1

Oh Dio, la risposta così meravigliosa e di buon senso è sopra. Bel lavoro.

Detto in parole povere, se si tratta di una moda o tendenza in voga, se sei un buon programmatore, leggerai a riguardo, quindi tornerai a ciò che fai normalmente o con cui 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 nulla.

Ho una frase semplice, quella copertina è tutto questo.

"Se funziona, usalo"

Ciò significa che se questa nuova tecnologia è straordinariamente interessante, ma non nulla che renda il tuo lavoro più produttivo, o di qualità superiore, o meno soggetto a errori, o risolva problemi tecnici come soluzioni mobili o client / server. È meglio leggerlo, quindi ignorarlo, fino a quando non ne avrai un uso pratico.

Ho visto e letto più persone perdere tempo, cercando di trovare la nuova cosa calda, quindi usare la nuova cosa calda. Che di solito finisce per essere una totale perdita di tempo e denaro.

È importante imparare sempre, e praticare e migliorare il tuo mestiere e le tue abilità.

Tuttavia, dovresti imparare ciò che è utile o ciò che ti offre diverse prospettive per risolvere i problemi che hai normalmente.

Ma a parte questo, dovrebbe tornare alle basi di essere un programmatore fantastico.

  1. http://www.joelonsoftware.com/articles/fog0000000043.html
  2. Pianificazione
  3. Processo di gestione del progetto: per assicurarsi che non venga avviato alcun codice prima che venga elaborato un piano chiaro e approvato dalle persone che ti hanno chiesto lavoro.
  4. Migliora la leggibilità del tuo codice - Perché lavoriamo tutti sul codice di altre persone
  5. Organizzati, sii efficiente

Sono le migliori pratiche di buonsenso, che tutti impariamo dalle nostre esperienze. Non perdere tempo con cose fantastiche.

Perché onestamente, cool non è semplicemente cool.


0

Ho sentito questa frase attribuita ai campi dell'ingegneria, non alla programmazione. Più specificamente, ho sentito: "Quando riceverai una laurea in ingegneria, i tuoi primi due anni di studio saranno basati sulla vecchia tecnologia". (O qualcosa in tal senso.)

Non penso che si applichi affatto alla programmazione. L'unico modo possibile per vederlo relativo è quando le funzionalità sono deprecate o rimosse da un linguaggio di programmazione / libreria / qualunque cosa.


0

La piattaforma tecnologica media si attesta da qualche parte tra i 10 e i 25 anni, quindi questo mi sembra abbastanza improbabile, anche se si ignora del tutto il fatto che la conoscenza dei modelli persiste attraverso le tecnologie. Se ti trovi su qualsiasi tipo di piattaforma principale, puoi contare sul fatto che lo stack è popolare per almeno 5 o 6 anni prima ancora che inizi a svanire. Conosco programmatori che hanno codificato in RPG per 30 anni usando strumenti hardware e software quasi identici.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.