Trolldi : votre beau diplôme en info ne vous préparera pas aux utilisateurs en colère à la reprise de code ou aux caprices des autres ingénieurs 120PARTAGES 32 1 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 ?



Avez-vous eu du mal à faire face à ces trois challenges en début de carrière ?

Avez-vous des anecdotes à raconter ?

Comment arrivez-vous désormais à gérer ce genre de problèmes ? 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.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 ».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 ».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 ».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 : hackernoonAvez-vous eu du mal à faire face à ces trois challenges en début de carrière ?Avez-vous des anecdotes à raconter ?Comment arrivez-vous désormais à gérer ce genre de problèmes ? Une erreur dans cette actualité ? Signalez-le nous ! Votre nom : Votre e-mail : Décrivez l'erreur que vous souhaitez porter à notre connaissance : 11 commentaires Poster une réponse Signaler un problème Les mieux notés Les plus récents Ordre chronologique Modérateur https://www.developpez.com 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 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

Au final il ne savent pas faire grand chose correctement. Les seuls qui sortent du lot c'est ceux qui ont une vrai passion et une expérience personnel et qui du coup sont à l'écoute et on une certaines soif d'apprendre.



Avez-vous des anecdotes à raconter ? Avez-vous des anecdotes à raconter ? 10 0 En fait l'école n'apprend pas grand chose et n'est pas assez claire la dessus. On voit passer pas mal de stagiaire (souvent Bac+4 ou 5) à qui on raconte qu'ils font partie de l'élite parce que issue d'une super école. Il sont généralement diffcile à encadrer car pense tout savoir mieux que tout le monde du haut de leur 2 mois d'expérience en stage d'étéAu final il ne savent pas faire grand chose correctement. Les seuls qui sortent du lot c'est ceux qui ont une vrai passion et une expérience personnel et qui du coup sont à l'écoute et on une certaines soif d'apprendre.On à hérité une fois d'une base de code qui était un mix de webdev 1.0 et de C dont les commentaires dataient de 1991 (on était en 2017) ... On à tous prié très très fort pour ne jamais avoir à toucher au projet Expert éminent https://www.developpez.com

Quand je suis arrivé en entreprise je me suis rendu compte que j'apprenais plus de choses en 6 mois sur un projet qu'en 3 ans d'école.



Après 5 ans de métier je peux dire que l'école n'est absolument pas ce qui m'a appris mon métier d'aujourd'hui.

Elle m'a donné des bases, du vocabulaire et des méthodes de travail.

Qui m'ont permis d'apprendre à vitesse grand V dès mon entrée en entreprise.



Et au bout de 5 ans j'en apprends encore tous les mois, c'est ça qui me plaît dans ce domaine si vaste.

Certains me considèrent déjà comme une référence ou un pseudo-expert dans certains domaines, alors que moi j'ai plutôt l'impression vu tout ce que je peux encore apprendre que même à 60ans j'en serai loin.



Après j'ai quand même l'impression que la majorité des choses qu'on cite ici sont plus de l'aspect social et rigueur qu'une compétence technique.

Ce n'est pas à l'école qui nous délivre des diplômes techniques de nous former pour cela.

Ou alors il faut passer un double master informatique et social pour être considéré comme compétent ? 7 0 Quand j'étais étudiant je pensais que mon école me formait sur des sujets très pointus et qui feraient une différence à l'embauche, que je pourrai parler de mes compétences et les vendre car ce serait très particulier.Quand je suis arrivé en entreprise je me suis rendu compte que j'apprenais plus de choses en 6 mois sur un projet qu'en 3 ans d'école.Après 5 ans de métier je peux dire que l'école n'est absolument pas ce qui m'a appris mon métier d'aujourd'hui.Elle m'a donné des bases, du vocabulaire et des méthodes de travail.Qui m'ont permis d'apprendre à vitesse grand V dès mon entrée en entreprise.Et au bout de 5 ans j'en apprends encore tous les mois, c'est ça qui me plaît dans ce domaine si vaste.Certains me considèrent déjà comme une référence ou un pseudo-expert dans certains domaines, alors que moi j'ai plutôt l'impression vu tout ce que je peux encore apprendre que même à 60ans j'en serai loin.Après j'ai quand même l'impression que la majorité des choses qu'on cite ici sont plus de l'aspect social et rigueur qu'une compétence technique.Ce n'est pas à l'école qui nous délivre des diplômes techniques de nous former pour cela.Ou alors il faut passer un double master informatique et social pour être considéré comme compétent ? Membre averti https://www.developpez.com 5 0 De ce point de vue là je suis content d'avoir fait mon cursus en alternance ; au moins je n'ai pas attendu d'être rendu à bac+5 pour me retrouver confronté à la réalité réelle du terrain véritable. Membre averti https://www.developpez.com Envoyé par Ryu2000 Envoyé par Le truc horrible c'est que j'ai du participer à l'écriture d'un cahier des charges, et ça jespère que ça ne m'arrivera plus jamais.

Bon après ça va il y avait les réunions régulière avec le client, pour essayer de comprendre ce dont il avait besoin.

