En quelque heures il est surtout possible d'apprendre n'importe quoi !
Programmer c'est dur et ça nécessite beaucoup de travail, en tout cas quand on veux le faire correctement.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
En quelque heures il est surtout possible d'apprendre n'importe quoi !
Programmer c'est dur et ça nécessite beaucoup de travail, en tout cas quand on veux le faire correctement.
Ne pas se laisser tromper par des titres ronflants
Envoyé par Gordon Fowler
Est-il possible d’apprendre la programmation "en quelques heures" comme le proposent tant de livres ?
Combien de temps faut-il pour devenir développeur ?
Peter Norvig est un développeur qui a fait une expérience amusante. Il a effectué une recherche sur Amazon avec les mots « apprendre en quelques jours », puis « en quelques heures ». Il a alors constaté que 90% des résultats concernaient l'informatique.
Deux conclusions lui sont alors venues à l'esprit : soit le développement devient de plus en plus populaire, soit le développement est un chose très simple à apprendre.
En fait, Peter Norvig opte pour une troisième option qu'il reprend du livre « How To Design Programs » : « Mal programmer est facile, n'importe quel idiot peut le faire, même les Nuls (NDR : allusion à la série "Pour les Nuls" des Editions First) ».
La vérité, selon lui, est que n'importe quel champs d'activité exige une dizaine d'année de pratique avant de pouvoir s'en revendiquer expert. Qu'il s'agisse d'échecs, de piano, de sport ou de sciences, rien ne peut se faire en 7 jours, 24 heures ou 3 mois.
Pour lui, le développement ne fait pas exception.
Qu'il faille 10 ans, 10.000 heures ou une vie entière (en fonction des références qu'il cite), il faut du temps pour devenir un « vrai développeur ». Et Peter Norvig doute que les compétences nécessaires puissent se trouver dans des livres.
Il ne nie pas l'intérêt de les lire pour compléter son savoir (les bons, tout du moins), mais sa recette pour devenir développeur ne repose pas sur eux. Celle-ci mélange l'amusement et la passion, l'échange avec les autres programmeurs, le travail, le travail et encore le travail, la connaissance du hardware (dans développement informatique il y a le mot « informatique ») et l'implication dans les évolutions des standards.
A cela il ajoute des études dans le domaine (pour rentrer plus facilement dans le milieu) et l'apprentissage d'au moins une douzaine de langages différents.
Tout ce qui ne se trouve pas, en résumé, dans des livres « en 7 jours ».
« Allez y, achetez ce livre sur Java, il vous sera certainement utile », conclue-t-il. « Mais il ne changera pas votre vie ou votre expertise sur le sujet, que ce soit en 24 heures, jours ou mois ».
Et de rêver d'une librairie remplie de livres dont les titres seraient « Apprenez à programmer en plus de 10 ans » (ou « Learning Perl the Hard Way », PDF sous licence GNU Free Documentation) ?
Source : "Teach Yourself Programming in Ten Years" de Peter Norvig
Et vous ?
D'après votre expérience, combien de temps cela prend-il pour devenir développeur ?
Prenons d'abord un livre sur la programmation dans un langage, il contient au moins 700 pages. Chaque chapitre traite d'une notion importante du langage, et pour assimiler chaque notion, donc chaque chapitre et pouvoir l'appliquer à travers des exercices peut prendre des jours... il est impensable de croire qu'on peut apprendre à programmer en quelques heures ou en quelque jours.
On peut peut-être lire le livre en question en quelques heures ou en quelque jour comme on lis un roman mais l'assimiler, maîtriser les differentes leçons et surtout pouvoir les appliquer c''est une tout autre histoire qui peut prendre au moins un an de travail assidu.
Apprendre à programmer pour la première fois est un peu comme apprendre une langue étrangère. Vous pourrez facilement recréer les phrases vous sont enseignées, mais vous manque la compréhension du contexte pour lesquelles il est fait de cette manière, et sera donc incapable de résoudre de nouveaux problèmes efficacement. Il faut simplement du temps.
L'auteur parle "d'apprendre en quelques heures" pas d'être compétent professionnellement. Je viens de débuter dans la vie professionnelle et je me rends bien compte qu'il me faudra des mois pour pouvoir pretendre savoir programmer en Java. Par contre je me rappelle de mes experiences de collégien ou je devorais un bouquin sur le flash en quelques heures pour voir 48h apres un Zelda-like fait maison... est ce que je savais programmer? pas au sens auquel vous membres méritants l'entendez, mais moi je considérais que oui parce que mes besoins etaient tous satisfaits a ce moment là.
J'ai fait la même expérience que l'auteur et on se rend vite compte que la plupart des resultats "apprendre programmer en quelques heures" concerne :
-HTML // CSS // PHP
Le grand public cherche à créer/gérer son site son blog soi meme. Peu importe s'il est laid au début. Et pour faire cela pas besoin de grandes connaissances. Donc je pense que si vous demandez à ces personnes en combien de temps elles ont appris à programmer elles vous répondront en quelques heures.
Tout dépend effectivement de la définition qu'on donne à programmer.
Mais quelques heures? Non c'est vraiment abusif comme argument de vente.
Voilà une remarque assez intéressante.
Pour quelqu'un qui n'a jamais fait du developpement c'est impossible, le developpement est l'un des metiers qui demande le plus de temps d'apprentissage.
J'ai l'impression que ne ne connais pas beaucoup d'autres métiers
Surtout que l'article de base parle de 10,000 heures pour maitriser à peu près un domaine - quel qu'il soit.J'ai l'impression que tu ne connais pas beaucoup d'autres métiers
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
En es-tu sûr ?
Il me semble que les métiers en rapport avec la médecine (médecins, chirurgiens, pharmaciens...), les métiers du bâtiment (compagnonage), la restauration, &c. sont des métiers où le temps d'apprentissage est très long aussi. L'informatique n'est pas une exception. Surtout si on veut devenir expert.
Mais, au risque de me répéter, je pense que l'apprentissage des bases (le code propre[noms de variables & de fonctions explicite, indentation, commentaires...], les types de données, les boucles & conditions) est très rapide. On n'est alors pas un bon développeur, mais on a l'essentiel pour se débrouiller. L'expérience peut faire le reste.
« Un peuple qui est prêt à sacrifier un peu de liberté contre un peu de sécurité, ne mérite ni l'une, ni l'autre, et finira par perdre les deux. »
Attribué indistinctement à :
Thomas Jefferson
Benjamin Franklin
Albert Einstein !
J'ai dit que "le developpement est l'un des metiers",
j'ai pas dit que c'était le seulmétier !
Je sais pas facteur par exemple faut pas des mois pour savoir distribuer le courrier...
Le developpement est l'un des seules metiers où l'on ne peut pas "faire semblant": cela a été dejà vu, un faux medecin...et récemment un faux directeur...
Pour ce qui est des bases comme tu dis, ce n'est pas assez pour construire une application fini, tu peux faire un truc (un compteur par exemple) mais c'est pas suffisant pour que tu puisse "sortir" un produit entier alors que comme par exemple pour faire un gateau, je n'ai qu'à suivre une recette meme si je debute ou que j'ai que les "bases en cuisine je peux "sortir" un truc final qu'il soit bon ou pas.
Mouhahahahaha!!!
Tu n'as pas vu des hordes d'incapables présentés comme des supercadors par des commerciaux aux dents longues, passer dans des services, et dévaster tout sur leur passage(à tel point qu'on préfère encore les flemmards, qui eux au moins ne changent pas les noms des champs - en production - quand ils ont à modifier un champ qu'ils ne trouvent pas parcequ'ils regardent la mauvaise table).
Quand en plus le client direct n'est pas informaticien, un bluffeur peut faire illusion looooongtemps. Parfois plusieurs années.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Il y a que des non developpeurs qui croient qu'on peut apprendre le dev comme n'importe quel autres metiers, par exemple en 2 mois, un dev peut se reconvertir en conseiller de ventes alors qu'un conseiller en 2 mois ne peut pas devenir dev (il aura à peine les bases mais ne saura pas trop en servir pour créer quelques chose de conséquent)
Il ne faut pas comfondre "parametrer" et "developper"
Bon, puisqu'apparemment ce n'est pas clair pour tout le monde, je précise (c'est d'ailleurs un rappel !) : il n'est pas question de savoir tout faire en informatique au bout de quelques heures|jours|semaines. "Apprender à développer" ne signifie pas qu'à la fin de l'apprentissage on sache tout faire vite & bien. Mais simplement qu'on peut avoir compris les bases qui permettront de progresser.
C'est comme l'exemple de la pâtisserie de gps10 : en suivant une recette on peut produire quelque chose qui ressemblera vaguement à un gâteau, mais de là à ce qu'il soit comestible... Et si on veut faire autre chose, on sera obligé de suivre une autre recette. Autrement dit on ne fera que recopier ce qu'aura inventé quelqu'un d'autre. Conclusion : en cuisine aussi un apprentissage est indispensable.
On peut apprendre les bases de la mécanique en quelques jours (savoir desserrer un écrou, fût-il récalcitrant, savoir déposer un clip ou freiner une vis... Mais de là à s'attaquer aussitôt au démontage-remontage d'une boîte de vitesses... Là aussi un apprentissage long est indispensable. Néanmoins, dès qu'on sait utiliser les outils à bon escient, on peut progresser rapidement, surtout si on est guidé par la RTA (Revue technique automobile, qui détaille les outillages & explique les procédures pour réparer chaque véhicule, y compris les poids lourds & les engins agricoles) ou un mécano expérimenté.
De la même façon, on peut produire un code mal fagoté qui fera à peu près ce qu'on en voudra. Mais tant qu'on n'aura pas les bases, on ne progressera pas.
Une fois les bases assimilées, tout est possible, plus ou moins rapidement, bien sûr.
Et quand on a les bases, on peut se mettre à n'importe quel langage, car ils fonctionnent fondamentalement tous de la même façon (au moins dans les grandes catégories : procédural, objet, fonctionnel...) De même, quand on sait interroger une base de données avec des requêtes simples, on peut, en cherchant un peu, créer des requêtes complexes. On a appris àcréer une requêteinterroger une base en quelques heures, ça ne signifie pas qu'on sache faire toutes les requêtes instantanément, mais qu'on sait en créer d'autres, en se donnant du mal.
En bref : on ne devient pas programmeur expérimenté en quelques heures, évidemment. Mais on peut devenir programmeur débutant en quelques heures ou jours. Et s'améliorer ensuite.
« Un peuple qui est prêt à sacrifier un peu de liberté contre un peu de sécurité, ne mérite ni l'une, ni l'autre, et finira par perdre les deux. »
Attribué indistinctement à :
Thomas Jefferson
Benjamin Franklin
Albert Einstein !
Désolé, mais tu ne connais pas le monde du travail. "paramétrer" un système SAP, c'est un des trucs les plus complexes qui soient trouvables en informatique.
Je dis ça, ça fait 12 ans que je développe pour remplir mon écuelle. Mon métier est complexe. Je continue à progresser tous les jours. Mais c'est faire preuve d'aveuglement de croire que le métier de l'autre est facile, ou s'acquièrt en quelques mois. Bon, si tu prends les métiers "tout-venant", peut-être. Mais à partir du moment ou la compétence a un impact fort, progresser demande beaucoup de boulot. De temps, de sueur et de larmes. C'es vrai pour nous développeurs. C'est vrai pour tous les autres, les graphistes, commerciaux, managers, qualiticiens, financiers, musiciens, logisticiens.....
Ton conseiller en ventes, au bout de deux mois, il pourra faire quelques ventes. Il ne pourra pas gérer les dossiers les plus complexes, ni établir une stratégie pour l'évolution des ventes. CA, ça demande de la bouteille. Pareil en dev : on met rarement un perdreau de l'année à l'architecture technique du projet(et quand on le fait quand même, c'est généralement pour faire plaisir à un manager ignorant, et on va dans le décor). Eh bien toi(ou moi), reconverti en vendeur, on en te confiera pas la stratégie des ventes au bout de deux mois.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Ca, ca dépend de ce qu'on entend par "programmeur". Personnellement, je ne mets pas dans cette catégorie des gens n'ayant qu'une vague idée de comment concevoir un helloworld apres avoir lu un bouquin. Et je ne parle pas des divers paradigmes, de ce qu'est un objet, un pointeur, etc. (notions vaguement importantes pour savoir ce qu'on fait quand même, j'ai pu assister a des trucs improbables de la part de personnes n'ayant rien compris à ce qu'était un objet).
Ca demande de l'expérience, pas mal, et de savoir raisonner autrement. Imho, pour devenir ne serait ce que programmeur débutant, il ne suffit pas de quelques heures et d'un bouquin au quidam moyen (me semble que c'est de cette catégorie de personne dont on parle, pas du gars qui a des prédispositions / dont le cursus l'a déjà "préparé" pour - je pense aux maths par ex).
Mais bon, faut bien commencer quelque part
De toute façon, celui qui n'a pas de prédisposition (sens logique, par exemple) ne s'intéressera probablement pas à la chose. Et, en tout cas, n'arrivera jamais à quelque chose, même avec un bon prof.
Quant à la notion d'objet, c'est un prérequis si tu développes en objet. Sinon, tu t'en tapes. Mais si tu n'arrives pas à comprendre ce qu'est un objet, c'est évident que tu n'arriveras pas à programmer en objet !
Quant aux pointeurs, si tu développes tranquillement avec un langage qui les utilise peu (Pascal & Ada, par exemple), tu ne t'en serviras pas beaucoup.
J'ai bien écrit qu'on pouvait se débrouiller de tout si on avait compris les notions de base. Il va de soi que si on n'a pas assimilé ça, on ne peut aller plus loin.
Si celui qui n'a "qu'une vague idée de comment concevoir un helloworld apres avoir lu un bouquin" ne peut pas aller loin, celui qui a pris le temps d'aller un peu plus loin & qui a bien assimilé les bases peut progresser & être considéré comme un programmeur, amateur certes, mais programmeur quand même.
On ne peut comparer celui qui n'a rien compris avec celui qui a bien assimilé le peu qu'il sait !
Je crois que tout le débat vient de cette confusion.
« Un peuple qui est prêt à sacrifier un peu de liberté contre un peu de sécurité, ne mérite ni l'une, ni l'autre, et finira par perdre les deux. »
Attribué indistinctement à :
Thomas Jefferson
Benjamin Franklin
Albert Einstein !
Je ne sais pas si beaucoup de livres proposent d'apprendre la programmation en quelques heures, mais je pense que si le nombre de ces "quelques heures" est inférieur à une vingtaine, c'est un objectif illusoir pour ne pas dire mensonger. Une vingtaines d'heures devrait permettre d'avoir une relativement bonne introduction à la programmation dans un language à condition d'y ajouter au moins autant -- et sans doute plus -- d'heures d'exercices. En revanche, une fois un language correctement appris, il ne faut pas plus de quelques heures pour en apprendre un nouveau; un language de programmation n'étant au fond que quelques primitives, quelques règles de composition et quelques moyens d'abstraction. Pour résumer, je paraphraserais ce qu'un professeur nous a dit lorsque j'étais étudiant: la programmation est similaire au échec, il ne faut pas plus de quelques minutes pour apprendre à déplacer les pièces sur l'échiquier mais des années pour devenir un maître.
Confusion
Lorsque l'on passe notre permis de conduire, nous passons un certain nombre d'heures à apprendre le code, à rouler avec un professeur, à rouler, puis un jour nous passons notre permis de conduire. Cela fait-il de nous un automobliste, un coureur automobile, un maître de l'enseignement de la conduite ? non, cela fait de nous un automobiliste débutant. Le fait de lire un bouquin avec les différents types de panneaux nous permet d'avoir une base qui nous permettra de prendre le volant et de rouler juste. C'est la même chose avec le développement, il faut bien commencer quelque part et l'utilisation de livres est une excellente base pour se lancer, puis l'expérience vient en programmant. Ce qui est certain, c'est que dénigrer une méthode pour une autre est une sorte d'élitisme qui a tendance à me donner des aigreurs d'estomac.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager