Le développement de logiciels augmente-t-il le QI ?

Oui, le logiciel de programmation peut augmenter partiellement votre QI, car il profite directement à l'intelligence logico-mathématique et créative, qui sont évaluées dans les tests de QI.

Cependant, il est important de garder à l'esprit que le développement de logiciels favorisera nos capacités cognitives tant qu'ils sont élevés dans un environnement bonnes pratiques et apprentissage continu.

• 1.- Bonnes pratiques de développement logiciel qui influencent votre façon de penser
• 1.1.- Simplicité
• 1.1.1.- Pourquoi les ordinateurs plantent-ils si continuellement ?
• 1.1.2.- Qu'est-ce qu'un mauvais programmeur ?
• 1.1.3.- Comment être un bon programmeur ?
• 1.1.4.- Est-il plus difficile de programmer de manière simplifiée ?
• 1.2.- Tests
• 1.2.1.- Des erreurs informatiques se sont produites en raison de l'absence ou de l'utilisation incorrecte des tests logiciels
• 1.2.1.1.- Défaillance du radar du détecteur de missiles
• 1.2.1.2.- Destruction du Mariner I
• 1.2.1.3.- Therac-25, accélérateur linéaire de radiothérapie
• 1.2.1.4.- Navire Yorktown (CG-48) et sa division par zéro
• 1.2.1.5.- Processeur Intel Pentium avec erreurs de division
• 1.2.2.- Exemple de logiciel plus proche de la perfection
• 1.2.3.- Quel est le paysage actuel des tests logiciels ?
• 1.2.3.1.- Erreurs et incohérences des tests de logiciels aujourd'hui
• 1.2.3.2.- Développement formel comme solution proposée aux tests logiciels incohérents
• 2.- Comment l'apprentissage continu profite-t-il à notre cerveau?
• 2.1.- L'intelligence est basée sur l'efficacité neuronale - Erhan Genç
• 2.2.- Comment la programmation influence-t-elle nos capacités mentales ?
• 2.2.1.- Les outils que nous utilisons pour programmer influencent nos modèles mentaux
• 2.2.1.1.- Pourquoi le secteur informatique est-il l'un des plus recommandés en 2021 ?
• 2.2.2.- C'est sain pour le cerveau
• 2.2.3.- Pendant la programmation, vous stimulez jusqu'à 5 zones de votre cerveau.

Bonnes pratiques de développement logiciel qui influencent votre façon de penser

Lorsque nous avons déjà une certaine expérience dans le développement de projets logiciels, nous avons déjà construit un modèle mental de ce que pourrait être un projet logiciel idéal. Mais, quelle voie suivre pour développer correctement un projet logiciel ?

Cela peut sembler pas très compliqué, car aujourd'hui, nous pouvons trouver de nombreuses informations sur Internet sur les méthodologies pour le développement de projets, tels que SCRUM ou Extreme Programming. Les deux nous fournissent des lignes directrices que nous devons suivre pendant le cycle de développement d'un projet, pour garantir l'organisation, observation, estimation du temps et/ou travail d'équipe.

De notre point de vue :

S'organiser (pour être très productif) peut être beaucoup plus difficile que d'apprendre à programmer (pour ceux qui débutent), ou maîtrisant une nouvelle technologie, car la chose vraiment difficile est de développer des projets dans un cadre structuré, lecture précise et surtout facile.

Albert Einstein a dit un jour :

Si vous ne pouvez pas l'expliquer simplement, vous ne le comprenez pas assez bien. Albert Einstein

Cela s'applique à tout domaine d'apprentissage, par exemple, spécifiquement dans le développement de logiciels, si nous ne sommes pas en mesure de simplifier notre code, et de l'organiser de manière à ce qu'un tiers puisse comprendre notre projet, nous ne le faisons pas bien.

En ce sens, par la pratique, nous devons atteindre façonner notre façon de penser et de faire les choses. De plus, tenir compte des lignes directrices et des lignes directrices fournies par les différents cadres, méthodologies et/ou recommandations d'experts appliquées à nos projets. Cependant, il n'est ni conseillé ni efficace de suivre ces directives à la lettre, car nous devons être flexibles et non stricts.

