Discussion :

[provirus]

On ne se le cachera pas, en entreprise, il y a beaucoup de tâches qui deviennent routinières. Par contre, dès qu'une routine est trouvée, ce n'est pas le moment de pleurnicher, mais plutôt de fêter, car les ordinateurs sont justement fait pour faire la routine.
Moi, c'est ça qui m'allume: enlever toutes mes routines en les délégant à l'ordinateur et en ce temps-là, on sauve du temps, ce qui permet de faire plus de tâches non routinières.

Par exemple:
- je faisais un peu de support niveau 2 à l'application qui me précédait et les problèmes comme "je n'arrive pas à voir tel rapport" revenait souvent parce c'était complexe en ayant 4 ou 5 choix pour gérer les permissions. Avant que j'arrive, tous fouillaient partout dans les bases de données, ce qui prenait 15-20 minutes à chaque fois. J'ai juste fait un script qui affichait d'un coup la recherche et maintenant on avait la réponse en 20 secondes. C'était tellement simple que le support niveau 1 a fini par ne plus amener ces questions puisqu'ils pouvaient y répondre aisément.
- je fais présentement une application d'audit et en gros, ça ne fait que prendre des données de pleins de services web internes et les mets dans plusieurs tables avec des relations entre-elles. Les testeurs allaient commencer à valider les données et ça voulait dire que chaque fois, ils auraient 5 requêtes SQL à faire en jouant avec les ids. Personne ne me l'a demandé, mais j'ai créé une application web qui affiche toutes les entrées les plus récentes et en en choisissant une, toute la hiérarchie était visible sur une page avec des couleurs et des indentations. Tout le temps sauvé pour tout le monde, c'est juste merveilleux (les testeurs trouvent un bogues et ils n'ont qu'à donner le URL ou imprimer la page)

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à

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

[ptah35]

Moi, c'est ça qui m'allume: enlever toutes mes routines en les délégant à l'ordinateur et en ce temps-là, on sauve du temps, ce qui permet de faire plus de tâches non routinières.

Cela me rappelle ce qu'un de nos illustre prédécesseur confiait en 1979 au journal Think: "Much of my work has come from being lazy".

C'était John Backus et c'est comme un ingénieur et non pas comme un "chercheur" qu'en 1954, il mit au point la première version de FORTRAN. Ce n'était pas une invention, mais une innovation ; tout était là, il ne restait "plus qu'à" définir le langage et écrire un programme capable de prendre un programme source pour le traduire dans un programme cible.

Je pense que le terme "ingénieur" est mal compris et galvaudé. Il ne s'agit pas d'un grade, mais d'un métier, un métier qui consiste à concevoir des choses, non pas en inventant, mais en innovant. L'innovation ne consiste pas seulement à assembler des pièces existantes, mais à les assembler de manière originale et efficiente. Si ce n'est pas ce que vous faites alors vous n'exercez pas le métier d'ingénieur.

Je ne pense pas qu'il y ait de hiérarchie entre l'ingénieur et le chercheur en terme de défit intellectuelle, ce sont juste des métiers différents.

[palmreg]

Le metier a changé depuis les projections du passé.
On pouvait s'attendre:
1. à un divan des cogitations pour développer un outil de complexité en toute tranquillité,
2. A un champs de travail vaste et silencieux,
3. à un espace de rencontre entre collègues pour échanger sur les complexité du problème informatique.
4. Une bibliothèque pour approfondir certains point...
Une qualité de travail.

On a des poste à 6 voir 10 codeurs,... des fils de partout, des ordis qui font un boucans, et le son du clavier qui claquette sévère à la fin du mois pour terminer le projet... Quand l'autre est en retard et qu'il stress, rien qu'aux coups sur la barre d'espace du clavier et tu comprends.
Lors des études on nous a vendu des rêves à la silicon-valley,... et on se retrouve comme des rats en cage,... avec la tête en enclume le soir quand on rentre... Un investissement intellectuel assez poussé sans possibilité de se relaxer vraiment dans son travail... pour avancer plus proprement... Hier Jo a pêté un cable...

[blkcm0]

Il a raison, ce gars. Je pense exactement pareil, sauf que je n'ai que 19 ans et que je suis en troisième année en école d'ingé, en info.
Sauf que moi, je n'ai pas commencé l'info comme lui, c'était plutôt en mode "j'essaie de programmer sur ma calculette des petits trucs par moi même", ou bien faire des trucs en plus quand on avait du matos à disposition (je faisais MPI = maths, physique, "informatique" : une matière en plus en seconde) avec des circuits logiques etc.
J’avais essayé avec Crocodile clips aussi

Donc j'ai encore pas mal de choses à apprendre, et là, perso, je m'en fous de ne pas être payé bien, et j'en arrive même à me dire que mon salaire ce serait la récompense de trouver la solution à un problème. Bon faut vivre et épargner n'abusons pas. Mais tout ce qui me motive là, c'est apprendre quoi.

