IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Emploi Discussion :

10 vérités difficiles à avaler sur le métier d'ingénieur logiciel, par Mensur Durakovic


Sujet :

Emploi

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    Décembre 2023
    Messages
    1
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2023
    Messages : 1
    Points : 20
    Points
    20
    Par défaut 10 vérités difficiles à avaler sur le métier d'ingénieur logiciel, par Mensur Durakovic
    10 vérités difficiles à avaler que l'on ne vous dira pas sur le métier d'ingénieur logiciel, par Mensur Durakovic, ingénieur logiciel

    Le week-end dernier, j'ai eu l'occasion de discuter avec des étudiants qui viennent d'obtenir leur diplôme. Ils sont à la recherche de leur premier emploi d'ingénieur logiciel. En discutant avec eux, j'ai appris qu'ils avaient une perception assez erronée de ce métier.

    En effet, la réalité de ces jeunes est très déformée. Ils ne voient que les bons salaires, le travail à distance, le développement de l'esprit d'équipe et les soirées pizza.

    Ce sont tous de bons avantages, mais personne ne leur parle des vraies choses que nous faisons dans ce travail.

    En tant que personne ayant passé de nombreuses années dans ce secteur, je leur ai infligé une claque sur la réalité. Je leur ai dit de bonnes choses, mais aussi des vérités difficiles à avaler.

    Après avoir lu cet article, certains diront que j'en parle de manière trop négative, mais mon opinion est que ces choses vont de pair avec le travail et qu'il faut les accepter.

    1) L'université ne vous prépare pas à la réalité du travail

    C'est la première chose que j'ai expliquée à ces personnes.

    Pour décrire précisément comment l'université vous préparera au travail, imaginez que vous apprenez à nager.

    Votre instructeur passe énormément de temps à vous décrire tous les mouvements que vous devez faire. Il vous fait réciter tous ces mouvements, vous pose des questions à ce sujet et vous passez des examens. Mais vous ne touchez jamais l'eau.

    Au bout de cinq ans, vous recevez un papier qui atteste de vos compétences en natation. Le jour venu, vous devez nager. Les gars de l'école de natation vous jettent à l'eau d'un coup de pied.

    Vous avez du mal à respirer, vous luttez pour votre vie. Peut-être que vous vous noierez, peut-être que vous réussirez à nager.

    Voilà à quoi ressemblent les six premiers mois d'un étudiant fraîchement diplômé qui occupe un poste d'ingénieur en informatique.

    L'université vous prépare à certaines bases, mais ce que la plupart des universités enseignent est très éloigné des emplois quotidiens. La plupart des professeurs qui enseignent dans les universités ne sont pas de bons ingénieurs logiciels.

    Seul un petit pourcentage d'entre eux a même travaillé comme ingénieur logiciel. En outre, les programmes universitaires sont largement dépassés. Ils ont des années de retard sur les besoins du marché en matière de développement de logiciels.

    Vous devez fournir un travail supplémentaire pendant vos études. Codez plus de projets en plus des devoirs et des séminaires. Faites du bénévolat. Renseignez-vous sur les domaines commerciaux pour vous préparer à l'emploi qui vous attend.

    La plupart des étudiants ne le font pas. Ils attendent d'avoir leur diplôme pour commencer à travailler sur leur portfolio.

    2) Vous obtiendrez rarement des projets entièrement nouveaux

    À l'université ou dans les boot camps, vous recevez de nombreuses petites missions que vous écrivez à partir de rien. Vous êtes totalement libre de vous exprimer. Vous pouvez mettre en œuvre tous les trucs fantaisistes que vous apprenez, comme les algorithmes ou les modèles de conception.

    Le temps que vous passez sur ces travaux est au maximum de quelques semaines, mais la plupart du temps de quelques jours de travail. En général, ces travaux contiennent au maximum 500 lignes de code.

    Dans votre travail quotidien, vous travaillez sur des projets qui contiennent plusieurs couches et des milliers de lignes de code. Plusieurs personnes travaillent en même temps sur ces projets. Votre liberté est limitée, vous devez vous adapter au projet. Le temps que vous passez sur les projets est généralement compris entre un semestre et deux ans.

    Parfois, vous passez une semaine entière à corriger un bogue désagréable. La correction ne porte que sur quelques lignes de code. Vous discutez avec vos collègues. Vous échangez des informations sur le projet. Vous collaborez avec eux pour obtenir l'approbation de votre solution.

    Les nouveaux projets sont rares, et la plupart du temps, vous travaillez sur des projets existants. Vous pouvez vous estimer heureux si vous obtenez un projet normal et non un vieux projet hérité.

    3) Personne n'en a rien à faire de la propreté de votre code

    Vous pouvez oublier que votre patron vous dira : "Félicitations pour avoir écrit ce code élégant et propre, je vais vous donner une augmentation !". Bien au contraire, tout le monde se fiche de votre code propre.

    Ne vous méprenez pas, les gens s'attendent à ce que vous écriviez un code propre et de qualité. Cependant, vous recevrez rarement des éloges à ce sujet. Sauf parfois de la part de vos collègues qui examineront votre code.

    Cela peut être un choc pour certains nouveaux venus, mais c'est tout à fait logique. En tant qu'ingénieur logiciel, votre tâche principale est de générer de la valeur pour les utilisateurs. Écrire du code n'est qu'une étape qui permet d'atteindre cet objectif.

    Vous pouvez l'envisager comme le cycle suivant :

    • l'ingénieur logiciel écrit le code ;
    • les utilisateurs bénéficient de nouvelles fonctionnalités ;
    • de plus en plus d'utilisateurs utilisent vos produits ;
    • l'entreprise tire des bénéfices de ses produits.

    Le code n'est donc qu'un outil permettant de réaliser des bénéfices.

    J'ai vu tant de cimetières de projets, avec d'horribles bases de code héritées du passé. Pourtant, ces projets ont du succès parce qu'ils ont des pages d'accueil élégantes et qu'ils résolvent les problèmes des utilisateurs. Les utilisateurs sont donc heureux de payer pour les utiliser.

    L'utilisateur ne sait pas à quoi ressemble la base de code. Il ne voit que les fonctionnalités offertes par le produit. Ne vous attachez donc pas trop à votre code propre et élégant. Concentrez vous sur la livraison de la fonctionnalité dans les délais et sans bogues.

    4) Vous travaillerez parfois avec des personnes incompétentes

    Les gens ont des préjugés selon lesquels seules les personnes intelligentes et compétentes travaillent dans le secteur des technologies de l'information. En particulier dans le secteur du développement de logiciels. Mais c'est loin d'être le cas.

    Comme dans tout travail, vous serez parfois confronté à des personnes incompétentes dans votre environnement. Travailler avec eux est très frustrant. Ils font perdre beaucoup de temps et créent un environnement toxique. En outre, elles sont extrêmement improductives. Tout cela se répercute sur les délais et entraîne des retards. Cela coûte de l'argent et des ressources aux entreprises.

    Malheureusement, j'ai aussi eu l'occasion de travailler avec ce genre de personnes. Je dois dire qu'elles ont tellement mis mes nerfs à l'épreuve que j'ai passé beaucoup de temps à réfléchir à des moyens de contourner leur incompétence.

    Voici quelques conseils :

    • essayez d'être efficace et productif autant que vous le pouvez, concentrez-vous sur vous-même et non sur cette personne
    • essayez d'autres options/solutions qui n'impliquent pas cette personne dans le processus
    • documentez tout ce que vous faites. Si les choses tournent mal, vous aurez la preuve de son incompétence.
    • si vous avez un blocage parce que cette personne n'a pas fait son travail, essayez de demander à quelqu'un d'autre de vous débloquer (si c'est possible)
    • parlez-lui directement, soyez professionnel mais pas méchant, et dites-lui ce qu'il peut améliorer et comment il peut le faire

    N'oubliez pas qu'il n'est pas nécessaire d'être désagréable avec eux.

    Parfois, vous ne connaissez pas toute l'histoire. J'ai vu des cas où une personne ne pouvait tout simplement pas faire son travail correctement. Elle est accablée par des tonnes de tâches et travaille pour deux personnes.

    5) Habituez-vous à participer à des réunions pendant des heures

    Les réunions sont une partie importante du travail de développement de logiciels. Certaines d'entre elles sont utiles, mais d'autres ne font que perdre du temps.

    Il y a des réunions récurrentes programmées sur une base quotidienne ou hebdomadaire. La plupart d'entre elles ne sont pas productives. La majorité d'entre elles sont imposées par la personne qui les organise parce que c'est le seul "travail" qu'elle fait.

    Il s'agit simplement d'un protocole vide visant à prouver sa raison d'être au sein de l'entreprise.


    D'autre part, il existe des réunions productives. Ces réunions assurent l'échange d'informations entre les membres de l'équipe ou entre différentes équipes.

    La majorité des ingénieurs logiciels détestent les réunions. Mais n'oubliez pas que votre travail consiste également à communiquer ouvertement et de manière proactive.

    Le partage d'informations est essentiel pour faire avancer les projets. Lorsque vous partagez des informations, cela peut aider les autres équipes à mieux comprendre ce que vous faites et l'inverse.

    6) Ils vous demanderont des estimations à de nombreuses reprises

    Les affaires tournent autour des chiffres. Chaque projet a son coût et, pour le calculer, la direction doit estimer le temps nécessaire à la réalisation d'une fonction donnée.

    Ensuite, ce sont les ingénieurs logiciels qui doivent estimer leur travail. En général, les estimations sont basées sur le temps, mais il arrive aussi qu'ils demandent des estimations de la complexité.

    Dans de nombreuses situations, vous n'avez aucune idée du temps qu'il vous faudra pour construire quelque chose. Vous lisez les exigences, vous faites des recherches et vous donnez un chiffre.

    Nom : image-6.png
