Discussion :

[SylvainPV]

Non seulement l'auteur a raison (le métier de "software engineer" devient vite routinier) mais la réalité est encore pire que cela...

Routinier, vraiment ? Avec toutes les évolutions/révolutions qu'on a connu ces dix dernières années ? Mon métier n'arrête pas de changer, si je ne consacre pas une demi-journée par semaine à la veille technologique je suis OUT. J'ai à peine eu le temps de commencer à maîtriser le développement sur mobiles et tablettes, les montres et lunettes connectées sont déjà là. Et on me parle ce matin du nouveau secteur des robots domestiques et de l'électroménager connecté où il faut absolument se positionner à l'avenir. C'est ça routinier ? Parce que j'ai quand même l'impression que ça évolue pas autant chez les assureurs, les taxis ou les boulangers...

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

Je ne sais pas dans quelle boîte tu bosses pour penser ça mais un conseil, n'en fais pas un cas général et change vite de boîte

[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

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

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

[xelab]

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

Je préfère faire en sorte que les choses changent dans le cadre de mon boulot (ou changer de boulot) et ensuite pouvoir occuper mon temps libre à autre chose que ce que je devrais faire au travail.
(je dis ça, j'ai moi même un petit projet sur github, mais hors de question que ce soit mon lot de consolation d'un job pourri...)

[imikado]

@xelab des fois les projets perso vous font apprendre des langages/technos que vous pouvez proposer ensuite en entreprise

Je me souviens avoir fait pas mal de flash en perso (actionscript, compil avec mstasc à l'époque) et j'ai pu proposer une interface flash d'affichage en etoiles des différents serveurs

Des fois le perso/pro peuvent de mélanger

Idem pour le html5/canvas que j'apprends pour du perso et utilise de plus en plus en pro.

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

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

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

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

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

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

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.

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

[xelab]

@xelab des fois les projets perso vous font apprendre des langages/technos que vous pouvez proposer ensuite en entreprise

Je me souviens avoir fait pas mal de flash en perso (actionscript, compil avec mstasc à l'époque) et j'ai pu proposer une interface flash d'affichage en etoiles des différents serveurs

Des fois le perso/pro peuvent de mélanger

Idem pour le html5/canvas que j'apprends pour du perso et utilise de plus en plus en pro.

Je suis bien d'accord qu'on peut amener des connaissances perso au boulot, le problème c'est que la formation, c'est dans le cadre de l'entreprise que ça doit se faire, pas dans un cadre perso. Même si tu es à ton compte, quand tu fais de la veille techno, tu te dis que t'es dans le cadre des loisirs ou du boulot?
À un moment, dire qu'il faut faire des projets persos chez soi pour ensuite en faire bénéficier l'entreprise, ça revient à mélanger vie perso et travail et au passage à travailler gratuitement si on est salarié... Je crois que chez google le vendredi est dédié aux projets persos, le tout évidemment rémunéré comme véritable travail, et c'est aussi pour ça que cette entreprise sort autant de produits. Voilà éventuellement une piste de solution à l'ennui au travail. Bref, si ton entreprise a besoin de HTML5 ou si tu sens qu'elle pourrait bien en avoir besoin, demande une formation sur le sujet (le DIF ça existe), demande du temps pour l'étudier au lieu d'utiliser ton temps libre à ça (du coup tu étudieras ces technos avec autant de plaisir mais en étant payé). Surtout que le jour où tu n'auras plus de temps libre pour ça (les enfants, maison à retaper tout ça...), eh bien il ne te restera que ce fameux ennui au travail si aucune veille techno n'y est possible...

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

[imikado]

@xelab
Les projets perso permettant d'apprendre c'est en plus des formations d'entreprise (qui sont vivement conseillé)

Mais vous pouvez découvrir en perso puis demander une formation pro pour approfondir

Perso, je suis considéré comme un passionné, je fais beaucoup de veille / de dev perso, et c'est la raison pour laquelle on m'a embauché à chaque fois, malgré mon absence de diplôme (je n'ai même pas le bac, ni le bts, ni la licence: niveau bac + 3)

[jouana]

Je pense que ce qui est mis en avant dans l'article c'est que le gars chasse la complexité dans ces projets.

Perso je suis pareil et si tu prend en compte ton contexte familiale, géographique ou autres il boulot trouvé n'est pas toujours intéressant.

Il est écœuré pcq il ne sais pas comment s'orienter dans notre magnifique métier.

Perso je le comprend ça va faire un ans que je suis sortie d'étude et je suis déjà dégoutté par le fonctionnement de notre monde.

Si tu désire juste être un expert technique avec un grand E pour la plupart des gens tu rate ta vie :/

Si la gestion ne t'intéresse pas et que les solutions techniques que tu proposes sont trop évolué pour la plupart des gens avec qui tu bosse ça devient très vite frustrant.
Le mieux et peu être de trouver une idée et créer sont propre métier.
Ou de trouver une boite de nerds mais la c'est pas simple non plus...