Je m’intéresse surtout aux algos, aux maths poussées avec une certaine rigueur scientifique etc. Le système à la limite m'en tape un peu même... Je pense même déjà à un éventuel doctorat...

mais du coup, je ne sais pas vers quelle spécialisation m’orienter ! Logiciel (est-ce que ça inclus de la BDD ??), embarqué, (Réseaux je pense que ça n'est pas pour moi) ou réalité virtuelle

Faire un site web pour gagner de l'argent, ca me parait tellement bidon, et redondant. Surtout que le défi intellectuel n'est pas là... Autant aller faire, je sais pas moi, de la maçonnerie. Au moins on ne resterait pas assis toute la journée...

[Matthieu Vergne]

Vu que mon cursus est des plus similaires (commencé à prog sur calculatrice au lycée, puis école d'ingé info-réseau-élec, spécialisation info-réseau mais le réseau c'est pas mon truc, sent l'ennui arriver à l'idée de faire de l'ingénierie, préfère travailler sur des algos même si j'aime bien voir qu'ils sont exploitables en pratique), je me permet de partager mon expérience/point de vue sur ce dernier post.

Si j'en crois mon expérience (la seule que je puisse prendre pour exemple cela dit, donc à prendre avec des pincettes), oriente-toi vers la recherche. Si tu aimes l'abstraction pure, préfère la recherche en université plutôt qu'en entreprise. Tu devras de toute façon passer par la pratique et montrer que tes théories s'appliquent à des cas concrets, mais en entreprise il me semble que tu es plus contraint par les besoins de l'entreprise, donc si ton idée va trop loin les gens seront probablement plus frileux de te laisser faire. Sinon tu peux le faire en entreprise en connaissance de cause, mais en sachant que tu peux généralement prétendre à une meilleure paye et que ce que tu ne peux pas faire au boulot tu peux le faire chez toi pendant ton temps libre (si t'as encore le temps cela dit). L'université c'est bien aussi pour donner des cours si ça t'intéresse.

Pour la spécialisation à viser, c'est vraiment à toi à identifier le domaine où tu veux faire ta recherche. Quoi que tu fasses tu devras de toute façon lire beaucoup et tu seras amené à savoir des choses qui couvrent pas mal de domaines. Pour ma part, je suis thésard en ingénierie des exigences (en gros identification/modélisation/analyse des besoins) mais ça m'amène à lire des tas de choses en sociologie et psychologie, notamment sur l'identification et la construction de l'expertise, mais aussi l'IA avec l'analyse du langage naturel, les algos d'optimisation, etc. Selon tes intérêts, tu peux couvrir bien plus large, par exemple la semaine qui arrive je fais un séminaire sur l'application de la théorie quantique au niveau macro (plutôt qu'au niveau micro), des fois que ça donnerai des idées à certains pour exploiter ces propriétés au niveau logiciel.

Faire de la recherche implique de ne pas se cantonner à son domaine, ce qui est très enrichissant. D'ailleurs, je pense que c'est plus à cette occasion que tu découvriras ce que tu veux vraiment faire, pas avant, même si tu peux avoir une idée générale de ce qui te plait. Idée qu'il faut d'ailleurs exploiter pour trouver un sujet de thèse qui t'intéresse, parce que passer plusieurs années sur un sujet qui est à côté de ce que tu aurais voulu faire, c'est frustrant. Sur tout ce dernier paragraphe, je parle en connaissance de cause {'^_^}.

Je réponds ici des fois que ça donnerai des idées à certains, mais vu que c'est pas trop le sujet ceux qui veulent plus de détails passez par les MP (ou ouvrez un sujet en conséquence).

[redcurve]

J'irais même plus loin : c'est notre devoir d'ingénieurs(avec ou sans diplôme) que de ne pas se contenter d'obéir aux ordres, mais d'aller plus loin, et de faire mieux que ce qui était demandé.

Ah que je voudrais faire ça, mais ce n'est pas possible ce qu'il faut c'est aller vite, et avoir la plus grosse marge opérationnelle possible .

Ce que j'aimerai pouvoir corriger les innombrables bugs de l'application sur laquelle je travail, un pansement sur une jambe de bois.

Comme dirais un des meilleurs archi que j'ai connu "Nous faisons souvent de la peinture sur de la merde" ... désespérant mais il a raison . Il en a eu marre et est allé dans une boite qui fait des softs médicaux donc exit le code bancale faut que tout soit nickel. Je vais laisser tomber les SSII ça me désespère.

[vadim]

Pour ma part, je ne suis pas tout a fait d'accord avec cet article,
bien que je le comprenne. Il est vrai que le paysage a beaucoup changé
et que l'esprit "pionnier" que j'ai connu et que je décèle dans l'article a été peu a peu remplacé par des procédures, des façons de faire quelque peu "ennuyeuses"

Il n'en demeure pas moins que l'informatique continue de se développer, à la manière d'une forêt. Il reste des programmes, des projets qui ne sont pas enfermés dans les soi-disant règles. L'inventivité a encore sa place.

Bon courage à tous,
Vadim

[el_slapper]

(en réponse à J'irais même plus loin : c'est notre devoir d'ingénieurs(avec ou sans diplôme) que de ne pas se contenter d'obéir aux ordres, mais d'aller plus loin, et de faire mieux que ce qui était demandé.)
Ah que je voudrais faire ça, mais ce n'est pas possible ce qu'il faut c'est aller vite, et avoir la plus grosse marge opérationnelle possible .

Mais précisément, on me demande de faire des rattrapages de données en 4 heures tous les jeudis, ça me laisse 4 heures pour faire les rattrapages ET préparer une solution pérenne pour que ça se fasse tout seul. Le jour ou j'ai fait ça, on est tombé à une heure de budget(et en fait ça prenait 10 minutes, le panard).

[Pill_S]

Pour ma part, je suis majoritairement d'accord avec le billet...

Le développement logiciel, quand on apprend, c'est génial, on a l'impression d'ouvrir une porte vers un monde merveilleux où chaque jour de travail est riche de découverte, de nouveaux défis, on apprend à maitriser la machine, et on se dit "waou, je fais vraiment ce qui me plait!!"

Puis vient le monde professionnel... et là... tout change et devient vite barbant:

1) du code, on n'en pond plus tant que ça, on passe surtout du temps à changer l'existant
2) les frameworks/technos à utiliser, ça ne change pas tous les jours. Une fois maitrisés, on passe 5 à 10 ans à les utiliser, encore et encore, de la même façon ou presque, avec beaucoup de copier/coller et peu de nouveauté...
3) on passe peu de temps à mettre en place des trucs mais beaucoup à les modifier, re-modifier, re-re-re-re-modifier, passer du temps en meetings pour obtenir des spécs, changer les spécs, les faire valider, déployer sur 12 environnements différents, monitorer les perfs, les logs, faire de la doc, etc. qu'à réellement faire ce qui nous plait vraiment: implémenter des algos...
4) finalement, aucun business n'est vraiment intéressant... en tout cas pas sur le long terme...