Affichages : 162108
Taille : 78,1 Ko

    Plus tard, lorsque vous commencez à travailler sur cette fonctionnalité, vous rencontrez de nombreux problèmes dont vous n'étiez pas conscient lorsque vous avez donné des estimations de temps. Vous devez alors compenser les pertes de temps et espérer ne pas dépasser la date limite.

    C'est pourquoi il est toujours bon de ne pas faire de promesses, mais de faire plus que ce qui a été prévu.

    Par exemple, lorsque votre chef de projet vous demande de mettre en œuvre la fonctionnalité X pour vendredi, vous ne direz pas "Oh, je peux le faire pour mardi". Vous lui répondrez plutôt : "Bien sûr, pas de problème".

    Pourquoi ?

    Parce que si vous promettez de le livrer pour mardi et que vous rencontrez des problèmes, vous ne pourrez pas tenir votre promesse. En revanche, si vous acceptez le vendredi comme date limite et que vous terminez le travail le mercredi, vous pourrez le livrer deux jours plus tôt.

    Il existe de nombreuses formules sur la manière de faire des estimations, et chacun a ses propres règles. J'ai également mes propres règles.

    Si je dois livrer une fonctionnalité et que je pense qu'elle prendra deux jours, j'ajoute environ 40 % de temps supplémentaire, juste pour être sûr. Ainsi, dans ce cas, l'estimation sera de 3 jours. Plus tard, si j'ai terminé en 2 jours, je peux simplement livrer plus tôt.

    7) Les bogues seront votre ennemi juré à vie

    Plus vous codez, plus vous vous rendez compte que les bogues dans le code sont omniprésents. Lorsque vous commencez à programmer, vous pensez que vous allez coder quelque chose, que cela fonctionnera bien et que c'est la fin de l'histoire.

    Mais en réalité, c'est une autre histoire. Il y a d'innombrables choses qui peuvent produire des bogues :

    • votre propre code - les humains font des erreurs, et vous ne devriez pas croire que le code fonctionne parfaitement. Vous pouvez écrire des tests, mais des bogues peuvent survenir après cela pour diverses raisons dont vous n'êtes même pas conscient.
    • Bibliothèques tierces - Ces bibliothèques sont également écrites par des ingénieurs logiciels comme vous et moi. Surveillez toujours l'activité et la fréquence des mises à jour de ces bibliothèques.
    • défaillance matérielle - les logiciels dépendent du matériel. Mark Hanna a expliqué ce qu'est un logiciel sans matériel dans sa citation : "C'est un fugayzi, un fugazi. C'est un whazy. C'est un woozie. C'est de la poussière de fée. Elle n'existe pas. Ça n'a jamais atterri. Ce n'est pas une matière. Ce n'est pas sur la carte des éléments. Ce n'est pas réel."

    Nom : output-onlinegiftools.gif