Ensuite, je vais décrire 2 bonnes pratiques de développement logiciel que vous devez prendre en compte dans la réalisation de vos projets et qui, j'en suis sûr, finiront par changer votre façon de penser.

Simplicity

Rendez votre code aussi simple que possible !

Ce n'est pas une nouvelle de dire que l'un des plus gros problèmes de l'informatique est la complexité. Donc, la simplicité est peut-être la qualité la plus importante et la plus appréciée dans le monde du logiciel.

Au fil du temps, les ordinateurs sont devenus indispensables dans nos vies, et ont provoqué un changement très important dans la société. Bref, les ordinateurs sont utiles parce qu'ils nous permettent de faire plus avec moins, c'est-à-dire de faire de nombreuses tâches en utilisant moins de ressources humaines.

Imaginons qu'une personne veuille faire toutes les opérations qu'un ordinateur fait pendant une année. Probablement, cela prendrait les années qu'il lui reste de sa vie, et c'est que la vraie valeur d'un ordinateur est sa vitesse et sa précision. Et c'est super !

Cependant, cela ne pouvait pas être aussi parfait, car les ordinateurs ont un défaut majeur : ils ont toujours des défauts. Peut-être n'avons-nous pas encore été au courant du nombre de fois qu'ils ont généralement un défaut logiciel. Si tout ce qui est utilisé fréquemment était aussi défectueux qu'un ordinateur, je suis sûr que nous nous en serions déjà débarrassés.

La plupart, sinon la totalité, des personnes que je connais subissent au moins 1 dommage par semaine, sinon plus. Je pourrais dire qu'au moins une fois par semaine j'ai subi une sorte d'échec ou j'ai découvert qu'un ami ou collègue a vécu la même chose, cela pendant environ 10 ans.

Si nous comptons, il y a 480 formes différentes de pannes d'après mon expérience. Et ce n'est pas cool.

Pourquoi les ordinateurs plantent-ils si continuellement ?

Quand il s'agit de logiciels, il n'y a qu'une seule raison : les mauvais programmeurs.

Il y a environ 5 ans, je soupçonnais que la raison en était de mauvais programmeurs ; cependant, je n'étais pas très sûr. Aujourd'hui, avec quelques années d'expérience en plus dans le domaine informatique et ayant consulté de nombreux experts à travers leurs publications, je n'ai plus de doutes.

Je peux pleinement affirmer que les mauvais programmeurs sont à blâmer pour d'innombrables pannes informatiques.

Qu'est-ce qu'un mauvais programmeur ?

Il semble un peu injuste de blâmer les programmeurs de logiciels, d'autant plus que la grande majorité des personnes que je connais qui se consacrent au développement de logiciels de haut niveau sont des professionnels qui ont une pensée logique assez développée.

Si la grande majorité des programmeurs sont des gens assez logiques, pourquoi y a-t-il des logiciels avec autant de bogues ? La principale raison des erreurs informatiques est la COMPLEXITÉ.

Construire un ordinateur est probablement le processus le plus complexe que je connaisse, car pour chaque seconde qui s'écoule, des millions de tâches peuvent être exécutées. De plus, il contient des milliers de pièces qui doivent fonctionner de manière synchronisée. Le système d'exploitation qu'un ordinateur utilise à lui seul se compose de dizaines de millions de lignes de code. Seul Windows 10 compte plus de 4 millions de fichiers et plus d'un demi-million de dossiers. La preuve en est la capture suivante :

Pour vous donner une idée encore plus complète, je détaille ci-dessous les nombre de lignes de code par système d'exploitation:

Operating system	Lignes de code
Linux 3.1 Kernel	15 des millions
Windows XP	40 des millions
Windows 7	40 des millions
Windows Vista	50 des millions
Debian 5.0 (base de code)	67 des millions
Mac OS X «Lion»	85 des millions

Je vous laisse une information complémentaire :

Facebook a environ 61 millions de lignes de code et Google a environ 2 milliards de lignes de code. Bien entendu, le grand nombre de services proposés par Google le justifie.

Le logiciel sur lequel fonctionne un ordinateur est si complexe que personne ne sera probablement en mesure de comprendre le code dans son intégralité.

Par conséquent, la programmation doit exister dans un environnement où elle cherche à réduire la complexité et ainsi atteindre la simplicité. De cette façon, nous nous assurons que tout programmeur sans talents extraordinaires a la capacité de continuer à travailler sur une application. Sinon, le code pourrait atteindre un niveau de complexité si élevé qu'il serait presque impossible de travailler dessus.

Bref, c'est ça la programmation : "Réduire la complexité à la simplicité".

Comment être un bon programmeur ?

Un bon programmeur crée des choses faciles à comprendre, à maintenir et à trouver des bogues. Mais ne confondez pas la simplicité avec moins de lignes de code ou ne plus utiliser les technologies modernes. Parfois, simplifier votre code peut augmenter vos lignes de code, assurez-vous simplement de toujours le documenter.

En général, les technologies plus avancées ou modernes tendent naturellement vers la simplicité. Il suffit d'apprendre à les utiliser correctement, ce qui est souvent un défi.

Est-il plus difficile de programmer de manière simplifiée ?

En général, nous pensons que programmer de manière simplifiée nous prendra plus de temps que de le faire rapidement. Par exemple, lorsque nous devons accomplir certaines tâches de notre travail, nous essayons généralement de le faire rapidement, sans nous arrêter pour réfléchir et planifier. Nous ne pouvions pas avoir plus tort !

Il est plus efficace de passer plus de temps à réfléchir au problème à la recherche d'une compréhension maximale et de cette façon être capable de proposer une solution simplifiée, que de commencer à écrire une solution rapidement puis de s'arrêter à réaliser que la mise en œuvre est devenue inutilement complexe.

Il suffit de regarder autour de soi et de se rendre compte du grand problème qu'est devenu la COMPLEXITÉ dans les logiciels.

Il existe de nombreuses applications qui sont devenues stagnantes en essayant d'ajouter de nouvelles fonctionnalités à l'horrible, énorme et complexe monstre de code qu'ils sont devenus.

Si vous souhaitez en savoir plus sur les fondamentaux et les méthodes de programmation simplifiée, je vous recommande de lire le livre suivant. Je l'ai aimé!

Tests

Faites toujours des tests. Ils ne sont pas optionnels !

En réalité, ils n'auraient jamais dû être une option, cependant, de nombreux programmeurs développent encore des applications sans utiliser aucun type de test logiciel, puisque les erreurs de code sont signalées par le client final. C'est généralement le cas pour le pigiste moyen.

Programmer sans tester, c'est comme conduire sans ceinture de sécurité ou faire des cascades de trapèze sans filet de sécurité. Actuellement, la bonne pratique de toujours tester les logiciels reste à adopter.

Passons en revue quelques antécédents qui se sont produits en raison de l'absence ou de l'utilisation incorrecte des tests logiciels qui ont causé des millions de dollars de pertes économiques et, dans certains cas, ont coûté la vie à des dizaines de personnes.

Des erreurs informatiques se sont produites en raison de l'absence ou de l'utilisation incorrecte des tests logiciels

Je suis sûr que les événements mentionnés ci-dessous vous feront réfléchir et donneront beaucoup plus d'importance aux tests de logiciels.

Défaillance du radar du détecteur de missiles.

Cela s'est produit en 1983 lorsque le système d'alerte de détection de missiles de l'Union soviétique a signalé que les États-Unis avaient lancé 5 missiles et qu'ils étaient en cours.

Heureusement, le responsable par intuition et/ou critères n'a pas ordonné d'attaque immédiate en réponse, puisqu'ils considéraient l'attaque comme étrange parce qu'elle était hors contexte et aussi à cause du nombre de missiles, car ils n'étaient pas ceux couramment utilisés pour une attaque surprise.

