Discussion :

[bruneltouopi]

Il est clair qu'entre les temps de livraison de projets,les couts et la routine qui te permet d'executer des taches le plus rapidement possible.ça devient lassant de ne pas pouvoir appliquer des nouvelles technologies par passion.
Alors on se consacre à faire des projets personnelles à la maison et il faut encore trouver du temps.
Pour ma part je ne m'ennuies pas car je suis comme un enfant qui à chaque fois qu'il voit un nouveau jouet sortir il veut vite le tester ou bien voir ce qui a été amélioré.Sincèrement il est difficile de s'ennuyer en developpement logiciel tellement il y'a des choses à faire.
Pour moi je trouves que c'est souvent un manque de volonté de certains ingénieurs qui se reposent sur leurs acquis pour ne pas vouloir faire d'effort pour évoluer.

[EleriaConseil]

Je suis plus que d'accord : gamin j'ai adoré réaliser des programmes à partir de langage peu "verbeux", avec quelques librairies, tel le C, voir l'ASM sur Amiga (bon ok, moins glorifiant, avec le BASIC également dont AMOS) , car il y avait réellement un défi intellectuel sans passer trop de temps à chercher les fonctions. De nos jours, en ingénierie, on passe la majorité du temps dans la documentation des FrameWorks/API et à "googler" la solution à chaque problème qui se pose à notre projet. De mémoire, c'est à l'aube des MFC coté interface graphique, que j'ai trouvé qu'on sombrer dans trop d'outil pour peu d'algorithmique.

J’émettrais un bémol à cette nostalgie,cette désillusion est naturelle lorsque l'on passe d'amateur passionné, à faire ce qui nous plait, à professionnel sous le joug d'impératifs extérieurs, de la rigueur imposée...

[e-ric]

On apprend beaucoup de choses à l'école et ça laisse penser que la pratique sera toute aussi exhaltante. La réalité est assez souvent une douche froide, la routine s'installe vite et les projets deviennent très "formalisés" voire administratifs... Ce qui tue la créativité de nombreux développeurs et suscite leur ennui mais bon c'est le boulot.
Au départ, on pense que le développement dans le monde professionnel est une activité créatrice mais c'est assez peu souvent le cas. En ce qui me concerne, ça consiste le plus souvent à jouer le pompier et à faire fumer Office.

Une solution pour les imaginatifs est de développer ses propres projets.
Les développements libres sont, en partie je pense, l'illustration de cette tendance.

@+

[e-ric]

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

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

Je pense surtout que tu travailles dans l'exception, la plupart des développements n'ont rien d'intéressant, il faut faire tourner les programmes, point barre. Quant aux derniers gadgets, souvent plus marketing que franchement révolutionnaires, on n'a pas souvent le temps de s'y consacrer.
Se positionner à l'avenir demande du temps et des projets sur lesquels on peut pratiquer de nouvelles idées.
Enfin, je dirais que papillonner d'une nouvelle techno à une autre n'est à mon avis pas un gage de maîtrise dans l'une ou dans l'autre, à courir après plusieurs lièvres...

[e-ric]

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

Ca sent le vécu... (je connais ce genre de réalité).
Maintenant les ouvriers du numériques doivent avoir Bac+5 (y compris pour faire du cobol).

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

[Nathanael Marchand]

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

[Kihmé Xs]

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

Derrière le terme ingénieur ici, dans les faits, on parle plus souvent d'un profil et d'un type de poste que du titre ingénieur lié au diplôme. D'ailleurs j'ai fais le constat que là où je travaille il y a plus d'ingénieur de poste que d'ingénieur de titre.

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.

J'ai souvent entendu de tels propos, excuse moi, mais pour moi ce sont toujours des propos sans fondements. Je pourrais même m'amuser à établir une statistique comme quoi les meilleurs développeurs que j'ai rencontré sont ceux ayant une vision pro de leur travail et non ceux cherchant à assouvir une passion. Je stigmatise, on s'entend bien, il peut exister des cas de passionnés capables de professionnalisme, j'en ai pas trouvé, mais je le conçois. J'avoue même que j'évite au maximum les très passionnés, ils ne sont pas des valeurs surs, c'est comme ci le fait d'être passionnés les empêchaient d'être professionnels et rigoureux. A la moindre contrariété y'a plus personne pour se faire violence afin de réaliser la tâche. Les discussions que j'ai eu avec des RH de l'informatique montrent qu'ils considèrent avoir compris ça trop tard...

[MacDev]

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 ?

défis intellectuellement intéressants pour un ingénieur logiciel il y en a. Mais il faut vouloir faire un pas en avant. Ne pas faire marche sur place.

[MacDev]