Affichages : 7697
Taille : 1,15 Mo

    • L'électricité - oui, le matériel a besoin d'énergie électrique pour fonctionner, sans quoi il est inutile. J'ai travaillé sur un projet avec un Raspberry Pi. Le client avait des problèmes constants avec l'appareil qui s'éteignait à des moments aléatoires. Après des jours d'enquête, nous avons finalement trouvé le problème. Il avait utilisé une alimentation différente de celle fournie à l'origine. À cause de cela, l'appareil s'éteignait de manière aléatoire.

    La vérité, c'est qu'il faut partir du principe que tout a des bogues. C'est pourquoi les développeurs expérimentés ne font jamais confiance à leur code s'il fonctionne correctement du premier coup. Même si l'ingénieur de l'assurance qualité signale un bogue, il faut partir du principe que le billet de bogue contient un "bogue" et tout vérifier.

    8) L'incertitude sera votre amie toxique

    Dans ce travail, vous serez confronté à l'incertitude presque tout le temps.

    J'ai déjà expliqué l'exemple des estimations ci-dessus. Ce n'est qu'un exemple d'incertitude. Vous faites de votre mieux, mais vous n'êtes pas sûr à 100 % de pouvoir terminer le travail dans les délais prévus.

    En outre, il y a d'innombrables autres choses qui sont incertaines. En voici quelques exemples

    • mise en œuvre dans votre projet d'un élément avec lequel vous n'avez jamais travaillé, par exemple une API tierce - comment allez-vous mettre en œuvre quelque chose que vous ne connaissez pas ?
    • transfert vers un nouveau projet, avec de nouvelles technologies - vous réfléchirez à la manière dont vous allez être efficace et productif avec quelque chose que vous devez apprendre
    • déménagement dans une nouvelle entreprise - vous ne savez pas comment vous allez vous intégrer et vibrer avec de nouvelles personnes
    • rapport de bug le jour où vous devez terminer le travail - vous craignez de ne pas respecter le délai.
    • la sécurité de l'emploi - les situations économiques, les pandémies, les guerres et d'autres facteurs affectent fortement ce secteur, ce qui entraîne des licenciements
    • l'évolution de la technologie - vous n'êtes jamais sûr d'être remplacé demain par de nouvelles technologies telles que l'intelligence artificielle.

    L'avantage de l'incertitude est qu'elle vous pousse à devenir un meilleur ingénieur logiciel. Elle exige des améliorations et des apprentissages si l'on veut rester dans la course.

    9) Il vous sera presque impossible de vous déconnecter de votre travail

    De temps en temps, je me surprends à penser à mon travail, aux problèmes et aux bogues. Ou aux choses que je dois faire demain alors que je devrais me détendre et me relaxer.

    Parfois, l'eau froide de la douche me réveille alors que je réfléchis à la manière dont je vais résoudre le vilain bogue sur lequel j'ai travaillé hier. J'ai eu d'innombrables disputes avec ma copine qui me demandait pourquoi j'étais sur Slack alors que nous étions sur la plage.

    J'admets donc publiquement que j'ai du mal à me déconnecter du travail.

    C'est particulièrement difficile de se déconnecter quand on travaille à la maison. Si votre ordinateur portable est allumé, vous pouvez toujours consulter vos courriels ou vos messages Slack.

    Alors, pour éviter tout cela :

    • J'éteins mon ordinateur portable lorsque j'ai terminé mon travail,
    • Je mets des heures de silence sur mon téléphone portable pour mes courriels professionnels.
    • Je mets en pause les notifications Slack après les heures de travail. Je les désactive le week-end.
    • Lorsque mon esprit entre dans cette boucle "penser au travail", j'essaie de l'interrompre immédiatement. Je me rappelle que le repos et la détente sont importants pour être productif.
    • Je fais de longues promenades après le travail. Certains jours, je fais du sport, comme du padel ou du football.
    • J'essaie de m'engager socialement autant que possible, en évitant de passer du temps devant un écran après le travail.

    Malgré toutes ces mesures que je prends chaque jour, il m'arrive souvent d'échouer.

    10) Vous profiterez davantage de bonnes "soft skills" que de bonnes compétences techniques

    Les compétences techniques sont celles que vous pouvez apprendre facilement. Grâce à différents projets, vous pouvez comprendre un langage de programmation particulier. Vous pouvez apprendre sa syntaxe, ses avantages et ses inconvénients. C'est juste une question de pratique.

    En revanche, les compétences non techniques (soft skills) sont beaucoup plus difficiles à améliorer. L'amélioration demande beaucoup de force mentale. Vous devez faire des choses avec lesquelles vous n'êtes pas à l'aise.

    Vous devez vous mettre dans des situations où vous pouvez améliorer ou pratiquer certaines compétences non techniques.

    Par exemple, la communication est une compétence non technique dont les gens parlent toujours. Disons que vous êtes nul pour parler en public. Vous devez vous forcer à vous mettre dans des situations où vous pouvez vous entraîner à parler en public.

    Il est très difficile de se mettre intentionnellement dans des situations où l'on sait que l'on sera nul. Votre esprit fera tout pour éviter ces situations. Il trouvera des centaines d'excuses et il est facile d'abandonner.

    Outre la communication, il existe d'autres compétences non techniques :

    • le travail d'équipe
    • l'esprit d'apprentissage
    • l'organisation/la gestion du temps
    • l'intelligence émotionnelle/l'empathie
    • la capacité d'approche
    • la persistance/la patience
    • la confiance en soi

    J'ai rencontré beaucoup de personnes qui possèdent de bonnes compétences techniques, mais avec lesquelles il est très difficile de travailler.

    Par exemple, un collègue me demandait souvent de l'aide. Je l'ai aidé quelques fois. Puis, j'ai remarqué qu'après avoir résolu ses problèmes, il revenait vers moi et me reprochait d'avoir gâché d'autres aspects du projet. J'ai donc dû passer plus de temps avec lui pour régler des problèmes dont je n'étais même pas conscient. Et comme il me faisait des reproches sur un ton si négatif, j'ai cessé de l'aider. Je dirais que j'ai beaucoup de choses à faire et que je pourrai l'aider demain.

    Autre exemple : j'étais le nouveau sur le projet. Un collègue (appelons-le George) était chargé de m'aider en cas de besoin. J'ai mis en place le projet pratiquement tout seul, mais j'ai rencontré une erreur lorsque j'ai essayé d'exécuter le projet. J'ai demandé de l'aide à George. Il a passé environ deux minutes avec moi pour résoudre un problème et m'a dit qu'il ne connaissait pas la solution. Je l'ai quand même remercié, j'ai essayé de résoudre l'erreur par moi-même, mais j'ai finalement réussi avec l'aide de mon collègue Michael. Lors de la réunion quotidienne, George a déclaré qu'il passait toute la journée à me soutenir. Par la suite, je n'ai plus jamais demandé d'aide à George.

    Un autre exemple : un collègue était l'homme fort du projet. Pourtant, toute l'équipe le détestait (les autres développeurs, les chefs de projet, l'assurance qualité, les concepteurs, etc.) C'était un bon ingénieur logiciel, mais un vrai salaud. Il était extrêmement grossier dans sa communication avec tout le monde. Il ne voulait jamais admettre qu'il avait tort ou accepter une critique constructive de son code. La direction le tolérait car il était toujours le plus bruyant dans la pièce. Lorsqu'il a finalement démissionné, toute l'équipe l'a fêté.

    Si vous possédez de bonnes compétences relationnelles, les gens vous apprécieront davantage et vous aurez plus de chances d'obtenir une augmentation ou une promotion. Si vous êtes techniquement doué, mais difficile à côtoyer, vos chances sont légèrement réduites.

    En outre, si vous possédez de bonnes compétences relationnelles, les personnes qui vous connaissent parleront de vous dans votre dos. Elles peuvent vous recommander pour un poste, sans même que vous le sachiez.

    Conclusion

    Le développement de logiciels n'est pas un emploi de rêve.

    Travailler dans le domaine de l'ingénierie logicielle implique souvent de longues heures de travail. La plupart du temps, vous êtes rivé à un écran d'ordinateur, avec peu d'équilibre entre vie professionnelle et vie privée.

    Le travail exige une présence en ligne, parfois même après les heures de travail. Il en résulte souvent du stress et un manque de temps personnel.

    En outre, les tâches fastidieuses nuisent souvent à la satisfaction professionnelle. Selon la situation, les perspectives d'évolution de carrière sont limitées. Le travail à distance présente également un risque d'isolement. Enfin, il existe toujours un risque d'insécurité de l'emploi en raison de l'évolution rapide de la technologie.

    Mais il y a aussi des aspects positifs.

    Le développement de logiciels favorise l'innovation permanente. Les ingénieurs en logiciel peuvent créer des applications attrayantes et résoudre des problèmes intéressants.

    La demande mondiale de solutions logicielles dans divers secteurs est importante. Cela signifie qu'il y a toujours une demande pour de bons ingénieurs en logiciel. Les carrières dans le domaine du développement de logiciels offrent une certaine flexibilité grâce aux possibilités de travail à distance.

    C'est une grande chance de pouvoir travailler depuis n'importe quel endroit. La flexibilité vous permet de dormir le matin sans alarme. Vous pouvez travailler depuis votre domicile en pyjama confortable. De plus, vous ne perdez pas votre temps et votre argent précieux en déplacements.

    Source : "10 hard-to-swallow truths they won't tell you about software engineer job", par Mensur Durakovic, ingénieur logiciel

    Plus de 20 000 offres d'emploi de Développeur ou en Informatique

    Et vous ?

    Quel est votre avis sur le sujet ?

    Voir aussi

    Les microservices ne sont pas le problème. Ce sont les personnes incompétentes qui le sont, par Dmitry Non

    Python est facile. Go est simple. Simple != Facile, Python et Go ont des qualités distinctes qui peuvent se compléter, par Preslav Rachev, ingénieur en informatique

    Ce que tout programmeur doit savoir #1 : L'idempotence, par Berkan Sasmaz, ingénieur logiciel

  2. #2
    Membre éclairé
    Homme Profil pro
    Urbaniste
    Inscrit en
    Août 2023
    Messages
    369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Urbaniste

    Informations forums :
    Inscription : Août 2023
    Messages : 369
    Points : 735
    Points
    735
    Par défaut
    Bonjour,

    Le soft skill est le plus important.
    Comme les projets se complexifient,
    que les équipes sont de plus en plus grande,
    savoir naviguer dans la meute,
    dans l'esprit de groupe,
    est plus important que d'être bon techniquement.

    Par ailleurs, les meilleures solutions
    ne s'évaluent jamais qu'en regard d'un contexte.
    Il ne servirait à rien à une petite boite dont la spécialité
    est le développement react de se retrouver avec
    le meilleur framework d'UI multiplateforme/toutcequetuveux
    écrit en c++. Ils n'ont pas les compétences pour le faire
    fonctionner et si l'expérience devait se dérouler,
    le client ne serrait pas satisfait puisque la vélocité
    des livrables seraient minable.

    La qualité technique des livrable n'est
    que très rarement réellement jugé.
    Ce qui importe c'est de livrer
    dans les temps de ce qui est budgété
    et qui plaît au client.
    Lors de la phase d'exploitation d'un dev,
    si ce dernier fait défaut, on optera pour
    des solutions simple et maitrisés
    pour combattre les défaut rencontrés.
    C'est lent ? Mets plus de CPU ou de RAM.
    ça doublonne de la merde ? Mets des petites mains à dédoublonner.

    Il n'y a qu'à voir le succès de certains projets
    logiciels bien qu'ils sont critiquable à bien des
    égards, d'un point de vue de qualité d'ingénierie, ou autres,
    les clients s'en contre balancent, ce dont
    ils ont besoin c'est de solution opérationnelle éprouvées,
    pour pouvoir capter des marchés rapidement et
    à bas coût.
    Ce dont ils ont aussi besoin, mais cela ils peinent
    à l'avouer, c'est de personnel engagés
    sur qui ils peuvent compter.
    L'essentiel n'est pas de révolutionner l'industrie,
    c'est de contourner ou de sauter au dessus
    des difficultés.

    Cependant, le fait qu'aujourd'hui les devs ne
    parviennent plus à se déconnecter de leurs jobs
    et sont constamment disponible provient
    essentiellement du fait de la mauvaise qualité
    du travail intégré des multiples équipes, à mon sens.
    Ce n'est pas parce que chacune des équipes
    fournit un travail qualitatif et rationnel
    à son niveau que l'ensemble forme
    nécessairement un tout cohérent et rationnel
    dont l'exploitation est reposante.

    Pour les bugs, il faut faire le tri entre
    ce qui est bloquant, et ceux avec lesquels on peut
    survivre, ou, pour utiliser un mot plus neutre, avancer.

    La propreté du code, tu te l'imposes pour toi même
    et ton équipe, parce que de toute manière c'est toi qui
    y reviendra quand ça bug.

    Les estimations, tu doubles, systématiquement.
    Tu triples quand t'es sur une stack que tu ne maitrises pas.
    Au pire, tu livres en avance, tu en ressorts avec plus de lauriers..
    Pour le reste ça fait longtemps que les dirigeants ont intégrés
    l'incertitude du développement logiciel, et si ce n'est pas le cas,
    changez d'équipe dirigeante.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    Le développement de logiciels favorise l'innovation permanente
    Cette phrase m'hérisse le poil. Cela laisse entendre que les autres
    secteurs économique ne font pas d'innovations.
    C'est une grande méprise, même les bouchers de quartiers innovent.
    L'innovation n'est pas un choix, c'est une nécessité résultant des dynamiques
    de développement des sociétés humaines.
    Ce n'est même pas un choix à la portée de théories politique,
    ni même économique.
    On se rappellera de la guerre froide, avec la course à la lune,
    ou la course à l'armement, pour ne citer que des phénomènes récent,
    pour se convaincre que l'innovation n'est pas un choix dans le paradigme humain.



    C'est même, selon moi, un comportement sauvage,
    puisque c'est faire un non choix quand au paradigme
    qui s'impose à nous.



    Bonne journée.

  3. #3
    Membre habitué
    Profil pro
    Chef de projet
    Inscrit en
    Septembre 2008
    Messages
    40
    Détails du profil
    Informations personnelles :
    Localisation : France, Vosges (Lorraine)

    Informations professionnelles :
    Activité : Chef de projet

    Informations forums :
    Inscription : Septembre 2008
    Messages : 40
    Points : 178
    Points
    178
    Par défaut Tellement vrai
    Je suis plutôt en accord avec cet article. Les conseils sont pertinents aussi.

    Mais attention! c'est une article intitulé "10 vérités difficiles à avaler", il est normal qu'il ne mette pas en avant les bons aspects:
    • Vous allez aussi travailler avec des gens compétents
    • De temps à autres, des gens seront contents de votre travail et vous le montreront
    • Globalement vous allez rencontrer des gens éduqués et intéressants
    • Si vous aimez les puzzles, et résoudre des énigmes, ce métier est pour vous


    Il y a tout de même plusieurs autres vérités sur ce métier:
    • Vous allez découvrir que dans l'envers du décor, Microsoft, Amazon, Google mettent souvent sur le marché des logiciels non terminés
    • Travailler de concert avec vos utilisateurs vous permet de faire des outils merveilleusement adaptés - mais négligez de les faire briller côté des encadrants et votre logiciel n'existe pas
    • N'importe quel article publicitaire dans un journal sur un produit peut rendre le vôtre terne aux yeux d'un décideur
    • Rien de majeur n'a réellement été inventé - si vous avez 20 ans de pratique, vous connaissez à peu près tous les courants, ils vont revenir périodiquement sous un autre nom


    Et pour les bugs matériels: sur une install, j'ai eu 2 "bugs" faciles à corriger mais difficiles à tracer:
    • Un bug de retour d'une pesée - lié au fait que la balance n'était pas à la masse
    • Un bug de détection de colis périodiquement toutes les nuits - lié à de la buée sur un capteur trop proche d'un porte, la buée s'accumulait lors des passages par cette porte à la pause

  4. #4
    Membre éprouvé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2019
    Messages
    198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Septembre 2019
    Messages : 198
    Points : 967
    Points
    967
    Par défaut
    11) Sitôt embauché dans votre nouvelle boîte (souvent, une ESN), vous serez harcelé par d'autres recruteurs (également des ESN) et vous passerez tous les ans ou tous les deux ans à changer d'entreprise

  5. #5
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 340
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 340
    Points : 20 324
    Points
    20 324
    Par défaut
    Citation Envoyé par d_d_v Voir le message
    11) Sitôt embauché dans votre nouvelle boîte (souvent, une ESN), vous serez harcelé par d'autres recruteurs (également des ESN) et vous passerez tous les ans ou tous les deux ans à changer d'entreprise
    au vu de la conjoncture c'est une logique très risquée...là on a Atos , 5 milliards de dette donc grosse ESN au bord de la faillite qui risque de mettre 100 000 salariés sur le carreau.
    Je pense pas que Kretinsky, sauf erreur de ma part, souhaite injecter du cash dans la boite car c'est pas pour ça qu'elle sera plus rentable.
    Après on va me rétorquer évidemment que la situation chez Atos n'est pas la même comparativement à d'autres ESN,qu'il ne faut pas généraliser mais tout de même on reste très interrogatif.

  6. #6
    Membre éprouvé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2019
    Messages
    198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Septembre 2019
    Messages : 198
    Points : 967
    Points
    967
    Par défaut
    Citation Envoyé par Mat.M Voir le message
    au vu de la conjoncture c'est une logique très risquée...là on a Atos , 5 milliards de dette donc grosse ESN au bord de la faillite qui risque de mettre 100 000 salariés sur le carreau.
    Je pense pas que Kretinsky, sauf erreur de ma part, souhaite injecter du cash dans la boite car c'est pas pour ça qu'elle sera plus rentable.
    Après on va me rétorquer évidemment que la situation chez Atos n'est pas la même comparativement à d'autres ESN,qu'il ne faut pas généraliser mais tout de même on reste très interrogatif.
    C'est amusant ce que tu dis car coïncidence, je suis en cours de process de recrutement chez ... Atos; enfin une entreprise entité d'Atos

  7. #7
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 042
    Points
    32 042
    Par défaut
    Citation Envoyé par Mat.M Voir le message
    au vu de la conjoncture c'est une logique très risquée...là on a Atos , 5 milliards de dette donc grosse ESN au bord de la faillite qui risque de mettre 100 000 salariés sur le carreau.
    à 85% de taux d'activité chez une SSII moyenne (enfin, c'est ce qu'on m'avait dit au début des années 2010), il y a donc 85 000 salariés qui sont en mission chez les clients, et que les autres seront ravis de réembaucher immédiatement. Les 15 000 autres, c'est plus compliqué, mais si le marché ne s'effondre pas, ils devraient finir par retrouver aussi.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  8. #8
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 340
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 340
    Points : 20 324
    Points
    20 324
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    il y a donc 85 000 salariés qui sont en mission chez les clients, et que les autres seront ravis de réembaucher immédiatement.
    rien ne prouve que toutes ces personnes soient ré-embauchées dans la foulée.
    Citation Envoyé par el_slapper Voir le message
    à 85% de taux d'activité chez une SSII moyenne (enfin, c'est ce qu'on m'avait dit au début des années 2010), il y a donc 85 000 salariés qui sont en mission chez les clients.
    merci pour l'info donc ça signifie que 15% des salariés sont en intercontrat alors ?
    Mais moi je raisonne en logique financière au cas où personne ne l'a remarqué pas en logique de ressources humaines.
    Y'a pas les finances et les liquidités pour payer les salariés bah...personne ne reçoit sa paie
    Citation Envoyé par d_d_v Voir le message
    C'est amusant ce que tu dis car coïncidence, je suis en cours de process de recrutement chez ... Atos; enfin une entreprise entité d'Atos
    admettons que vous soyez embauché vous allez être payé comment ? En actions Atos ? Le titre il vaut même pas 4 euros donc c'est pas avec ça que vous allez payer vos factures

  9. #9
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 042
    Points
    32 042
    Par défaut
    Citation Envoyé par Mat.M Voir le message
    rien ne prouve que toutes ces personnes soient ré-embauchées dans la foulée.
    non, mais le besoin est là. Donc ça devrait passer quand même pas trop mal

    Citation Envoyé par Mat.M Voir le message
    merci pour l'info donc ça signifie que 15% des salariés sont en intercontrat alors ?
    La formulation exacte était "la facturation est calculée pour un taux d'activité de 85%". Ce qui doit amener à un résultat approximativement proche de 15% de salariés en intercontrat.

    ça resterait un problème violent si ça tombait, mais d'ampleur nettement moins brutale que ce qu'il parait au premier abord.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  10. #10
    Membre éprouvé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2019
    Messages
    198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Septembre 2019
    Messages : 198
    Points : 967
    Points
    967
    Par défaut
    Citation Envoyé par Mat.M Voir le message
    Y'a pas les finances et les liquidités pour payer les salariés bah...personne ne reçoit sa paie
    admettons que vous soyez embauché vous allez être payé comment ? En actions Atos ? Le titre il vaut même pas 4 euros donc c'est pas avec ça que vous allez payer vos factures
    Je ne vois pas le rapport entre le fait que la valeur boursière se soit effondrée et le fait d'être payé ou pas en tant que salarié.
    D'abord, il s'agit d'une entreprise (pas une ESN) appartenant à Atos. Et même si c'était Atos directement, l'entreprise est endettée, et bien tout simplement, les salariés sont payés grâce à l'endettement, qui, normalement, devrait se réduire si l'entreprise est bien reprise en main. Et de toutes façons, c'est une entreprise avec un chiffre d'affaires.
    Si je prend le parallèle avec la France, comment croyez-vous que les fonctionnaires sont payés, alors que le pays est ultra-endetté, et qui continue à creuser sa dette ? A votre place, je me soucierais plus de l'état des finances du pays que d'une entreprise

    Pour votre information, j'ai déjà travaillé dans une entreprise qui a déposé le bilan. Dans ce cas là, l'administrateur judiciaire récupère tout ce qu'il peut récupérer, et les salariés étant les premiers indemnisés (au bout de plusieurs mois). Je crois même qu'il y a un fond de garantie étatique dans le cas extrême où même les premiers servis (les salariés) ne pourraient pas être indemnisés. Les actionnaires passent après les salariés.

  11. #11
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 340
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 340
    Points : 20 324
    Points
    20 324
    Par défaut
    Citation Envoyé par d_d_v Voir le message
    A votre place, je me soucierais plus de l'état des finances du pays que d'une entreprise
    bonsoir c'est que l'état des finances publiques bref la dette publique je m'en préoccupe pas; évidemment à condition que la fiscalité (impôts société/revenu) n'augmente pas.
    C'est les problèmes de Mrs Le Maire de Mr Macron , de Mr Moscovici et toute leur clique pas les miens et je leur fais confiance...
    mon message concernait l'économie privée bref marchande pas celle publique
    de toute façon faut pas perdre de vue qu'avec une dette publique élevée le gouvernement risque de supprimer des dépenses notamment des budgets pour des projets informatiques ou pas.
    Moi ce qui me préoccupe c'est de faire du business or j'ai l'impression que les ESN françaises ont des difficultés pour ça

  12. #12
    Membre éclairé
    Homme Profil pro
    Urbaniste
    Inscrit en
    Août 2023
    Messages
    369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Urbaniste

    Informations forums :
    Inscription : Août 2023
    Messages : 369
    Points : 735
    Points
    735
    Par défaut
    C'est les problèmes de Mrs Le Maire de Mr Macron , de Mr Moscovici et toute leur clique pas les miens et je leur fais confiance...
    hheeeeuuuu j'aii de mauvaises nouvelles à vous annoncer. Par où on commence ?

    Ils sont balèzes quand même les gars à la propagande, il faut le reconnaître.

  13. #13
    Membre éprouvé
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    1 817
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 1 817
    Points : 972
    Points
    972
    Par défaut
    Ajouter entre 50-300% sur l'estimation de temps, perso le truc qui ne sert pas à grand chose... car au final, ça impact le prix que va payer le client... qui va dire qu'il laisse tomber parce que c'est trop cher... donc le commercial fait une ristourne pour avoir l'affaire... et là, tu reviens à une estimation sans marge.
    J'ai déjà eu des cas où j'ai annoncé un temps et ce temps a été minoré... après je dirai que ce n'est plus mon problème.

    Le plus difficile, c'est de coter une fonctionnalité quand le client ne sait pas trop ce qu'il veut... tu te retrouve généralement avec plein de dev supplémentaires à réaliser pour que le client soit content parce qu'il a mal cadré sa demande.

  14. #14
    Expert confirmé
    Avatar de shenron666
    Homme Profil pro
    avancé
    Inscrit en
    Avril 2005
    Messages
    2 519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : avancé

    Informations forums :
    Inscription : Avril 2005
    Messages : 2 519
    Points : 5 170
    Points
    5 170
    Par défaut
    1) L'université ne vous prépare pas à la réalité du travail
    Malheureusement vrai, les ingés sortis d'école connaissent une partie théorique très étriquée du métier

    2) Vous obtiendrez rarement des projets entièrement nouveaux
    Plutôt vrai aussi, et vécu

    3) Personne n'en a rien à faire de la propreté de votre code
    Pas totalement d'accord, entre techs on aime un code lisible, mais côté management c'est malheureusement vrai
    et après ils ne comprennent pas pourquoi il faut plus de temps pour faire évoluer le produit

    4) Vous travaillerez parfois avec des personnes incompétentes
    pas parfois, non, souvent, très souvent
    mais souvent aussi, "l'incompétent" c'est l'ingé sorti d'école
    plus exactement il manque d'expérience, il faut qu'il ait conscience qu'il doit monter en compétence et pas se prendre pour le kador dès son arrivée

    5) Habituez-vous à participer à des réunions pendant des heures
    j'appelle ça la réunionite aigüe
    2h par ci, 2h par là, pour ne prendre aucune décision et ne rien faire avancer

    6) Ils vous demanderont des estimations à de nombreuses reprises
    bien souvent avant même de connaitre le besoin ou d'avoir fait l'étude
    avant on chiffrait à la louche
    ensuite on est passés à la pelleteuse
    maintenant je répond 42

    7) Les bogues seront votre ennemi juré à vie
    là dessus, pas d'accord
    enfin il y a bogue et bogue
    il y a le bogue critique et celui qui est anecdotique
    et il y a le bogue de la bibliothèque du fournisseur qui met des mois à identifier la root cause et encore plus à corriger

    8) L'incertitude sera votre amie toxique
    euh... là je vois pas

    9) Il vous sera presque impossible de vous déconnecter de votre travail
    il y a un travail de prise de conscience
    parfois après le burnout
    mais l'être humain n'a qu'un seul cerveau, et pas de switch pour passer du mode travail au mode perso

    10) Vous profiterez davantage de bonnes "soft skills" que de bonnes compétences techniques
    ça reste à voir
    mais le mieux reste de se réserver soi-même du temps pour faire de la veille techno

    Conclusion
    Le développement de logiciels n'est pas un emploi de rêve.
    il y a autant d'emplois dans le développement que de boites de développement

    Quel est votre avis sur le sujet ?
    un point oublié qui est de plus en plus présent dans mon quotidien
    au delà de faire la chasse aux bugs, c'est la chasse aux failles de sécurités et les remédiations qui me prennent infiniment plus de temps
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

Discussions similaires

  1. Réponses: 14
    Dernier message: 19/02/2008, 11h55
  2. Réponses: 1
    Dernier message: 22/12/2005, 18h28
  3. Réponses: 2
    Dernier message: 12/10/2005, 16h15
  4. Réponses: 19
    Dernier message: 19/09/2005, 22h02
  5. Réponses: 9
    Dernier message: 23/02/2004, 20h14

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo