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 !