Du coup, c'est sûr que l'impression du métier qu'on obtient durant les études ne reflète pas si bien que ça la réalité du monde du travail et... on finit par s'ennuyer

mais comme on dit: c'est la vie

[Matthieu Vergne]

mais comme on dit: c'est la vie

Fataliste ! Si ça bouge pas c'est que personne ne le fait bouger. Heureusement certains tentent de faire bouger les choses, et parmi ceux-là certains finissent par y trouver leur compte. Quand on veut on peut, comme on dit {^_^}.

[GeoffreyOnRails]

L'auteur parle de se passion de transformer des algorithmes en code. J'imagine (et je ne connais bien) le côté grisant d'étudier un nouvel algorithme, d'en trouver un autre plus efficace, de le voir fonctionner et de le mettre en oeuvre.. Ces métiers existent toujours, les algorithmes sont de plus en plus complexe (et leurs implémentations/optimisations également), mais il s'agit de maintenant recherche, pas d'ingénierie logiciel, et plus d'un prérequis à l'ingénierie logiciel. J'imagine bien le côté agréable de coder son propre algorithme de tri, mais lorsqu'on a besoin de trier un tableau, on appelle la fonction sort, on ne recode plus son algo. Ce qui est différent de l'école où on en code pour apprendre, mais heureux en terme de coûts/performances/maintenabilité.

Pour moi sa déception (et celle de nombreuses autres personnes) vient du passage de certains développeurs de l'artisanat à l'industrialisation (framework, solutions éprouvées, règles strictes...), un peu comme un artisan qui fabriquait des meubles s’ennuierait grandement dans une usine automatisée de meubles. Mais il reste de nombreux domaines un peu plus "artisanaux" dans l'informatique (recherche, architecture, technologies de pointe dans tout un tas de domaines de niche...), simplement le développement d'une application de gestion n'en fait plus partie depuis au bas mot une bonne dizaine d'années.

[CodeurPlusPlus]

Si tu as un grand tableau de char ou de short à trier, il vaut mieux un tri par casier qu'un quicksort.

Ok cela se produit rarement.

[Matthieu Vergne]

Après c'est une question d'optimisation : est-ce qu'implémenter un algo super spécifique qui ne s'applique qu'à des structures bien particulières vaut le coup ? Pour quelqu'un qui veut juste un tableau trié, il s'en fout un peu même si sa structure correspond. Il prend l'algo déjà implémenté de base qui est généralement assez efficace pour éviter les bourdes et gagner du temps. Ton tri par casiers, tu l'implémentera que si tu as besoin d'optimiser ton code.

