Pop Pop a écrit :



Pas sur que ce soit gratifiant pour ces ecoles ..

La partie Hard et réseau de la FB est franchement impec ,pour la partie soft du Player c’est quand même pas d’un très bon niveau.





Si tu regarde l’effectif de la branche R&D de Free (si mes souvenirs sont bons, c’est genre une vingtaine de personnes pour TOUT faire au niveau R&D du groupe et pas seulement la box en elle-même), et compare avec l’effectif (ou les moyens) engagé pour faire l’équivalent chez la concurrence , tu auras alors une meilleure idée de la quantité de boulot abattue par les gugus et leur efficacité.







Cherryblue a écrit :



Sans parler du fait, que ton savoir faire, quand bien même tu es super bon peu importe ton école, si tu ne leur montres pas ton diplôme





C’est pourtant ce qui se fait à peu près partout … sauf en France: les embauches sont beaucoup plus motivées par l’expérience plutôt que le nom du diplôme quand on sort de nos frontières.



J’en parle d’autant plus facilement que j’ai fait une ‘grande’ école , et que j’ai travaillé à la fois en France et dans des pays limitrophes.



Chez Orange par exemple, ton salaire à poste égal, mais aussi ta carrière tout entière (ta probabilité d’accéder à un poste de manager, etc…) sont quasi totalement conditionnés par la feuille de choux que tu as décrochée en sortie d’école. Chez FT, tu dois avoir un bon 80% des managers qui sortent de l’X, ou de Télécom.

RaYz a écrit :



Sauf qu’Epitech (ainsi que les concurentes Supinfo and co) ne sont pas des écoles d’ingé.





Elles ne délivrent pas un diplôme d’ingénieur reconnu par la CTI (Commission des Titres de l’Ingénieur), mais il me semble que ça reste un diplôme d’ingénieur quand même.



Et c’est le (très) gros des troupes des ingé. R&D chez Free.



EDIT: my mistake, le diplôme délivré porte le titre de “expert en technologies de l’information”

quicky2000 a écrit :



Non historiquement un ingenieur c est quelqu un qui a un solide bagage technique et generalement dans plusieurs domaines ce qui lui permet justement de proposer une solution a un probleme.





Evidemment qu’il faut des bases (et les pointeurs font partie des bases, on est d’accord) ; ce que je voulais avancer c’est que:

• l’ingé. n’a pas à être un expert technique.
  


• l’ingé a vocation à apprendre au cours de sa carrière ; s’il doit évoluer dans un domaine orienté développement et qu’il lui manque les bases, il doit être capable de se former là dessus.
  
  
  
  
  
  
  
  quicky2000 a écrit :
  
  
  
  Proposer une solution sur quelque chose qu on ne comprends pas c est aller droit dans le mur " />
  
  
  
  
  
  J’ai jamais qu’on ne comprenait pas le problème ; mais tu oublies qu’on peut comprendre les enjeux sans être un expert.
  
  
  
  
  
  Celui qui organise et qui n a pas de connaissances techniques c est un manager
  
  
  
  Et ça fait partie des attributions de l’ingénieur.
  
  
  
  
  
  le role du technicien est d implementer la solution definie par l ingenieur
  
  
  
  On est d’accord.
  
  
  
  
  
  
  
  Zic0 a écrit :
  
  
  
  C’est vrai, mais il se trouve que l’informatique en France (contrairement à d’autre secteurs) un ingénieur conçois et réalise.
  
  
  
  
  
  C’est déjà beaucoup moins vrai à l’étranger où on ne fait pas une séléction basé sur le diplôme, mais plutôt sur l’expérience.
  
  
  
  
  
  Je suis trés séptique. J’ai vu des code de merde qui passent haut la main des outils de qualimétrie statique de code.
  
  
  
  Les outils, c’est par exemple les nouveaux langages qui font la part belle à des mécanismes intrinsèques de réutilisation et d’encapsulation du code par exemple, qui participent à une meilleure qualité du code (avoir des données privées dans une classe, c’est pas un concept technique, c’est une vue de l’esprit qui sert justement à améliorer la qualité du code).
  
  Les méthodes, c’est par exemple les design patterns, mais aussi des organisations telles que le pair programming, les cycles de projets, le scrum, etc… etc…
  
  Tout cela a considérablement évolué en très peu de temps et a permis d’éviter une implosion du software à cause d’une qualité de code initiale très limite.
  
  
  
  
  
  Si la complexité des problèmes ne changent pas, mais que la complexité du logiciel augmente, c’est bien qu’il y a eu ajout de complexité accidentelle lors du design et de la réalisation.
  
  
  
  C’est l’inverse que je dis: la complexité des logiciels a totalement explosé. Il y a 20 ans, un programme (donc un code) tenait dans quelques centaines de ko, tournait sur une archi donnée, dans un environnement mono-thread, mono utilisateur ; pas de réseau, de périphériques divers, de montagnes d’interfaçages, de diversité des postes clients, etc…
  
  Aujourd’hui, tu n’as pas fini d’inclure quelques libs strandard que tu as déjà dépassé la taille en code des plus gros programmes de l’époque.
  
  
  
  
  
  C’est le rêve ultime de la gestion d’une entreprise : ne pas dépendre des “héros”. Malheureusement, quelques soit les organisations mises en place, au final, ca dépends toujours d’une poignée de gus. A l’extrème, je dirais :
  
  Pas d’organisation avec des héros, ca marche.
  
  
  
  Dans le monde réel, c’est exactement l’inverse. Les héros, ça n’existe que dans les films, et l’imaginaire de ceux qui veulent se croire irremplaçables. Un héros seul a un potentiel d’action très limité, ne serait-ce que parce qu’il n’a que 24 heures dans sa journée, lui aussi.
  
  
  
  Au delà, quand tu gères un projet ou une boite, un “héro”, c’est un facteur de risque accru, puisque son départ pourrait impacter profondément la continuité de ton activité.
  
  
  
  
  
  Une super organisation avec des mauvais, ca marche pas.
  
  
  
  La vie n’est pas faite que d’extrêmes, mais par expérience l’équipe de super héros qui est efficace n’est pas adaptée à autre chose que des actions commandos, limitées dans le champ d’action et le temps d’intervention.
  
  
  
  
  
  En d’autre terme, les sociétés préfèrent mesurer “pourquoi on perds de l’argent” vs “faire confience et ne pas savoir pourquoi on en gagne”.
  
  
  
  
  
  
  
  Selon moi, le niveau 1 de l’informatique, c’est de connaitre les concepts de base. Aujourd’hui, je trouve qu’ils ne sont pas bien enseignés.
  
  
  
  Je ne dis pas le contraire, mais du moment que c’est quelque chose qui peut s’acquérir en dehors du strict cadre scolaire, il n’y a aucune raison de vouloir obligatoirement l’imposer dans le cursus.
  
  
  
  Perso, je préfère quelques collaborateurs issus d’horizons différents (j’ai même un ancien mécanicien reconverti dans mon équipe) qui sont motivés et capables d’apprendre que des nerds experts dans telle ou telle techno qui n’ont pour seul horizon que l’approche technique de leur travail.
  
  
  

Pop Pop a écrit :



Mais leur principale problème ce n’est pas tant leur compétence technique, juste leur manque de sérieux.





C’est pas tant un manque de sérieux qu’une organisation de l’équipe qui est foireuse (et probablement autant un manque de ressources quasi inadmissible quand tu compares le CA de la boite à la taille de l’effectif en R&D).



Pour le reste, les ingés R&D sont difficilement qualifiables de noobs en matière technique ; c’est à peu de chose près une succursale de l’Epita/Epitech.

Zic0 a écrit :



l’informatique ne s’apprends plus.Qu’est ce qu’une pile, un tas ? Passage par référence ou par copie ? Ou sont les donnée ? Comment sont elles structurée ?





Ce que tu décris, c’est normalement pas le rôle d’un ingénieur, c’est plutôt le rôle d’un technicien.



C’est pas parce qu’en france on achète des ingé. par brouettes pour en faire des techniciens++ dans les SSII que le but initial n’est pas pour autant totalement dévoyé.



Un ingénieur c’est pas initialement un expert technique, c’est quelqu’un capable de trouver une solution efficiente et adaptée et à un problème (et son contexte) et d’organiser le travail. C’est donc pas avoir l’expertise technique dans le domaine, mais plutôt trouver les moyens pour répondre à la problématique (quitte à s’auto-former, ou à déléguer à l’expert ou au technicien qui a la connaissane).





Et les indicateurs de non-qualité genre “le client n’est pas content du nouveau firmware de sa box” ne cessent d’augmenter.



Tu te trompes sur plusieurs points:

• d’une part la qualité du code produit s’est considérablement améliorée ces dernières décennies (notamment de par les outils et méthodes qui ont vu le jour).
  
  
  


• d’autre part, la complexité des logiciels a crû de façon exponentielle, bien plus vite que les ‘problèmes’.
  
  
  


• enfin, la qualité finale d’un logiciel dépend plus de la façon dont est organisée un projet (présence d’une équipe dédiée au tests, pair programming, etc…) que de la qualité isolée (et donc l’expertise technique) de chacun des intervenants.
  
  
  
  
  
  Il y a de plus en plus de gens qui remonte des indicateurs, et de moins en moins qui sont capables de corriger.
  
  
  
  Ca c’est la conséquence d’une organisation défaillante d’un projet, tendance Shadok. C’est justement de la responsabilité de celui qui le gère, pas de la qualité intrinsèque des gugus qui pissent le code.