A-t-on besoin d'apprendre la programmation pendant 10 ans avant d'être un développeur accompli ?
Partagez votre expérience

Le , par Michael Guilloux, Chroniqueur Actualités
Le développement informatique fait sans doute partie des métiers les plus convoités aujourd'hui, surtout que de certains avis, il y a une forte demande sur le marché qui ne peut être absorbée par l'offre actuelle de développeurs. Initialement réservé à des formations en informatique de 4 ou 5 ans en général, le marché de l'emploi voit donc de plus en plus l'arrivée de candidats issus de formations intensives de courte durée.

Mais pour Peter Norvig, directeur de recherche chez Google, la programmation est quelque chose qu'on devrait normalement apprendre sur une période assez longue, 10 ans par exemple. C'est ce qu'il expliquait d'ailleurs dans un billet publié il y a quelques années et intitulé « Teach Yourself Programming in Ten Years ». Dans ce billet, il critiquait notamment les bouquins avec des titres comme « Apprendre X en Y heures/jours », par exemple « Teach Yourself C++ in 24 Hours ». Il disait avoir fait une recherche avancée sur Amazon pour répertorier les livres avec des titres de ce genre qui ont été publiés depuis l'année 2000. Et il en avait trouvé 512. Le point remarquable est que 9 des 10 premiers étaient des livres de programmation.

« Soit les gens sont pressés d’apprendre la programmation, soit la programmation est en quelque sorte fabuleusement plus facile à apprendre que toute autre chose », a-t-il conclu. Bien sûr, il pense que c'est plutôt parce que les gens sont pressés d'apprendre la programmation, mais il avertit qu'on ne peut rien apprendre de bon dans de courts délais, peu importe les techniques pédagogiques utilisées : « une mauvaise programmation est facile, les idiots peuvent l'apprendre en 21 jours, même s'ils sont des nuls », dit-il en citant des auteurs d'un bouquin en informatique.

Ses raisons sont évidentes. Dans un court délai, vous n'aurez pas le temps d'écrire plusieurs programmes significatifs, et d’apprendre de vos succès et échecs. Vous n'aurez pas non plus le temps de travailler avec un programmeur expérimenté et de comprendre ce que c’est de vivre dans cet environnement. En résumé, vous n’aurez pas le temps d’apprendre vraiment. Vous allez vous familiariser à la programmation ou au langage en question, sans avoir de connaissance approfondie. C'est ce.qu'il exprime par une citation du poète anglais Alexander Pope : « a little learning is a dangerous thing », ce qui peut se traduire en français par : « un peu d'apprentissage est une chose dangereuse ».


Peter Norvig, directeur de recherche chez Google

Cela dit, pour avoir du succès en tant que développeur, Peter Norvig propose, entre autres, de :

  • s'intéresser avant tout à la programmation, et le faire parce que c’est agréable. Du moins, cela doit être suffisamment agréable de sorte que vous désiriez vouloir y consacrer 10 ans ;
  • apprendre la programmation par la pratique ;
  • échanger avec d’autres programmeurs et lire d'autres programmes. C’est, selon lui, plus important que n’importe quel livre ou cours ;
  • suivre une formation informatique de 4 ans ou plus, ce qui va vous donner une compréhension plus approfondie du domaine et un accès à des emplois qui nécessitent des qualifications. Sinon, Peter Norvig pense que vous pouvez aussi suivre le chemin de l'autodidacte, pour acquérir des compétences similaires, mais estime que l'apprentissage par les livres ne sera pas suffisant ;
  • travailler sur des projets avec d’autres programmeurs, en tant que numéro un pour certains projets et à la dernière place dans d'autres projets. A la tête d'un projet, vous allez tester vos habiletés à mener un projet, et à inspirer les autres par votre vision. Dans l'autre cas, vous allez apprendre ce que font les leads et apprendre ce qu’ils n’aiment pas faire (parce qu’ils vous le donneront à faire) ;
  • travailler sur des projets après d’autres programmeurs, par exemple prendre le temps de comprendre un programme écrit par quelqu’un d’autre. Cela devrait vous permettre d'avoir une idée de l’effort nécessaire pour le comprendre et le corriger lorsque les programmeurs initiaux ne sont plus là. Cela devrait en outre vous faire réfléchir à la manière de concevoir vos programmes de manière à faciliter la vie de ceux qui vont les maintenir par la suite ;
  • apprendre au moins une demi-douzaine de langages de programmation, y compris un langage qui supporte l’abstraction de classe (comme Java ou C++), un qui supporte l’abstraction fonctionnelle (comme Lisp ou Haskell), un qui supporte l’abstraction syntaxique (comme Lisp), un qui supporte les spécifications déclaratives (comme Prolog ou les templates C++) et un qui supporte le parallélisme (comme Clojure ou Go) ;
  • toujours se rappeler que l’ordinateur fait partie intégrante de l’informatique. Peter Norvig estime en effet que vous devez savoir combien de temps cela prend à votre ordinateur pour exécuter une instruction, lire un mot dans la mémoire (qu’il soit déjà dans la mémoire cache ou pas), lire des mots consécutifs à partir du disque ;
  • s'impliquer dans un projet de standardisation d’un langage. Il pourrait s'agir d'un projet de standardisation international ou juste de décider si votre style de codage local aura des indentations de 2 ou 4 espaces. De toute manière, Peter Norvig pense que cela va vous permettre de connaitre ce que les autres aiment dans un langage, à quel point ils y tiennent, et peut-être un peu sur leurs raisons.

