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 !

Le métier d'ingénieur logiciel passionne-t-il encore ?
Un développeur raconte comment il a perdu la flamme

Le , par Stéphane le calme

21PARTAGES

10  3 
Sur un billet blog, un développeur se remémore les circonstances dans lesquelles est née sa passion pour la programmation. Avec quelquefois une pointe d'humour, il se rappelle comment il griffonnait des lignes de code sur des bouts de papier pendant les cours d'histoire. « Elle (le professeur) pensait probablement que je prenais des notes. Ou alors elle savait que je n'y prêtais aucune attention mais elle ne s'en préoccupait pas » explique-t-il.

La programmation le fascinait. Il ne vivait plus que pour concevoir des algorithmes et les transformer en langage de programmation. A l'époque il n'avait pas d'ordinateur et devait se résoudre à utiliser celui d'un de ses amis. Il décrit la sensation qui s'emparait de lui une fois que le code était fonctionnel, cette sensation bien connue par les développeurs qui sortent victorieux d'un challenge intellectuel.

Bien sûr c'était grisant. Sa soif de connaissance étant de plus en plus grande, il se tourne vers Internet pour se former. Puis vient la fac. Naturellement il opte pour des études en Sciences informatiques. Seulement, les TP de programmation deviennent vite ennuyeux puisqu'il a déjà parcouru la majorité des sujets. La seule chose qui aiguise encore son intérêt à l'école ce sont les cours théoriques. Pour avoir l'occasion de tester ses connaissances dans le monde réel, il recherche un stage de développeur à mi-temps. Le fait qu'il soit peu payé ne le préoccupait pas, à ce moment ce qu'il recherchait c'était une plus grande expérience. Seulement il avait l'impression de ne pas réellement en apprendre tant que ça, bien au contraire même. Il avait l'impression de ne pas faire grand usage de son intellect à cause de la routine. Pour lui, tout cela aurait été différent s'il était né plusieurs dizaines d'années plus tôt, à l'époque où l'ingénierie logicielle en était à ses balbutiements, car les défis étaient plus stimulants car plus difficiles.

Il conclut en disant que si vous aimez réellement le développement, devenir ingénieur logiciel ne serait pas votre meilleure option. L'une des raisons qu'il évoque est que la plupart des offres d'emploi correspondant à ce profil sont ennuyeuses. Ce qu'il propose c'est de se spécialiser. « Vous aimez les algorithmes ? Vous pouvez devenir un chercheur en informatique. Vous pouvez devenir un programmeur système et développer des OS. Essayez de creuser dans le code source Linux. » recommande-t-il, « Quoi que vous fassiez, ne soyez pas un " ingénieur logiciel " générique. ».

Source : billet blog

Et vous ?

Partagez-vous son point de vue ?

N'y a-t-il plus de projets aux défis intellectuellement intéressants pour un ingénieur logiciel ?

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

Avatar de pcaboche
Rédacteur https://www.developpez.com
Le 16/10/2013 à 6:43
Non seulement l'auteur a raison (le métier de "software engineer" devient vite routinier) mais la réalité est encore pire que cela...

De ce que j'ai pu constater, la plupart des problèmes d'informatique en entreprise sont en fait liés à une architecture bancale. Par contre, si en tant que "software engineer" vous relevez ces problèmes (alors que personne d'autre ne semble en comprendre la cause exacte) et expliquez comment le résoudre (ce qui, malheureusement, implique souvent de revoir une partie de l'architecture), on vous répond (dans l'ordre) :
- "on peut pas"
- "ça coûte trop cher"
- "faut faire avec"
- "dit, tu pourrais pas nous trouver un moyen de contourner le problème sans pour autant changer la structure du programme, sans introduire de bug, et pour la semaine prochaine ? Ah, et puis si au passage tu pouvais nous rajouter ces 3 fonctionnalités que le client demande, ça serait sympa, merci..."


En résumé, le métier de "software engineer", ça consiste à appliquer des rustines infâmes pour contourner des problèmes informatiques qui ne devraient même pas exister si les "responsables" avaient fait leur boulot correctement (ou au moins se donnaient les moyens de corriger les problèmes rapidement plutôt que de les laisser s'accumuler pendant 10 ans...).

En entreprise, "software engineer" est considéré comme le métier au plus bas de l'echelle dans le domaine développement. Certains diront même que c'est le terme politiquement correct pour dire "pisseur de code" (tout comme on ne dit pas "caissière" ou "balayeur" mais "hôtesse de caisse" ou "technicien de surface".

Bref, pour des raisons différentes on en arrive à la même conclusion que l'auteur: "Whatever you do, don't just be a generic "software engineer". It sucks bad.".
27  4 
Avatar de redcurve
Membre éclairé https://www.developpez.com
Le 16/10/2013 à 7:52
Citation Envoyé par pcaboche Voir le message
Non seulement l'auteur a raison (le métier de "software engineer" devient vite routinier) mais la réalité est encore pire que cela...

De ce que j'ai pu constater, la plupart des problèmes d'informatique en entreprise sont en fait liés à une architecture bancale. Par contre, si en tant que "software engineer" vous relevez ces problèmes (alors que personne d'autre ne semble en comprendre la cause exacte) et expliquez comment le résoudre (ce qui, malheureusement, implique souvent de revoir une partie de l'architecture), on vous répond (dans l'ordre) :
- "on peut pas"
- "ça coûte trop cher"
- "faut faire avec"
- "dit, tu pourrais pas nous trouver un moyen de contourner le problème sans pour autant changer la structure du programme, sans introduire de bug, et pour la semaine prochaine ? Ah, et puis si au passage tu pouvais nous rajouter ces 3 fonctionnalités que le client demande, ça serait sympa, merci..."


En résumé, le métier de "software engineer", ça consiste à appliquer des rustines infâmes pour contourner des problèmes informatiques qui ne devraient même pas exister si les "responsables" avaient fait leur boulot correctement (ou au moins se donnaient les moyens de corriger les problèmes rapidement plutôt que de les laisser s'accumuler pendant 10 ans...).

En entreprise, "software engineer" est considéré comme le métier au plus bas de l'echelle dans le domaine développement. Certains diront même que c'est le terme politiquement correct pour dire "pisseur de code" (tout comme on ne dit pas "caissière" ou "balayeur" mais "hôtesse de caisse" ou "technicien de surface".

Bref, pour des raisons différentes on en arrive à la même conclusion que l'auteur: "Whatever you do, don't just be a generic "software engineer". It sucks bad.".
Je suis tout à fait d'accord personnellement en fait j'en ai assez de faire des applications bancale. Créer des rustines sur des archi pourave, faire du code sans queue ni tête pour contourner les délires de certains fumistes.

En ce moment par exemple je travail sur une application qui est une catastrophe technique, des palanqués de code aussi bête qu'inutile du code spaghetti à gogo, des choses qui défis l'entendement, mais impossible de corriger les bugs de fou ou de remettre tout ça d'équerre parce que :

- "on peut pas"
- "ça coûte trop cher"
- "faut faire avec"
- "dit, tu pourrais pas nous trouver un moyen de contourner le problème sans pour autant changer la structure du programme, sans introduire de bug, et pour la semaine prochaine ? Ah, et puis si au passage tu pouvais nous rajouter ces 3 fonctionnalités que le client demande, ça serait sympa, merci..."


Et toujours les même excuse "C'est une vieille application" "ça utilise une ancienne version de dotnet (2.0)" comme si il y avait une corrélation entre la version du Framework X ou Y et la qualité du code produit par les devs ^^. Donc en gros on peut faire de la merde parce qu'en 2023 ce que nous aurons produit sera vieux. J'en ai marre de cet état d'esprit.

Je commence à désespérer tout simplement ...
16  1 
Avatar de Deaf
Membre éprouvé https://www.developpez.com
Le 16/10/2013 à 9:41
Je pense juste que c'est une vision naïve de la part de l'auteur. C'est comme l'enfant qui veut devenir pompier pour utiliser la lance ou la grande échelle. Il ne savait pas que c'était aussi des interventions pour des malaises, des accidents de voitures (plus ou moins trashs), couper le gaz de quelqu'un parti en vacances...

Le métier d'ingénieur logiciel, c'est bien plus que de pondre des algos chiadés. C'est déjà comprendre la problématique, poser les bonnes questions pour s'assurer que celui qui exprime le besoin l'a bien fait, anticiper les changements d'avis, d'humeur qui conduisent à un changement du besoin, énumérer toutes les contraintes, faire une synthèse de tout cela avant de songer à concevoir l'algo. Et cela, ce n'est que le travail en amont.

En concevant l'algo, il faut surtout avoir le sens pratique et pas uniquement le plaisir théorique d'un joli truc qui marche. Il faut penser testabilité, lisibilité, maintenance, évolutivité. Il faut donc aussi pondre de la doc pour les autres, mais aussi pour soi, parce que dans 1 an, l'algo qu'on a fait en quelques heures/jours, on aura oublié une bonne partie des tenants et des aboutissants, étant donné qu'on en aura fait des dizaines/centaines d'autres entre temps.

Et la maintenance, cela fait partie intégrante de notre travail. Vous changeriez de voiture à chaque fois qu'un phare ne fonctionne plus ou qu'elle a du mal à démarrer?
C'est normal de maintenir ce que l'on a fait ou ce que les autres ont fait et c'est la plupart du temps beaucoup moins couteux, même si on a tendance à croire l'inverse, surtout quand manque d'expérience.

En bref, un métier se regarde dans son ensemble et s'accepte dans son ensemble. L'auteur a découvert le monde réel et cela ne lui convient pas, soit! Ce n'est juste pas un ingénieur logiciel dans l'âme, quoi qu'il en dise. Du coup, son avis n'a pas de valeur à mes yeux.

Pour un vrai pompier, son travail n'est pas d'éteindre les incendies, c'est venir en aide aux autres, et cela couvre un certain nombre d'interventions peu passionnantes...
De même, pour moi ingénieur logiciel, c'est utiliser mes compétences, techniques et humaines (ne pas négliger la seconde), pour répondre à un besoin le plus intelligemment possible, via l'informatique. Cela peut aller de la conception au conseil en passant par la formation et la maintenance. Faire une tâche qui ne me passionne pas fait aussi partie de mon travail, mais je le fais plus facilement en gardant en tête le but à atteindre qui lui me permet de "garder la flamme" et d'aimer mon travail.
13  3 
Avatar de phryos
Membre du Club https://www.developpez.com
Le 16/10/2013 à 8:11
+1 pcaboche et redcurve

Le pire c'est quand tu tombes sur un projet qui foire et ou tu manges grave parce que tu es le dernier maillon de la chaine de production (i.e. tout le monde a pris du retard ou n'a pas fait son taf, et toi t'es le dernier à coder donc tu dois rattraper le retard de tout le monde et ce sera toujours à toi que l'on demandera toujours plus). J'ai vu plein d'excellents développeurs complètement dégouté qui se sont barrés de la boite ou qui ont arrêté le dev.
10  1 
Avatar de 4sStylZ
Membre éprouvé https://www.developpez.com
Le 16/10/2013 à 11:48
+1 avec les deux plus haut.
J'ai pas la même expérience, mais je vois déjà les choses comme ça.

Quand je repère des anomalies grave dans l'architecture :

- On n'écoute même pas mon avis du fait de ma faible expérience.
- Si on l'écoute, on me dit que c'est trop tard pour des raisons de couts.
- Au mieux on me demande des rustines pour "corriger une section" sans pour autant que j'ai le temps de changer vraiment la structure d'une fonctionnalité ou d'un module, et que je corrige l'origine des problèmes.

Le résultat c'est que X mois après quand il y à une autre petite évolution ou anomalie repérée sur une fonctionnalité que j'ai du rustiner en speed, ben je dois avertir que cela ne vas pas être possible parce que... Encore une fois l'archi est pourrie on me sort :

"Tatata mais tu est passé dessus ya 2 mois, comment ça se fait que le code est encore pourri? Tu as donc refait de la merde une seconde fois?"

J'ai obtenu une fois le droit de faire une étude d'impact sur la refonte d'une fonctionnalité : Elle n'a pas été lu, et on ne changera jamais rien dans l'archi parce que "Oh surprise : Le travail est conséquent...".

Moi, le travail d'une architecture, la refonte, je vois un peu ça comme cette petite blague :

Un bucheron américain sort sa hache émoussée, et commence à couper du bois. Un indien le vois et lui dit : "Tu as beaucoup de bois à couper dit donc, pourquoi n'aiguise tu pas ta hache?"
-> "Je n'ai pas le temps d'aiguiser ma hache, je suis déja à la bourre dans le planning, regarde ce qu'il me reste à couper !"

Au final, j'ai qu'une paire d'année de métier, et j'ai déja l'impression de ne produire que des immondices. Et franchement, quand on est passionné, coder des saloperies, c'est vraiment pas du tout valorisant, et cela même si personne relis ton code.
10  1 
Avatar de Deaf
Membre éprouvé https://www.developpez.com
Le 16/10/2013 à 12:03
Citation Envoyé par lebaba Voir le message
JE VEUX REFLECHIR, TROUVER LES BONS ALGO ET PRODUIRE DU CODE PROPRE!
C'est bien là la raison de la désillusion des jeunes développeurs.

On a tendance à voir la situation de manière statique: il y a un problème, j'élabore une solution qui y répond, LA solution (ou une des meilleures quand on a un peu d'humilité).

Sauf qu'en fait le problème évolue, les contraintes changent et LE bon algo devient d'un coup une solution passable. Donc celui qui vient après veux la jeter parce qu'il a LA solution, lui...

Même pour un problème bien défini, le bon algo n'existe pas.
L'évolution des technos et du matériel font qu'une meilleure solution sera bientôt possible, mais elle nécessitera de tout refaire, ce qui n'est pas acceptable pour un logiciel déjà opérationnel.

L'exemple du bucheron et de la hache n'est pas complet si on veut se rapprocher de la discussion.
Imaginons que le bucheron écoute l'indien et aiguise sa hache. Dès qu'elle va s'émousser un peu, il va de nouveau l'aiguiser et il va finalement passer autant de temps à l'aiguiser qu'à couper.

Dans les deux cas, il faut trouver le juste milieu: Jauger quand est-ce que c'est plus intéressant en terme de coût (temps/argent) de refondre un logiciel / d'aiguiser sa hache. Il faut le faire, mais pas tout le temps...
9  0 
Avatar de Paul TOTH
Expert éminent sénior https://www.developpez.com
Le 16/10/2013 à 6:07
Citation Envoyé par Stéphane le calme Voir le message

Partagez-vous son point de vue ?

N'y a-t-il plus de projets aux défis intellectuellement intéressant pour un ingénieur logiciel ?
je doute qu'il y a 20 ans, les ingénieurs sur IBM AS/400 ou Système 38 prenaient leur pied à coder en RPG ou Cobol...c'est intéressant une fois pour découvrir ce que c'est et ensuite c'est de la routine.

je pense contrairement à lui qu'on a jamais eu autant de stimulations intellectuelles qu'aujourd'hui. la multiplication des plateformes (Windows, Mac, Linux, Android, iOS), l'interconnexion de tout ce monde permet de faire des choses palpitantes. Par contre le développement d'applis de gestion reste toujours aussi rébarbatif.
7  0 
Avatar de Nathanael Marchand
Rédacteur https://www.developpez.com
Le 18/10/2013 à 13:01
Citation Envoyé par pvoncken Voir le message
Beaucoup de monde qui travaille en développement ne sont pas des passionnés, c'est ce qui donne cet impression que faire des appli de gestion ca n'est pas très intéressant.

Mais en réalité je suis complètement de l'avis contraire. Je me suis spécialisé assez tôt sur la création d'appli de gestion, d'abord je suis monté en compétence sur Java ensuite est venu l'industrialisation (avec Maven et Jenkins par exemple) et ensuite les méthodes agiles. Ces trois domaines complémentaires me permettent de gérer entièrement des projets autant du point de vue de l'architecture applicative que sur la gestion de projet pour faire en sorte que mes équipes soit motivés.

Les deux axes à améliorer pour travailler dans de bonnes conditions sont de proposer des technos industrielles / innovantes pour augmenter la productivité des équipes et de bien gérer ses projets grâce aux méthodes agiles qui permettent de ne pas accepter n'importe quelles demandes.

Lorsqu'on fait tout cela, je peux vous assurer que le métier est passionnant. La contre parti c'est qu'il faut acquérir des compétences sur ces trois domaines ce qui n'est pas évident lorsqu'on commence. Le secret c'est de travailler pour des boites spécialisés où on a l'occasion de travailler avec les meilleurs de chaque domaines.
T'as beau y mettre toutes les dernieres technos que tu veux, ca reste des formulaires avec de la mise en forme conditionnelle, des règles de validation et de la persistance... Quelque soit la techno, t'as a peu près la même archi ou du moins les mêmes concepts. Design des vues avec les champs, les controleurs, le modèle, la persistance et pouf, ca fait une appli de gestion.
Je vulgarise volontairement mais pas tant que ca en fait. J'ai dans ma besace quelques templates d'archi que je déploie (App intranet en Silverlight, App Windows Phone, App Windows 8, Backend web avec WebAPI) qu'on va même se permettre d'automatiser tellement ca bouge peu... On le rafraichit régulièrement autre pour rester adopter les dernières technos et derniers framework mais fondamentalement, il reste que l'adaptation au métier de l'app à faire quoi...

Faut pas se leurrer, si sur le marché y'a autant d'outils génériques disponibles comme des ERP, des CMS et des générateurs de projet, c'est que y'a quand même une grosse part qu'est repetitive est automatisable.

Après effectivement, autour, y'a quelques postes qui sont plus funky comme l'architecte qui met au point ca, ou les gens qui interviennent sur des problèmatiques précises (optim d'accès aux bases, besoins spécifiques). Mais la majorité des features dans un catalogue, c'est quand même rajouter une case à cocher et la cabler en BDD.

Pour ma part, dans ma boite j'ai justement un poste special qui me permet de pas tomber dans cette routine et d'avoir des missions plus funky mais c'est pas la majorité des gens...
6  0 
Avatar de Nathanael Marchand
Rédacteur https://www.developpez.com
Le 21/10/2013 à 20:37
Citation Envoyé par Johnny P. Voir le message
Non je ne suis pas d'accord si on te recrute en tant que développeur .Net c'est que tu aimes faire du C# et pas du ruby , java ou autre le fait d'accepter d'utiliser un langage que tu n'aimes pas fait que tu feras mal ton métier.

Mais ton post prouve que les gens dans une société n'ont pas compris c'est qu'est d'être programmeur... c'est avec une telle mentalité que le métier ne passionne plus.
En fait les programmeurs sont pris pour une simple relation d'exécutant ? si on me demande de faire du cobol c'est sans moi c'est ça un pro.

Par ailleurs ton message est étonnant alors qu'on sait que se spécialiser reste la meilleur façon d'être opérationnel et bon si l'employeur croit que du jour au lendemain tu apprends à fond un langage en passant du .net -> Java et ses multiples API c'est qu'il n'a pas sa place.

Pour en revenir au sujet je dirai qu'effectivement il y a des grandes différences entre l'école et la réalité ou tu dois subir les choix (parfois correcte) et souvent mauvais.
Tout dépend de la boîte et le degré de liberté/tolérance.
Il y a qu'en France (Europe ?) ou y a cette notion d'immédiateté opérationnelle, très lié au contexte SSII : un client paie pour une prestation assez courte (<3ans) il ne peut pas se permettre de perdre 17% (6mois) du temps pour mettre le consultant à niveau sur le langage (d'autant plus que ca serait un mauvais investissement, le consultant n'étant plus là après).
Dans un milieu ou il y a moins de prestation mais plus de production logicielle, ca n'est plus le cas : on mise sur un profil qui sait raisonner, il s'adaptera à la techno après... Dans la Bay, les entretiens sont plutôt de l'algorithmie en pseudo langage sur un tableau blanc, que tu roxxes Java, .Net au Cobol importe peu... Mais les besoins et contextes sont différents...

C'est une opposition entre une informatique de service, ou le but est de combler un besoin métier de la manière la plus efficace (la notion d'efficacité est totalement subjective: ca peut être un pansement sur une jambe de bois qui hérisse le poil d'un technique mais qui satisfait le business) et une informatique d'édition ou le but est d'avoir le meilleur produit pour le vendre ensuite. La France n'est malheureusement pas un grand pays d'éditeurs de logiciels (mis à part Dassault Systèmes).
6  0 
Avatar de zaventem
Membre chevronné https://www.developpez.com
Le 22/10/2013 à 11:24
Citation Envoyé par Johnny P. Voir le message
Non je ne suis pas d'accord si on te recrute en tant que développeur .Net c'est que tu aimes faire du C# et pas du ruby , java ou autre le fait d'accepter d'utiliser un langage que tu n'aimes pas fait que tu feras mal ton métier.
D'ailleurs si un ouvrier est spécialisé en marteau, faut pas le demander d'utiliser un tournevis!

Je crois vraiment que je ne fais pas le même métier que certaines personnes ici: mon métier, c'est utiliser mes connaissances pour que l'outil informatique aide/rende possible le métier de l'entreprise à accomplir ses taches. Le langage n'est qu'un outil et il faut utiliser le plus approprié.
6  0