Discussion :

[Community Management]

Comment devenir un meilleur développeur ?
La formation et l’expérience sont-elles suffisantes ? Vous êtes invités à partager votre avis

Le métier de développeur suscite de plus en plus d’intérêt pour un choix de carrière professionnelle. Il offre un large panel de spécialités telles que la programmation d’applications d’entreprise, la création de jeux, l’intelligence artificielle, et bien d’autres encore, qui suscitent de la passion chez de nombreux jeunes. Qui plus est, le métier de développeur peut tout aussi être bien rémunéré, avec un niveau de revenu mensuel pouvant aller à 5000 euros en France, et même au-delà dans certains pays.

Cependant, s’engager dans une carrière de développeur, ne garantit pas qu’on sera un bon programmeur. Il faut surtout s’en donner les moyens.
Le meilleur développeur est-il celui qui connait le plus de langages de programmation ? Pas certain, mais toujours est-il que tout développeur doit avoir une bonne faculté d’apprentissage, et une aptitude à résoudre les problèmes.

Henrik Warne, un développeur senior, indique quelques critères qui qualifient un bon développeur. Mais quel est le chemin pour y parvenir ?

La passion et la motivation ne suffisent pas pour parvenir à la qualité de bon développeur. Plusieurs éléments sont à prendre en compte pour réussir le pari de devenir meilleur programmeur. Et le but de ce sondage est d’identifier, lesquels seraient les plus importants.

Vous êtes donc invités à voter pour les méthodes que vous estimez les plus pertinentes, en vous s’inspirant notamment de votre expérience personnelle : comment avez-vous évolué dans votre carrière de développeur ? Et aussi, quelles erreurs éventuelles faudrait-il éviter pour devenir meilleur développeur.


Votre avis

Quels conseils donneriez-vous à une personne qui voudrait devenir un bon développeur ?


Voir aussi

Tout le monde ne peut pas devenir développeur : il faut d'abord disposer de certains prérequis
Qu'est-ce qui fait un bon programmeur ? Un senior liste cinq caractéristiques d'un bon programmeur
Y a-t-il une corrélation entre diplôme et succès en tant que développeur de logiciels ?
Emploi développeur 2017 : les langages les plus demandés et les mieux payés

[Angelsafrania]

Je pense que c'est comme un peu toutes choses que l'on veut maîtriser.
Il faut consacrer du temps, s'entraîner et voir d'autre horizon (échange avec d'autre personnes / d'autre façon de faire).
Du temps pour bien encrer les résonnement logique (la durée dépend fortement des personnes).
De l'entraînement pour acquérir les réflexes inconscients.
Et d'autre horizon pour élargir le champs de compétence.

Il est important de ne pas toujours faire la même chose. Se mettre en "danger" ou en situation "difficile" est souvent bénéfique, je pense, pour progresser.

[sergio_is_back]

Il est important de ne pas toujours faire la même chose. Se mettre en "danger" ou en situation "difficile" est souvent bénéfique, je pense, pour progresser.

J'aurais dit : "Sortir de sa zone de confort" mais cela revient au même.

Il faut aussi lorsque cela est possible (c'est pas toujours le cas), parler avec les gens qui vont utiliser le logiciel à développer : Pas les décideurs, les VRAIS utilisateurs, ceux qui vont
utiliser le logiciel au jour le jour surtout dans mon domaine, l'informatique industrielle. Lorsque l'on fait des logiciels orientés grand public, c'est plus difficile...

Par exemple : C'est le cas actuellement, j'attaque un soft de supervision d'atelier et de traçabilité et le directeur de production veut valider l’ergonomie lui-même, hors j'ai du mal à lui faire comprendre :

1. Que c'est pas lui qui va l'utiliser
2. Que ses subordonnés ont d'autres habitudes et besoins que ce que lui me rapporte (Il veut principalement de la statistique de prod)

Au final ça ne change pas le but premier du projet (la majeure partie est invisible des opérateurs), mais ce sont des détails importants qui peuvent conditionner l'adoption par les opérateurs et la réussite d'un projet

Enfin en dernier et c'est le plus difficile car c'est jamais chiffré, il faut faire un bilan quelques semaines/mois après livraison : Qu'est qui a bien marché, qu'est ce qui a foiré le cas échéant,
qu'est ce qu'on aurait pu améliorer en terme d'ergonomie, de codage, etc... C'est important car c'est une façon de capitaliser l'expérience acquise sur un projet et si il y a eu des loupés, des erreurs, des incompréhensions,
ne plus les reproduire sur le projet qui suivra (autant que possible)... Mais comme cette phase qui peu prendre du temps, en terme de réflexion et d'analyse n'est jamais vendue, et que bien souvent les
projets s'enchainent sans temps mort, on ne le fait que très rarement.

[Pyramidev]

J'ai voté :

• S’auto-former régulièrement. Pour avoir un bon niveau technique, c'est, à mon avis, le critère le plus important.
• Tirer les bonnes leçons de ses échecs. Par exemple :
  
  • Quand on écrit un code qui n'est pas assez flexible et réutilisable et que cela ralentit les développements plus tard, il faut se rendre compte que le code aurait pu être plus flexible et plus réutilisable.
  • Quand on introduit un bogue, il faut se demander si, en écrivant le code autrement au départ, un tel bogue aurait été plus difficile voire impossible à introduire.
  • En dehors du code, quand il y a des problèmes organisationnels, il faut aussi pouvoir les identifier. Par exemple, certains problèmes de communication viennent d'un manque de feedback.
• Apprendre plusieurs langages de programmation. Il y a plusieurs raisons :
  
  • De toute façon, on ne peut pas toujours se contenter d'un seul langage, car les langages les plus connus ne sont pas assez polyvalents.
  • Plus on connaît de langages, plus on a accès à des ressources pour s'auto-former.
  • Maîtriser les meilleurs langages ouvre l'esprit et aide à échapper au Blub Paradox. Le Blub Paradox est un concept introduit par Paul Graham dans son article Beating the Averages, écrit en 2001. Voici un extrait :
    

    Programmers get very attached to their favorite languages, and I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.
    
    And in fact, our hypothetical Blub programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice).
    
    As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
    
    [...]
    
    Programs that write programs? When would you ever want to do that? Not very often, if you think in Cobol. All the time, if you think in Lisp.

    Je n'ai pas encore étudié Lisp, mais j'ai expérimenté le Blub Paradox pendant mon apprentissage (encore en cours) du langage Haskell. Avant, avec C++, je connaissais le procédural, l'objet et la programmation générique, mais je ne connaissais presque rien du monde de la programmation fonctionnelle.

[Hizin]

Plusieurs des propositions, et autre.
Apprendre et partager. Discuter et échanger.
J'entends par là :

• Poser des questions sur notre projet lorsque l'on ne comprend pas une architecture, un choix technique, un code... bref, quoi que ce soit de technique
• Faire partie d'une communauté de développeurs, que ce soit virtuel (exemple : forum) ou réel (exemple : meetup)
• Rester humble : pour ça, j'aime beaucoup la signature de el_slapper avec le serment de non-allégeance de Cockburn => "Je promet 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."

Je rajouterai aussi le manifeste software craft(wo)manship qui me paraît être une bonne route vers l'amélioration.

En bref : l'intérêt et l'échange.

[carrows]

pour rester competitif et rester meilleur je participe souvent aux projets et je regarde des conférences,
comme par exemple NgConf, DEVOXX

[Daniel Josue]

Apprendre et partager. Discuter et échanger.

+1

J'adhère totalement à ce principe. Un bon développeur n'est pas celui qui s'enferme en vase clos, mais qui doit surtout apprendre à comprendre les autres (les utilisateurs finaux) et se faire comprendre. Sinon ...

[Saverok]

Je pense que rien ne vaut l'expérience et c'est un thème très vaste à prendre au sens large.
Plus on travaille sur des projets différents et plus on est confronté à :

• des problématiques différentes
• des collègues différents
• des managers différents
• des utilisateurs différents
• des échecs et causes d'échecs riches en enseignement
• ...

[footsteps]

Aimer ce que l'on fait.
Pas de concurrence, de performance, de temps .
Revenir à l'essentiel: aimer son métier.

CAD l'inverse du monde professionnel, ou tout est de plus en plus == c'est terminé quand?

[Saverok]

CAD l'inverse du monde professionnel, ou tout est de plus en plus == c'est terminé quand?

Parce que dans la vie personnelle c'est différent ?
J'ai le bonheur d'être le père de 2 garçons et je suis harcelé de questions du genre "c'est quand qu'on va au ciné ?" ou encore "c'est quand qu'on mange ?" ou la meilleure de toutes "c'est quand que je finis l'école ?"
Avec la femme, ce n'est pas mieux avec le traditionnel : "à quelle heure rentres-tu du travail ?"

[Mister Nono]

Bonjour,

Il faut aussi être un vrai collaborateur dans l'équipe de projet, être considéré à sa juste valeur, être rémunéré correctement et avoir de la flexibilité dans son mode de travail (télétravail, horaires flexibles...).

A+

[Matthieu Vergne]

Je vais profiter de ma formation pour donner un avis générique et sourcé, basé sur des travaux scientifiques. Les source en question sont sur les travaux effectués sur l'expertise dans de nombreux domaines, dont un bon point de départ est cet ouvrage :
Ericsson, K. Anders, éd. The Cambridge Handbook of Expertise and Expert Performance. Cambridge ; New York: Cambridge University Press, 2006. http://www.cambridge.org/us/academic...rt-performance.

Pour la question principale, à savoir "Comment devenir un meilleur développeur ?", ce n'est pas différent des autres domaines, et c'est tout simple. Il faut en effet avoir seulement 2 choses :
1. la volonté de s'améliorer
2. un bon coach

Le coach a pour rôle d'identifier les lacunes (2a) et de fournir les moyens pour les corriger (2b). Une fois qu'on a assez d'expérience, on peut faire cela par soi-même et donc être son propre coach, ce qui permet une autonomie totale pour une amélioration continue. Seule reste à maintenir la volonté de s'améliorer (ce qui n'a rien d'évident, ne soyons pas simpliste non plus).

Le sondage effectué montre d'ailleurs bien cela. À l'heure où j'écris ces lignes, 39 votants se sont exprimés et le classement est le suivant :
- S’auto-former régulièrement = 1+2b
- Tirer les bonnes leçons de ses échecs = 2a+2b
- S'engager sur les bonnes pratiques en programmation = 1
- Pousser toujours l’effort au-delà de ses capacités et de son confort personnel = 1
- Avoir une bonne formation de base = 2

Il existe des tas de manières de s'améliorer, celles listées là ne sont que des cas particuliers. Pour devenir toujours meilleur, il s'agit avant tout de se poser deux questions :
1. est-ce que j'ai vraiment envie de faire l'effort pour m'améliorer ?
2. est-ce que l'environnement dans lequel je suis (ou qu'on me propose) me permet d'identifier et de combler mes lacunes ?

Ainsi, comme mentionné dans l'article "La passion et la motivation ne suffisent pas pour parvenir à la qualité de bon développeur." Mais c'est tout de même un point primordial, qui doit être complété avec du bon coaching. Autrement, on prend le risque de tourner en rond ou de s'orienter sur des voies sans réelles issues.

[rcorler]

Pour ma part, je pense qu’il faut d’abord connaître plusieurs langages, OS, base de données ... Langage Objet, procédural, de 4ème Génération, ... Un bon développeur doit connaître cela. Il faut aussi qu’il sache l’utilité de tel ou tel langage. Faire du Cobol n’a pas le même objectif que du Java. Ces connaissances me paraissent essentielles.
Après, il doit aussi être spécialiste d’un langage car un bon développeur est avant tout un développeur efficace qui sait rapidement répondre à un besoin ou une urgence.
Je lis «*il doit aimer ce qu’il fait*». Évidemment ! Mais il est vrai qu’en entreprise, on rencontre des développeurs désabusés, initéréssés, ce qui est énervant.
Je pense aussi qu’il doit connaître les autres métiers (Analyste, récetteur, chef de projet). Comprendre l’environnement autour de lui me parait important.
Il doit être curieux et autodidacte. IA, Cloud, SAP, ... Un bon développeur doit avoir une bonne culture technologique.

[vertex.3F]

(ce qui me vient a l'esprit car la liste complete serait longue)

aimer développer,
avoir une mémoire correcte,
pouvoir se concentrer,
aimer et vouloir raisonner (analyser, modéliser, synthétiser, etc.),
pratiquer souvent,
ne pas développer seul (je veux dire en gros qu'il me parait important d'avoir une équipe ou au moins un collègue ou un coach pour pouvoir échanger sur sa production et l’améliorer),
aimer explorer /comparer de nouvelles solutions (pour s’améliorer aussi),
savoir pourquoi on développe (comprendre le besoin),
savoir tester,
être plus humble que la moyenne et ne pas refuser la critique constructive,
résister à l’échec,
vouloir (et pouvoir) prendre du recul sur notre techno favorite (par ex. pouvoir s'exercer sur des technos différentes),
bosser dans une organisation capable de valoriser ce métier qui, à mon, sens, est relativement complet et exigeant, qui prend du temps, qui est critique et qui est exposé (un trou dans la spécif pourra etre masqué par le développeur, mais un trou dans l'algo ça fera probablement un bug livré en prod si les testeurs du fournisseur et du client ne le signalent pas),
...

[ihaboumoussa]

Je pense que autoformation est la meilleure de chose pour être compétent en développement.

[el_slapper]

Je vais être encore plus basique : chercher délibérément à s'améliorer.

Peu importe la méthode, à mon sens.

[Nebulix]

C'est quoi un bon développeur ?
A écrit avec un langage d'il y a 30 ans un programme qui tient en 50 ko et fait le boulot avec une interface austère
B utilise les techniques dernier cri, qui en met plein les yeux et implique 12 fichiers

J'ai l'impression que B sera toujours mieux considéré ...

[Daniel Josue]

être rémunéré correctement et avoir de la flexibilité dans son mode de travail (télétravail, horaires flexibles...).

Personnellement, je ne vois pas en quoi avoir une bonne rémunération aide à être un meilleur développeur.

[Daniel Josue]

A écrit avec un langage d'il y a 30 ans un programme qui tient en 50 ko et fait le boulot avec une interface austère
B utilise les techniques dernier cri, qui en met plein les yeux et implique 12 fichiers

J'ai l'impression que B sera toujours mieux considéré ...

Peut-être parce B a intégré toutes les exigences liées à la sécurité.
Justement, être bon développeur ce n'est pas seulement écrire du code, mais c'est de réaliser un programme qui prend en charge toutes les contraintes du moment (besoins métiers, sécurité, ergonomie, etc.

[CinePhil]

Autres : Participer à Developpez.net !