«La moitié de tout ce que vous savez sera obsolète dans 18 à 24 mois» = (vrai ou faux?) [Fermé]

Je suis juste tombé sur cela et je me demandais si quelqu'un avait un moyen de prouver ou d'infirmer cette affirmation:

Il faut garder à l'esprit… quelle est la demi-vie de la connaissance dans la haute technologie? Il suit la loi de Moore: la moitié de tout ce que vous savez sera obsolète dans 18 à 24 mois.

SOURCE: Dans la réponse de Craig Trader à cette question " Quelle est la chose la plus efficace que vous ayez faite pour améliorer vos compétences en programmation? "

Cette déclaration ne s'applique qu'aux technologies éphémères, que vous ne devriez apprendre que de toute façon, au besoin. Cela dit, vous allez en apprendre beaucoup au cours de votre carrière.

Les principes et techniques de programmation fondamentaux sont éternels.

Absurdité

Les gens qui disent des choses comme celles-là n'essayent que d'être sensationnalistes, sinon ils apprennent les mauvaises choses.

Le meilleur (pire?) Test auquel je puisse penser est simplement de revenir en arrière un an. Quelle quantité de connaissances en programmation que vous utilisez chaque jour a été apprise au cours des 18 à 24 mois précédents? De plus, combien a été inventé au cours des 18-24 mois précédents? Le principe me semble hautement suspect, car la majorité des connaissances techniques et de la programmation que j'utilise quotidiennement ont été acquises sur une période de 5 à 10 ans.

Maintenant, si vous développez quelque chose comme une plate-forme de téléphone mobile, c'est peut-être un jeu de balle différent.

D'après mon expérience, il y a un fossé énorme entre l'image médiatique / publique de la technologie qui est la nouvelle chose à voir et ce qui est réellement utilisé dans le monde réel.

Prenez quelque chose comme Visual C ++ / MFC dans l'espace d'application de bureau. Bien que cela puisse sembler vieux et obsolète, et probablement pas quelque chose qu'un nouveau programmeur devrait apprendre en ce moment pour le développement de postes de travail, il y a encore énormément de projets du monde réel et d’emplois écrits dans ce projet qui sont maintenus - et sera probablement maintenu pour les années et les décennies à venir. J'allais donner l'exemple de COBOL, mais ce serait parler théoriquement - je connais en fait très bien l'exemple VC ++ / MFC personnellement.

Essentiellement, ce n'est pas que les technologies deviennent inutiles et inutilisées quand elles deviennent "obsolètes", c'est plutôt qu'elles ne sont plus considérées comme la manière la plus moderne de faire les choses et de démarrer de nouveaux projets. Mais le déclassement de grands systèmes logiciels du monde réel qui ne sont pas en panne et qui n'ont pas besoin d'être réparés se produit beaucoup plus lentement. La plupart des projets Visual C ++ / MFC sur lesquels j'ai travaillé (qui ont débuté au début des années 90) sont encore bien vivants et emploient de nombreux programmeurs (en maintenance et en développement) et ne semblent aller nulle part. à tout moment bientôt. En fait, je suis sûr que la plupart de celles auxquelles je pense resteront en 2020 et plus longtemps.

Bien sûr, ce n’est même pas le problème principal. Le problème principal est que beaucoup de concepts sont similaires, ou liés, et que vous ne commencez pas à zéro lorsque vous apprenez une nouvelle technologie. Par exemple: une fois que vous avez compris les langages de marquage et leur contenu, il est très facile d’en apprendre de nouveaux. Il importe donc peu que JSON soit la nouvelle nouveauté et que tout ce que vous utilisiez depuis des années soit XML. Il s’agit simplement d’apprendre une nouvelle syntaxe - par opposition à un non-programmeur qui ne sait rien de ce que sont les langages de balisage, ni des concepts internes à la base des données qu’ils représentent, etc.

TL; DR: 1) Il y a beaucoup de technologies "obsolètes" en usage sur le marché, mais comme ce n'est pas une nouveauté sexy, on n'en parle pas beaucoup - mais c'est loin d'être inutile pour ceux qui l'utilisent . 2) Les concepts de programmation se superposent et évoluent. Peu de choses sont vraiment quelque chose que vous devez apprendre complètement à partir de zéro et oublier l'ancien.

Tout dépend de ce que vous concentrez sur l'apprentissage, la mémorisation et le remplissage général de votre cerveau. Les détails peuvent devenir rapidement obsolètes, mais les principes devraient durer beaucoup plus longtemps.

Exemples de choses dans lesquelles j'ai été profondément impliqué récemment:

• Syntaxe générique Java et conteneurs typés
• Types de données MySQL, limites de stockage, etc. par rapport aux principes d'évolutivité de la base de données
• Couche d'abstraction de base de données légère que j'ai aidé à créer et principes de rigidité / flexibilité d'abstraction de base de données

Les choses que j'ai apprises en gras dureront beaucoup plus longtemps que celles de gauche. Si vous voulez éviter les pièges de l'obsolescence dans la programmation, concentrez-vous sur les principes .

Robert Harvey a bien compris , mais après y avoir réfléchi, je suis obligé de faire preuve de brièveté et de répondre.

Je dois ajouter un disclaimer, je ne suis pas allé fouiller dans Perl On Rails au moment de l'annonce. J'avais le sentiment que cela fonctionnait bien pour l'utilisation très localisée pour laquelle il avait été conçu et en prenais note pour pouvoir le consulter ultérieurement.

Je n'ai pas non plus succombé dans plus de 50 permutations de la bibliothèque standard C au cours des deux dernières décennies. J'aimerais pouvoir y accéder, mais elles semblent maintenant être contestées de manière existentielle.

Insérez ici un long discours sur le fait de croire tout ce que vous lisez ou entendez.

Quand quelque chose de nouveau sort, attrapez-le et jetez un coup d'oeil. Si vous dites "beurk", laissez tomber. Si vous dites «wow», améliorez-le. Si vous ne pouvez pas envisager une telle décision, allez choisir le cerveau de ceux qui le peuvent.

Jugez tout sur le seul mérite technique . Valeur de votre temps signifie que cela vous fait gagner du temps tout en obtenant un coup de pouce de la majorité de vos pairs.

Maintenant, je vais répondre directement à votre question:

La moitié de tout ce que vous savez sera obsolète dans 18 à 24 mois, vrai ou faux?

Vous devrez nous le faire savoir dans 18 à 24 mois. Les entreprises paient des sommes substantielles pour faire comprendre à leurs clients à quel point leur produit est excellent. Nous devons traverser non seulement des entreprises en démarrage, mais également des géants établis qui déboursent des sommes considérables pour:

• Les blogueurs respectés font-ils régulariser leur argumentaire avec leurs lecteurs?
• Envoyez du matériel gratuit coûteux de marque pour gagner le placement de marque où il pourrait être remarqué par vantardise ou utiliser
• Payez les gens pour vous assurer que vous voyez une "solution efficace" dans le top 10 de Google lorsque vous recherchez un problème.
• Payer pour les "récompenses" des sites "Top dix annuaires" et prétendre que ceux-ci font autorité
• Une véritable pléthore d'autres moyens pour convaincre les gens d'arrêter de penser et de suivre la foule

Vous pouvez bien entendu prendre vos propres décisions en fonction de votre expérience et de vos essais avec quelque chose de nouveau. Ce faisant, évitez les employeurs qui ont des gestionnaires qui distribuent des commandements basés sur leur lecteur RSS.

Cependant, j'ai cette nouvelle bibliothèque étonnante de bâtiment de pont qui est assez intelligente pour basculer entre Brooklyn et Londres en fonction de vos paramètres régionaux. Ça va être énorme, voulez-vous entrer au rez-de-chaussée?

Ma réponse est en effet intentionnellement sardonique et peut-être l'anti-booléen, mais vraiment? Aux fins de la gestion des exceptions, ma réponse est une fausse flagrante .

Si vous pensez que quelque chose est techniquement valable - adoptez-le, sinon les choses se passent normalement. C est ma langue maternelle, ça marche aussi bien qu’il ya presque deux décennies, alors que je suis payé deux fois plus cher qu’il ya presque deux décennies.

J'admire votre forme concise et vos citations, mais cela semble être une expérience de rupture .

Bien joué :)

Cela dépend de ce que vous passez votre temps à apprendre. J'ai appris la programmation Bourne Shell et C en 1980. Je l'utilise encore tous les jours. D'autre part, le temps que j'ai passé à apprendre les structures de menus Compuserve est une perte totale et ce n'était pas vraiment utile, même à cette époque. Ensuite, il y a des choses entre les branchages de câbles RS-232 et les protocoles série: inutiles aujourd’hui, mais essentielles pendant une dizaine d’années de ma vie. Choisissez les technologies auxquelles vous consacrez beaucoup de temps.

Le principe est vrai. La valeur réelle est - à ma connaissance - beaucoup plus grande.

Je me souviens d'une présentation de Pragmatic Programmer où ils ont parlé d'environ sept ans, mais je ne peux pas la localiser maintenant, donc la valeur pourrait être légèrement différente.

Imaginez comment les technologies ont changé: il y a quinze ans, le Web était tout neuf et nous avions tous essayé d'écrire des pages Web - peut-être même avec des tableaux - et un gif animé. AJAX a décollé il y a sept ans. Aujourd'hui, certaines personnes écrivent des jeux de type Doom pour les téléphones portables.