Source : Peter Norvig

Et vous ?

Qu'en pensez-vous ?
Faut-il remplir toutes les conditions citées ici par Peter Norvig pour être un développeur expérimenté ou accompli ?
Quelles conditions sont les plus nécessaires ?
Vous considérez-vous comme un développeur accompli ou expérimenté ? Si oui, combien d'années cela vous a-t-il pris ?

Voir aussi :

Comment devenir un meilleur développeur ? La formation et l'expérience sont-elles suffisantes ? Vous êtes invités à partager votre avis
Que faire pour minimiser l'impact des interruptions sur l'activité de développement de logiciels ? Appliquer les méthodes Agile ?
Y a-t-il une corrélation entre diplôme et succès en tant que développeur de logiciels ? Un acteur de la sphère donne son avis
Pourquoi réécrire un projet en partant de zéro ? Parce que l'ancien code est un fatras ou qu'il est plus facile d'écrire que de lire un code ?
Que pensez-vous des formations intensives en programmation ? Sont-elles plus efficaces que les formations classiques en informatique ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de Matthieu76 Matthieu76 - Membre éclairé https://www.developpez.com
le 16/05/2018 à 10:22
échanger avec d’autres programmeurs et lire d'autres programmes. C’est, selon lui, plus important que n’importe quel livre ou cours ;
travailler sur des projets avec d’autres programmeurs, en tant que numéro un pour certains projets et à la dernière place dans d'autres projets.
Je suis entièrement d'accord, en développant en équipe avec des programmeurs expérimentés j'ai rapide appris des choses que je n'aurais jamais su même en 20 ans de programmation en solo.
Avatar de akd akd - Membre actif https://www.developpez.com
le 16/05/2018 à 10:35
Je pense que tout dépend le domaine d'activité dans lequel on va se situer... et ce que la/les boite(s) où on va travailler vont réclamer.

Ca ne peut en effet fonctionner que lorsqu'on travaille sur des technos ou langages plutôt stables dans le temps; avec peu d'évolutions (ou alors des évolutions logiques, comme on peut en voir par exemple en C++).

Pour avoir bossé pendant 10 ans dans une boite qui est passé d'un EDI vers java jee, je peux juste affirmer que si les conditions ne sont pas remplies (formation continue avec au moins 1 jour par semaine qui y est dédié); les dev séniors peuvent être vite largués.

Sans compter que dans ce langage là avec les effets de mode, on change de lib tous les 6 mois... il est donc totalement impossible de passer 10 ans sur une lib pour en maitriser le fonctionnement.

Résultat : on passe son temps à être un 'débutant' et à peine on commence à saisir le fonctionnement de l'engin, il faut passer au suivant.

