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

Le , par Siguillaume, Community Manager
Comment devenir un meilleur développeur ?
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


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 Angelsafrania Angelsafrania - Membre confirmé https://www.developpez.com
le 08/05/2018 à 9:53
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.
Avatar de sergio_is_back sergio_is_back - Membre éprouvé https://www.developpez.com
le 08/05/2018 à 11:02
Citation Envoyé par Angelsafrania Voir le message

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.
Avatar de Pyramidev Pyramidev - Membre émérite https://www.developpez.com
le 08/05/2018 à 11:48
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.

Avatar de Hizin Hizin - Modérateur https://www.developpez.com
le 08/05/2018 à 13:20
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.
Avatar de carrows carrows - Nouveau Candidat au Club https://www.developpez.com
le 08/05/2018 à 15:19
pour rester competitif et rester meilleur je participe souvent aux projets et je regarde des conférences,
comme par exemple NgConf, DEVOXX
Avatar de Daniel Josue Daniel Josue - Membre régulier https://www.developpez.com
le 08/05/2018 à 16:25
Citation Envoyé par Hizin Voir le message

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 ...
Avatar de Saverok Saverok - Expert éminent https://www.developpez.com
le 09/05/2018 à 15:28
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
  • ...
Avatar de footsteps footsteps - Membre actif https://www.developpez.com
le 10/05/2018 à 19:44
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?
Avatar de Saverok Saverok - Expert éminent https://www.developpez.com
le 11/05/2018 à 10:15
Citation Envoyé par footsteps Voir le message
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 ?"
Avatar de Mister Nono Mister Nono - Membre expérimenté https://www.developpez.com
le 11/05/2018 à 16:54
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+
Contacter le responsable de la rubrique Programmation