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.


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

• 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