IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

248PARTAGES

27  1 
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de 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.
14  2 
Avatar de 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.
11  0 
Avatar de GordonFreeman
Membre éclairé https://www.developpez.com
Le 16/05/2018 à 13:09
En ce qui me concerne, ça fait plus de 20 ans que je suis dans la technique et env 10 ans que j'ai décidé de me focaliser su le langage Java (après avoir fait du Pascal, PHP, javascript, C#)
Ma conclusion (pour le développement en général), plus j'en apprend, moins j'en sait...

La programmation est un monde complexe, ne serait-ce que connaitre un langage et son API prend un temps énorme. Mais c'est une infime partie de la connaissance requise pour être un bon développeur.
Ensuite viennent les concepts POO, APO, etc. le toolings, les bonnes pratiques, la conception, code maintenable, ensuite les framework et autres API, etc. etc etc.....

Et comme tous évolue très vite en matière de développement, dès qu'on maîtrise plus ou moins un outils/API/etc, ben on recommence.

C'est un monde excitant mais un peu fatiguant à la longue.
9  0 
Avatar de Anselme45
Membre extrêmement actif 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
6  1 
Avatar de bilgetz
Membre averti https://www.developpez.com
Le 16/05/2018 à 13:52
L’expérience de développeur, au delà de mieux maitriser un langage / librairie / framework , permet aussi de mieux comprendre et appréhender des concepts, de mieux cerner des patterns et leur défauts.
Tu as beau apprendre ce que tu veux dans des livres, tu ne verra que rarement les limites.

Je pense que tous le monde ici a déjà vue des architectures qui vont très bien sur des projet et qui se casse la gueule bien comme il faut sur d'autres.
Et ça, seul l’expérience peut le donner, qu'on l'ai vu en direct ou expliquer par des collègues.
5  0 
Avatar de 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.
4  0 
Avatar de sergio_is_back
Expert confirmé 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...
4  0 
Avatar de yildiz-online
Expert confirmé https://www.developpez.com
Le 16/05/2018 à 12:54
Citation Envoyé par onilink_ Voir le message
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).
Si, et la règle est on ne peut plus simple: on ne compare JAMAIS des objets avec ==, rien d'autres à savoir.

Si tu veux creuser pourquoi certains objets passent avec == ce sont des optimisations de la JVM (pools), donc propre à l'environnement d’exécution et non au langage, il ne faut donc pas du tout en tenir compte.
4  0 
Avatar de
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...)
3  0 
Avatar de bilgetz
Membre averti https://www.developpez.com
Le 16/05/2018 à 13:41
Citation Envoyé par sergio_is_back Voir le message
Exact : comme b2 possède la même valeur que b3 et qu'ils ne sont pas altérés après déclaration la JVM peut décider de faire pointer les deux instances sur le même "emplacement mémoire"... Mais c'est pas garanti
C'est comme ça que dans un cas "==" peut renvoyer vrai et faux dans l'autre... Mais y'a que les développeurs de la JVM qui pourraient l'expliquer, j'en suis pas un

En règle général pour des utilisations "standard" il vaut utiliser les types primitifs "int", "short", "byte", etc... que les classes "Integer", "Boolean", etc...
La programmation est facilitée (plus besoin de se poser la question pour == ou .equals) et la consommation mémoire bien moindre

Voir cet article (et les deux liens dans la première réponse) :

https://stackoverflow.com/questions/...nt-and-integer

Maintenant pour tes collègues c'est peu être un problème de formation ou d'habitudes (ou de manque d'attention)
Si tu regarde bien la Class Integer, tu verra une classe static IntegerCache qui a en cache les integer de -128 a 127, et elle serve à l'auto-boxing (et au valueOf)
du coup quand tu fait :
Code : Sélectionner tout
1
2
3
   Integer b2=127;
   Integer b3=127;
Grace a l'auto-boxing, tu aura la même référence, car elle sont en cache.

mais quand tu fait
Code : Sélectionner tout
1
2
3
   Integer b2=128;
   Integer b3=128;
tu as toujours de l'auto-boxing, mais cela n'est pas en cache, du coup les 2 Integer seront créer.
3  0