Votre meilleur pari est d’apprendre des choses générales qui peuvent être appliquées avec la technologie suivante au lieu de dire "Commencez! I ne connais que Visual Basic!" (ou l’équivalent dans 15 ans).

Je ne pense pas que ce soit exact du tout.

C'était autrefois plus proche de la vérité - il y a bien longtemps, vous n'aviez d'autre choix que de programmer à un niveau d'abstraction relativement faible, ce qui impliquait de connaître un grand nombre de détails qui n'étaient plus pertinents sur une nouvelle plate-forme.

Au fil du temps, cependant, de plus en plus de programmes sont réalisés à des niveaux d'abstraction de plus en plus élevés. Un niveau d'abstraction plus élevé se traduit plus ou moins directement par une préoccupation moindre des détails susceptibles de changer et de devenir rapidement obsolètes.

Il est évident que certaines personnes travaillant sur des éléments tels que les pilotes de périphériques ou les systèmes embarqués minuscules doivent encore travailler à un niveau d'abstraction faible. En dehors de telles zones, cependant, il y a relativement peu d'excuses pour ce genre de choses. Oui, beaucoup de gens faire apprendre beaucoup d'anecdotes qu'ils ne ont besoin, mais si vous êtes vraiment en utilisant une telle substance dans votre code beaucoup, les chances sont assez bonnes que vous êtes tout simplement pas faire de très bonnes décisions. La plupart de ces choses peuvent (et surtout, devraient) être généralement évitées.

Peut-être vrai, peut-être pas; Cependant, même si les connaissances acquises deviennent rapidement obsolètes, les concepts et les idées qui les sous-tendent peuvent être utiles beaucoup plus longtemps.

Si c'était le cas, seuls 5,39 x 10 ^-6 de Mythical Man-Month seraient pertinents aujourd'hui. Comme il y a très peu de principes clés dans les détails de Fred Brooks qui sont datés de manière significative ou qui se sont révélés fondamentalement faux.

Une grande partie de vos connaissances restera pertinente au cours de l’épreuve du temps (bien qu’elle puisse nécessiter quelques mises à jour au fil du temps), en particulier des principes fondamentaux, tels que les structures de données, etc.

Bien sûr, si vous connaissez les langages de programmation X et Y, l'apprentissage de la langue Z sera plus facile que si vous ne connaissiez ni X ni Y, vous pouvez donc utiliser vos connaissances antérieures pour adapter de nouvelles connaissances.

Il convient également de mentionner que de nombreuses compétences qui étaient pertinentes il y a plusieurs décennies sont toujours d'actualité, même des technologies spécifiques, telles que C (début des années 1970, sont toujours d'actualité).

Il est possible que la moitié de ce que vous savez devienne obsolète au fil du temps, et probablement plus que la moitié, mais chaque 18-24 mois semble un peu extrême.

Les faits simples n'ont pas une grande pertinence. Vous les prenez, les comprenez, appliquez-les pour le moment seulement.

Mais cela vous apprend le processus de traitement des faits ou du moins un certain sous-ensemble de faits. J'ai appris beaucoup de mathématiques à l'école que je n'ai jamais utilisées. Pourtant, j'ai appris et formé la pensée mathématique.

J'ai travaillé en tant que programmeur Web avec Ruby on Rails. Et bien que je n’écrive pas de sites Web pour le moment, cela a fortement influencé ma réflexion sur le code et fait de moi un meilleur codeur C ++. (Usind plus de STL par exemple).

Il en va de même pour l'apprentissage de la raquette. Je n'ai jamais écrit de gros programme, mais cela m'a donné un nouveau point de vue à appliquer sur certains problèmes.

Il s'agit juste d'entraîner votre esprit ...

Je pense que vous pouvez facilement réfuter cette affirmation en jouant avec l'objet qui vous intéresse dans "la moitié de tout ce que vous savez".

Il existe une certaine répartition des connaissances, dont certaines deviendront obsolètes (quel que soit le taux). Ainsi, si une personne ne contient que des connaissances appartenant à la moitié de ce spectre qui subsistera après 18 à 24 mois, elle cassera la déclaration.

Voici une meilleure version de la phrase: la moitié de tout ce que vous avez appris aujourd'hui (ou cette semaine, ou ce mois-ci ou cette année) sera obsolète dans un an ou deux. C’est vrai, vous apprenez à faire quelque chose dans la version 5 d’un outil et, lorsque 6 sortent, il le fait automatiquement, ou vous apprenez à faire quelque chose dans une langue qui ne s’accroche pas, de sorte que vous ne l’utilisez plus jamais. Mais l’autre moitié de ce que vous apprenez chaque jour reste avec vous et grandit. C’est ce qui fait qu’un développeur de 20 ans d’expérience est meilleur qu’un développeur de deux ans.

