Discussion :

[Odulo]

J'ai lu une bonne partie des commentaires et je suis tout a fait d'accord sur le fait que d'appliquer des rustines, de ne pas avoir le temps ou la permission de faire les choses proprement devient vite lassant.

Mais il faut aussi savoir travailler avec le code des autres meme si ce n'est pas en accord avec notre maniere de faire et que l'on pense que nous ferions mieux. C'est une maladie courante des developpeurs de penser qu'ils font ou peuvent faire toujours mieux que les autres.

Il faut arreter de reinventer la roue meme si c'est tres tentant et que c'est effectivement ce qui nous plait le plus. Nous ne faisons pas de la recherche, nous travaillons pour une entreprise qui doit sortir un produit. Comment convaincre son superieur que le soft est mal fait et qu'il serait preferable de le refaire quand il entend ca constamment ? Admettons qu'il accepte, vous refaites le code, vous changez de projet ou quittez la boite et un autre developpeur arrive et fait la meme chose... Que doit-il penser ?

Je ne dis pas qu'il faut se contenter d'un code sale mais l'est-il tant que ca ?

Et comme pour tout metier, la routine, les contraintes, la pression pour les delais et la realite viennent souvent egratigner la motivation.

[imikado]

Et je le répète: si vous êtes frustré au boulot, vous pouvez développer/contribuer à des projets opensource dans votre domaine de compétence

Sur github ou ici même dans la rubrique projets

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

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

[gnto]

Je comprends son point de vue et j'adhère a 100%.

Entre la théorie et la réalité, il y a un gap ou ce que l'on appelle contraintes.

Contrainte de temps :
- On envoie du code qui respecte le besoin client en un minimum de temps. Effet de bord : Pas de structuration du code, duplication, maintenabilité du code difficile.
- On forme des gens d'un autre métier pour les envoyer au front. "Il faut que le produit sort de tout façon"

Contrainte d'argent :
- On prend une techno parce que l'on a un effectif de personne "ayant de l'expérience". Effet de bord : On utilise un bazooka pour tuer une mouche.
- On fait de la réutilisation de produit sans se soucier s'il faudra pas tout péter car les besoin ne sont plus les même. On arrive a faire des usines à gaz parce que le temps de comprendre que ce n'était pas adapter aux besoins on a déjà cramé un budget et on peut plus faire marche arrière.
- On fait de l'adaptation (on utilise un four pour griller du pain)

Bien sur, c'est subjectif, je ne parle que de ce que je connais : l'informatique industrielle.

[pvoncken]

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. ... sinon le but reste relativement le même.

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.

[Mat.M]

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

+500
malheureusement ce que tu écris c'est très vrai dans la réalité
les projets informatique de gestion c'est les sempiternels formulaires avec des données à rentrer, un bouton nouveau, un bouton maj, un bouton effacer pour gérer les données...
là où ça peut être intéressant c'est de faire du requêtage SQL

[Matthieu Vergne]

Je plussoie à l'avis de l'auteur : si on veut du défis intellectuel, l'ingénierie (tout domaine confondu) n'est pas ce qu'il faut. On se contente de chercher les pièces qu'il faut pour finir le puzzle, on ne les crée pas. Bien sûr, on peut toujours le créer par nous même, mais si c'est pour se faire reprendre par des "faut pas réinventer la roue" et passer pour quelqu'un qui n'a juste pas les compétences pour utiliser des "frameworks que tout le monde connaît", on a vite fini de rêver. C'est d'ailleurs ce qui m'a fait continuer mes études dans la recherche (je suis ingénieur logiciel à la base) parce que je me sentais pas de me tenir à un rôle d'assembleur de technologies existantes.

Si on fait ingénieur, c'est parce qu'on aime combiner l'existant pour avoir une solution adaptée au problème, pas pour faire mieux que l'existant. Ce dernier c'est du domaine de la recherche, pas de l'ingénierie. Bien sûr c'est du stéréotypage, en pratique c'est toujours une combinaison des deux (avec l'un qui est plus présent que l'autre), mais si tu veux un boulot d'ingénieur orienté recherche, il faut viser les bonnes boites... en espérant qu'elles embauchent pas des chercheurs pour ça.