Quelques heures plus tard, il a été confirmé que tout était causé par une erreur du système de radar de missile. Une erreur un peu difficile à détecter à l'époque, tant le système confondait le reflet du soleil dans les nuages dans une certaine position avec des missiles. Pour un peu et finit par déclencher la Troisième Guerre mondiale. Cependant, cela aurait pu être évité après un travail minutieux de :

• Etude de l'environnement sur lequel le système d'alerte allait être déployé
, et
• l'injection de tous types de variables d'entrée qui pourraient affecter le système.

Les deux sont des pratiques qui font partie des tests de logiciels.

Destruction du Mariner I

Survenu en 1962 et causant la perte d'environ 18,5 millions de dollars, Mariner J'ai été la première mission du programme Mariner à tenter de survoler Vénus, malheureusement sans succès.

293 secondes après le décollage, un bogue logiciel a été trouvé. Ce bug a dévié sa trajectoire. Quelques secondes plus tard, un ordre a dû être envoyé pour le détruire, et ainsi empêcher sa chute de causer d'autres dommages.

L'erreur a été déterminée plus tard : une formule dans le code qui a été mal programmée.

Therac-25, accélérateur linéaire de radiothérapie

vous vous demanderez, qu'est-ce qu'un accélérateur linéaire de radiothérapie? Les accélérateurs linéaires sont des machines qui émettent des faisceaux de rayons X dirigés vers une tumeur sous différents angles. Ce qui est bien, c'est que ces appareils sont capables de personnaliser les rayons X pour s'adapter à la forme de la tumeur sans affecter la zone environnante.

Entre juin 1985 et janvier 1987, le Therac-25 produit par EACL (Énergie atomique du Canada limitée) a participé à au moins 6 accidents et 3 décès dus à une surdose de rayonnement.

Après les enquêtes, il a été conclu que le Les principales causes des accidents du Therac-25 étaient les suivantes:

• Mauvaises pratiques de développement de logiciels.
• Mauvaise analyse des besoins.
• Mauvaise conception du logiciel.

Et comme si cela ne suffisait pas, le logiciel sur lequel le Therac-25 fonctionnait a été développé d'une manière où il était presque impossible d'identifier et corrigez les bogues ou les erreurs automatiquement.

Autres causes trouvées :

• EACL n'a jamais envoyé d'entité indépendante pour examiner le code source.
• Aucune fonctionnalité liée à la gestion des risques n'a été prise en compte dans la conception.
• Le système n'a pas permis de vérifier le bon fonctionnement des capteurs.
• Il y avait des variables de drapeau qui ont changé leur valeur au lieu de maintenir des valeurs constantes.
• Débordement variable "class3".
• Entre autres.

Navire Yorktown (CG-48) et sa division par zéro

Croyez-le ou non, le Yorktown Ship, un navire de guerre qui a remporté d'innombrables récompenses pour son excellence au combat et surtout pour son équipement technologique, a fini par être remorqué en raison d'une erreur logicielle.

En septembre 1997, un membre d'équipage a entré un zéro dans un champ de la base de données, ce qui a amené le système à exécuter une division par zéro en interne, ce qui a causé des bugs, générant finalement un débordement de buffer et finalement une panne du système de propulsion du navire.

Processeur Intel Pentium avec erreurs de division

En 1993, Intel a sorti un nouveau processeur avec des erreurs de calcul. Bien qu'ils aient été très difficiles à remarquer, car pour pouvoir voir l'erreur, vous deviez exécuter des opérations qui nécessitent un résultat assez exact.

Malgré cela, Intel a enregistré une perte d'environ 350 millions de dollars, sans compter les dommages à son image difficilement quantifiables.

Les 5 cas que je viens de vous citer ne sont que quelques-unes des innombrables erreurs informatiques qui ont malheureusement coûtent des vies humaines et sont une preuve évidente de la nécessité d'écrire un logiciel correct.

Les ingénieurs logiciels, ainsi que les ingénieurs en structure ou les ingénieurs civils, devraient être capables de démontrer par une méthode, la fiabilité et la réalisation des fonctionnalités requises.