(c'est un peu pour ça que je suis en reconversion...)
Avatar de onilink_ onilink_ - Membre éprouvé https://www.developpez.com
le 16/05/2018 à 10:55
Tout dépend des technos utilisées j'ai envie de dire, et ce que l'on appelle un développeur accompli (qualité? rapidité? maintenabilité?)

Pour mon expérience, C++ est un langage long a maîtriser, malgré que l'on puisse gratter la surface très rapidement (et se penser bon, tant qu'on reste sur de petits projets on ne comprend pas forcement certaines difficultés).
Pour C++ je pense qu'il faut pratiquer au moins 3 ans (a raison de 35h par semaine minimum hein, pas juste en faire de temps en temps), et SURTOUT, entouré des bonnes personnes (des personnes calées niveau standard, qui vont t'expliquer ce qu'est une UB, comment ne pas en faire, a mieux utiliser la docu etc, c'est pas forcement évident tout seul au début) pour arriver a un bon niveau. Il ne faut pas oublier aussi que les standards évoluent, et qu'il faut donc régulièrement se mettre a jour. Il est inacceptable de ne pas faire du C++11 de nos jours si la toolchain est compatible par exemple (voir du c++14).

A première vue, Rust semble aussi être un langage long a maîtriser pleinement, a moins que ce soit surtout le début (j'aimerais des retours) étant donné que le langage semble bien conçu pour empêcher les devs de faire n'importe quoi avec (beaucoup de choses se font en "compile time".

A côté de ça, il y a des langages conçus pour être rapidement maîtrisés. Certains font ça correctement, d'autres non.
Je pense notamment a java qui veut faire croire que c'est un langage simple d'utilisation, mais qui en réalité ne l'est pas, a cause de beaucoup d'exception aux règles, de tricks chelous et de règles stupides.
On a aussi javascript et tout ses fameux corner cases bizarroïdes et éléments perturbateurs, au final le langage a l'air simple de loin mais ça devient vite un cauchemar dans un champ de mines.
Ou encore PHP avec sa bibliothèque standard foireuse (sans compter pas mal de problèmes dans le langage en lui même).

Au final je vois peu de langage assez bien pensés pour être rapidement maîtrisés, sans avoir a connaître une palanquée de corner cases et de pièges à éviter.
Avatar de danielhagnoul danielhagnoul - Rédacteur https://www.developpez.com
le 16/05/2018 à 11:17


Chimiste de formation et autodidacte en informatique, j'ai commencé avec un Apple II et le Basic, puis très vite, le langage Pascal. Au fur et à mesure des années et de l'évolution du matériel, j'ai pratiqué aussi un peu de C, de C++, et de C#.

Depuis plusieurs années, je me consacre au JavaScript, au HTML et au CSS.

Les seules choses dont je sois persuadé :

  • le temps du "touche à tout" est révolu ;
  • il faut se spécialiser dans un langage et dans un domaine ;
  • il faut apprendre quelque chose de nouveau tous les jours ;
  • le sujet évolue plus vite que je ne peux l'absorber.


Je constate souvent que les jeunes ont tendance à se satisfaire de ce qu'ils pensent maîtriser et à rester dans leur zone de confort. Quelques années plus tard, je pense à 5 ans, ils s'aperçoivent avec effroi qu'ils sont en train d'être largués et qu'il leur reste une montagne de choses à apprendre.

Mais vous me direz sans doute qu'à 68 ans je peux me reposer, qu'elle horreur, le repos c'est la mort.
Avatar de Drowan Drowan - Membre éclairé https://www.developpez.com
le 16/05/2018 à 11:25
échanger avec d’autres programmeurs et lire d'autres programmes
+1

Citation Envoyé par akd Voir le message
on change de lib tous les 6 mois... il est donc totalement impossible de passer 10 ans sur une lib pour en maîtriser le fonctionnement.
Résultat : on passe son temps à être un 'débutant' et à peine on commence à saisir le fonctionnement de l'engin, il faut passer au suivant.
C'est justement là où l'expérience (plusieurs années) dans la programmation fait la différence. Tu as l'habitude de chercher à comprendre des mécanismes et tu en connais déjà un grand nombres. C'est donc bien plus facile de s'adapter. Alors que via des livres et apprentissage rapide, on pas eu le temp d'apprendre à s'adapter et à chercher.

Citation Envoyé par onilink_ Voir le message
A côté de ça, il y a des langages conçus pour être rapidement maîtrisés. Certains font ça correctement, d'autres non.
Je pense notamment a java qui veut faire croire que c'est un langage simple d'utilisation, mais qui en réalité ne l'est pas, a cause de beaucoup d'exception aux règles, de tricks chelous et de règles stupides
Je suis d'accord avec toi, il ne faut pas croire que Java est facile à apprendre ou maitriser. Je pense d'ailleurs pas qu'il y ai de langage vraiment facile à maitriser.
Je pense notamment que Java n'est pas un bon langage pour démarrer la programmation car il est basée sur un paradigme complexe qu'est l'orienté objet.
Pour moi, un débutant doit démarrer par du "simple" procédurale (base de la programmation) et si possible sans s'attacher à un langage particulier (vive le papier et le stylo). Quand il est à l'aise avec cela (et ça prend du temps) il peut commencer à l'appliquer dans un langage (par exemple C) mais tout en sachant qu'il y a plein de tricks qu'il ne connait pas par rapport à ce langage. Et quand enfin il est plutôt serein avec ça, il peut attaquer d'autres paradigmes (POO, fonctionelle, etc). Ben tout ça, ça prend du temps, beaucoup de temps

Citation Envoyé par onilink_ Voir le message
règles stupides
Je suis curieux de connaitre ces règles, tu dis ça de manières objective ou moyennement ?
Tu as des exemples ?
Avatar de grunk grunk - Modérateur https://www.developpez.com
le 16/05/2018 à 11:42
La maîtrise d'un langage est une chose qui peut prendre du temps , mais ce qui fait un bon développeur selon moi , ce n'est pas forcément sa maîtrise du langage (ça reste important) mais plutôt sa capacité à faire les bons choix technique, à anticiper la vie du code.
Et pour arriver à prendre les bonnes décisions au bon moment , ça demande de s'être trompé , d'avoir recommencé , encore et encore ... et inévitablement cela prend du temps.

Citation Envoyé par danielhagnoul Voir le message

  • il faut se spécialiser dans un langage et dans un domaine ;

Je suis d'accord avec ça sauf qu'aujourd'hui le marché de l'emploi va à l'opposé.
Pour le web par exemple , il faudrait des dev frontend (html/css/js) , des dev backend (php/java/js/...) des dba (gestion base de données) et des admin système. Sauf que le seul mot qu'on les employeur à la bouche c'est "fullstack" , comprendre , qui sait tout faire. Et on va pas se mentir il est impossible d'être au top sur tous à la fois.
Avatar de Anselme45 Anselme45 - Membre éprouvé https://www.developpez.com
le 16/05/2018 à 11:47
Citation Envoyé par danielhagnoul Voir le message
.
Je constate souvent que les jeunes ont tendance à se satisfaire de ce qu'ils pensent maîtriser et à rester dans leur zone de confort. Quelques années plus tard, je pense à 5 ans, ils s'aperçoivent avec effroi qu'ils sont en train d'être largués et qu'il leur reste une montagne de choses à apprendre.
D'un point de vue théorique, c'est juste... Malheureusement, il y a bien longtemps que votre description ne correspond plus à la réalité du monde économique!

Les jeunes ne restent pas dans "leur zone de confort" (c'est un terme qui ne se voit plus en entreprise) et ne se satisfassent pas de leur connaissance, ils sont en permanence mis sous pression par leur hiérarchie qui ne leur laisse aucune possibilité de se former.

Dans le monde de l'informatique d'aujourd'hui, on ne planifie pas la formation du développeur (cela coûte trop cher): On se contente d'engager le spécialiste déjà formé pour ensuite le virer dès qu'il a fait son office.

Ce n'est pas pour rien que les SSII pullulent et que les mandats limités à 3-6 mois destinés aux "moutons à 5 pattes" sont beaucoup plus nombreux que les contrats en CDI
Avatar de sergio_is_back sergio_is_back - Membre expérimenté https://www.developpez.com
le 16/05/2018 à 12:03
Citation Envoyé par grunk Voir le message
La maîtrise d'un langage est une chose qui peut prendre du temps , mais ce qui fait un bon développeur selon moi , ce n'est pas forcément sa maîtrise du langage (ça reste important) mais plutôt sa capacité à faire les bons choix technique, à anticiper la vie du code.
Et pour arriver à prendre les bonnes décisions au bon moment , ça demande de s'être trompé , d'avoir recommencé , encore et encore ... et inévitablement cela prend du temps.
Oui, beaucoup de langages ont évolués au cours du temps et en maitriser tous les aspects peu vite devenir chronophage... Malgré 20 le nez dans Delphi j'en découvre encore tous les jours... Et que dire de C++ quoi n'arrête pas d'évoluer ces dernières années... Pour Python, Java, Php et les autres, comme dit plus haut dans ce topic je n'ai fais "que gratter la surface" même si j'ai déjà mené des développements dans ces langages....

Il est très rare d'utiliser un langage à ses pleines possibilités, du fait que l'on est aussi limité par notre propre vision "de ce que l'on développe", les raccourcis que l'on choisit ne sont pas toujours les plus appropriés même si ils fonctionnent et très souvent d'autres possibilités du langage choisi pourraient être mieux exploités

Citation Envoyé par grunk Voir le message

Je suis d'accord avec ça sauf qu'aujourd'hui le marché de l'emploi va à l'opposé.
Pour le web par exemple , il faudrait des dev frontend (html/css/js) , des dev backend (php/java/js/...) des dba (gestion base de données) et des admin système. Sauf que le seul mot qu'on les employeur à la bouche c'est "fullstack" , comprendre , qui sait tout faire. Et on va pas se mentir il est impossible d'être au top sur tous à la fois.
"fullstack" c'est encore un de ces termes qui veut tout et rien dire à la fois, ceux qui l'emploient à tour de bras n'ont souvent que très peu de culture technique et c'est plus souvent pour se faire mousser...

Tout maîtriser demande du temps, de l'expérience (toujours l'histoire de la théorie et de la pratique), il faut juste être curieux des choses, savoir sortir de sa zone de confort, être ouvert
Et avoir de bonnes bases

Les gens qui remplissent ces critères sont selon moi des "fullstack"

Et pas hésiter à parcourir les forums techniques comme developper.com, stackoverflow et d'autres, qui sont des mines d'infos et savoir additionner 1 et 1 pour faire 2 et pas s'arrêter à la première réponse
trouvée qui est peu être bonne mais rarement la seule...
Avatar de onilink_ onilink_ - Membre éprouvé https://www.developpez.com
le 16/05/2018 à 12:16
Citation Envoyé par Drowan Voir le message
Je suis curieux de connaitre ces règles, tu dis ça de manières objective ou moyennement ?
Tu as des exemples ?
Un exemple qui touche pas mal de collègues qui bossent dans le domaine, c'est l'égalité, avec == qui compare par référence et equals qui compare par valeur qui peuvent poser pas mal de pièges assez vite:
https://stackoverflow.com/questions/...rting-to-integ
https://stackoverflow.com/questions/...trings-in-java

Y a pas mal de casses têtes aussi avec les primitives qui ne fonctionnent pas par référence.
J'ai pas mes collègues sous la main mais je me souviens qu'il y avait beaucoup de problèmes du genre.
Je posterais quand je les aurais si ça t’intéresse. Ce que j'en ai retenu, c'est que le langage n'est pas homogène au niveau des règles, et on tombe souvent dans des pièges absurdes (si ce n'est pas dans des limitations).
Avatar de sergio_is_back sergio_is_back - Membre expérimenté https://www.developpez.com
le 16/05/2018 à 12:41
Citation Envoyé par onilink_ Voir le message
Un exemple qui touche pas mal de collègues qui bossent dans le domaine, c'est l'égalité, avec == qui compare par référence et equals qui compare par valeur qui peuvent poser pas mal de pièges assez vite:
https://stackoverflow.com/questions/...rting-to-integ
https://stackoverflow.com/questions/...trings-in-java

Y a pas mal de casses têtes aussi avec les primitives qui ne fonctionnent pas par référence.
J'ai pas mes collègues sous la main mais je me souviens qu'il y avait beaucoup de problèmes du genre.
Je posterais quand je les aurais si ça t’intéresse. Ce que j'en ai retenu, c'est que le langage n'est pas homogène au niveau des règles, et on tombe souvent dans des pièges absurdes (si ce n'est pas dans des limitations).
C'est pas débile : Integer est une classe en Java du coup dans l'exemple sur ton premier lien b2 et b3 sont des instances (des pointeurs)
donc l'instance b2 n'est pas "égale" à l'instance b3 (c'est deux instances différentes) même si elles sont initialisées avec le même contenu...

En java il ne faut confondre l'entier "natif" : int avec la classe "Integer"
C'est pas la même chose...

Par exemple :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
class D {
    public static void main(String args[]) {
        Integer b2=128;
        Integer b3=128;
        System.out.println(b2==b3);
    }
}
Renverra faux

Alors que

Code : Sélectionner tout
1
2
3
4
5
6
7
8
class D {
    public static void main(String args[]) {
        int b2=128;
        int b3=128;
        System.out.println(b2==b3);
    }
}
Renverra vrai
Contacter le responsable de la rubrique Accueil