C'est comme les ingénieurs-maison : t'étais technicien mais tu es devenu ingénieur à force de compétences et d'expérience. De même tu peux tenter de te faire un statut de chercheur-maison à partir d'un boulot d'ingénieur. Mais dans les deux cas faut que l'environnement de travail y soit favorable : ne pas avoir quelqu'un qui remplit déjà ce rôle (ou très mal) + en avoir le besoin, sinon on aura tôt fait de te remettre à ta place.

Cela dit j'en rejoins d'autre sur la conclusion : le métier d'ingénieur logiciel peut être tout aussi passionnant que n'importe quel autre job, le tout étant de savoir ce qu'on veut faire et de faire le boulot qui y correspond. Dans son cas c'était chercheur, pas ingénieur.

Je ne me suis jamais fait dire que faire ces choses coutent trop cher pour deux raisons:
- ça ne prend pas beaucoup de temps et je peux facilement dire que le temps sauvé est beaucoup d'argent sauvé
- je dis rarement quand je fais ces trucs. Les gens sont au courant une fois qu'ils sont fait alors ils ne peuvent pas dire "ça prendrait trop de temps à faire" puisque c'est déjà là

Ça c'est LE truc à faire pour préserver sa passion {^o^}.

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

[lebaba]

Pour ma part je pense que le métier de "software engineer" devient de moins en moins intéressant. dans les entreprise c'est carrément de la routine, on réfléchit même pas: des mots clés dans google + un copier coller et voilà le problème est résolu. Il n'y a que quelques uns qui réfléchissent, font le boulot et partagent (heureusement pour le reste de la meute). Je crois que les formations devraient plus se tourner vers la maitrise de la recherche sur google
A la fac, j'étais animé d'une passion pour le dev. J'ai passé tout mon temps à faire que ça (au point de sacrifier le temps de loisir). J'aimais faire les algo et les développer. Mais aujourd'hui le monde de l'entreprise a tué cette passion, tout est routinier. Je ne suis plus motivé. A vrai dire le métier commence à me lasser. Et je crois que je retournerai à la fac pour m'orienter dans la recherche. JE VEUX REFLECHIR, TROUVER LES BONS ALGO ET PRODUIRE DU CODE PROPRE!

[Deaf]

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

[4sStylZ]

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

[zeavan]

ca va faire un peu plus de 15 ans que je suis dans le domaine informatique (ingenieur logiciel/ architect), et j'ai tres vite compris que ce qui m'avait faire choisir ce metier (cette flamme) et bien je devrais vite trouver un moyen de la preserver, chose jusqu'a aujourd'hui accomplie, la recette elle est simple un peu dur a faire appliquer. Dans toutes les boites ou mes services ont ete utilises je leur impose le system 2/3 1/3 (2/3 pour la boite, 1/3 pour l'enrichissment personel de mes connaissances qui peuvent avoir ou ne pas avoir de liens avec les projets en cours). Au bout du compte les entreprises ont toujours ete gagnante, (panel d'outils assez large acquis) et moi de meme , j'aime encore mon boulot.

[sinople]

Dans ce métier on a la chance de:

> Pouvoir varier très fortement le domaine métier. Faire des applications pour le milieu médical, la vente ou la finance ça change quand même pas mal.

> Le domaine technique évolue très rapidement. Même en réalisant la même fonctionnalité, il est fort probable que les outils qu'on utilise ne soit plus les même.

Peu de métier ont cette chance à mon avis. Même un médecin se rend compte assez rapidement que 90% de ses interventions sont des trucs communs qui reviennent en boucle et se bouscule au moindre truc spécial qui sort de l'ordinaire (qui sera defacto réalisé par le plus gradé...)

[gnto]

Dans ce métier on a la chance de:

> Pouvoir varier très fortement le domaine métier. Faire des applications pour le milieu médical, la vente ou la finance ça change quand même pas mal.

Juste un bémol, c'est pas vrai partout. C'est compliqué pour une SSII, ils préfèrent vendre une compétence métier plutôt qu'une compétence techno. De plus pour le médical, il faut se plier a des normes et du coup bien les connaitre.

C'est le cas du médical, de l'aéronautique et du spatial (p-e pas si tu fais de l'info de gestion). Et c'est très compliqué plus contraignant de vendre quelqu'un qui ne connait pas le métier (Ça c'est pour ce qui est de la SSII)

[Traroth2]

