Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualité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 ?

    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 ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Modérateur

    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
    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.

    Avez-vous des anecdotes à raconter ?
    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
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  3. #3
    Expert éminent
    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 ?

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  4. #4
    Membre averti
    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.

  5. #5
    Modérateur

    Citation Envoyé par CS FS Voir le message
    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.
    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.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  6. #6
    Membre extrêmement actif
    Citation Envoyé par transgohan Voir le message
    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.
    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.
    Keith Flint 1969 - 2019

  7. #7
    Membre averti
    Citation Envoyé par Ryu2000 Voir le message
    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.
    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...

  8. #8
    Membre extrêmement actif
    Citation Envoyé par Eric80 Voir le message
    Cela signifie donc proposer des solutions techniques, et bien souvent participer à la rédaction du cahier des charges...
    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.
    Keith Flint 1969 - 2019

  9. #9
    Expert éminent
    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.

    Moi je suis plus un gars des diagrammes de classe, des cas d'utilisation et de séquence.
    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.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  10. #10
    Membre extrêmement actif
    Citation Envoyé par transgohan Voir le message
    Rien ne t'empêche de faire un cahier des charges avec cela, mais c'est risqué car trop technique et détaillé.
    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.
    Keith Flint 1969 - 2019

  11. #11
    Expert confirmé
    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.
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

  12. #12
    Membre confirmé
    Citation Envoyé par Ryu2000 Voir le message
    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.
    C'est une assez bonne vision de la différence entre école et monde du travail justement, que le travail de préparation en amont est très important,que la vision du client est très différente de la notre , qu'on va y passer du temps et potentiellement trouver ça chiant.

    On n'y est pas forcément formé. Mais en même temps ce sont des choses qui s'apprennent sur le terrain

###raw>template_hook.ano_emploi###