Il y a une pépite de vérité ou de pertinence ici, mais je pense que c'est présenté de manière inexacte.

Une meilleure façon de présenter cela serait

Combien de connaissances que vous utilisez aujourd'hui avez-vous eues il y a 18 à 24 mois?

ou

Dans 18-24 mois, dans quelle mesure connaissez-vous déjà les connaissances que vous allez appliquer? De combien aurez-vous besoin d'apprendre aujourd'hui pour mener à bien ces tâches?

Cela peut dépendre du domaine dans lequel vous travaillez, mais je sais que je travaille constamment sur les nouvelles technologies. Chaque projet semble avoir une énorme quantité de nouvelles choses que j'ai besoin d'apprendre - de nouveaux cadres et modèles, de nouvelles approches de problèmes légèrement variés, ou simplement de nouveaux outils qui sont (supposément!) Meilleurs que ceux que nous utilisions auparavant.

Si tous les six mois, 12,5% seulement des nouvelles connaissances sont nécessaires pour un projet, alors sur 50%, 50% des connaissances utilisées seront «nouvelles».

Cela dit, ce n'est pas très significatif ni précis.

• Le "vieux" truc n'est pas obsolète.
• Le "nouveau" produit se chevauche énormément avec l'ancien
• Les principes sont généralement transférables

Oh mon Dieu, cette merveilleuse réponse de bon sens est ci-dessus. Bon travail.

En termes simples, s’il s’agit d’une lubie ou d’une tendance, si vous êtes un bon programmeur, vous en saurez plus à ce sujet, puis revenez à ce que vous faites ou travaillez normalement.

Sauf s'il y a quelque chose de vital dans ce que vous faites ou de nouvelles pratiques qui ont un sens pour vous.

Ce n’est pas parce qu’un produit est nouveau, un peu nouveau ou un peu ancien qu’il faut absolument utiliser la solution.

J'ai une phrase simple, cette couverture est tout cela.

"Si cela fonctionne, utilisez-le"

Cela signifie que si cette nouvelle technologie est incroyablement cool, mais rien ne rend votre travail plus productif, une qualité supérieure, moins sujet aux erreurs, ni ne résout de problèmes techniques tels que des solutions mobiles ou client / serveur. Alors, mieux vaut le lire, puis l’ignorer, jusqu’à ce que vous en ayez un usage pratique.

J'ai vu et lu plus de personnes qui perdent leur temps à essayer de trouver la nouvelle chose intéressante, puis à utiliser la nouvelle chose chaude. Ce qui finit généralement par être une perte totale de temps et d'argent.

Il est important de toujours apprendre, pratiquer et améliorer votre métier et vos compétences.

Cependant, vous devriez apprendre ce qui est utile ou ce qui vous donne différentes perspectives pour résoudre les problèmes que vous rencontrez normalement.

Mais à part cela, il faudrait revenir aux principes de base d'un programmeur génial.

1. http://www.joelonsoftware.com/articles/fog0000000043.html
2. Planification
3. Processus de gestion de projet - pour vous assurer qu'aucun code n'est démarré avant qu'un plan clair soit établi et approuvé par les personnes qui vous ont demandé du travail.
4. Améliorer la lisibilité de votre code - Parce que nous travaillons tous sur le code des autres
5. Soyez organisé, soyez efficace

Je fais les bonnes pratiques du bon sens, que nous apprenons tous de nos expériences. Ne perdez pas de temps sur des choses simplement cool.

Parce que honnêtement, cool n'est pas cool.

J'ai entendu cette phrase attribuée aux domaines de l'ingénierie, pas à la programmation. Plus précisément, j'ai entendu, "Au moment où vous recevrez un baccalauréat en ingénierie, vos deux premières années d'études seront basées sur une technologie ancienne." (Ou quelque chose à cet effet.)

Je ne pense pas que cela s'applique à la programmation. La seule façon possible de comprendre les relations est que les fonctionnalités sont déconseillées ou supprimées d'un langage de programmation / bibliothèque / quoi que ce soit.

La plate-forme technologique moyenne dure entre 10 et 25 ans, donc cela me semble plutôt improbable, même si vous ne tenez pas compte du fait que la connaissance des modèles persiste grâce aux technologies. Si vous êtes sur une plate-forme majeure, vous pouvez compter sur sa popularité pendant AU MOINS 5 ou 6 ans avant même qu’elle ne commence à disparaître. Je connais des programmeurs qui codent en RPG depuis 30 ans en utilisant des outils matériels et logiciels presque identiques.