Journée de protection des enfants contre le mauvais code

Ce post est dédié à la journée de protection des enfants. Toute coïncidence est purement fortuite.

À 10 ans, j'ai eu mon premier ordinateur et un disque avec Visual Studio 6. Depuis, je me fixe des petits défis - automatiser des tâches, créer un service web pour trois personnes ou écrire un jeu qui sera finalement retiré du Play Store à cause de son âge. Bien sûr, j'ai perdu des fichiers sources et écrit du code dont je suis honteux. À 10 ans, j'aurais été ravi de recevoir un archive du futur avec tous mes défauts, pour ne jamais les répéter.

Il y a quelques semaines, j'ai demandé à des collègues de Yandex.Money ce qu'ils conseilleraient à un enfant qui veut devenir développeur, et j'ai repensé à certains aspects de ma propre expérience. C'est ainsi qu'est né ce texte. Je propose d'en discuter.

Je ne recommande pas de dépenser beaucoup d'énergie à choisir, mieux vaut tout essayer et toucher à tout. Une fois que tu auras compris en gros de quoi il s'agit, tu pourras décider dans quel sens te diriger et ce dont il vaut mieux te détourner.

Sergueï, développeur junior

Enfance

Quelle est l'activité la plus amusante dans l'enfance d'un programmeur, quand il n'y a pas encore Internet ?

J'en avais deux - démonter tous les jeux du disque « 800 jeux en russe » avec tous les programmes du disque « Tout ce qu'un hacker doit avoir », puis réécrire tous les jeux sur lesquels j'ai passé plus de 10 heures, de zéro en BASIC. Peu importe le résultat - même si c'est quelque chose comme ça.

Tu prends, tu essaies, tu réarranges les blocs, tu expérimentes et tu touches à tout ce qui est accessible. Tu désinstalles Windows, tu réinstalles Windows pendant 10 heures. Tu essaies de récupérer les pilotes. Tu cherches à comprendre comment fonctionne DOS. Tu comprends comment positionner les jumpers pour que ton disque dur démarre sur l'ordinateur d'un ami (là-bas, il y a 200 Mo de nouveaux jeux !). Tu manipules le logiciel, le matériel, tu démontes et remontes un ordinateur. Tu écris un simulateur de football pendant 13 ans, finalement.

Quand il n'y a rien, tu deviens heureux de cela.

Il ne faut pas sous-estimer l'importance de l'auto-vérification. À mon avis, les novices en IT sous-estiment à quel point ils devront contrôler strictement leur produit (et en analyse aussi) et combien cela prend de temps en comparaison de la partie purement créative. Et plus ce que tu fais est intéressant, plus la vérification sera difficile et longue.

C'est, bien sûr, un conseil un peu abstrait, mais si j'avais su tout de suite.

Et je ne recommande pas de se concentrer sur un seul domaine dans l'informatique. Ici aussi, l'horizon est important.

Anna, analyste système senior

École secondaire

À un moment donné, sur le forum de la ville provinciale P, il a été question de programmation — et un fil de discussion est apparu avec le titre « Une grande entreprise recherche des programmeurs PHP ». Le texte de l'annonce était le suivant :

Une grande entreprise recherche des programmeurs PHP :

Pour déterminer si vous devriez venir à l'entretien, vous devez réaliser un exercice simple : écrivez un programme en PHP qui trouve des entiers positifs x, y et z, tels que x^5 + y^5 = z^5. (^ - puissance).

Vous pouvez répondre ici.

Dans ce fil, seulement quelques personnes ont répondu — il y avait moi aussi. Avec toute ma naïveté de seize ans, j'ai répondu :

C'est vraiment un peu étrange. Et il faut un ordinateur puissant pour trouver ça...
Car pour x, y, z <= 1000, il n'y a pas de tels nombres — c'est d'abord (je l'ai rapidement codé en VB, plus pour l'instant ce n'est pas fait), et ensuite l'ordinateur plante complètement.

Ce n'est pas qu'il n'y a rien, à mon avis.

Oui, c'était un piège, une embuscade pour les débutants, oui, c'est de la bêtise, et alors ? Il est évident que j'ai passé un certain temps sur un simple script, mais j'ai complètement oublié l'existence du théorème de Fermat — ce que l'auteur du fil, le respectable The_Kid, a précisé à la fin.

Le résultat est triste - il n'y a pratiquement personne à P qui connaisse les mathématiques, mais chaque deuxième se prend pour un super programmeur. En trois heures, sur tous les forums où j'ai posté, il y avait environ deux cents vues au total... et seulement deux réponses correctes. Et le théorème de Fermat — c'est pourtant au programme scolaire, et ses conditions sont si simples qu'elles devraient sauter aux yeux. D'ailleurs, en parallèle, lors d'un sondage sur ICQ, 6 sur 6 étudiants de Novossibirsk ont répondu « C'est le théorème de Fermat ».
Alors qui doit-on embaucher après ça ?

À l'époque, cela a suscité chez moi une grande indignation dans le style : « Si je n'ai pas écrit sur le théorème de Fermat, cela ne signifie pas que je ne le sais pas » — classique excuse. Est-ce que cela me rend triste maintenant ? Non, c'est aussi une leçon pour toute la vie. Comme à l'époque où mon jeu a été mis en avant dans le Windows Phone Store indonésien, et deux semaines après, il a été supprimé parce que je n'avais pas mis à jour certaines conditions de l'EULA.