Comme vous l'avez peut-être remarqué, les tests sont une partie fondamentale de tout projet. Ils ne sont pas optionnels !

Selon Ilene Burnstein dans son livre : “Tests pratiques de logiciels”, les tests logiciels ont 3 processus principaux :

• Développement de cas de test
• Exécution des cas de test
• Analyse des résultats

Si vous ne prenez pas le temps de construire vos cas de test, vous ne le faites pas correctement. Il est important de construire des cas de test avec divers scénarios qui simulent autant de cas que possible. Malheureusement, il est impossible de simuler 100% des scénarios.

Bien dit Edsger Dijkstra :

Le test peut montrer la présence d'erreurs dans un programme, mais pas leur absence Edsger Dijkstra (prix Turing en 1972)

Mais tout comme il existe de nombreux cas d'erreurs informatiques causées par une exécution incorrecte des tests, il existe également des réussites dignes d'un prix.

Exemple de logiciel plus proche de la perfection

Aujourd'hui, il est possible de développer des logiciels aussi fiables que n'importe quel autre produit, d'autant plus avec l'augmentation des capacités d'automatisation.

La ligne 14 du métro parisien est entièrement automatisée. Les trains sont sans conducteur et gérés par un logiciel. Cette ligne de train a été mise en service en 1998.

Bien que cela soit vrai, sa perfection ne peut être garantie, des dizaines d'années se sont écoulées et aucun défaut n'a été détecté, grâce à un travail de test exhaustif, qui a fini par exécuter environ 86 000 instructions dans le processus de test.

En général, des processus de test rigoureux pouvant garantir un logiciel sans défaut ne sont requis dans certains pays que pour les systèmes pouvant entraîner des pertes humaines.

La grande majorité des éditeurs de logiciels refusent de mettre en œuvre des processus de test aussi rigoureux en raison du coût élevé que cela implique et aussi parce qu'il est difficile de trouver des professionnels dédiés aux tests avec une formation et une expérience suffisantes pour une telle tâche, étant donné que la mise en œuvre des processus de test du logiciel peut coûter autant ou plus que le développement du logiciel lui-même.

Bien sûr, "Vous n'apprenez qu'à votre tour", comme c'est le cas avec INTEL, qui a dû perdre environ 350 millions de dollars en raison d'une erreur de calcul dans son logiciel de processeur. Erreur qui l'a conduit à devenir l'une des sociétés informatiques avec le budget le plus élevé pour la recherche de tests logiciels.

Quel est le paysage actuel des tests logiciels ?

Le cheminement pour développer un projet logiciel se compose de 3 étapes bien définies :

• Specifications
• Conception et codage
• Validation

Dans la phase de validation, les ingénieurs en charge s'assurent que le logiciel est conforme à ce qui est prévu dans le cahier des charges, la façon dont ils le font est de "tester".

Une fois le logiciel validé, on suppose qu'il répond à toutes les spécifications et le cycle de validation est répété une dernière fois afin de vérifier la validation correcte.

Ce qui est décrit ci-dessus a un gros problème d'incohérence, je vais vous l'expliquer ci-dessous :

Erreurs et incohérences des tests de logiciels aujourd'hui

Le problème le plus important avec la méthode de validation actuelle "testing" est qu'elle ne garantit pas que le logiciel est conforme à ce qui est indiqué dans le cahier des charges. En effet, la rédaction du cahier des charges se fait en langage naturel, avec des termes qui tendront toujours à l'interprétation individuelle, ce qui génère des ambiguïtés qui seront sûrement remarquées à la fin du projet.

Un deuxième problème est que vous n'arrivez jamais à tester tous les cas possibles. Supposons que nous ayons un petit logiciel qui :

• reçoit n'importe quel nombre en entrée,
• ajouter 10 et
• renvoie la valeur de la somme comme résultat.