Question de besoin.

[TheSadThing]

Je ne sais pas si c'est le fait d'avoir commencé à programmer en 1980 ( 1er CPU 8080 en assembleur ),
ou comme disent certains le fait que maintenant on a plusieurs plateformes, mais ma passion est toujours
au top
En entreprise c'est pas tous les jours la joie, mais parfois on est encore content de son dernier petit
algo
Après mes heures, je travaille encore à la maison (sous Linux et sous Win XP )
J'ai fait de l'assurance vie pendant 5 ans et là effectivement c'était rarement la joie, mais depuis
bientôt 10 ans je travaille dans l’industrie ( transport ferroviaire ) et la programmation consiste
à créer des binaires pour carte servant à la signalisation des trains.
Là on s'embête pas du tout et on utilise de tout ( Delphi, CBuilder, XE3, SQLServer, Linux et Windows, Python, etc ... )
Bref, on a intérêt à avoir une bonne tête.
Voilà, j'espère que cela motivera les plus jeunes d'entre vous.

Cordialement,

Juan Carlos

[CodeurPlusPlus]

Ton tri par casiers, tu l'implémentera que si tu as besoin d'optimiser ton code.

Question de besoin.

Il faut cinq minutes pour écrire un tri par casiers. Une fois dans sa vie. Une fois pour toutes.

[Matthieu Vergne]

Et un algo déjà implémenté de base, 5s. Question de besoin.

[CodeurPlusPlus]

Oui mais ton algo déjà implémenté de base, soit c'est toi qui l'avais implémenté et ça a pris cinq minutes (donc tu te retrouves dans le cas dont je parle). Soit tu l'as cherché ailleurs et ça t'a pris au moins autant de temps. Et viens pas me dire qu'on ne fait pas mieux que le quicksort des bibliothèques standard...

[Matthieu Vergne]

On peut toujours faire mieux qu'un algo générique. Comme on peut toujours faire pire. Si je prends l'exemple d'un algo de tri de liste, est-ce que je vais m'embêter à chaque programme que je fais de ré-implémenter ou rechercher dans un ancien projet et copier l'algo que j'ai fais, ou bien est-ce que je vais me souvenir qu'il y a ce Collections.sort() qui me permet de trier un List en une ligne de code ?

Ta question est simple, mais ta réponse est naïve. J'ai des implémentations persos que je réutilise, et ça a ses avantages et inconvénients. L'utilisation de bibliothèques standards a les siens. Partir du principe que la réponse est la même quelque soit le contexte montre un manque d'expérience.

On peut discuter encore longtemps comme ça si tu veux, mais même si plus personne ne participe à ce sujet, ça n'en tient pas moins du hors sujet. Donc j'arrête-là sur ce point et si tu veux continuer fait-le par MP.

[Invité]

Qui a dit que c'est parce qu'on était ingénieur qu'on avait pas le droit de chercher ?

Je déteste utiliser des technologies existantes derrière lesquelles je ne comprends pas grand chose, je préfère utiliser des petites libs et faire ensuite une plus grosse lib, ça a ses avantages (tu ne t'embête pas à aller rechercher toutes les minutes dans la doc car t'a oublier comment utiliser la technologie ce qui m'arrive souvent) mais aussi ses inconvénients. (on est plus limité au niveau des fonctionnalités car c'est moins générique mais au final si l'on a pas besoin d'un truc générique on s'en fou.)

Moi par exemple j'ai fait un moteur qui utilise des sommets en 3D pour afficher de la 2D, et 2 modules différents qui gère les entités en 3D et en 2D, le tout dessiner sur des composants que je dessine sur la fenêtre.

Il n'y a pas autant de fonctionnalité que dans un framework comme Qt par exemple, mais, elle à l'avantage de suffire à mes besoin, d'être moins grosse et de devoir chercher moins longtemps dans la doc quand j'ai oublier comment l'utiliser. (Tout en restant fort générique vu qu'elle utilise des design pattern très générique)

Les autres fonctionnalités il y a toujours moyen de les rajouter par la suite dans la librairie au fur à mesure que le projet avance, ou bien de laisser des autres s'en charger si tu travaille en groupe.

De plus avec une plus petite lib, t'a moins de dépendance à gérer.

Donc en gros je ne réinvente pas la roue car j'utilise des petites libs qui me permettent juste de faire du code portable, du chiffrement de manière sécurisée, la gestion des listes, etc..., mais tout le reste il y a largement moyen de refaire soit même, le tout est d'avoir un bon design similaire à celui des frameworks déjà existant si tu veux refaire un genre de mini-framework.

D'ailleurs je suis un grand fan du c++11 qui permet de faire des framework de manière assez simple grâce à la méta-programmation.