Juste un bémol, c'est pas vrai partout. C'est compliqué pour une SSII, ils préfèrent vendre une compétence métier plutôt qu'une compétence techno. De plus pour le médical, il faut se plier a des normes et du coup bien les connaitre.

C'est le cas du médical, de l'aéronautique et du spatial (p-e pas si tu fais de l'info de gestion). Et c'est très compliqué plus contraignant de vendre quelqu'un qui ne connait pas le métier (Ça c'est pour ce qui est de la SSII)

Je travaille en SSII : Mes derniers clients étaient dans les domaines suivants :

-Logistique automobile
-Immobilier d'entreprise, commercial et évenementiel
-Travail temporaire
-Transport aérien
-Logistique express

[Nathanael Marchand]

Je travaille en SSII : Mes derniers clients étaient dans les domaines suivants

Tout pareil, en SSII je passe du dev sur des pricers en banque d'investissement, a des app mobiles, du e-commerce et des jeux vidéos.

[Kihmé Xs]

En gros cet article c'est :

"Bonjour, je suis médecin généraliste, je m'ennuie car je ne fais pas de recherche."

Ma question, pourquoi ne t'es tu pas lancé dans la recherche, ça coule de source non ?

[Traroth2]

La durée de cotisation avant de pouvoir prendre sa retraite, c'est 43 ans, désormais. Je ne pense pas qu'il existe UN SEUL métier qui soit passionnant pendant 43 ans, personnellement. Il y a toujours des moments plus difficiles que d'autres. L'important, c'est que son métier soit intéressant au moins à certains moments. Quand on est ouvrier à la chaine ou balayeur, ça doit pas être évident.

Maintenant, est-ce que l'informatique est moins passionnante maintenant qu'à l'ère des pionniers ? C'est bien possible, effectivement.

[abrillant]

Première chose, "ingénieur logiciel" c'est quelque chose qui me gène un peu car un développeur reste un développeur et c'est beaucoup plus une histoire d'intérêt et d'investissement que de diplôme.... Celui qui décroche son diplôme uniquement pour avoir un emploi ne sera jamais bon. Je ne dénigre pas celui qui a bossé pour avoir son diplôme (que je possède), mais je met une distance entre l'enseignement et la pratique. Les meilleurs développeurs que j'ai pu rencontrer n'étaient pas ceux qui avaient des diplômes mais ceux qui étaient passionnés avant tout. Pour moi, le développeur qui touche à l'excellence se rapproche plus de l'artisan qui tisse patiemment son projet ligne par ligne que d'un "ingénieur" qui trouve la bonne formule de math.

Autre point, après 15 ans de développement, le concept d'algo est pour moi secondaire, on n'est pas à chercher l'optimal mais le suffisant, c'est - à - dire quelque chose qui répond à un besoin en un temps raisonnable. L'optimal c'est plus de la recherche qu'autre chose. Dans la pratique, on a pas le temps de chercher et encore moins sur des projets de plusieurs millions de lignes de code..., il faut produire et résoudre des problèmes non pas de vitesse mais d'adaptation, s'adapter à l'évolution et au besoin de l'entreprise. Cela implique une certaine rigueur, la capacité à organiser son code pour anticiper le changement ce qui demande finalement beaucoup d'expérience et rend le développement vraiment intéressant.

Il y a malheureusement beaucoup d'arrogance et d'ignorance à la sortie de l'école, à passer des années à suivre des cours d'algo, on est confronté en entreprise à un univers radicalement différent. Ecrire du code, c'est aussi prendre conscience que cela a un coût et qu'il faut rendre une copie au mieux des moyens dont on dispose. Si on passe 1 semaine à écrire un code (que l'on croît...) optimal pour répondre à un besoin qui n'existe pas, c'est 1 semaine de perdu. Cela ne veux pas dire écrire n'importe quoi à la va vite, cela veux dire rester dans l'utile et le besoin. On ne raisonne pas non plus de la même manière sur 10 lignes de code et sur 1 million de lignes, ni lorsqu'on traite d'une cinquantaine de projets à la fois plutôt qu'un seul comme à l'école. C'est peut être tout le problème de l'enseignement actuel, se confronter à la réalité...

Bref, cette personne devrait peut être plus se tourner vers la recherche que vers le développement. Pour moi on ne fait pas le même métier.