Il serait impossible de tester tous les cas possibles puisque les données d'entrée sont infinies. C'est pourquoi les tests logiciels ne sont exécutés que sur un échantillon de cas sélectionnés, qui sont parfois de très petits échantillons. La raison de ces mauvaises pratiques est justifiée par des contraintes financières et temporelles. En conclusion, nous ne pouvons pas dire qu'un logiciel est correct après avoir terminé la phase de test, car il n'y a pas suffisamment de preuves pour une telle affirmation.

Si nous essayons d'être logiques (comme nous devrions l'être si nous nous consacrons au domaine de l'informatique), en affirmant qu'un logiciel est correct après avoir terminé la phase de test et n'avoir trouvé aucune erreur, nous encourons ce qu'on appelle: “Appel à l'ignorance fallacieuse”.

En logique, un argument ad ignorantiam, ou argumentum ad ignorantiam, également connu sous le nom d'appel à l'ignorance, est un sophisme qui consiste à soutenir la vérité (ou la fausseté) d'une proposition affirmant qu'il n'y a aucune preuve du contraire, ou encore invoquer l'incapacité ou le refus d'un opposant de présenter des preuves convaincantes du contraire. Cette impatience face à l'ambiguïté est souvent critiquée par la phrase : "l'absence de preuve n'est pas une preuve d'absence" c'est-à-dire que cette erreur est commise lorsque la vérité ou la fausseté d'une proposition est inférée sur la base de l'ignorance existante à son sujet. Appel à l'ignorance fallacieuse

Comme vous l'avez peut-être remarqué, nous commettons de nombreuses erreurs lors de l'application des tests logiciels de manière conventionnelle et à de nombreuses reprises nous ne sommes pas conscients des coûts que cela génère.

Juste pour vous donner une idée:

• La méthode conventionnelle de test de logiciel implique la détection de défauts dans le logiciel.
• Par la suite, la phase de débogage est entrée, c'est-à-dire la révision du code afin de comprendre les causes des échecs et enfin corriger les défauts du logiciel.
• En travaillant de cette manière, les programmeurs passent en moyenne 49,9% de leur temps à déboguer leurs propres erreurs.
• Cela implique une dépense mondiale de 156 milliards de dollars par an.

Développement formel comme solution proposée aux tests logiciels incohérents

Comme nous l'avons déjà vu, l'un des principaux problèmes est l'ambiguïté des spécifications qui, lorsqu'elles sont exprimées en langage naturel, manque de précision et de sens mathématique logique. Une solution consiste à utiliser un langage formel, où il n'y a pas de place pour l'ambiguïté.

En utilisant une méthode formelle pour le développement de nos projets logiciels, la certitude des propriétés et/ou fonctionnalités du logiciel est garantie par déduction, c'est-à-dire par les mathématiques (p -> q).

Cette méthode formelle nécessite beaucoup plus de temps et de budget pour sa préparation, car beaucoup plus de précision est nécessaire dans l'élaboration des spécifications, qui doivent à leur tour être débarrassées des ambiguïtés afin que lors de la création du code, il puisse démontrer sa fiabilité en fonction de ses spécifications.

Il semble assez éloigné de la réalité d'atteindre cette limite de demande pour créer des logiciels de qualité. Cependant, il existe actuellement des entreprises qui fondent leurs systèmes sur le développement formel, généralement avec des entreprises dédiées à des domaines critiques où une petite erreur peut entraîner la perte de vies humaines instantanément.

Cependant, à petite échelle, un tel niveau de demande n'est pas rentable ; au minimum, nous devons nous conformer aux tests conventionnels.

Ci-dessous, je partage une série de publications de bonnes pratiques à ne pas manquer si vous cherchez à développer des projets de qualité.

Comment l'apprentissage continu profite-t-il à notre cerveau?

L'apprentissage est comme le carburant de notre cerveau.

Au collège ou à l'université, nous avons sacrifié des études continues et rien de tout cela n'a été suffisant, parce que chaque minute qui passe, de nouvelles informations sortent quelle que soit la carrière que vous avez étudiée.

Il y aura toujours quelque chose de nouveau à apprendre.

