Discussion :

[cfranco]

Pour moi en réalité les nouveaux développeurs (comme moi) ont un manque de logique pour traiter les problèmes logiquement et de faire des algorithme pour résoudre un telle problème. dans la programmation tous vient de logique par contre la syntaxe d'un telle langage de programmation s'apprendre successivement.

La logique s'apprend aussi. Plus précisément, ce qui s'apprend, c'est à découper les problèmes pour déterminer les tâches élémentaires à effectuer, revoir le code en suivant quelques méthodes très systématiques pour le remettre en forme dans une structuration raisonnable, imaginer les conditions à tester, etc...

Par contre, c'est vrai que malheureusement, je n'ai encore pas vraiment vu de formation qui inclue l'apprentissage de ce genre de méthodologie... Ce qu'on voit, c'est de l'apprentissage de concepts (c'est quoi une classe ? C'est quoi un objet ?), et de l'apprentissage de langages pour ce qui est de la syntaxe et éventuellement de quelques classes d'une bibliothèque bien classique...

[Jidefix]

A la fac on a eu des cours d'algorithmique, où on cherchait justement à essayer de reformuler, représenter et/ou simplifier différents problèmes posés (parcours de graphes, d'emploi du temps, d'organisation de tâches...).
Le but final restait de trouver l'algorithme "optimal", ou de savoir juger de la qualité d'une heuristique, mais la qualité de la présentation du l'algorithme comptait aussi pour beaucoup...

C'était un cours dont on ressortait sans trop savoir à quoi ça pouvait servir concrètement mais deux ans après, je réalise que le travail d'analyse d'un problème fait défaut à beaucoup de gens...

[cfranco]

A la fac on a eu des cours d'algorithmique, où on cherchait justement à essayer de reformuler, représenter et/ou simplifier différents problèmes posés (parcours de graphes, d'emploi du temps, d'organisation de tâches...).
Le but final restait de trouver l'algorithme "optimal", ou de savoir juger de la qualité d'une heuristique, mais la qualité de la présentation du l'algorithme comptait aussi pour beaucoup...

C'était un cours dont on ressortait sans trop savoir à quoi ça pouvait servir concrètement mais deux ans après, je réalise que le travail d'analyse d'un problème fait défaut à beaucoup de gens...

C'est un peu le problème justement, c'est que les différents cours soient aussi dissociés les uns des autres... Ce type d'apprentissage, pour qu'il soit efficace, il faut le faire tout en programmant, sinon on n'y comprend pas grand chose...

On a eu le cas récemment, en recevant des stagiaires, on était horrifiés de la manière dont leurs cours sont organisés. Une école d'informatique (dont je tairai le nom par charité...) où les cours de calcul numérique se font de manière totalement séparée de toute programmation, considérant que la programmation était l'apanage du cours... de programmation. Donc les gens ont vu des méthodes de calcul sur papier, sans jamais faire ni même voir la moindre implémentation, ils sortent de là en n'ayant aucune idée des problèmes concrets que l'on doit se poser quand on programme des calculs numériques.

Là j'avoue que c'est quand même un cas extrême... il y a heureusement pas mal de formations où l'aspect pratique de la programmation est vu pour pas mal des thématiques abordées. Mais pas forcément l'ensemble...


Et puis ce dont je parlais, c'est justement pas de l'algorithmique... C'est beaucoup plus "terre à terre".

[Jidefix]

C'est un peu le problème justement, c'est que les différents cours soient aussi dissociés les uns des autres... Ce type d'apprentissage, pour qu'il soit efficace, il faut le faire tout en programmant, sinon on n'y comprend pas grand chose...

Même si ce serait plutot justement le role du stage selon moi, c'est vrai que terminer chaque module par un projet concret serait pas mal (il y a pas mal de modules où on ne savait tellement pas où on allait qu'on étaient incapables de déterminer i on était doués ou pas )...

Et puis ce dont je parlais, c'est justement pas de l'algorithmique... C'est beaucoup plus "terre à terre".

C'est quand même très lié, les qualités pour être bon en algorithmique, c'est de savoir analyser, réduire un problème, changer de point de vue, remettre en cause, et surtout ne jamais se contenter d'un résultat... (pour Noël 2010 je demanderai un dictionnaire des synonymes).
Finalement ce sont précisément ces qualités qui font défaut à de nombreux débutants

[cfranco]

C'est quand même très lié, les qualités pour être bon en algorithmique, c'est de savoir analyser, réduire un problème, changer de point de vue, remettre en cause, et surtout ne jamais se contenter d'un résultat... (pour Noël 2010 je demanderai un dictionnaire des synonymes).
Finalement ce sont précisément ces qualités qui font défaut à de nombreux débutants

Euh, on n'a peut-être pas eu les mêmes cours d'algorithmique, mais personnellement ce que j'en ai connu, ça n'avait RIEN à voir avec ça... Au contraire même, c'était vraiment de la logique mathématique, dans le sens : je démontre sur papier que l'algorithme que j'ai mis au point va résoudre le problème posé, je détermine sa complexité, j'en passe et des meilleurs, et après ça la programmation c'est accessoire.

Alors que ce dont je parle, c'est pas ça. C'est plutôt du genre : j'ai écrit un code, ça tourne, ou du moins j'ai l'impression que ça tourne. Quelle méthode je suis pour vérifier réellement s'il fait ce que je m'attend à ce qu'il fasse ? (je dis bien vérifier, pas écrire une justification théorique qui semblerait dire que ça devrait tourner...) Comment m'y prendre pour restructurer mon code (ou celui de quelqu'un d'autre...) sans remettre en cause son fonctionnement ? Si je dois y ajouter quelque chose, comment je m'y prend pour faire en sorte que ça ne casse pas ce qui fonctionne déjà ?

Parce que c'est ça le travail de programmation au quotidien (en n'oubliant pas le plus gros du travail, ce qu'on fait sans arrêt : choisir des noms appropriés pour nommer tout ce qu'on crée : classes, méthodes, objets...). Et ça, je n'arrive pas à trouver des débutants qui aient vraiment eu une formation là-dessus, donc ils sont perdus, ça les ralentit vraiment plus que de raison... C'est possible (probable ?) qu'ils aient sans doute eu peu d'encadrement dans leurs stages préalables, parce qu'une fois qu'on les reprend un peu en main, en quelques mois ils s'en sortent en général (enfin, à condition qu'ils en fassent l'effort bien sûr).

C'est vrai aussi que parfois il y a des blocages qui semblent quand même plus profonds que ça... C'est un fait, quand un étudiant a des gros problèmes de confiance en soi, il y a plus de chances de le retrouver à aller bosser dans l'informatique que de devenir chef de chantier (l'instinct de survie sans doute...). Le problème, c'est que les formations donnent peu de méthodes pour bâtir et garder cette nécessaire confiance en soi...

C'est le blocage bien connu, on a un truc qui tourne à peu près avec une fonctionnalité à ajouter, on est bien conscient que tel que c'est programmé c'est trop crado pour supporter un rajout, mais on a tellement peur de tout casser si on essaie de nettoyer (surtout après deux ou trois tentatives qui se sont soldées par un désastre) qu'on n'ose plus rien faire... Alors on finit par se laisser dépasser, et ça c'est particulièrement courant chez quelqu'un qui n'aura pas la pratique (parce que, même sans avoir de méthode, j'ai aussi connu des gens qui dès qu'ils ont un minimum d'habitude de programmation, se mettent dans l'optique : "je fais de la cochonnerie, mais c'est pas grave, si à un moment donné j'arrive plus à m'en sortir je jette tout et je recommence à zéro")

Les méthodes existent pour se constituer ce "filet de sécurité" qui permet de travailler raisonnablement sans finir de s'arracher les cheveux blancs qu'il nous reste... Mais malheureusement, ça ne fait pas partie du bagage technique avec lequel les gens démarrent, et c'est bien dommage, parce qu'on ne peut pas considérer que ça soit des méthodes réservées aux experts (surtout que ça n'a rien de sorcier, c'est un peu besogneux mais les concepts derrière sont tellement basiques qu'on peut les apprendre vite...)

[douzoumka]

Bonjour,

l'erreur la plus fréquente, ce de n'est pas demander de l'aide quand on s'embrouille. Généralement, ils s'enfoncent dans des codes difficiles alors qu'il faut commencer simple et faire simple si possible.

Douz

[cinemania]

cfranco, chaque école ou fac a son propre diplôme et son propre programme aussi les cours qu'une diffuse n'ont rien avoir avec ceux de la fac à 50 bornes de là pour un diplôme similaire.

walibda... la question a te poser, c'est quelle fut ta formation ?
si tu a fait un bac+2 ou +3 tu n'a clairement pas été formé pour faire de l'algorithmique, tu n'a d'ailleurs qu'a peine les bases mathématiques nécessaires.

si en revanche tu as fait un bac+5, là il faut t'inquiéter, car dans ce cas, c'est déjà plus embettant, bien que cela dépend aussi de l'intitulé de ton diplome... si ta opté pour ingénieur web2.0... espère pas faire de cours sur l'algorithmique, la calculabilité et autres joyeusetés... pourquoi ? simple.. à quoi bon analyser la calculabilité d'un programme en web dans la mesure où les types d'applicatifs visés sont tous "calculables" et ne nécessite pas non plus des algorithmes complexes (a programmer et à comprendre) et avec un fort niveau de complexité en temps de calcul...

tout est toujours affaire de besoins...

en théorie tu n'est pas non plus sensé tomber sur des cas particulièrement épineux qui auraient dues normalement etre étudiés et débroussaillés par quelqu'un de former à la problèmatique.

le principal manque c'est qu'on ne vous apprend toutefois pas à découper un problème en problèmes plus petits... principe même de la programmation dynamique... et il est assez triste par exemple que ceci ne soit que rarement vu en bac+2...

là encore tout dépend des intitulés de diplomes et de l'école/fac choisie.
mais comme je l'ai déjà dit tu devrais avoir un confirmé qui te chapote un peu...

je n'ai pas lâché mes stagiaires dans la fosse aux lions sans les avoirs former au préalable sachant quelles étaient leurs carence en fonction de l'école et du diplôme...
si tu a fait un peu d'uml, les profs pensent à tord que l'analyse que vous y voyez en coup de vent en plus, est suffisante pour vous pour apprendre à appréhender les problèmes que vous rencontrerez... c'est une erreur mais bon.

douzoumka, les algorithmes les plus simples ne sont pas toujours les meilleurs... je pourrais te citer quelques cas simples à comprendre mais là n'est pas le sujet de la question... si le débutant a fait un tant soit peu d'algorithmique, il peut de lui meme, s'il est un peu plus débrouillard que la normal envisager un algorithme plus complexe, mais plus efficace.
cela dit je te consede que pour quelqu'un d'inexpérimenté, le mieux est l'ennemi du bien.

[Lung]

Par contre, c'est vrai que malheureusement, je n'ai encore pas vraiment vu de formation qui inclue l'apprentissage de ce genre de méthodologie...

Moi, en IUT (informatique de gestion), c'est exactement ce qu'on apprenait en première année.

[skyzomik]

Je trouve que les nouveaux programmeurs manquent d'expérience

Mouais, par définition... :

débutant, adjectif
Sens 1 Qui débute, qui n'a pas d'expérience en la matière. Synonyme nouveau Anglais novice

[Louis Griffont]

Moi, en IUT (informatique de gestion), c'est exactement ce qu'on apprenait en première année.

C'est la grosse différence, à mon avis, entre les IUT et les Écoles d'ingé, les premiers forment à l'entreprise, les autres ne font qu'apprendre les théories.

[cfranco]

C'est la grosse différence, à mon avis, entre les IUT et les Écoles d'ingé, les premiers forment à l'entreprise, les autres ne font qu'apprendre les théories.

Euh, même pas vraiment en fait... A part quelques écoles de très haut niveau, il y a vraiment très peu de théorie dans les écoles d'ingénieur. En général, leur principe c'est pas que les étudiants apprennent des choses théoriques, ni pratiques non plus, mais qu'ils apprennent à trouver un boulot... (donc avoir vu très rapidement un vaste éventail de notions diverses et variées pour avoir de quoi remplir son CV, et faire des stages qui autant que possible pourraient leur ouvrir des portes pour la suite)

[skawll]

Bonjour,
Je fait actuellement un bts info gestion option dév en fongécif. C'est à dire que j'effectue le bts en un an. J'ai déjà fait un stage en août et là en ce moment, je fais mon deuxième stage.
J'ai eu de la chance de tomber sur des chefs de projets compréhensibles, n'hésitant pas à me demander si on s'en sortait, à poser des questions si on n'en avait besoin.
Parfois, on a pas toujours envie d'harceler le chef de projet car lui a du boulot aussi, donc parfois on se retient!
Et puis, là, dans la boite ou j'suis, les autres stagiaires sont en école d'ingénieur, je remarque que jsui bien loin de leur niveau. Et dire que je finis en mai, je me demande si les entreprises ne seront pas frileuses par rapport au temps de ma formation.
Quand on regarde les annonces, on ne cherche que des ingénieurs, avec une bonne expérience, je me pose la question à savoir si je pourrais me défendre sur le marché du travail.
J'espère trouver une boite où je pourrais continuer à apprendre car un an c'est court pour maitriser plusieurs langages.

[Lyche]

Bonjour,
Je fait actuellement un bts info gestion option dév en fongécif. C'est à dire que j'effectue le bts en un an. J'ai déjà fait un stage en août et là en ce moment, je fais mon deuxième stage.
J'ai eu de la chance de tomber sur des chefs de projets compréhensibles, n'hésitant pas à me demander si on s'en sortait, à poser des questions si on n'en avait besoin.
Parfois, on a pas toujours envie d'harceler le chef de projet car lui a du boulot aussi, donc parfois on se retient!
Et puis, là, dans la boite ou j'suis, les autres stagiaires sont en école d'ingénieur, je remarque que jsui bien loin de leur niveau. Et dire que je finis en mai, je me demande si les entreprises ne seront pas frileuses par rapport au temps de ma formation.
Quand on regarde les annonces, on ne cherche que des ingénieurs, avec une bonne expérience, je me pose la question à savoir si je pourrais me défendre sur le marché du travail.
J'espère trouver une boite où je pourrais continuer à apprendre car un an c'est court pour maitriser plusieurs langages.

Je te rassures dessuite, si tu travailles sur les technologies porteuses, tu auras des demandes. Je suis actuellement en recherche d'emploi en développement, j'ai un bac+2 et j'ai pu avoir une dizaine d'entretiens en très peu de temps. Donc, si tu te décarcasses un peu, que tu prend le temps de bien te former et que ton cv est bien fait, tu trouveras

[OWickerman]

Ce qui me gène le plus avec la "jeune" génération, c'est leur méconnaissance totale du français, du coup, leurs commentaires, leurs rapports, bref, tous leurs écrits sont incompréhensibles, illisibles et donc inutiles.

[skawll]

Je te rassures dessuite, si tu travailles sur les technologies porteuses, tu auras des demandes. Je suis actuellement en recherche d'emploi en développement, j'ai un bac+2 et j'ai pu avoir une dizaine d'entretiens en très peu de temps. Donc, si tu te décarcasses un peu, que tu prend le temps de bien te former et que ton cv est bien fait, tu trouveras

Qu'entends tu par technologies porteuses? tu veux parler des programmes pour téléphones portables?

[Lyche]

Qu'entends tu par technologies porteuses? tu veux parler des programmes pour téléphones portables?

Pas forcément, il faut rester à l'écoute du marché. En ce moment ce qui est très demandé, c'est le .Net mais c'est pas tout, Java est demandé, J2EE aussi.

[skawll]

Pas forcément, il faut rester à l'écoute du marché. En ce moment ce qui est très demandé, c'est le .Net mais c'est pas tout, Java est demandé, J2EE aussi.

Ok je vois, merci

[Invité]

Pour moi, les problèmes sont de deux ordres

1- une certaine tendance à sous estimer la difficulté, ou à ne pas la voir au bon endroit. Je crois que cela tient à la façon dont l'enseignement est présenté.

Dans les cours, on présente les problèmes un par un, et on expose des solutions. Du coup, un débutant n'a jamais vu le "vrai monde", où la principale difficulté c'est davantage de repérer le problème que de le résoudre (écrire du code, c'est presque toujours facile, c'est savoir quoi écrire qui est dur), où le débogage et la maintenance consomment la majeure partie des ressources, et dans lequel l'environnement (à commencer par l'expression des besoins) n'est jamais stable.

Aussi, certaines formations (en particulier les plus réputées) donnent à leurs étudiants une idée un peu exagérée de leur niveau scientifique ou technique. Couplé au désir de "bien faire" en arrivant, on se retrouve avec des personnes qui se jettent tout de suite sur la partie la plus difficile du programme, n'y arrivent pas, s'acharnent, et on a alors un gros pb d'amour propre à gérer...

Pour des applications qui sont installées chez des clients, une caractéristique des débutants est leur ignorance totale de la réalité de l'informatique client (j'ai vu des gens terrifiés à l'idée "qu'il allait falloir tout recompiler", mais ne pas lever un sourcil en proposant une "évolution" qui impliquait la réinstallation "profonde" de tous les postes utilisateurs du client, avec intervention en mode admin et tout le cirque).

2- une foi un peu trop aveugle dans les livres, les théories à la mode, et le progrès technologique. L'idée qu'il suffirait de passer à la version suivante, d'adopter le modèle de développement ou le langage à la mode, ou de racheter une machine neuve pour que tout aille bien, comme par magie.

Ca crée un mode de fonctionnement un peu complexe. Il faut à la fois écouter les nouveaux, qui amènent des idées nouvelles, mais ne pas trop leur faire confiance, parce qu'ils n'ont pas une vision claire de la réalité, le tout sans vexer ni les nouveaux ni les anciens.

Ce qui me gène le plus avec la "jeune" génération, c'est leur méconnaissance totale du français, du coup, leurs commentaires, leurs rapports, bref, tous leurs écrits sont incompréhensibles, illisibles et donc inutiles.

Oui, et ça permet d'avoir le plaisir de se retrouver face à un client qui fait observer, copie d'écran à l'appui, que "Fermer" ne s'écrit pas "Fermé"...

Sérieusement, ca fait partie d'un problème plus général. J'ai souvent l'impression qu'on écrit et qu'on lit de moins en moins en entreprise, et qu'on ne rédige presque plus. Du coup, le management prend plus de temps: là où l'on pouvait écrire une note qu'on diffusait, et que chacun lisait, il faut maintenant aller "dire les choses", et ensuite repasser répéter (parce qu'à l'oral on oublie), et la précision du travail en prend un coup.

Francois

[cfranco]

Sérieusement, ca fait partie d'un problème plus général. J'ai souvent l'impression qu'on écrit et qu'on lit de moins en moins en entreprise, et qu'on ne rédige presque plus. Du coup, le management prend plus de temps: là où l'on pouvait écrire une note qu'on diffusait, et que chacun lisait, il faut maintenant aller "dire les choses", et ensuite repasser répéter (parce qu'à l'oral on oublie), et la précision du travail en prend un coup.

Ca se résout assez bien en adaptant le format du document écrit pour qu'il soit plus directement accessible.

Le problème du "rapport", c'est que bien souvent quand on le lit on n'a pas en tête toutes les problématiques auxquelles il peut se rapporter. Et c'est rare qu'une fois qu'on est finalement confronté à une de ces problématiques dont la réponse est dans le rapport, on retourne s'y référer, tout simplement parce que généralement il est difficile de savoir dans quel document aller chercher l'info, de s'y retrouver, et pour peu que ça mélange de l'information à différents niveaux de confidentialité et que donc tout le monde n'y ait pas accès (et en particulier les stagiaires et débutants à qui généralement on ne donne accès qu'à très peu de choses...), au final l'information rate sa cible.

Personnellement, ce que je fais, et j'ai constaté que c'était très efficace, c'est que je découpe les documents pour les mettre à disposition de mes développeurs. C'est particulièrement pratique avec les PowerPoint, quand on a une série de schémas et de maquettes de pages, j'en sors un export en PNG, j'uploade le tout dans un message sur le système de gestion de projet (BaseCamp pour ne pas le nommer), ça passe en images directement visualisables.

Comme cela, les gens ont accès à l'information très rapidement, ça ne les interromp pas trop dans leur travail d'aller se référer aux specs, même anciennes. Et quand il y a un changement dans un document, il suffit de remplacer la version obsolète par la nouvelle, et on est à peu près sûr que les gens vont aller toujours voir la version à jour sur le serveur, et pas une copie locale qu'ils auraient pu conserver, pour la simple raison que c'est plus facile pour eux d'aller voir la bonne version que d'en prendre une mauvaise par erreur.

Opter pour cette façon de faire, plutôt que de distribuer les documents bureautiques "bruts" aux développeurs (ils y ont accès, mais dans la quasi totalité des cas ils n'ont pas besoin de les télécharger ni de les ouvrir), a permi de faire disparaitre presque totalement les erreurs liées à des mauvaises compréhension des cahiers des charges, à l'utilisation d'un cahier des charges obsolète ou à l'oubli pur et simple qu'un cahier des charges existait... Et tout ça, sans bousculer les habitudes des personnes qui rédigent ces cahiers des charges et qui se sentent plus à l'aise de les faire sous Word, Excel et PowerPoint, que directement sur un système dédié spécifique.

[skawll]

Pour ce qui est du français, il faut reprendre les bases. Je n'ai pas de problèmes mais je sais que certains sont très calés dans leur domaines mais incapables d'écrire une phrase sans fautes! Après ça vient aussi du système scolaire mais aussi du bon vouloir de chacun!