Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...
Une réponse vous a aidé ? utiliser le bouton
"L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel
Oausi super ce matin j'étais à 10 et là j'ne sui sà -10
Merci les bots' lol
Traiter les autres de bots quand on s'appelle gps...
Bin l'un n'empeche pas l'autre
C'est parce que je suis un bot que les autres ne peuvent pas en être, de même rien m'empeche de traiter les autres de bots meme si étant moi meme un bot sinon on peut plus rien dire
Et si on revenait au sujet initial?
Qu'est-ce qu'un bon développeur? Ma réponse va peut-être paraître stupide mais pour moi un bon développeur et quelqu'un qui aime ce qu'il fait (je n'emploi pas le mot passioné exprès).
Je m'explique, j'ai dans mon équipe un gars qui préférerait vendre des voitures que développer, mais voilà il voulait gagner de l'argent alors il s'est formé au dev et à trouvé un emploi. Maintenant, dès qu'une tâche lui est confié il râle parce que ce n'est pas censé être lui qui doit la faire (alors que doit-il faire je me le demande toujours?), quand on doit faire du partage de compétence/connaissance il y va à reculons parce qu'il ne comprends pas que d'autres personnes utilisent ce qu'il a temps suer à faire, etc... En gros travail d'équipe 0, en plus très dur de lui expliquer qu'il a tort...
Pour moi ce cas reflète ce qu'est, peut être pas un mauvais, mais en tout cas pas un bon développeur.
Un sage se distingue des autres hommes, non par moins de folie, mais par plus de raison.
Emile-Auguste Chartier, dit Alain
Aimer ce qu'on fait facilite l'implication.
Je ne dirais pas que l'implication est forcément corrélée avec la compétence, mais elle facilite l'effort, autant dans l'utilisation des compétences existantes que dans la recherche.
Et je considère cela indispensable pour faire du bon boulot.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
J'aime bien ce sujet. Je l'avais déjà lu quand j'avais reçu la news, et je me dit pourquoi pas participer.
Perso je pense que je suis pas assez expérimenté pour savoir ce qu'on pourrait appeler un bon dev. Mais si je prend mon exemple perso, je dirais que ce qui fait de moi un dev décent c'est ma polyvalence qui pour moi est la base d'une bonne capacité d'adaptation.
La base de ma réflexion vient d'un vécu assez simple. A une époque, pour les besoin de mon client je bossais beaucoup en AS3. Le jour ou Adobe a annoncé la fin du développement du player sur le web...du jour au lendemain, il ne voulait pas de flash (alors que c'était pas du tout justifié pour ce que l'on faisait). Ah ce moment je lui dit "on aura pas des aussi bon rendu, mais on va faire autrement". Bref, pas grave.
J'ai fait un tour des forums, et pour certains j'avais l'impression que c'était la fin du monde...
Beaucoup pensait qu'ils allaient perdre des années de formations bla-bla.
Pour eux l'idée même d'évoluer vers un autre langage, ou vers d'autres type de projet (plus desktop que web) n'était pas concevable.
Alors qu'au contraire, je trouve que quand on connait bien les base d'un langage, et les "good practice" en général, il est assez facile de se former sur d'autres langages qui seront amenés à compléter ou à remplacer ce que l'on connait déjà.
Bref pour moi la polyvalence :
- Me permet d'appréhender assez rapidement les bases de nouveaux langage/concept/techno
- Donne plus de corde à mon arc quand je dois proposer au client une façon de faire car il est beaucoup plus facile de jongler avec les contraintes
- Me permet de travailler avec tous les profils de l'équipes beaucoup plus facilement car même si je suis pas expert dans leur domaines, ce qu'ils me racontent me parle quand même.
- De travailler sur beaucoup de projet différent et donc je m'ennuie rarement.
Mes derniers projet je suis passer du module de vidéo Conférence en AS3 avec WOWZA Server, au jeu de l'oie en HTML/CSS Javascript. EN passant par une (toute petite) appli mobile sur android... Avec en tache de fond le dev d'un gros site de mise en relation presta-donneur d'ordre.
Et sur chacun de ces projet, j'apprend ou j'approfondie toujours des nouveaux truc.
Bref, au jour d'aujourd'hui, je dirais que des bonnes bases et de la polyvalence c'est déjà un bon début.
Je ne sais pas si cela a été évoqué, mais perso je penses qu'un point positif, de prime abord, c'est l'intérêt que porte la personne à la programmation en général.
Ce n'est pas ce qui fait un bon développeur, mais ça en fait un bon développeur potentiel. Et d'ailleurs un de nos RH est descendu pour effectuer des recrutements et il y avait 5 ou 6 personnes de ma promo (qui eux ont été jusqu'à la fin de leurs études avant de se faire embaucher ). Sur les 6, il m'a demandé ce que j'en pensais, et sur les 6 je n'en ai mis qu'un en avant : celui qui faisait de la programmation même en dehors de l'école.
Bon au final tout le monde a reçu une proposition donc personne n'a été lésé, mais en lisant ce sujet je me suis dit qu'avant toute chose (les compétences techniques, le niveau d'expertise, la connaissance du monde de l'entreprise, etc), si je devais qualifier une personne de bon ou de mauvais développeur, je regarderais avant tout s'il voit ça comme "une activité" ou "une passion".
La personne que j'avais mis en avant, elle lit des bouquins, elle fait des petits progs à droite à gauche, bref : elle pratique, sans qu'on lui demande, comme moi. personnellement je suis IED C++ et si je devais me noter je dirais que je suis un bon développeur selon mes critères et qu'en terme de connaissance je vaut 4 ou 5/10, 10 étant le niveau que je rêverais d'avoir en C++ (genre Bjarne, Herb, Andreï, Scott, Loïc, etc^^). On peut en conclure que pour moi, être un bon développeur ne se résume pas à être à 10/10 en terme de compétence technique, mais plutôt à avoir le potentiel, et surtout l'envie, d'y être un jour à ce niveau.
Nullius in verba
Comme tout recrutement, un "bon" développeur devra être bon dans son domaine MAIS AUSSI un "bon collaborateur", selon le poste, on insistera plus sur le premier ou le second (projets, clients ...). Capacité d'adaptation, communication, même culture générale, ne sont pas des qualités que l'on trouve facilement chez les techniques, malheureusement on sait que les projets n'échouent pas de manque de compétences mais bien de manque de communication.
Personnellement, je fuis les "voies royales", j'ai une nette préférence pour les parcours un peu cabossés, ceux qui ont touché un peu a tout, ne viennent pas "du sérail" et n'ont pas réponse a tout. Les autres se prennent trop souvent pour des as et vont se prendre le chou toute la journée pour savoir qui a la plus longue alors qu'au final, je vais être dur, ils sont très quelconques, voir médiocres.
De vrais ovnis, j'en ai croisé quelques uns, très peu en plus de vingt ans, et d'ailleurs, on les reconnait rapidement a leur capacité d'écoute, de compréhension et leur talent de vulgarisation. Mais qu'on se rassure, il y a de la place pour tout le monde, les talentueux, les inspirés, parfois, souvent ... et les laborieux, car il n'y a rien de plus stupide que de sur recruter ou, a contrario, de demander a certains d'être des dieux alors que dans le même temps, on les a choisi parce qu'ils étaient pas cher
J'sais pas pour toi mais moi quand je passe 8h par jour à faire de la programmation j'ai pas forcément envie d'en faire en rentrant chez moi. L'informatique c'est une passion si tu veux, mais c'est aussi un métier, un métier comme un autre. Un métier dans lequel on peut être très bon juste en étant productif quand il le faut.
Bien sur si c'est une corvée pour toi tu ne sera pas très bon. Mais mettre en avant quelqu'un juste parce qu'il programme le week end... Bon je comprend ton point de vue, et quand tu sorts de l'école pour un recruteur ça peut en effet être un plus. Mais au bout d'un moment ça ne rentre pour moi plus le critère pour être un bon développeur.
Bah personnellement moi c'est le contraire, ça m'énerve tellement de bosser sur des applis aussi vieilles que moi dans des langages tous les jours différents et sur des codes plus mauvais les uns que les autres, que je passe énormément de temps ensuite sur mes projets persos. Maintenant je comprends aussi ton point de vue : il est vrai qu'une fois que tu travaille, c'est plus trop la chose à regarder. Mais par contre, un étudiant qui n'a jamais pratiqué en dehors des heures de classe, il est un peu mal barré. Quand je vois qu'en master 1° année, on apprends seulement les bases du C++, et que certains n'y ont jamais touché avant, je sais qu'ils ne feront pas de bons développeur C++ (et pourtant il y en a qui malgré ça veulent en faire leur techno de prédilection).
Même dans ma boite, on est 3 ou 4 à être dev C++ et j'ai halluciné de voir que j'étais le seul à pratiquer et à être au courant qu'une nouvelle norme était sorti récemment.
Notre domaine est aussi vaste que celui de la médecine. Et un bon médecin, c'est un médecin qui se tient à la page. Du coup je considère qu'un dev qui ne s'intéresse ni à sa propre techno ni aux actualités du monde de l'informatique (et même du monde scientifique en général) ne fera jamais un bon développeur, même s'il sera apte à faire ce qu'on lui demande à son boulot.
Nullius in verba
Bonjour, je n'ai jamais posté chez vous, vous ne me connaissez pas. Moi, si ! J'ai déjà eu beaucoup de plaisir à vous lire pendant des heures. En tant que développeur pro, je partage beaucoup de vos préoccupations, expériences et constatations.
La question posée, "Qu'est ce que c'est un bon développeur" me fait réagir, j'ai ma thèse ! Je vous fais des excuses par avance, ce que j'écris ici n'est pas facile à lire d'un trait, c'est plutôt à méditer, pour qui veut bien sur.
THESE
Selon ma théorie, le développement est un métier qui met constitutivement en valeur les personnes dont la préférence cervicale est située dans l'hémisphère droit.
Si vous ressentez le besoin de vous faire une idée, voyez cette synthèse : http://cerveaudroit.ouvaton.org/.
Selon les théories de neuropsychologie concernant les styles cognitifs,
- l'hémisphère cérébral droit est irrationnel - ou sensible -, parallèle et visuel ;
- l'hémisphère cérébral gauche est rationnel, sériel et auditif.
Selon ma thèse, un bon développeur doit plutôt avoir la préférence cervicale droite.
Le rationnel correspond à ce qui est quantifiable et prévisible, soit à priori tout le contraire du développement. Ceci est un argument qui vaut ce qu'il vaut et qui ne doit pas à ce niveau de l'explication faire débat. Il doit être évident qu'un bon développeur est en mesure de savoir le temps qu'il faudra pour faire certaines tâches. J'ai bien certains clients, des habitués, qui parviennent à le faire pour moi, aussi bien que moi !
L'important est d'obtenir un bonne vue d'ensemble de ce que j'expose, éclairée par les analogies oppositionnelles dont on dispose.
Voici une autre d'entre ces analogies : le contraire du disciplinaire est le ludique.
C'est ma thèse. Si elle vous fait bondir, ne vous prenez pas le chou, ce n'est rien, c'est juste un essai.
DEVELOPPER
Développer ne s'apprend pas à l'école de la spécialisation. Développer, c'est savoir s'adapter à la situation. Nous savons tous ici qu'il est pratiquement impossible d'anticiper ce que veut vraiment le client avant de l'avoir fabriqué. Aucun enseignement ne pourra jamais permettre d'avoir réponse à tout selon des protocoles ou des ouvrages de référence. Un bon enseignement pour développeur se devrait d'être au moins pratique, extrêmement varié et imprévisible. Un examen de développeur ne devrait jamais sanctionner le par coeur, mais au minimum l'aptitude à trouver des solutions qui tiennent compte de la demande et qui sachent utiliser le disponible.
D'ailleurs en développement ce qui motive vraiment le développeur, c'est la nouveauté. Coder à nouveau la même chose est le pire ennui qui puisse nous arriver.
Etre développeur, c'est avoir une connaissance horizontale, c'est à dire un savoir dans toutes les directions et aimer ça. Le savoir horizontal est diffus quand le le savoir vertical est pointu.
Au jeu d'échec, on peut être bon de deux façons : pour sa capacité à calculer des tas de coups d'avance, ou bien pour avoir des tas de parties en mémoire. Le meilleur développeur est celui qui a sait tirer des réponses à partir de toute son expérience des situations vécues. Il bonifie en vieillissant !
Dans ma théorie, un bon développeur se sent plutôt nul dans l'abstraction, il peut peiner lamentablement pour coder certaine choses théoriques, alors que d'autres très pratiques l’enivrent littéralement. J'ai certains tout petits codes fonctionnels essentiels, de peut être cinquante ou cent lignes, qui m'ont demandé des efforts monstrueux et sur lesquels apporter une modification me donne des cauchemars au point que... je préfère essayer de les réécrire, en mieux, si du moins je me suis amélioré depuis. Je suis persuadé que d'autres personnes le feraient beaucoup mieux, plus compréhensible et plus vite, simplement d'après le cahier des charges. Par contre l'IHM, par exemple, quel pied ! J'ai des fois le coeur qui bat à plein, rien qu'à penser à la bidouille que je suis en train d'ajouter, que je vais tester et améliorer directement dans l'IDE et qui va apporter à mes utilisateurs une fonctionnalité déjà forcément magique et incontournable !
Pour moi, développer et hacker sont fondamentalement des synonymes : développer, c'est jouer. Et je pense que l'école, dans l'état actuel des choses, est largement capable d'empêcher la nature de ce métier de se développer naturellement chez ses élèves.
Je peux continuer à l'envie les analogies. Je finirais par celle que tout le monde connaît ici : le contraire et complémentaire du développement, c'est l'analyse bien sur.
Etant autodidacte, vouloir être les deux est l'erreur grave et coûteuse, mais finalement créative, que j'ai commise voici plus de vingt ans et qui m'a conduit à faire ce que j'ai fait : des outils puissants dédiés au service de mon effrayante nullité en analyse.
HORS DE CETTE THÉORIE
Le fait est que la caractérisation que je montre ici peut sembler caricaturale. Dans la vie réelle les développeurs rationnels existent. Ce sont ceux qui font des codes certes pas très créatifs, mais solides et propres.
Puisqu'il est une activité paradoxale, toujours selon ma thèse, le développement rationnel est le développement le plus difficile à réaliser. Pensez donc : faire un énorme code en troupeau où, même l'imprévisible serait prévu dans ses moindres détails...
Des fois ça me fait rire de voir ces gens se coltiner encore et encore avec un réel rétif, malgré toutes les préventions imaginables. Mais si je ris ainsi, c'est seulement quand il s'agit de gens prétentieux. Parce que j'admire vraiment cette écriture claire, naturellement associée aux projets d'équipes, qui est hors de ma portée de roi de la bidouille. Je dois dire que j'adorerai travailler avec ce genre de personnes à refabriquer en vrai mes joujoux. Je considérerais ce genre de chose rien de moins qu'une consécration.
Je pense discerner que ce sont ces gens là en particulier qui ont rendu possible un projet tel que Linux - et le libre en général -, qui correspond bien aux critères énoncés avant : pas très créatif, mais extrêmement rigoureux, solide et efficace. Industriel.
Ce sont de gens qui ne peuvent pas travailler sans cahier des charges qui sont désormais inaptes à rendre compte du besoin bouillonnant qu'à installé la démocratisation fulgurante des ordinateurs. A ce titre vous pouvez aussi aller lire ou visionner sur ce site une théorie du futur du cerveau droit : http://www.paris-philo.com/article-l...mment105479968 qui corrobore très bien ma petite thèse.
TAO
Tout vrai développeur, bordélique par nature selon cette thèse, se fait dompter un jour par la réalité. Il est alors forcé, s'il ne l'a pas fait par son cursus, d'apprendre la discipline et c'est là, quand il a du fortement combattre avec lui même qu'il peut enfin devenir un excellent développeur, quand il sait discerner selon la situation s'il à le temps ou non de jouer, s'il doit faire appel à une expertise extérieure et laquelle. C'est le moment crucial du développement, un Tao en quelque sorte.
Il est montré avec une grande constance dans ces forums que l'écriture d'un cahier des charges réaliste est une gageure radicintenable. La réalité est que le développeur tel que je l'entend, c'est à dire l'irrationnel est précisément celui qui réalise ceci. C'est lui qui crée la maquette utilisable, qui rend les choses possibles pour qu'une autre catégorie de personnes soient en mesure de se les réapproprier pour les rendre réelles.
Un bon développeur, c'est celui dont l'écran affiche des outils de développements, et pas des forums débattant de ce qu'est un bon développeur ?
pas tapay, je suis déjà sorti.
Je fais de la veille technique et managériale, en prévoyance du jour où je serais chef et que je devrai gérer une équipe de developpeurs.
http://www.traducteur-sms.com/ On ne sait jamais quand il va servir, donc il faut toujours le garder sous la main
J'étais dehors et je n'ai vu personne. Ou il est ? ou il est ?
Bon ok, j'ai fait long trop long trop compliqué et en plus j'ai une contradiction dans le texte qui m'obligerait à le réécrire (nooon plus tapé) pour enlever un petit côté glissant, n'est ce pas ?
Le développement est irrationnel au début et rationnel à la fin.
Pour corriger mon raisonnement erroné, je dois dire qu'il n'y a pas qu'un type de développeurs, mais deux (ou plus). Il faut des gens comme moi pour se coltiner le rugueux en individuel et des gens pas comme moi pour en faire quelque chose de sérieux en équipe. Donc le bon développeur, c'est les deux, différents et complémentaires.
Voili.
Justement un bon dev est celui qui fait autre chose en meme temps car il a le code en tete, ce qui lui permet de "switcher" avec un autre truc
la littérature dit autre chose...
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets 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.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager