Discussion :

[Legarsdelouest]

Personnellement, en tant que développeur débutant, je pense que le principal "problème" (notez les guillemets), est de ne pas savoir exactement vers où l'on va.

Dans le sens de mettre en place un control List, puis de passer après à un ensembles de TextBox, pour finalement arriver au ComboxBox.

Ce qu'un débutant oublier souvent de faire, parce qu'il se dit que "ce n'est pas pour lui", c'est tout simplement prendre un crayon, une feuille, et de mettre en place un schéma structurelle de ce qu'il veut accomplir !

Si dans son esprit l'idée semble un peu flou, vous pouvez me croire (quoique on a ici des programmeurs séniors et qualifié), il mettra une semaine au lieu de 3 jours a faire son programme.

Après, cela reste un avis personnelle

[cfranco]

Personnellement, en tant que développeur débutant, je pense que le principal "problème" (notez les guillemets), est de ne pas savoir exactement vers où l'on va.

Dans le sens de mettre en place un control List, puis de passer après à un ensembles de TextBox, pour finalement arriver au ComboxBox.

Ce qu'un débutant oublier souvent de faire, parce qu'il se dit que "ce n'est pas pour lui", c'est tout simplement prendre un crayon, une feuille, et de mettre en place un schéma structurelle de ce qu'il veut accomplir !

Mais je pense que précisément, ce n'est pas à lui - débutant - de le faire, en tout cas pas à lui tout seul.

Personnellement, quand je confie un travail à faire à un débutant, 3 fois sur 4 je prend un papier, je fais le schéma avec lui en lui expliquant ce qui est demandé, si nécessaire je fais également le schéma de la méthode qu'il peut/doit suivre pour y parvenir.

Il y a deux problématiques bien distinctes :

1. comprendre ce qui est demandé
2. trouver une méthode correcte pour le faire.

Le débutant, il ne sait faire ni l'un ni l'autre, il faut l'accompagner à chacune des deux étapes. Mais il ne faut pas perdre de vue qu'une fois expérimenté, il saura normalement se charger de l'étape n°2 (en discutant avec le reste de l'équipe de développement idéalement), mais l'étape n°1 par contre elle reste toujours à discuter ensemble avec le ou les intervenants du projet qui sont impliqués dans cette demande fonctionnelle.

[cinemania]

legarsdelouet... le développeur/concepteur confirmé que je suis ne se lance jamais dans l'élébaration d'un programme sans avoir au moins pris une feuille de papier (ou sa tablette graphique et onenote) et un crayon (ou le stylet) et laissé son esprit vagabonder sur le sujet pour essayer d'entrevoir les problèmes avant de les rencontrer...
histoire d'avoir déjà une idée de là où je met les pieds, et pourtant comme nombre de développeurs confirmés, je vois le code dans ma tete, je n'ai qu'a laissé les mains sur le clavier pour voir le code apparaitre sans difficultés.

je trouve qu'il est inconcevable lorsque l'on souhaite développer de ne pas réflechir un minimum au chemin que l'on va empreinter quitte à aller demander aux autres ce qu'ils en pensent...

là je dirige un projet relativement conséquent, je suis le seul expert en conception, il m'incombe donc de faire l'architecture, le cadre et le micronoyau de l'applicatif, néanmoins je ne suis pas le seul programmeur, et toute une partie du cadre de travail passe par l'élaboration d'un framework, d'une api que les autres devront réutiliser... alors meme s'ils me font aveuglément confiance je prend quand meme à coeur de leur demander leur avis meme si souvent ca les dépasses... pourquoi car c'est eux (et pas que moi) qui vont devoir utiliser l'api, et donc le socle de l'applicatif... et quelques uns d'entre eux sont débutants, mais j'aime bien les voir poser leur questions, et donner leur point de vue, parfois totalement à l'ouest, et parfois sans meme s'en rendre compte parfaitement pertinent.
c'est toujours très instructif...

personnellement je dit toujours a quiconque de faire une pause et de prendre un papier et de reflechir avant de se lancer tete baissée dans le code... ca évite pas mal de galères... car meme avec cette méthode on y échappe pas.

ensuite une chose évidente, les débutants doivent etre encadrés... sinon on cours à la catastrophe, après tout s'ils doivent devenir les développeurs de demain, c'est en les formant à cela non ? sinon ils ne vont pas progresser et nous non plus au passage.
rester à son poste sans se remettre en question, sans lire sans apprendre est dénué de sens et d'interet pour moi... si je suis développeur pour ne plus progresser ni rien n'apprendre autant aller faire cantonnier...

[myz81]

N'etant en poste que depuis un petit peu plus d'un an, je dirais que les erreurs que j'ai commises sont pour la plupart liees au manque d'experience:

Du point de vue du debutant:

- Ne pas savoir estimer la duree d'un projet qu'on me confie. Normal, j'ai jamais fait... Si en plus on me donne pour mission d'apprendre une nouvelle technologie que personne d'autre n'utilise dans la compagnie... comment estimer combien de temps est necessaire?

- Ne pas tester la validite des donnees qu'on nous donne, ce qui revient au meme que de croire que l'entreprise dans laquelle on est a forcement des outils corrects pour travailler. Ca m'a cause pas mal de problemes sans que j'arrive a trouver le bug dans mon code...
=>Maintenant je sais qu'il faut s'assurer que les donnees qu'on nous fournit sont correctes (j'ai en tete un fichier de world vector shoreline qui etaient seme d'erreurs)

- croire que les developpeurs deja en poste sont de veritables encyclopedie. J'ai remarque que certains perferent nous envoyer *** plutot que
1.de dire qu'ils ne savent pas
2.ou plutot qu'ils ne veulent pas nous faciliter un peu trop la vie: si on apprend trop vite et qu'on decele des failles dans leur image d'experts, ca ne leur plait pas. Et potentiellement ca pourra leur faire de l'ombre.
Je ne dis pas que c'est le cas de tout le monde, loin de la (j'evite toujours les generalites). J'expose simplement mon experience de developpeuse debutante.
=> On a toujours la facilite de rechercher sur des forums, ca peut prendre du temps mais c'est toujours constructif.

- Ne pas prendre en compte la possibilite de modification de projet en cours de route et obtenir au bout du compte un programme mal structure et horrible.
=> j'ai fait, plus jamais... promis

- Ne pas s'imposer quand on veut faire une documentation par projet si ca n'est pas dans la politique de l'entreprise.
=> J'ai fini par le faire. Ils sont contents d'avoir la doc mais ca reste du temps "non-productif" pendant la redaction...alors qu'en fait ca fait gagner du temps quand on y revient plus tard.

Du point de vue du boss:

je pense qu'en sortant tout fraichement de l'universite, il est rare qu'on soit expert en tout.
Il doit me manquer beaucoup de connaissances, j'ai toute une expertise a acquerir.
=> Malgre tout avec deux sous d'idees, de la logique et en etant methodique on peut trouver les reponses sur le net, s'autoformer (pas forcement de facon parfaite, faudrait qu'un expert revoit le boulot qu'on a fait pour qu'on s'ameliore), et developper une version du projet (peut-etre pas la meilleure, mais en revenant dessus quelques semaines/mois apres, on voit plus clairement nos erreurs)

conclusion:
le developpeur debutant fait plein d'erreurs (surtout s'il n'est pas geek). l'important je pense c'est d'estimer sa capacite de comprehension et d'adaptation. Apres, le langage ou la nouvelle technologie, on est capable de les apprendre, donc je suis pas sure que ce soit vraiment une erreur.

@cfranco:
j'ai bien aime ton discours

[annemar]

"Mon nom est personne" : Le français semble t'être un langage obscur !
"pour ma part j'ai surtout remarque le cote faire du compliquer pour ce faire remarquer. Du genre développer dans un langage obscure en version alpha qui est aussi stable qu'un flanc. Et aussi l'oublie systematique de commentaires et de nom de variables explicitent. j'ai toujours envie de mettre des claques !"
J'aimerai bien voir les commentaires de tes développements ! Si c'est aussi rigolo

[annemar]

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

Ah, oui, c'est vrai ... et réciproquement

[cfranco]

personnellement je dit toujours a quiconque de faire une pause et de prendre un papier et de reflechir avant de se lancer tete baissée dans le code... ca évite pas mal de galères... car meme avec cette méthode on y échappe pas.

Cela dit, il est tout aussi bon, voir encore plus indispensable, de se poser un peu et de réfléchir après avoir programmé. L'idéal est à mon avis de garder avec soi un papier et d'y noter au fur et à mesure toutes les idées qui viennent au cours de la programmation, et à chaque fois qu'on a fini une tâche (j'entends par là, une tâche vraiment élémentaire, c'est à dire un truc qui prend maximum quelques dizaines de minutes, et normalement nettement moins), reprendre point par point ce qu'on avait noté et ne pas considérer qu'on a fini son travail tant que toutes les problématiques qu'on avait entrevues n'ont pas été clairement élucidées (et en général, ça se traduit par autant de tests unitaires...)

C'est aussi un gros problèmes de la quasi totalité des débutants (et de ceux qui n'ont pas correctement évolué...), ne pas être capable de savoir quand on a fini son travail. Considéré qu'on a fini parce que "ça tourne". Ou dit plus vulgairement, le refactoring c'est pas fait pour les chiens...

C'est aussi pour ça que l'estimation préalable du temps de développement est aussi difficile, parce qu'elle n'est déjà de toutes manières qu'une estimation, que moins on a d'éléments de réflexion sur le sujet et plus on se réfère au marc de café (et en général, avec les machines à café du bureau on n'a même pas accès au marc... ). Il y a une abondante littérature sur la question de l'estimation, il est clair que l'on ne peut pas raisonnablement attendre d'un débutant qu'il sache estimer ce qu'il a à faire, ou bien c'est que soi-même on n'a pas compris ce que ça implique d'estimer une tâche...

Pour cela, j'avoue que je ne suis pas partisan de faire estimer les tâches à faire par une seule personne, qu'il s'agisse du développeur qui aura à les réaliser lui-même ou de son chef de projet (c'est même pire si c'est une tierce personne qui estime seule...). L'estimation, c'est probablement ce qu'il y a de plus difficile dans le développement logiciel, c'est un processus qui ne peut être raisonnablement fait que de manière collective, en faisant intervenir l'ensemble des gens qui ont des idées à apporter sur la question, pour être sûr d'avoir pu bien la comprendre de la manière la plus précise possible, avec le maximum de "billes" pour ne pas se planter.

Cela implique aussi bien sûr de ne pas chercher à faire une estimation trop anticipée, parce que forcément elle sera d'autant plus mauvaise qu'on ne connait pas grand chose à la problématique que l'on doit estimer. Être prêt à admettre que l'on ne s'améliore pas rapidement aussi : si on a estimé que développer une page web prendra une semaine, sachant qu'on en aura 10 du même genre à faire en tout, donc une prévision de 10 semaines, et qu'au bout de la première page on voit qu'on a mis plutôt 2 semaines pour en venir à bout, il y a deux approches pour revoir l'estimation qu'on avait fait :

• Se dire "bon, on a explosé notre estimation, mais c'était la première page, donc les autres on va sans doute mettre beaucoup moins de temps maintenant qu'on sait faire, et on va finir en avance"
• ou plutôt : "bon, si cette page a pris le double du temps prévu, il y a des chances que ça soit pareil pour les autres, donc il faudrait dès maintenant prévenir le chef de projet que le total va très certainement prendre beaucoup plus de temps que prévu...

En moyenne, il y a une des deux approches qui est réaliste, et l'autre assez délirante, je vous en laisse juge...


Un outil aussi assez important pour être capable de mieux estimer son temps, surtout dans de telles situation où il y a une répétition de tâches assez semblables (c'est souvent le genre de boulot qu'on file au débutants d'ailleurs...), c'est de dissocier dans les premières tâches réalisées le temps de travail, du temps de recherche et d'apprentissage. Cela permet de voir (pas du premier coup, après une ou deux tâches au minimum) dans quelle mesure on s'améliore, et dans quelle mesure aussi chaque tâche qui peut sembler quasiment identique comporte des spécificités qui font qu'on doive à nouveau passer du temps à se documenter.

[fbchir]

Je suis heureux que le débat soit et j'ai lu avec intérêt, notamment la réaction de cinemania et puis celle de Steave qui souligne bien que ""PERSONNE n'a une Connaissance absolue".
Cinemania parle de contenir le délire du client. Oui, en effet, sa méconnaissance des solutions techniques l'y amène forcément et c'est pourquoi, personnellement, j'ai essayé de comprendre pour délirer le moins possible et j'ai toujours demandé à mon vis-à-vis de me dire stop lorsque j'émets des demandes pas... très catholiques - comme dirait un certain président Montpellierain - mais surtout de m'EXPLIQUER pourquoi il me déconseille de le faire. Du temps perdu ? Je préfère, pour ma part, un partenaire technique qui prend le temps de réflechir, de rechercher les meilleures solutions plutôt que de "jeter" à la va-vite des solutions convenues et peut être inadaptées. Le développeur pour être pro doit être aussi un conseiller.
Encore une fois, pour moi ce n'est pas le niveau qui est en cause ici. La question est certes essentielle, mais c'est la méthode qui fait défaut.
Dans mon métier - l'écriture - il est recommandé (et on y gagne) de se faire relire par un confrère, selon un échange de procédés bien compris, parce qu'il y a la conviction que nul ne détient la perfection.
Pour les développeurs, anciens ou débutants, la règle devrait être la même: adopter une règle de conduite qui ne soit pas exclusivement commerciale (épicière, je dirais) mais veiller au crédit de confiance, sur le long terme. Pourquoi des développeurs ne se mettraient-ils pas en réseau, même à deux, pour se "relire", se corriger et nul ne devrait se sentir supérieur à l'autre, mais se convaincre que l'analyse faite par un oeil nouveau permet un recul que l'on ne peut avoir soi-même car souvent gavé de l'alignement de lignes de code. Le risque de se faire "voler" des idées ? Bof. L'essentiel n'est sans doute pas là. Le plus important est de bien faire le boulot et d'acquérir la confiance. ça ne vaut évidemment pas pour ceux qui font du court terme, des "spéculateurs" qui ne présentent pas plus d'intérêt qu'un marchand à la sauvette sur un marché de banlieue.
Le plus important est de mettre en place une méthode qui sécurise la relation développeur-client. Et celui-ci ne doit pas garder le sentiment qu'il n'a été qu'un "cochon de payant" sans site fonctionnant comme il l'a désiré.

[cfranco]

- Ne pas tester la validite des donnees qu'on nous donne, ce qui revient au meme que de croire que l'entreprise dans laquelle on est a forcement des outils corrects pour travailler. Ca m'a cause pas mal de problemes sans que j'arrive a trouver le bug dans mon code...
=>Maintenant je sais qu'il faut s'assurer que les donnees qu'on nous fournies sont correctes (j'ai en tete un fichier de world vector shoreline qui etaient seme d'erreurs)

Ca, c'est vraiment un truc très important, et je ne connais hélas pas bien grand monde qui le fait...

C'est même plus général que de tester des données extérieures au logiciel, s'assurer de la validité des données (au sens large) qui sont fournies au morceau de programme que l'on est en train de faire, c'est vraiment indispensable pour s'éviter des nuits blanches... Ne pas hésiter à mettre des tests de validité des entrées dès leur arrivée dans le code.

Et pour ce qui est difficile ou impossible à tester par une vérification au niveau compilation, ces tests permettent au moins de s'assurer que si des données peuvent causer des erreurs dans le programme possible, il faut mettre des tests qui les détectent et arrêtent tout le plus tôt possible, parce que c'est comme ça que l'on s'assure concrètement que son intuition était la bonne ou pas, c'est comme cela que l'on identifie le plus vite possible les problèmes, et que l'on peut y apporter les corrections nécessaires. Mais bien sûr, ça implique des tests, un maximum de tests, et aussi automatiques que possible.

[cfranco]

Le risque de se faire "voler" des idées ? Bof. L'essentiel n'est sans doute pas là.

Effectivement, ce que craignent les développeurs, et leurs employeurs surtout, c'est plutôt que le niveau abominable de leur boulot finisse par se savoir

Il y a une problématique qui est celle du rapport au client (à bien différencier d'ailleurs d'une autre problématique qui est celle du rapport aux utilisateurs du logiciel...), qui à mon avis ne relève pas de ce sujet sur les débutants.

Si ce n'est peut-être pour que les clients comprennent qu'ils n'ont surtout pas intérêt à s'adresser à un débutant, qu'on ne recrute pas un débutant si on n'a pas déjà quelqu'un d'expérimenté, bref qu'un débutant est, comme son nom l'indique, quelqu'un qui débute, qui ne peut pas donner satisfaction s'il n'est pas correctement guidé.

Après, il y a une problématique qui peut se poser, et qui se posera à mon avis de plus en plus, c'est celle des débutants dans des postes qui ne sont pas directement de la programmation, mais qui sont "autour" des développeurs, et par là-même beaucoup plus en contact avec les clients. Je veux parler de postes de concepteur de logiciels, de testeur, de formateur... Postes qui, à n'en pas douter, seront à l'avenir de plus en plus des carrières à part entière, avec des formations dédiées, et donc avec des "purs" débutants.

[Legarsdelouest]

legarsdelouet... le développeur/concepteur confirmé que je suis ne se lance jamais dans l'élébaration d'un programme sans avoir au moins pris une feuille de papier (ou sa tablette graphique et onenote) et un crayon (ou le stylet) et laissé son esprit vagabonder sur le sujet pour essayer d'entrevoir les problèmes avant de les rencontrer...

C'est bien pour sa que je précise que c'est souvent le problème des développeurs débutant, et disons "occasionnels". Peut-être l'excitation de rentrer dans le vif du sujet, ou l'envie de terminer le programme le plus vite possible lui donne envie de commencer direct le codage.

Mais je n'ai jamais douté (et j'espère ) que les codeurs et développeurs professionnels prennent le temps d'expliquer à leur équipe la structure du programme qu'il vont mettre en place, rassure toi

Note : c'est legarsdeloueSt, pour le breton que je suis

[cfranco]

C'est bien pour sa que je précise que c'est souvent le problème des développeurs débutant, et disons "occasionnels". Peut-être l'excitation de rentrer dans le vif du sujet, ou l'envie de terminer le programme le plus vite possible lui donne envie de commencer direct le codage.

Cela n'est pas forcément un problème en soi de commencer par coder, pour autant qu'on a bien conscience que le travail ne s'arrête pas une fois le dernier point virgule tapé...

C'est même souvent salutaire, si on ne sait pas trop par quel bout prendre un problème, de ne pas passer des heures à réfléchir dans le vague. Coder peut être un excellent moyen de démarrer, parce que en codant on voit arriver les questions qu'on ne se serait jamais posé avant de coder...

En particulier, lorsqu'on doit utiliser un code de tierce partie qu'on ne connait pas, qu'il s'agisse d'une bibliothèque ou d'une partie du programme développée par quelqu'un d'autre dans l'équipe (personne qui n'est pas toujours encore là d'ailleurs...), une excellente méthode pour comprendre comment ça fonctionne, et réfléchir à la façon dont on va procéder, c'est justement de programmer quelques exemples d'utilisation de ce code (sous forme de tests unitaires typiquement), pour voir les tenants et les aboutissants du problème.

Du genre, on vous demande de programmer une fonctionnalité d'import de fichiers Excel, vous avez une bibliothèque sous la main qui lit les fichiers Excel, mais que vous n'avez jamais utilisé. Plutôt que de commencer par réfléchir à la manière de structurer votre code, commencez donc par prendre juste un peu de temps (pas beaucoup, 1/2h suffit souvent, maximum 1h) pour "jouer" avec la bibliothèque, vous en faites un test unitaire où vous lui faites lire un fichier "bateau" que vous avez fait pour ça, et vous vérifiez que vous arrivez bien à obtenir le contenu que vous vous attendez à avoir. Rien que en faisant ça, vous allez voir arriver une foule de questions, qui vous seront incontournables pour savoir comment programmer la fonctionnalité demandée, mais aussi et surtout pour pouvoir avoir une idée du temps que ça va vous prendre (et éviter de découvrir au dernier moment, une fois tout fini, que les fichiers que le client veut mettre dedans c'est du Excel 2007 et pas du Excel 98 comme vous pensiez...)

[Isukthar]

Si tu avais une formation web, c'est inadmissible. C'est impensable de faire du web sans CSS.

Non, je n'ai pas une formation web. C'est pour ça qu'il est presque normal de ne pas avoir vu CSS en cours. Mais les formations web sans CSS, je pense pas que ça existe.

[cinemania]

Isukthar... aussi abérant que cela puisse paraitre, j'ai vu des "ingénieurs" bac+5 soit disants web 2.0 qui ne connaissaient pas CSS... enfin de nom, mais dès que j'ai commencé à parler de CSS2.1 ou carrément de normes W3C... là il m'a regardé avec ses yeux de merlan fris, mais qu'est ce qu'il me raconte celui la ...

cela dit j'ai déjà vu dans le domaine de la programmation pure, développement logiciel, un energumene de la meme engence bouffi d'orgueil avec son bac+5 tout fraichement en poche, qui n'était pas fichu de faire de la programmation objet... le simple fait de lui parler de classe... j'ai bien cru qu'il avait avalé sa cravate... il est devenu tout bleu...

quand tu vois cela tu te pose des questions... si si...


ceci étant dit, je suis quelqu'un qui pense que toute chose qui mérite d'etre faite, mérite d'etre bien faite, alors il m'arrive, de faire du code spaguetti de facon temporaire, que je prend sur moi de corriger par la suite, quand j'ai 5mn et après y avoir bien réfléchi et noté mes idées... mais parfois il est indispensable pour que le reste de l'équipe puisse avancé d'avoir au moins un morceau de code "fonctionnel" meme s'il est partiel et incomplet, et surtout illisible (meme pour moi et malgré les commentaires)
en général suit un affisionado du code aéré, indenté, présenté, meme si j'oublie volontier les commentaires dans les nested-class ou dans les classes internes que seules des parties internes du noyau utilise... je sais c'est pas bien mais bon... lors de mon dernier projet je n'avais clairement pas le temps de documenter proprement le code... meme s'il était clair pour moi et très lisible meme 2 mois après.

en ce qui concerne la relation client, il est évident que coller un débutant devant le client, c'est un peu comme lancer une bombe dans la marre a coté de soit et espéré ne pas etre ... éclaboussé...
il est évident que coller un débutant au poste de concepteur, alors qu'il est fraichement sorti de l'école et qu'il est pas fichu d'aligner 2 lignes de code... et que le simple acronyme de POO lui donne des sueurs froides... c'est assez ubuesque... surtout qu'effectivement il doit etre plus proche du client qu'un développeur.

personellement je préfère la phase conceptuelle, l'analyse, trouver des problèmes, trouver des solutions et rédiger la méthodologie pour les contourner, éviter, ou résoudre, les problèmes, pour que les développeurs ne se creuse pas la tete... cela dit pour cela je l'ai deja dit, il est nécessaire de confronter les idées...

tout ce qui pour moi constitue un challenge, nécessite que j'acquiert des connaissances que je n'ai pas, bref tout ce qui me force à progresser, est une source d'amusement infinie... et j'aime travailler dans ces conditions...
ces deux dernières années j'allais au travail, tous les matins avec un sourrir béat... (moins ensuite, mais normal... j'ai changé de supérieur et suis tombé sur un incompétent fini, et puis le gros de mon activité n'a plus été ni la conception ni le developpement, mais du consulting auprès du client grand compte qui ne voulait plus parler qu'a moi, car j'était le seul qui savait à peu près de quoi il parlait et qui n'a jamais hésité à dire qu'il ne savait pas et qu'il allait se renseigné plutot que de s'enfoncer...)

j'ai vu des débutants avec le meme esprit dont un dont je suis très fier maintenant même si on ne travaille plus ensemble... je suis quand meme sa carrière avec grand intéret, car je l'ai encadré, et formé...
récemment celui ci m'a appelé pour me remercier, car les heures passées à lui répéter des choses qu'il refusait pourtant d'appliquer, aujourd'hui lui sont indispensable là où il travail...
jme suis dit que finalement il y avait toujours de l'espoir et que la situation n'est pas si noire qu'on pourrait le croire.

[Lyche]

Non, je n'ai pas une formation web. C'est pour ça qu'il est presque normal de ne pas avoir vu CSS en cours. Mais les formations web sans CSS, je pense pas que ça existe.

Bah, c'est ce que je reproche à l'heure actuelle. Les personnes qui me remplacent ont eu une formation web pour leurs diplôme et ne connaissent même pas CSS.

[cfranco]

Bah, c'est ce que je reproche à l'heure actuelle. Les personnes qui me remplacent ont eu une formation web pour leurs diplôme et ne connaissent même pas CSS.

Cela n'est pas fondamentalement un problème, si la formation est cohérente par ailleurs, c'est à dire si au moins les gens qui en sortent savent faire autre chose (le développement web, c'est vaste, dans mon équipe rare sont les gens qui font du CSS, et pourtant tout le monde y fait du développement web, mais la plupart ne programment que côté serveur... Par contre bien sûr, ceux qui font du développement côté client font forcément du CSS, cela va sans dire).

Mais après il faut que ça soit cohérent au niveau du recrutement aussi... C'est à dire que si on recrute quelqu'un, il faut obligatoirement évaluer en cours de recrutement, avant de prendre la décision de l'embaucher, ce qu'il sait ou ne sait pas faire pour chacune des technologies qu'il aura - lui, personnellement - à utiliser dans son travail. Après, si on décide de l'embaucher, ça sera en sachant que là où il a des lacunes, de deux choses l'une : soit on assume le fait qu'il doive être formé à ça avant toutes choses, soit on revoit le contenu du poste en conséquence.

Mais c'est pas une démarche spécifique aux débutants ça...

[Louis Griffont]

Et à quoi sert la période d'essai ? Ne serait-ce pas à évaluer le "nouveau" par rapport au poste souhaité, à ses capacités à s'intégrer, à son réel niveau professionnel ?

[cfranco]

Et à quoi sert la période d'essai ? Ne serait-ce pas à évaluer le "nouveau" par rapport au poste souhaité, à ses capacités à s'intégrer, à son réel niveau professionnel ?

La plupart du temps, ça n'est pas une solution tenable, sauf à remplacer "période d'essai" par "stage" (d'ailleurs, je rappelle que les dernières modifications légales font que désormais, les stages préalables à une embauche dans la même entreprise sont obligatoirement décomptés de la période d'essai, jusqu'à - au minimum suivant la loi - 50% de sa durée).

Une période d'essai, ça coute cher. On ne peut pas embaucher quelqu'un sans savoir ce qu'il sait faire, pour découvrir un mois ou deux après son arrivée qu'il va falloir le former à des technologies qu'on avait supposé qu'il connaissait, et donc - de fait - ne pas être en mesure d'évaluer sa capacité réelle de travail et d'intégration dans l'équipe (rôle réel de la période d'essai) avant qu'il ait réussi à se former aux technologies en question.

Donc il faut avoir prévu cela au préalable. Ce n'est pas pour rien qu'il y a autant d'entreprises qui n'embauchent jamais un débutant sans l'avoir eu au préalable en stage. C'est d'ailleurs totalement normal et sain qu'un stage serve à compléter la formation d'un étudiant, c'est à ça que ça doit servir.

Ce qui fait d'ailleurs que je trouve assez malsain de prendre des gens en stage de fin d'études lorsqu'il n'y a aucune éventualité d'embauche par la suite, aussi bon le stagiaire soit-il. Parce que non seulement on pénalise le jeune qui voit ses chances de trouver rapidement une première embauche très réduites, mais en plus l'entreprise se pénalise elle-même parce qu'elle aura un stagiaire qui va passer plus de temps à chercher du boulot qu'à se consacrer à son stage...

Pour cette raison, dans notre structure, nous ciblons systématiquement les stages de la manière suivante :

• si c'est en vue d'une possible embauche à court terme, c'est a priori un stage de fin d'études qui sera proposé
• si par contre il n'y a aucune embauche prévue, on ne propose le stage qu'à des étudiants qui comptent de toutes manières poursuivre leurs études par la suite : étudiants de 2e année d'écoles d'ingénieur, étudiants étrangers qui retournent dans leurs établissements d'origine pour une dernière année d'études après le stage, personnes qui souhaitent effectuer un 3e cycle d'études après leur diplôme, etc...

Maintenant, après, si vous voulez mon avis profond sur la question, la plupart des boites ne se donnent pas les moyens d'évaluer correctement les compétences des gens qu'elles recrutent. Et la tendance de plus en plus lourde de confier le recrutement à des structures spécialisées qui ne font que des RH, ça ne facilite pas les choses...

[aba.com]

ouahhhhhhhhhhhh je suis le meilleur et je n'ai pas besoin de votre aide... ca c'est l'erreur fatale que comette les debutant. il faut toujours demander dans tout domaine que ce soit il y a toujours quelqu'un qui connait plus .

[walibda]

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.