Discussion :

[Stéphane le calme]

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

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 ?

[Olfredos6]

Je suis un peu choqué par cet article. je suis actuellement étudiant en afrique du sud en Computer Systems Engineering, ce n'est pas trop pareille à Computer Science parceque j'ai un tas d'autre cours d'electronique et Power engineering. Je comptais me faire un master en genie logiciel juste après mon BTech. Voir cet article, y a trop des questions qui se posent dans ma tête, au devellopeurs professionels, vais-je mess up ma vie en me specialisant en genie logiciel?? Avis s.v.p

[martin.magakian]

Slt Olfredos6,
Mais non tu vas pas foirer ta vie

Ce gas est un dingue d'algo. Il trouve sont bonheur à faire de l'algo pure et dure.
Personnellement j'aime bien aussi, mais je n'aimerai pas faire ça toute la journée.

ne soyez pas un " ingénieur logiciel " générique

Il veut dire "Ingénieur logiciel standard" ou "ingénieur logiciel généraliste"?

Si il s'agit de "standard" forcement il faut éviter d'être nulle dans sont boulot.
Ca permet d'accéder à des postes plus intéressent.

Si il s'agit de "généraliste" alors non je ne suis pas d'accord. Être généraliste permet d'accéder à un tous autre type de poste intéressent.

Cordialement
Martin Magakian

[pcaboche]

Il veut dire "Ingénieur logiciel standard" ou "ingénieur logiciel généraliste"?

Il veut dire : 'generic "software engineer" ' (cf. le billet original).

Dans ce contexte, 'generic' = générique/quelconque/lambda...

[Paul TOTH]

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.

[pcaboche]

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

[redcurve]

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

[phryos]

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

[kakashi99]

ouais, enfin comme d'hab sur ce genre de news ça peut s'appliquer à n'importe quoi et n'importe quel métier...

clairement le mec se fait chier dans son boulot, parce que ce qui l'éclate, c'est pas tant de développer, c'est la recherche avant et le fait que sa "recherche" ai ensuite fonctionné.
plutôt que de devenir un ingénieur logiciel, il aurait du partir dans la "recherche et développement".

un mec passionné par la maçonnerie, s'il ne se met pas à son compte il ne fera qu'empiler des parpaings...

et pour les exemples, j'ai quelques exemple ou on avait de la tune pour le projet, la techno qu'on voulait, le temps nécessaire... mais une fois passer le début de projet, ou tu "réfléchis" un peu plus bah tu te retrouves à faire la même chose que tous les jours : coder une page web/client lourd...

[imikado]

Partagez-vous son point de vue ?
Non:
1. il existe des postes où l'on peut s'épanouir, où on nous fait confiance pour concevoir des applications riches et puissante (surtout en interne où l'on maitrise le choix du navigateur)
2. si dans son travail il ne s'épanoui pas, rien ne l'empêche de développer à coté des solutions opensource (github, et ici même sur developpez rubrique projets)

N'y a-t-il plus de projets aux défis intellectuellement intéressant pour un ingénieur logiciel ?
Quasiment tous les projets sur lesquels je travaille ont une part de challenge de reflexion sur la meilleure voie à suivre pour être à la fois flexible et efficace

De plus, je développe depuis des années mon propre framework, disponible sur developpez depuis 2009, je suis ravi qu'il soit en opensource, je recois régulièrement des critiques, et axes d'amélioration des utilisateurs

De plus je propose depuis peu en téléchargement des applications développés avec sous licence LGPLv3 et également disponible sur github: MkNotes et MkSql ici: http://mkdevs.com/projets.html

Je rajouterai juste que le monde du web est en perpetuel évolution, qu'on a toujours à se mettre sous la dent des nouvelles technologies/bibliothèques/frameworks à essayer, et ceci c'est accéléré avec l'HTML5 qui permet même de faire de la 3D via webgl...

[fcharton2]

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

C'est ce qui fait, à mon avis, le charme du métier d'ingénieur... On doit vivre avec des logiciels qu'on n'a pas écrit, dont les fonctionnalités ont évolué dans une direction qui n'était pas prévue au départ, qui comportent leur lots de défauts et de problèmes, mais qui fonctionnent aujourd'hui. Et le boulot consiste à les faire évoluer sans les casser, à s'adapter au code des autres, à recycler ce qui marche, et à faire disparaitre ce qui pose problème.

Reconcevoir l'architecture, proposer une solution magique qui résoud les problèmes du moment (mais se révèlera tout aussi limitée que l'actuelle pour les problèmes de l'an prochain), et qui de toutes façons ne sera disponible que dans 6 mois (estimation initiale, en réalité, ce sera deux ans), ça fait toujours plaisir, parce que ca donne l'impression qu'on a le pouvoir, qu'on comprend les choses, mais ça n'arrive presque jamais.

Je crois que le métier d'ingénieur (logiciel ou autre) est passionnant, mais c'est quelque chose d'assez exigeant, qui demande pas mal de bases et de boulot, et de nos jours on a un peu tendance à mettre sous ce titre des fonctions qu'on aurait autre fois qualifiées de "technique spécialisée" (et en y mélangeant les chercheurs en algorithmique, l'auteur de l'article n'arrange pas les choses).

Francois

[jean-michel-78]

une petite relecture aurait permis de supprimer quelques fautes

[tomlev]

I'm choked

Tu es étouffé ?

[Deaf]

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.

[Kearz]

C'est clairement un problème qui lui est propre.
Personnellement, je suis pas maso, je ne fais pas du développement pour me casser les dents sur des choses complexes tous les jours. (de temps en temps c'est bien. Trop souvent, c'est énervant.)

Moi je préfère avec un problème métier, un problème d'utilisation, etc. Et essayé de le résoudre en me disant "Comment faire pour que ça soit simple pour l'utilisateur?". J'aime rendre les choses plus simple, plus intuitif ou résoudre informatiquement les problèmes des gens.

Après que ça soit complexe ou non, c'est pas vraiment mon soucis. (C'est plus celui de ceux qui gèrent les budgets/planning)

Après je pense que le monde de l'ingénieur qui est sous les ordres et qui fait ce qu'on lui dit de faire sans réfléchir, oui ça doit être bien chiant. Si on a une TODO list fait par son chef du type:
-> "Faire fonction X qui retourne un tableau de client"
-> "Faire fonction Y qui retourne les factures"
Et que derrière on a pas son mot à dire sur pourquoi? le but de ses fonctions?
Ouais, ça doit être chiant.

Maintenant un mec qui aiment les problèmes complexes, il peut toujours aller voir:
- Google
- MicroSoft
- Amazon
- etc.

[Grom61736]

Malheureusement, "Bonjour, je suis un mec qui aiment les problèmes complexes." ne suffit pas pour se faire engager là-bas. :-)

