2 pièce(s) jointe(s)
Trolldi : votre beau diplôme en informatique ne vous préparera pas aux utilisateurs en colère
Trolldi : votre beau diplôme en informatique ne vous préparera pas aux utilisateurs en colère
à la reprise de code ou aux caprices des autres ingénieurs
Une des expériences les plus universelles parmi les ingénieurs, semble-t-il, consiste à aller à votre premier emploi et à penser : «Je ne sais pas comment faire cela ».
Compte tenu de la rigueur et de la difficulté des programmes en cours d’informatique, il existera toujours des bases (et parfois même des compétences entières) en génie logiciel réel que l’école ne vous apprendra pas. Que votre premier emploi offre la formation et le mentorat pour vous aider à combler les lacunes, ou que vous deviez apprendre vous-même les nuits et les week-ends, la panique et le souci de se rattraper sont bien réels.
Parce que se plaindre peut parfois être amusant et instructif, la plateforme Hackernoon a interrogé une poignée d’ingénieurs ayant obtenu un diplôme en sciences informatiques sur ce à quoi l’école ne les préparait pas.
Faire face à des utilisateurs en colère
Votre diplôme en informatique ne vous apprendra pas à gérer une foule en colère sur Twitter.
La plupart des programmes en informatique n’abordent pas de la façon de traiter les utilisateurs en colère. Les rôles des startups à un stade précoce, d’autre part, en ont besoin.
« L’ingénieur qui était seul dans le bureau lorsque le site a planté a été l’un des récits les plus difficiles que nous ayons entendus. La société était récemment passée de serveurs dédiés à AWS, malheureusement l’ingénieur avait très peu d’expérience de travail sur AWS. Pendant les sept heures qui ont suivi, il était la seule personne disponible pour remettre le site en ligne, tandis que plus de 1 000 utilisateurs rageaient sur Twitter chaque heure. Il a comparé cela à une nuit blanche, mais avec 7 000 personnes qui criaient après vous.
« L’histoire de l’ingénieur qui aurait accidentellement lancé une rumeur selon laquelle sa société détesterait les utilisateurs de Linux devrait être tout près de celle qui est relatée plus haut. Il a fourni une nouvelle fonctionnalité sans la tester sous Linux. Il savait que seulement une fraction de leurs utilisateurs utilisaient Linux, mais il ne comprenait pas à quel point ces utilisateurs pourraient faire du bruit. En l'espace d'une journée, les principaux sites de développement ont discuté de la façon dont la société sabotait les utilisateurs de Linux. Son simple bogue est devenu une crise de relations publiques.
« En fait, lorsque des dizaines de milliers de personnes utilisent un produit, il n’y a pas de changement « mineur » - et si les gens n’aiment pas le changement que vous avez apporté, ils sont plus que disposés à partager leurs ressentiments ».
Les écoles / universités devraient ajouter à leur liste de cours : Réseaux sociaux 101 : Naviguer dans l'indignation et les sous-campagnes
Développer sur du code hérité
Votre diplôme d’informatique ne vous apprendra pas : d’où viennent ces nombres magiques
Si vous pensez aux mots « ancien » ou « héritage » dans le contexte de votre diplôme d’informatique, vous vous souviendrez probablement d'avoir travaillé en C ou en Assembleur. En fait, il est souvent plus facile de travailler dans un langage écrit il y a plus de 30 ans que d'utiliser le code spaghetti écrit par un autre ingénieur l'été dernier.
« Se plaindre des bases de code désordonnées était un passe-temps universel parmi les ingénieurs avec lesquels nous avons discuté. L'un d'entre eux, qui a débuté sa carrière dans une entreprise de technologie vieille de plusieurs décennies, a décrit le casse-tête particulier lié au déchiffrement d'un bogue plus âgé que lui.
« Un autre nous a dit qu’il a passé plusieurs mois à refactoriser du code écrit par un ancien fondateur. Il a pourtant vu des commentaires du genre “nous ferions mieux de changer cela bientôt”. À ce moment-là, ces dates de validation avaient déjà quelques années.
« De plus, nous avons également parlé à un stagiaire qui s’est plaint d’un “ancien” framework JavaScript, avec lequel il doit travailler - publié pour la première fois en 2010 et mis à jour en février 2019. C’est une question de perspective ».
Les écoles / universités devraient ajouter à leur liste de cours : Refactoring 220 : Nombres magiques, commentaires en charabia et lignes illisibles
Les autres ingénieurs
Votre diplôme en informatique ne vous apprendra pas : comment empêcher un seul ingénieur d’effectuer des écritures non autorisées dans la base de données
Pour être clair, il ne s'agit pas de jouer sur le stéréotype selon lequel certains ingénieurs sont antisociaux. Cependant, la plupart des personnes auxquels la plateforme a parlé ont eu quelques difficultés communes à interagir avec leurs coéquipiers.
« Le premier concernait des collègues incompétents. À l’école, vous n’avez pas vraiment besoin de vous soucier de ce que les autres savent, en dehors des devoirs de groupe. En revanche, s’il s'avère que votre coéquipier - un “hacker” autoproclamé - ne sait pas coder, c’est un problème. De même pour le code qu'il a copié, collé et modifié à partir de GitHub et qui n'a jamais fonctionné.
« Le deuxième problème commun concerne davantage l’adaptation au travail interdépendant entre équipes au sein d’une organisation technique. Un ingénieur, qui a commencé sa carrière sur un système d’exploitation populaire, a décrit la lenteur avec laquelle son code (qui a réussi tous les tests de son équipe) avait causé des bogues dans d’autres pièces du produit, apparemment sans rapport. Être la personne qui a poussé six autres équipes à passer au mode lutte contre les incendies n’est pas la meilleure façon de se faire des amis lors d’un nouvel emploi ».
Les écoles / universités devraient ajouter à leur liste de cours : Humains 302: Pourquoi sont-ils parfois les pires ?
Votre travail consiste à en apprendre davantage
Peu importe ce que votre université enseigne ou non dans son programme d’études, il vous restera toujours des lacunes à combler lorsque vous entrerez sur le marché du travail. Certains ingénieurs avouent qu’ils n'avaient jamais utilisé de contrôle de version ni fait de test écrit à l'école. D'autres ingénieurs ont déclaré avoir obtenu leur diplôme sans aucune idée de ce que sont les environnements de production.
Dans le même temps, des ingénieurs expérimentés affirment que, à mesure que la technologie évolue, il leur faut constamment combler de nouvelles lacunes dans leurs connaissances. C’est juste la nature de la technologie.
Toutes ces histoires nous apprennent donc une chose : en tant qu’ingénieur, votre responsabilité est d’apprendre plus, de le faire d’ailleurs constamment.
Source : hackernoon
Et vous ?
:fleche: Avez-vous eu du mal à faire face à ces trois challenges en début de carrière ?
:fleche: Avez-vous des anecdotes à raconter ?
:fleche: Comment arrivez-vous désormais à gérer ce genre de problèmes ?