Derrière le terme ingénieur ici, dans les faits, on parle plus souvent d'un profil et d'un type de poste que du titre ingénieur lié au diplôme. D'ailleurs j'ai fais le constat que là où je travaille il y a plus d'ingénieur de poste que d'ingénieur de titre.



J'ai souvent entendu de tels propos, excuse moi, mais pour moi ce sont toujours des propos sans fondements. Je pourrais même m'amuser à établir une statistique comme quoi les meilleurs développeurs que j'ai rencontré sont ceux ayant une vision pro de leur travail et non ceux cherchant à assouvir une passion. Je stigmatise, on s'entend bien, il peut exister des cas de passionnés capables de professionnalisme, j'en ai pas trouvé, mais je le conçois. J'avoue même que j'évite au maximum les très passionnés, ils ne sont pas des valeurs surs, c'est comme ci le fait d'être passionnés les empêchaient d'être professionnels et rigoureux. A la moindre contrariété y'a plus personne pour se faire violence afin de réaliser la tâche. Les discussions que j'ai eu avec des RH de l'informatique montrent qu'ils considèrent avoir compris ça trop tard...

Je crois que là ça dépend de ce que l'on appelle professionnalisme! La passion permet de se dépenser pour que le travail avance et avance bien. Donc ...(à vous de compléter)

[Kihmé Xs]

Je crois que là ça dépend de ce que l'on appelle professionnalisme! La passion permet de se dépenser pour que le travail avance et avance bien. Donc ...(à vous de compléter)

Je disais justement l'inverse, la passion génère plus de contrariété et est donc souvent un frein qui fait que le travail n'avance pas bien.

[e-ric]

Derrière le terme ingénieur ici, dans les faits, on parle plus souvent d'un profil et d'un type de poste que du titre ingénieur lié au diplôme. D'ailleurs j'ai fais le constat que là où je travaille il y a plus d'ingénieur de poste que d'ingénieur de titre.

C'est une pratique des SSII qui vendent ce que leurs clients leur demandent : de l'ingénieur. J'ai déjà eu des mission d'ingénieurs de développement mais :
- je n'ai qu'une pauvre maîtrise 'info (pouah !! disent les clients)
- ingénieur de développement est une terme qui ne veut rien dire, légalement parlant.
Mais tout le monde joue la comédie car il n'y a sans doute pas assez d'ingénieurs à placer sur des tâches de développement. En outre, même avec des bac pro, on pourrait faire une partie des développements à faire, pas besoin d'un ingénieur pour pisser 4 lignes de code.

J'ai souvent entendu de tels propos, excuse moi, mais pour moi ce sont toujours des propos sans fondements. Je pourrais même m'amuser à établir une statistique comme quoi les meilleurs développeurs que j'ai rencontré sont ceux ayant une vision pro de leur travail et non ceux cherchant à assouvir une passion. Je stigmatise, on s'entend bien, il peut exister des cas de passionnés capables de professionnalisme, j'en ai pas trouvé, mais je le conçois. J'avoue même que j'évite au maximum les très passionnés, ils ne sont pas des valeurs surs, c'est comme ci le fait d'être passionnés les empêchaient d'être professionnels et rigoureux. A la moindre contrariété y'a plus personne pour se faire violence afin de réaliser la tâche. Les discussions que j'ai eu avec des RH de l'informatique montrent qu'ils considèrent avoir compris ça trop tard...

C'est un drôle de jugement, je ne le partage pas. D'abord qu'est-ce qu'une vision pro du travail ? Un passionné à mon sens cherche à résoudre les problèmes, mêmes les plus coriaces. On a sans doute pas la même conception du mot "passionné". En ce qui concerne la compréhension des RH, ils sont assez souvent déconnectés de nos réalités.

[kakashi99]

D'abord qu'est-ce qu'une vision pro du travail ?

perso, je le vois un peu comme ça :
t'es développeur java/ruby/C (ce que tu veux), on te demande de coder un truc en vb sur access (un langage que t'aime pas)...
- tu le fais.
même si c'est pas ton truc, que tu trouves le langage nul etc... c'est ça être "pro".

la plupart du temps les "passionnés" sont des "intégristes" d'un ou deux langages, et refusent catégoriquement de faire autre chose que ça, par que les autres c'est nul, pas rapide, pas efficace, trop verbeux...

donc en gros: être "pro" c'est faire ce pour quoi on te paye, être "passionné" c'est faire ce qu'on aime faire...

attention, ceci est mon point de vue, de ce que j'ai vécu (et vis encore aujourd'hui même ^^)

[Nathanael Marchand]

C'est un drôle de jugement, je ne le partage pas. D'abord qu'est-ce qu'une vision pro du travail ? Un passionné à mon sens cherche à résoudre les problèmes, mêmes les plus coriaces. On a sans doute pas la même conception du mot "passionné". En ce qui concerne la compréhension des RH, ils sont assez souvent déconnectés de nos réalités.

Justement, un passionné cherche que les trucs les plus coriaces. Si tu lui demandes un truc rébarbatif à faire dans sa techno, il va t'envoyer bouler...

Et pour compléter mon propos, je connais des gens qui sont bons mais pas passionné et qui le font alimentairement (et qui n'iront jamais coder le soir ou le weekend). J'en connais aussi qui sont passionnés mais mauvais. Je préfère largement le premier dans mon équipe

[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

[youtpout978]

La plupart du temps on nous promet monts et merveille quand on rentre dans une entreprise, on se retrouve vite à travailler sur une appli à l'architecture bancal sur laquelle on doit apposer des rustines et développer des evos sur la même base bancal, au bout de 6 mois on a fait le tour et on a l'impression d'être rentré dans une certaine routine et ne plus rien apprendre, malheureusement il n'y a rien d'autre à faire et on se rend vite compte qu'on va travailler sur cette appli encore un moment ...
Voila ce qui se passe les 3/4 du temps, après on peut pas en vouloir à l'entreprise, elle a besoin d'entrer d'argent pour faire tourner la boite et elle ne peux pas se permettre de changer tous les 6 mois de collaborateurs parce que les développeurs ont besoin d'une certaine expérience sur l'appli pour bien connaitre le fonctionnel.

[imikado]

@Mat.M et @Nathanael Marchand

Pour les parties un peu moins intéressantes comme les CRUD, ça se génère avec les frameworks modernes donc on ne passe plus de temps la dessus, on passe plus de temps sur le design/ergonomie de l'application, les modèles de données derrière...

[gerard093]

Les gens se désintéressent du métier de développeur car :
- il n'est pas très qualifié. Souvent, effectivement, le développeur est considéré comme un convertisseur du langage vers le code. Comme celui ci est tout de même limité, l'activité finit par ressembler ... à de la traduction. Bref, on répète les mêmes séquences ...
- et surtout, après le plan calcul qui a échoué, le naufrage de Bull, l'informatique française est passée au frigo. C'est triste, mais les gros projets sont effectués avec SAP (ach Angela !) Oracle (made in india) et l'industrie du jeu (Microsoft xbox, nintendo ...) vient ... d'ailleurs !

Bref on s'ennuie car les projets manquent d'ambition

Donc, quand le capital risque vient à manquer, il ne reste plus qu'à faire l'accompagnement du changement

[Nathanael Marchand]

@Mat.M et @Nathanael Marchand

Pour les parties un peu moins intéressantes comme les CRUD, ça se génère avec les frameworks modernes donc on ne passe plus de temps la dessus, on passe plus de temps sur le design/ergonomie de l'application, les modèles de données derrière...

Merci de souligner ce que j'ai mis juste avant dans mon post
Le design et l'ergonomie, désolé mais ca n'est pas le boulot du développeur. Le modèle de donnée, normalement si il est bien conçu, c'est une fois pour toute et on le file pas à faire à n'importe qui. Du coup, qu'est ce qu'il reste à faire? S'adapter aux règles business à la con : Mr Michu de la comptabilité veut que tous les 36 du mois sa fenêtre soit en vert et que sa combo soit trié par l'ordre inversement proportionnel à l'âge du capitaine.

[imikado]

Effectivement, vous indiquez également qu'il y a une partie automatisable, je l'avais lu un peu vite, après: automatiquement ces outils génèrent une base qu'il nous faut adapter (vous l'écrivez aussi)

Je ne suis pas d'accord avec vous sur les points suivants: depuis 4-5 que je travaille dans cette boite: je fais l'ergonomie, le design et participe à la conception du modèle de donnée, aux réunions de spécifications...

Ceci dépend des sociétés où vous travaillez, certaines font plus confiance/implique plus leur développeurs en amont du projet
On est force de proposition: on nous explique la problématique, en nous proposant des interfaces (maquettes) pour y répondre et nous, avec notre expérience de l'ergonomie, de la compléxité à mettre en oeuvre.. on leur propose nos maquettes et on arrive à un compromis

Depuis une dizainne d'années que je travaille dans l'informatique, je n'ai jamais eu l'impression de faire un travail répétitif: tout ce que je peux automatiser, je le fais, je me lève toujours le sourire au lèvres et part travailler avec entrain.
A coté de cela, je fais beaucoup de veille, et travaille sur plusieurs projets personnels opensource (ici et sur github)