IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 , par Mensur Durakovic

67PARTAGES

31  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Rep.Movs
Membre actif https://www.developpez.com
Le 27/12/2023 à 14:08
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
7  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 30/01/2024 à 8:51
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.
4  0 
Avatar de shenron666
Expert confirmé https://www.developpez.com
Le 02/02/2024 à 20:09
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
4  0 
Avatar de unanonyme
Membre éclairé https://www.developpez.com
Le 23/12/2023 à 11:07
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
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  0 
Avatar de d_d_v
Membre éprouvé https://www.developpez.com
Le 29/01/2024 à 0:19
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
3  0 
Avatar de unanonyme
Membre éclairé https://www.developpez.com
Le 31/01/2024 à 19:20
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.
2  0 
Avatar de calvaire
Expert éminent https://www.developpez.com
Le 21/03/2024 à 11:13
Citation Envoyé par Mat.M Voir le message

il se trouve que cette personne c'est moi...ensuite si l'entreprise ne gagne pas assez d'argent pour payer ses dettes que se passe-t-il alors ?
elle se fait racheter plusieurs milliards. Twitter en est le parfait exemple.
le but d'une start up je pense c'est de crée le plus de buzz possible, de faire croire en un produit miracle pour faire gonfler sa valeur, tant que ca valeur est supérieur à sa dette c'est bon et quand le ceo pense avoir atteint le max de la valeur faut trouver un gafam pour la racheter.

A l'heure de la statup nation, qui va racheter la France ? l'information est tenu secrète mais il semble que ce soit Blackrock et/ou des princes d’Arabie.
Il n'ya pas que l'argent, une dette peut se rembourser en donnant des terres, des femmes et du patrimoine a des princes arabes, la tour eiffel et nos jeunes femmes vierge de 14ans par exemple pourrait être donné, il y'a quelques iles de milliardaires qui en cherche.
Ca se fait déjà en grece
pas les femmes mais les monuments, mais bon allons plus loin on est plus a sa prêt
2  0 
Avatar de Mat.M
Expert éminent sénior https://www.developpez.com
Le 29/01/2024 à 18:33
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.
1  0 
Avatar de Mat.M
Expert éminent sénior https://www.developpez.com
Le 30/01/2024 à 9:46
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
1  0 
Avatar de d_d_v
Membre éprouvé https://www.developpez.com
Le 31/01/2024 à 11:17
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.
1  0