Une chose à garder à l'esprit est que lorsque nous apprenons, notre cerveau est affecté par des changements dans les structures neuronales.

La recherche moderne a montré que le cerveau a la capacité de changer et de se déformer de façon permanente (plasticité), et pas seulement chez les enfants mais aussi chez les adultes.

Ces changements dans le cerveau peuvent être causés par bonnes pratiques d'apprentissage continu, restructurer les connexions synaptiques et parfois en créer de nouvelles.

Autrefois, on croyait que plus le cerveau d'une personne était gros ou lourd, plus il était intelligent. Cependant, des études récentes ont déterminé que les personnes ayant un QI plus élevé ont un réseau neuronal moins dense mais en même temps beaucoup plus organisé.

Pour cette recherche, le QI a été calculé sur les facteurs suivants :

• Capacité d'analyse
• Capacité de réflexion
• Résolution des problèmes

Voici un peu plus d'informations sur la recherche en question :

L'intelligence est basée sur l'efficacité neuronale - Erhan Genç

L'équipe dirigée par Erhan Genç a analysé le cerveau de 259 hommes et femmes âgés de 18 à 40 ans, et en bonne santé, afin de mesurer les dendrites dans le cortex cérébral, c'est-à-dire les extensions des cellules nerveuses que les cellules utilisaient pour communiquer entre elles dans l'exercice de l'intelligence.

Avant l'étude, tous les participants ont subi un test de QI. Après avoir étudié les dendrites, il a été déterminé que plus le QI est élevé, moins il y a de dendrites dans le cortex cérébral.

En d'autres termes, il a été conclu que les personnes plus intelligentes ont non seulement plus de neurones, mais aussi moins de connexions dendritiques entre les neurones. au moment de la cognition. Ce qui signifie qu'ils ont un réseau de neurones moins dense.

Les études ont été validées avec un échantillon de 500 personnes et les mêmes conclusions ont été tirées.

Erhan Genç, auteur principal de l'étude a conclu :

Les cerveaux intelligents se caractérisent par un réseau de neurones mince mais très efficace. Cela aide à atteindre un niveau élevé de réflexion tout en minimisant l'activité neuronale. Erhan Genç

Comment la programmation influence-t-elle nos capacités mentales ?

Comme je l'ai déjà mentionné dans les paragraphes précédents, la programmation affecte la façon de penser de ceux qui la pratiquent, en ce sens, il influence directement notre capacités mentales.

Mais de quelle manière le fait-il ? Voyons.

Un programmeur pense très différemment des autres, car en général, ils ont tendance à être plus logiques et plus rationnels que la moyenne, mais pas nécessairement.

Puisque nous avons décidé d'apprendre à programmer, nous devons choisir par quelle langue commencer. Bien qu'un tel choix ne soit pas tout à fait vrai, car, en général, la grande majorité de ceux qui se consacrent au monde du développement logiciel choisissent notre premier langage sans aucune expérience ou ont été soumis et pratiquement contraints de commencer par un langage de programmation imposé. par un enseignant, soit au collège et/ou à l'université.

Cependant, de telles limitations sont de moins en moins fréquentes en raison de la quantité d'informations que l'on peut trouver sur internet et la forte incitation et la promotion de l'apprentissage autodidacte.

Les paradigmes des langages de programmation ont déjà façonné de nombreux esprits, dans certains cas avec plus de limitations que dans d'autres en fonction de la langue avec laquelle il a été démarré. Je ne veux pas dire par là que votre langue maternelle définit votre réussite ou votre échec, mais je veux dire les paradigmes avec lesquels on commence dans le monde de la programmation insèrent des modèles dans notre pensée.

je vous mentionne ci-dessous 3 façons dont la programmation affecte votre cerveau:

1. Les outils que nous utilisons pour programmer influencent nos modèles mentaux

Le langage de programmation avec lequel nous avons commencé n'est rien de plus qu'un outil, qui s'accompagne de paradigmes et d'idiomes qui influencent directement votre façon de penser. Pas pour rien, Edsger