Et il est complètement incompréhensible : si dans une grande entreprise, il n'y a personne à recruter — que doit-on devenir ? Que doit-on faire ? Où doit-on grandir ?

Il ne faut pas penser qu'une fois diplômé, tu deviendras programmeur / taxi driver / mathématicien ou autre.

Nous sommes arrivés à une époque où les matières de base (mathématiques, physique, informatique, philosophie) ont beaucoup plus d'importance dans le diplôme que les matières appliquées (programmation, design dans des domaines spécifiques, etc.). L'enseignement supérieur commence à se diviser en couches - de base (ingénierie) et appliquées. Il est préférable d'apprendre à penser, d'adopter une approche scientifique, de comprendre comment résoudre des problèmes et d'acquérir des compétences interpersonnelles.

C'est ce qui concerne l'université. Pour les compétences appliquées, une personne aura toute sa vie.

Oleg, analyste système senior

Université

Tu écris du code en C++, tu écris du code en Java. Tu touches à l'assembleur, tu recules, tu t’embrouilles dans Qt et tu penses pourquoi cela t'arrive. À partir de la quatrième année, il devient de plus en plus indifférent sur quoi tu écris tes importants projets de laboratoire - les enseignants se contentent de survoler le code.

Bien sûr, ce n'est pas le cas partout - il y a des universités où c'est puissant et bien, mais elles n'acceptent que des étudiants qui résolvaient des problèmes ACM à l'école, tiraient le maximum de la théorie des graphes lors des cours supplémentaires et mémorisaient la mémoire requise par tous les algorithmes connus.

Quant à moi, je ne résolvais pas, je ne suis pas allé aux cours supplémentaires, j'ai juste terminé mes études dans ma classe de mathématiques, tout en faisant des choses intéressantes. Spoiler - lors des entretiens, elles ne seront utiles à personne.

Tout d'abord, il vaut mieux déterminer ce qui plaît dans l'IT. Si tous les domaines plaisent, cela sera compliqué. Apprendre un langage - ne mènera à rien, ce ne sera qu'une confusion par la suite.

Ian, spécialiste en monitoring financier

Une histoire réelle - pour un simulateur Windows, construit avec un ami à la va-vite en 10e année, on peut obtenir quelques examens et crédits automatiques à l'université. On peut aussi raconter à tout le monde à quel point c'était génial. Le problème, c'est que ce n'était pas génial - c'était une architecture compliquée, un code horrible et une totale absence de toute norme.

Ces choses doivent être faites avec un seul objectif - avoir son propre catalogue d'erreurs. Bien que cela ne préserve pas du syndrome de l'imposteur, lorsqu'on se retrouve dans une grande entreprise avec des connaissances superficielles sur tout et qu'on pense qu'on va se faire démasquer.

Je suis d'accord, il est plus important d'aider avec des conseils sur ce que l'on peut faire et où trouver des informations, plutôt que l'inverse. Et il n'est pas du tout effrayant s'il commence par tâtonner. — La prise de conscience viendra plus tard. L'essentiel est que cela lui plaise.

Éric, ingénieur en test

Nous rédigeons tous des plans de développement — ce qu'il faut étudier, sur quoi travailler dans un avenir proche et comment s'améliorer. Mais il semble que ce serait utile pour nous tous d'écrire une lettre à notre moi du passé — voici la mienne.

1. Prends le temps, trouve un livre et installe bien cette distribution d'Ubuntu que Canonical t'a envoyée gratuitement. Il y a sûrement un problème simple, Ubuntu fonctionne partout. Et Linux te sera très utile.
2. N'aie pas peur du terminal. Volkov Commander tient bien sur une disquette, mais essaie de comprendre à quoi servent toutes ces commandes, fais ami-ami avec la ligne de commande. Les disquettes vont disparaître. Les disques vont disparaître. Les clés USB aussi. Ne t'inquiète pas trop.
3. Lis sur les algorithmes, familiarise-toi avec le tri, les arbres et les tas. Lis des livres.
4. Pour comprendre les bases, il n'est pas nécessaire de suivre des cours payants. YouTube apparaîtra bientôt – tu seras étonné.
5. Ne te focalise pas sur le BASIC. Il existe des centaines de technologies qui méritent ton attention, et des millions de choses plus intéressantes que de dessiner encore des formulaires utilisateurs dans Excel. Commence par Python — tu t'en sortiras après.
6. Apprends à utiliser Git, sauvegarde tous tes source codes. Crée au moins une application client-serveur pour comprendre comment elles fonctionnent. Familiarise-toi avec les réseaux, les commutateurs et les routeurs.
7. Et si tu lis ceci maintenant, cela signifie que tout n'est pas vain.

Racontez dans les commentaires ce que vous vous diriez à vous-mêmes du passé ? Donnez des conseils aux étudiants et aux lycéens d'aujourd'hui qui sont encore indécis et essaient de trouver leur voie. Parlons-en.

Source : habr.com