Développer des connaissances approfondies en programmation

De temps en temps, je vois des questions sur les cas extrêmes et d'autres problèmes étranges liés à Stack Overflow auxquelles Jon Skeet et Eric Lippert répondent facilement, démontrant ainsi une connaissance approfondie de la langue et de ses nombreuses subtilités, comme celle-ci:

Vous pourriez penser que pour utiliser une foreachboucle, la collection sur laquelle vous effectuez une itération doit être implémentée IEnumerableou IEnumerable<T>. Mais il s'avère que ce n'est pas une exigence. Ce qui est requis, c’est que le type de la collection ait une méthode publique appelée GetEnumerator, qui doit renvoyer un type comportant un getter de propriété publique appelé Currentet une méthode publique MoveNextrenvoyant a bool. Si le compilateur peut déterminer que toutes ces exigences sont remplies, le code est généré pour utiliser ces méthodes. Nous ne vérifions si l'objet implémente IEnumerableou IEnumerable<T>.

C'est cool de savoir. Je peux comprendre pourquoi Eric le sait. il fait partie de l'équipe de compilation, il doit donc savoir. Mais qu'en est-il de ceux qui démontrent une connaissance aussi profonde qui ne sont pas des initiés?

Comment les simples mortels (qui ne font pas partie de l'équipe du compilateur C #) découvrent-ils de telles choses?

Plus précisément, existe-t-il des méthodes que ces personnes utilisent pour extraire systématiquement cette connaissance, l'explorer et l'intérioriser (en faire sa propre propriété)?

Tout d'abord, merci pour les mots gentils.

Si vous souhaitez acquérir une connaissance approfondie de C #, il est sans aucun doute un avantage de disposer de la spécification du langage, de dix années de notes de conception, du code source, de la base de données de bogues et de Anders, Mads, Scott et Peter au bout du couloir. Je suis certainement chanceux, pas de question à ce sujet.

Cependant, même sans ces avantages, il est toujours possible d’acquérir une connaissance approfondie du sujet.

À mes débuts chez Microsoft, je travaillais sur l'interpréteur JScript fourni avec Internet Explorer 3. À ce moment-là, mon responsable m'a dit que c'était l'un des meilleurs conseils que j'aie jamais eu. Il a déclaré qu'il souhaitait que je devienne l'expert reconnu de Microsoft en ce qui concerne la syntaxe et la sémantique du langage JScript, et que je devrais y parvenir en cherchant des questions sur ces aspects de JScript et en y répondant. Répondre particulièrement aux questions pour lesquelles je ne connaissais pas les réponses, car ce sont celles-là dont j'apprendrais.

De toute évidence, StackOverflow et d'autres forums publics de questions-réponses sont comme boire de l'alcool à la main pour ce genre de chose. À l'époque, j'ai lu religieusement comp.lang.javascript et nos forums internes «JS User» de Microsoft, et ai suivi les conseils de mon responsable: lorsque j'ai vu une question concernant la sémantique linguistique dont je ne connaissais pas la réponse, je l'ai faite. mon affaire à découvrir.

Si vous voulez faire une "plongée profonde" comme ça, vous devez choisir avec soin. A ce jour, je suis remarquablement ignorant du fonctionnement du modèle d'objet de navigateur. Depuis que je me suis concentré à devenir le spécialiste du langage C # ces dernières années, je suis remarquablement ignorant du fonctionnement des différentes classes des bibliothèques de classes de base. J'ai la chance d'avoir un travail qui valorise des connaissances approfondies spécifiques; Si votre travail ou vos talents sont plus en phase avec le statut de généraliste, aller en profondeur risque de ne pas fonctionner pour vous.

Écrire un blog est également extrêmement utile. en m'obligeant à expliquer des sujets complexes à d'autres personnes, je suis forcé de faire face à ma propre compréhension insuffisante de divers sujets tout le temps.

Ayant été du côté "gourou" de la conversation une ou deux fois, je peux vous dire que très souvent, ce que vous percevez comme une "connaissance approfondie" d'un langage ou d'un système de programmation est souvent le résultat du "gourou" qui lutte depuis peu pour un mois pour résoudre exactement le même problème. Cela est particulièrement vrai sur un forum où les gens peuvent choisir les questions auxquelles ils répondront. Même ceux comme Jon Skeet et Eric Lippert ont dû apprendre bonjour monde à un moment donné. Ils acquièrent leurs connaissances un concept à la fois, comme tout le monde.

Paraphrasant Yogi Bhajan:

"Si vous voulez apprendre quelque chose, lisez à ce sujet; si vous voulez comprendre quelque chose, écrivez à ce sujet; si vous voulez maîtriser quelque chose, programmez- le."

La programmation est comme le défi ultime de l’enseignement. Enseigner à l’ordinateur faire quelque chose exige que vous connaissiez très bien votre travail - ou vous apprendrez à le maîtriser.

Par exemple, si vous voulez apprendre la physique, écrivez un moteur de physique. Si vous voulez apprendre les échecs, programmez une partie d'échecs. Si vous souhaitez approfondir vos connaissances en C #, écrivez un compilateur C # (ou un autre outil).

Autant que je sache, les moyens d'apprendre ceci sont:

• Lisez à ce sujet quelqu'un comme Eric Lippert
• Expérience et ensuite résoudre les problèmes de première main.

La deuxième façon peut prendre beaucoup plus de temps mais entraînera probablement une compréhension plus profonde (mais pas toujours).

Je dirais faire ce qui suit:

Après avoir appris une pile de langues relativement utile (celle dont vous avez besoin pour un vrai travail) au niveau où vous pouvez effectuer les tâches les plus courantes, arrêtez d'apprendre d'autres langues jusqu'à ce que vous en ayez étudié au moins une en profondeur. À mon avis, une partie du problème qui se pose actuellement dans notre secteur est que les gens n'apprennent que les 5 à 10% premiers de la langue avant de passer à une autre langue. Une fois que vous avez la capacité d'effectuer les tâches les plus courantes d'un travail, commencez par examiner une chose en profondeur. (Vous pouvez revenir à la largeur après avoir obtenu de la profondeur, puis aller et venir entre les deux.)

Bénévole pour les tâches les plus complexes et les plus difficiles, celles qui vous obligent à aller en profondeur pour résoudre les problèmes. S'il n'y en a pas, cherchez des tâches open source à faire ou commencez à travailler sur un projet personnel qui vous obligera à approfondir. Si votre travail ne présente pas de problèmes intéressants, songez à rechercher un travail plus stimulant.

Lisez les livres avancés sur une langue (pour SQl Server, par exemple, cela inclurait des informations sur le réglage des performances et les éléments internes de la base de données) au lieu du type de livre learn X dans 30 jours.

Lisez les questions intéressantes ici et d’autres endroits où elles sont posées et essayez de les résoudre vous-même. Si vous voulez apprendre, essayez de résoudre certaines questions sans lire au préalable les autres réponses. Même si la question a déjà été répondue, vous en apprendrez plus si vous trouvez la réponse vous-même. Vous pourriez même trouver une meilleure réponse que celle contenue dans la question.

Posez quelques-unes des questions les plus difficiles. Évaluez les réponses qui vous sont données, ne vous contentez pas de les utiliser. Assurez-vous de comprendre pourquoi la réponse fonctionnerait ou non. Utilisez ces réponses comme point de départ pour vos recherches.

Trouvez de bons blogs techniques d'experts réputés dans le domaine et lisez-les.

Arrêtez de jeter vos connaissances après en avoir fini. Apprenez à retenir. La plupart des experts n'ont pas à rechercher la syntaxe commune. Ils n'ont pas à réinventer la roue à chaque fois qu'ils rencontrent un problème, car ils se souviennent de la manière dont ils avaient abordé un problème similaire auparavant. Ils peuvent relier les points et voir à quel point le problème X qu’ils ont rencontré il ya deux ans est semblable au problème Y qu’ils ont aujourd’hui (cela me surprend de constater à quel point peu de personnes semblent capables d’établir des relations de ce type). Par conséquent, ils ont plus de temps à consacrer à la recherche de sujets plus intéressants.

Vous pouvez commencer par étudier en profondeur les spécifications linguistiques de celles pour lesquelles vous souhaitez être un expert. Par exemple:

• C #
• Java

Procurez-vous Reflector ou tout autre décompilateur (car il paye maintenant) et commencez à ouvrir certaines des bibliothèques .NET les plus utilisées pour apprendre le fonctionnement des éléments internes. Combiné à un livre comme CLR via C #, vous obtiendrez une connaissance approfondie (plus profonde que la plupart d’entre nous dans leur travail habituel).

J'ai développé ce type de connaissances en C ++ en y restant comp.lang.c++.moderatedquelques années, même si je ne travaillais pas vraiment dur à la coder à ce moment-là. Je ne sais pas comment je peux dire que je suis un gourou.

Je pense qu'il y a deux types de connaissances que l'on peut acquérir sur un langage de programmation:

1. Connaître des anecdotes sur la langue et savoir comment éviter les pièges.
2. Savoir résoudre efficacement les problèmes.

Le numéro 2 ne peut être obtenu qu'en programmant dans la langue et en regardant le code des autres, mais en prenant beaucoup de temps pour lire la langue sur ses forums de discussion, en voyant quels types de questions les gens posent et ce les réponses sont. StackOverflow est un bon endroit pour cela aussi.

Une connaissance approfondie et une expertise en programmation signifient être à l'aise à tous les niveaux d'abstraction. C'est à dire

• bibliothèques et API
• sémantique linguistique
• optimisations du compilateur
• internes du compilateur et génération de code
• Comportement du runtime et du ramasse-miettes
• Problèmes d'architecture et de jeux d'instructions

Tout ce que j'ai vu au cours des 15 dernières années a montré que ce n'est que si vous pouvez vraiment entrer dans le compilateur et l'exécution que vous avez une chance de devenir très compétent. Vous devrez peut-être vous forcer à franchir le pas et à commencer à raisonner (et à construire) un logiciel à un niveau d'abstraction plus bas dans la pile , mais c'est le seul moyen d'expertise.

Tout ce que nous avons, c'est un langage pour l'abstraction. Vous devez comprendre comment les langages de programmation sont conçus et construits pour vraiment savoir ce que fait la machine.

Lisez le manuel détaillé Ce n'est pas une connaissance particulièrement approfondie. Il est publié dans la section 8.6.4 de la spécification du langage C # . Vous devriez avoir l’habitude d’écraser au moins les spécifications des langues que vous utilisez, ainsi que d’écrémer la documentation de toutes les bibliothèques intégrées.

Quoi qu'il en soit, ce n'est pas mon idée de la connaissance profonde; c'est juste un détail d'implémentation sans intérêt. Il serait peut-être plus intéressant que le concepteur explique pourquoi cela a été fait de manière plus dynamique, au lieu de simplement vérifier que l'objet implémente Iterable.