Dijkstra, l'un des pionniers dans l'établissement de la programmation distribuée, a déclaré :

Les outils que nous utilisons ont une influence profonde (et détournée) sur notre habitudes de pensée et, donc, dans notre capacités de réflexion. Edsger Dijkstra

Maintenant que vous savez à quel point le langage de programmation avec lequel nous commençons est important et en général tout l'ensemble d'outils que nous utilisons lors de la programmation, je vous conseille que la première chose à prendre en compte lors du choix de votre premier langage de programmation est votre confort.

Si vous débutez, ne vous laissez pas emporter par l'argent. Il est vrai qu'il existe des langages de programmation qui sont mieux payés que d'autres, mais l'argent ne doit pas être votre objectif. Si c'est le cas, je pourrais vous conseiller de commencer à programmer avec COBOL, PASCAL, FORTRAN, des langages qui ont très peu de documentation et qu'actuellement il y en a très peu qui le pratiquent, c'est pourquoi ils sont très bien payés là où ils sont nécessaires.

En réalité, se consacrer au développement de logiciels apporte non seulement des avantages à vos habitudes de réflexion et à vos compétences cognitives, mais peut également vous assurer un avenir économique plus que stable, car c'est un secteur très bien rémunéré qui est actuellement en croissance.

Aujourd'hui est le meilleur moment pour commencer. Voyons pourquoi :

Pourquoi le secteur informatique est-il l'un des plus recommandés en 2021 ?

Selon la Commission économique pour l'Amérique latine et les Caraïbes (CEPALC), les pays d'Amérique latine amorceront leur croissance après la récession économique de 2020.

Une croissance de 3,7% est estimée pour 2021, où la les principaux protagonistes seront ceux qui se consacrent au monde numérique.

2. C'est sain pour le cerveau

Comme nous l'avons déjà mentionné, l'apprentissage a des effets positifs sur le cerveau. En ce sens, la programmation compte comme un exercice mental qui favorise directement le cerveau.

Passons en revue quelques antécédents qui confirment les avantages de la programmation pour la santé du cerveau :

En 1991, une enquête a étudié les effets de la programmation informatique sur les résultats cognitifs et a déterminé que les élèves dans les domaines liés à la programmation obtiennent un score de 16 centiles supérieur à la moyenne aux tests de QI.

Une autre étude plus importante en 1999 a fini par confirmer que les activités intellectuellement engageantes servent à protéger les individus contre le déclin cognitif.

Plus tard en 2009, une étude a révélé que les personnes qui se livrent à des activités de stimulation cérébrale au cours des dernières années peuvent réduire leur risque et même retarder l'apparition de la maladie d'Alzheimer et d'autres types de démence.

3. Pendant la programmation, vous stimulez jusqu'à 5 zones de votre cerveau

En 2014, une étude intitulée “Compréhension du code source Compréhension avec l'imagerie par résonance magnétique fonctionnelle” utilisé des scans d'imagerie par résonance magnétique fonctionnelle pour observer l'activité cérébrale pendant que les programmeurs essayaient de travailler et de comprendre des morceaux de code.

Il a été conclu que 5 zones du cerveau étaient impliquées :

• BA 6: Gyrus frontal moyen (Attention, langage, mémoire de travail)
• BA 21: Gyrus temporal moyen (récupération de la mémoire sémantique)
• BA 40: Lobe pariétal inférieur (mémoire de travail)
• BA 44: Gyrus frontal inférieur (mémoire de travail)
• BA 47: Gyrus frontal inférieur (Langage, mémoire de travail)

Nous devons garder à l'esprit que les participants ont été soumis à l'examen d'un extrait de code de 20 lignes, ce qui n'est pas un grand défi. Et c'est pourquoi aucune activité n'a été détectée dans les zones du cerveau liées aux calculs mathématiques.

Ce qui a pu être remarqué, c'est la forte intervention de parties du cerveau qui sont normalement associées au traitement du langage, à la mémoire et à l'attention.

La programmation est ce qui se rapproche le plus des super-pouvoirs. Drew Houston, CEO de Dropbox