Même si son cas n'est clairement pas généralisable à l'ensemble de la profession, je dois avouer que j'ai le même feeling.

J'ai pas fait des études d'informatiques mais plus théoriques et moi aussi, je m'ennuie.
Par conséquent, j'ai quitté mon premier job qui était chez un client final (premier job, j'ai sauté sur ce qui me parraissait le plus sur) et j'ai voulu tenté le monde des SSII où quitte à faire des trucs chiants, autant que cela soit dans beaucoup de technos différentes (contrairement à beaucoup, moi j'aurais voulu qu'on me vende expert dans une techno inconnue...). Refus des SSII car "pas le bon diplômes et blablabla".

Du coup, j'ai abandonné l'idée d'avoir du fun à mon travail ... et je me défoule chez moi. :-)

Bon, du coup, je manque de temps pour tout ce que je voudrais expérimenté mais je ne désespère pas de gagner au Lotto :p

[Zefling]

À moins de faire de la R&D, tous les postes où j'ai bossé, 90% du temps, ça fait un peu « pisseur de code », faire des choses assez peu intéressantes. Y'avait bien que quand il y avait une grosse refacto ou un truc avec quelques algos un peu retord à écrire que je trouve ça pas trop rébarbatif.

Le pire reste tout de même de récupérer une appli ultra mal codée et que tu dois dire à ton N+1 : « Ce vous demandez ça va ne pas être possible, ça sera moins loin de tout recode. » Et qu'il refuse... Et au final, on finit de toute façon par tout recoder, sauf que ça a pris deux fois plus de temps à faire des choses inutiles pour roser des rustines sur du code ultra bancal parce que le type qui était passé avant n'avait rien à faire dans le dév.

Finalement, ce qui m’amuser le plus c'est de créer mes propres programmes, je me lance des défis, mais à côté du boulot j'ai peu de temps.

[imikado]

@Grom61736 avez vous penser à développer en opensource (github ou ici dans la rubrique projets) ou contribuer à un soft qui vous parait intéressant à developper (gimp/blender/des frameworks php/js...)

[el_slapper]

J'ai créé des applis de gestion, et je me suis éclaté. Bon, pas toujours. Mais c'est quand on m'a fait confiance que j'ai eu les meilleurs résultats - et les meilleurs souvenirs.

ça s'applique aussi aux incidents, d'ailleurs. "Il faut 2 jours pour relancer, mais ça doit être complètement réparé pour ce soir" est aussi un de mes meilleurs souvenirs.

Mais Pcaboche a hélas raison : bien souvent, on a pas cette autonomie, et on ne peut que constater la lente dégradation du système.

[Nathanael Marchand]

Faut pas se leurrer, la majorité du développement en entreprise c'est de faire des formulaires que ca soit en client lourd ou léger. Alors effectivement y'a toujours des nouvelles technos à tester mais sinon le but reste relativement le même.
Cependant, occasionnellement, il y a des postes plus complexes pour faire l'algorithmie plus poussé, résoudre des problèmes d'architecture (typiquement la scalabilité d'une appli), un système de workflow complexe à mettre en place, ou autre. Mais ca ne reste pas la majeure partie des dévs...