Cela signifie donc proposer des solutions techniques, et bien souvent participer à la rédaction du cahier des charges... 5 0 Pourtant, le job 1er d un consultant en info est d expliquer au client ce qu il veut, car le client sait très rarement ce qu'il veut vraiment.Cela signifie donc proposer des solutions techniques, et bien souvent participer à la rédaction du cahier des charges... Modérateur https://www.developpez.com Envoyé par CS FS Envoyé par De ce point de vue là je suis content d'avoir fait mon cursus en alternance ; au moins je n'ai pas attendu d'être rendu à bac+5 pour me retrouver confronté à la réalité réelle du terrain véritable. ) l'alternance est à mon avis la meilleur solution. La seule contrainte que j'y vois c'est que très souvent au bout de 6 mois / 1 an d'alternance , les cours technique on du mal à intéresser car les étudiant sont déjà un niveau au dessus avec leur expérience pro. 4 0 Très clairement pour quelqu'un qui veux faire du développement son métier (et pas 2 ans pour vite passer expert powerpoint) l'alternance est à mon avis la meilleur solution. La seule contrainte que j'y vois c'est que très souvent au bout de 6 mois / 1 an d'alternance , les cours technique on du mal à intéresser car les étudiant sont déjà un niveau au dessus avec leur expérience pro. Membre extrêmement actif https://www.developpez.com Envoyé par transgohan Envoyé par Quand je suis arrivé en entreprise je me suis rendu compte que j'apprenais plus de choses en 6 mois sur un projet qu'en 3 ans d'école.

Développer pour un projet scolaire ou développer pour une entreprise était assez similaire.



Le truc horrible c'est que j'ai du participer à l'écriture d'un cahier des charges, et ça jespère que ça ne m'arrivera plus jamais.

Bon après ça va il y avait les réunions régulière avec le client, pour essayer de comprendre ce dont il avait besoin. 1 0 Moi j'ai pas vu tant de différences...Développer pour un projet scolaire ou développer pour une entreprise était assez similaire.Le truc horrible c'est que j'ai du participer à l'écriture d'un cahier des charges, et ça jespère que ça ne m'arrivera plus jamais.Bon après ça va il y avait les réunions régulière avec le client, pour essayer de comprendre ce dont il avait besoin. Membre extrêmement actif https://www.developpez.com Envoyé par Eric80 Envoyé par Cela signifie donc proposer des solutions techniques, et bien souvent participer à la rédaction du cahier des charges...

Mais rédiger un cahier des charges, quand t'as pas l'habitude c'est ultra chiant.



Avec ces putains de diagramme pieuvre, et ses fonctions primaires et secondaires.

Il y a aussi une histoire d'analyse fonctionnel ou je sais plus quoi.

C'est pas ma passion les cahiers des charges.



Ça n'a pas été mon expérience préféré.

Je comprend que légalement c'est important, ça prouve que tu livres bien ce que le client avait été d'accord à ce que tu lui livres.

Mais je sais pas, je pense qu'on peut inventer des solutions plus moderne et plus flexible, avec plus de traçabilité.



Bon après c'est pas tous les jours qu'on rédige un cahier des charges.



====

Moi je suis plus un gars des diagrammes de classe, des cas d'utilisation et de séquence. 1 0 Comprendre le besoin du client et proposer des solutions techniques c'est sympa il n'y a pas de problème.Mais rédiger un cahier des charges, quand t'as pas l'habitude c'est ultra chiant.Avec ces putains de diagramme pieuvre, et ses fonctions primaires et secondaires.Il y a aussi une histoire d'analyse fonctionnel ou je sais plus quoi.C'est pas ma passion les cahiers des charges.Ça n'a pas été mon expérience préféré.Je comprend que légalement c'est important, ça prouve que tu livres bien ce que le client avait été d'accord à ce que tu lui livres.Mais je sais pas, je pense qu'on peut inventer des solutions plus moderne et plus flexible, avec plus de traçabilité.Bon après c'est pas tous les jours qu'on rédige un cahier des charges.====Moi je suis plus un gars des diagrammes de classe, des cas d'utilisation et de séquence. Expert éminent https://www.developpez.com

Le principal c'est d'être d'accord avec le client sur le contenu.



Moi je suis plus un gars des diagrammes de classe, des cas d'utilisation et de séquence. Moi je suis plus un gars des diagrammes de classe, des cas d'utilisation et de séquence.

Cela ne te laisse aucune marge de manuvre si cela a été mal réfléchi. 1 0 Il n'y a pas qu'une méthode et qu'un modèle pour rédiger un cahier des charges.Le principal c'est d'être d'accord avec le client sur le contenu.Rien ne t'empêche de faire un cahier des charges avec cela, mais c'est risqué car trop technique et détaillé.Cela ne te laisse aucune marge de manuvre si cela a été mal réfléchi. Expert confirmé https://www.developpez.com

Grâce à dvp et les témoignages de chacun,j'ai compris le système de production d'un logiciel et ses aberrations.

Aberration qui coûte très cher à l'arrivée et donne une image déplorable des technologies. Time is money est antinomique de qualité. Les décideurs devraient lire plus souvent dvp pour comprendre que vous n'êtes pas des magiciens. 1 0 Ayant fait 10 ans d'assistance technique aux utilisateurs, j'ai acquis une certaine compréhension patiente du client et de l'ingénieur. Être pris entre le marteau et l'enclume ça forge l'humilité et le discours diplomatique.Grâce à dvp et les témoignages de chacun,j'ai compris le système de production d'un logiciel et ses aberrations.Aberration qui coûte très cher à l'arrivée et donne une image déplorable des technologies. Time is money est antinomique de qualité. Les décideurs devraient lire plus souvent dvp pour comprendre que vous n'êtes pas des magiciens. Membre extrêmement actif https://www.developpez.com Envoyé par transgohan Envoyé par Rien ne t'empêche de faire un cahier des charges avec cela, mais c'est risqué car trop technique et détaillé.

Le diagramme de cas d'utilisation peut être compris par un client.

Par contre le diagramme de classe il en a rien à foutre. 0 0 Ils ne sont pas destinés aux mêmes personnes.Le diagramme de cas d'utilisation peut être compris par un client.Par contre le diagramme de classe il en a rien à foutre. Poster une réponse Signaler un problème

