Discussion :

[Cincinnatus]

Comme pour tout métier, certaines compétences sont nécessaires pour être développeur.
Beaucoup de choses s'apprennent. J'ai appris Merise et les bases de données sur le tard (après l'objet).

En distinguant donc les compétences et les connaissances, non, tout le monde ne peut pas devenir développeur.
En restant à un haut niveau :

• il faut pouvoir raisonner dans l'abstrait, faire preuve de logique. La programmation objet n'est pas innée : j'ai vu des dévs Cobol, très bons dans leur domaine, bloquer sur les concepts objets.
• il faut pouvoir traduire les demandes des clients / utilisateurs en fonctionnalités concrètes.
• il faut savoir se remettre en question en permanence.
• une bonne capacité à communiquer est généralement requise

Quant à la curiosité et la soif d'apprendre, quelqu'un qui se limite à ce qu'il a appris en cours ne pourra non seulement progresser mais même travailler correctement. Les technos et méthodes évoluent, il est nécessaire de se tenir au courant et de se former à celles qui nous concernent.

Enfin, heureusement que la passion est terminée. Tant que j'étais passionné, j'ai évité de travailler dans ce domaine. Maintenant, il est plus facile de supporter les maîtrises d'ouvrage et les utilisateurs de mes développements. Je suis très intéressé par le développement et très impliqué dans mon travail, très fier aussi de ce qui marche comme prévu, mais plus tolérant face aux retours négatifs qu'il y a aura toujours.

Combien de fois les collègues non informaticiens qui ne comprennent pas quelque chose qui pour nous est simple nous disent "je ne suis pas informaticien"

[Gulien]

Enfin, heureusement que la passion est terminée. Tant que j'étais passionné, j'ai évité de travailler dans ce domaine. Maintenant, il est plus facile de supporter les maîtrises d'ouvrage et les utilisateurs de mes développements. Je suis très intéressé par le développement et très impliqué dans mon travail, très fier aussi de ce qui marche comme prévu, mais plus tolérant face aux retours négatifs qu'il y a aura toujours.

C'est marrant car j'ai l'impression que c'est de plus en plus vrai (les retours négatifs):

-Dans les années '80 le dev. était un demi-dieu qui apportait un gain de productivité phénoménal, chaque nouvelle fonction était attendue, et permettait à l'utilisateur de gagner un temps précieux.
-Dans les années '90 à 2010 l'info est devenu petit à petit la norme avec des marchés de niche qui venaient se combler et où on pouvait encore ressentir ce "frisson" quand on rendait service au gens.

-Puis maintenant (dans ma boîte en tout cas) les gens sont blasés de l'info, ont tous un smartphone, touchent de près ou de loin Excel, et ne voient plus les fonctionnalités arriver avec un œil d'enfant, mais seulement comme une petite corde de plus à leur arc, et si ça ne répond pas exactement à leur besoin personnel, ils ne sont pas content et ne comprennent pas pourquoi "c'est si compliqué d’aligner 3 données comme ils le veulent".

Perso je me re-lancerais bien dans un domaine où on va retrouver cette fougue des débuts de l'info (Robotique ? Même si ce n'est pas nouveau, la courbe de croissance est plus lente ).

[DonQuiche]

Perso je me re-lancerais bien dans un domaine où on va retrouver cette fougue des débuts de l'info (Robotique ? Même si ce n'est pas nouveau, la courbe de croissance est plus lente ).

IA et big data. Dans ces domaines-là on crée encore des fonctionnalités révolutionnaires. Sinon opte tout simplement pour l'informatique dans n'importe quel domaine en expansion où tout est à faire. Il y a par exemple des choses innovantes à faire dans l'impression 3D, avec des bâtiments auto-construits et compagnie, ce qui est aussi un problème d'algorithmes. Je suis sûr qu'on pourrait aussi faire de l'algorithmique en biologie.

EDIT : lien corrigé.

De mon point de vue, les mauvais dévs sont ceux qui se croient bon, et les bons dévs sont ceux qui ne veulent pas rester mauvais.

Je dirais plutôt que les bons dévs sont ceux qui se savent moins mauvais que les autres.

[Matthieu Vergne]

Je dirais plutôt que les bons dévs sont ceux qui se savent moins mauvais que les autres.

Tu connais l'effet Dunning-Kruger ? Pour moi, ceux dont tu parles sont les premiers dont il faudrait se méfier.

[DonQuiche]

Tu connais l'effet Dunning-Kruger ? Pour moi, ceux dont tu parles sont les premiers dont il faudrait se méfier.

Je le connais et tu en fais une mauvaise interprétation. L'effet Dunning-Kruger reflète le fait que les plus compétents se sous-estiment le plus, pas qu'ils se croient mauvais. Plus précisément l'effet Dunning-Kruger n'établit pas une corrélation entre compétence et image de soi mais entre la compétence et le décalage entre l'image de soi et la compétence mesurée.

Si tu te crois mauvais en dépit des preuves du contraire et de l'opinion favorable des autres à ton égard, alors c'est un problème d'amour-propre, rien d'autre. En général les bons se savent bons et les mauvais se savent mauvais : la plupart des êtres humains ont une appréciation à peu près correcte d'eux-mêmes.

Enfin j'insiste sur le fait qu'une appréciation correcte de ses forces et faiblesses est une compétence nécessaire à l'expertise.

[Artemus24]

Salut à tous.

Et entre 0 et 5 ans d'expérience on est pas développeur?

Avant 5 ans, on est débutant. Ce n'est pas moi qui fait les règles d'embauches dans les SSII.
Pour s'en rendre compte, il suffit d'examiner les offres d'emplois.

C'est la première fois que j'entends que les développeurs sont bien payé...

C'était vrai avant le crise, mais plus maintenant.

Surtout en Europe, être chef de projet c'est bien plus gratifiant...

Il y a beaucoup de gens qui aiment les titres ronflants car cela leur donne de l'importance.
Le principe de Peter s'énonce ainsi : "dans une hiérarchie, tout employé a tendance à s'élever à son niveau d'incompétence".

En plus, l’évolution est très lente, donc non je ne suis pas du tout d'accord avec cette article.

Moi non plus, je ne suis pas d'accord avec cet article. Il n'y a pas une seule sorte de développeurs dans le monde informatique.
Vouloir généraliser sur des métiers totalement différent est une erreur.

Evolution lente ? Non, c'est plutôt un barrage qui t'empêche d'évoluer à ta convenance.
Tu es développeur, alors tu le resteras jusqu'à la fin.
A moins que de ta propre initiative, tu cherches une formation pour faire évoluer ta carrière.
La promotion par l'ancienneté, c'était jadis

Dans quelle type d'entreprise est-ce que j'ai débuté en sortant de formation alors ??

C'est le paradoxe à la française. Pour avoir du travail, il faut de l'expérience, mais pour avoir de l'expérience, il faut du travail.
D'où l'importance du premier employeur et du projet sur lequel tu vas travailler.
Nous sommes tous passé par là, et tu ne m'apprends rien du parcours du combattant pour trouver un premier emploi.

Les stages et les formations en alternance sont une pure invention des politiques.
C'est un complot destiné à marquer le chômage des jeunes !!

Je suis entièrement d'accord avec toi, même si je l'ai pris sous la forme d'un humour grinçant.
C'est la triste réalité du délabrement du travail à la française.
A moins d'être diplômé d'une école qui a la cote sur le marché du travail, les autres subissent ce désagrément.

@+

[janselmeer]

En distinguant donc les compétences et les connaissances, non, tout le monde ne peut pas devenir développeur.
En restant à un haut niveau :

• il faut pouvoir raisonner dans l'abstrait, faire preuve de logique. La programmation objet n'est pas innée : j'ai vu des dévs Cobol, très bons dans leur domaine, bloquer sur les concepts objets.
• il faut pouvoir traduire les demandes des clients / utilisateurs en fonctionnalités concrètes.
• il faut savoir se remettre en question en permanence.
• une bonne capacité à communiquer est généralement requise

J'ajouterais en plus qu'il faut être capable de maintenir et faire évoluer un existant.

Bref le métier de développeur est bien plus exigeant qu'il n'en a l'air. Il ne suffit pas de savoir coder.
Tout le monde n'a pas la capacité suffisante. Ceux qui n'y arrivent pas changent de voie comme chef de projet, expert métier, exploitant, manager...

Pour en revenir à la question du salaire, on ne choisit pas un métier dans l'ingénierie juste pour l'argent. Sinon autant s'orienter vers le commerce.

[Cincinnatus]

En distinguant donc les compétences et les connaissances, non, tout le monde ne peut pas devenir développeur.
En restant à un haut niveau :

• il faut pouvoir raisonner dans l'abstrait, faire preuve de logique. La programmation objet n'est pas innée : j'ai vu des dévs Cobol, très bons dans leur domaine, bloquer sur les concepts objets.
• il faut pouvoir traduire les demandes des clients / utilisateurs en fonctionnalités concrètes.
• il faut savoir se remettre en question en permanence.
• une bonne capacité à communiquer est généralement requise

J'avais hésité à ajouter : de la diplomatie...
Il en faut quand on vous sort une demande qui traînait depuis des mois avec un délai intenable

[el_slapper]

J'avais hésité à ajouter : de la diplomatie...
Il en faut quand on vous sort une demande qui traînait depuis des mois avec un délai intenable

Ouais. Mais ça s'apprend, ça. Ça fait des années que je n'ai plus raccroché de téléphone au nez. Donc on peut progresser sur ce domaine. Donc on peut être un grand professionnel, sans, au départ, avoir ça dans sa besace.

Tu répondais aussi à "j'ai vu des dévs Cobol, très bons dans leur domaine, bloquer sur les concepts objets.". Présent. J'en ai chié sur ce tutoriel. Mais j'ai insisté. J'avais pris un truc tout con(en gros, un getter de base, un setter de base), et j'ai essayé de comprendre. Je suis resté deux jour devant ces 12 misérables lignes, à les voir marcher, et à ne pas comprendre. Puis, au matin du troisième jour, Dieu a mis le soleil dans le ciel. Et j'ai pigé. J'ai traduit ça en mes propres mots : "une classe, c'est une structure de données, avec en plus le code qui agit sur ces données. Comme un niveau 88 sous stéroïdes. Qui permet même de mettre un vrai code à la place d'une valeur en dur"(pour ceux qui ont la flemme de suivre le lien, un niveau 88 en COBOL, c'est comme une énum, mais en mieux, parceque ça gère les plages de données, voire les chevauchements. Mais on ne peux pas mettre de vrai code dedans, donc c'est quand même limité. J'adorais. Mais je comprends aujourd'hui pourquoi il n'y a pas d'équivalents dans les langages objets : pour les trucs compliqués, on se farcit directement une classe, et on garde les enums pour les cas simplistes).

Après, soudain, j'ai compris tous les tutoriels que je feuilletais depuis des années et que je ne pigeais pas. Je comprenais la différence entre "instance" et "classe". La classe, c'est juste le code informatique qui s'applique au paquet de données en mémoire que l'on appelle "instance". Avec définition de données ET Code d'utilisation des données(les propriétés et méthodes). J'ai compris tous les exemples pourris qui font des héritages partout(putain, c'est vraiment le truc qui me bloquait dans la compréhension, ça, l'héritage. Une fois qu'on l'a sorti de l'équation, on peut comprendre, et une fois qu'on a compris, on peut remettre dans l'équation. Un héritage, c'est juste une COPY(nos include à nous) qui contiendrait une autre COPY).

Je pense que les tutoriels objets qu'on trouve un peu partout sont catastrophiques pour les gens qui ont un profil initial cobol. Ça part dans tous les sens en disant "c'est bien, mangez-en", mais ça tombe complètement à plat pour des gens qui ont déjà des outils très puissants à leur disposition. Qui ne comprennent pas ce que ça peut leur apporter. D'ailleurs, dans certains cas, c'est à proscrire. Mais dans d'autres, c'est hyper-puissant. Bon, la couche objet de COBOL est une horreur, ça n'aide pas.

Mais un tutorial objet efficace pour des cobolistes, ça serait "tiens, on va refaire un niveau 88. Mais en mieux. Avec carrément du code pour décider si oui ou non ton booléen est vrai ou faux". Et surtout pas ces trucs de bisounounours "ah, alors on a une classe animal, dont hérite l'objet chat" qui vont directement braquer les cobolistes qui auront l'impression - à juste titre - qu'on les prend pour des cons.

le tuto VB6 que j'ai utilisé était beaucoup plus adapté, parcequ'il ne s'encombrait pas de polymorphisme et autre concept intéressant, mais très à même d'obscurcir l'esprit. Mais il ne suffisait pas quand même en première lecture. J'ai du m'arracher, me dire que non, je n'étais pas si stupide, et que je pouvais comprendre. Et ça a fini par payer. Donc ce qu'on dit les autres(il faut vouloir pour réussir) est vrai. Mais pas suffisant. Il faut une leçon adaptée. Et je suis sur que ceux qui disent "les cobolistes ne peuvent pas apprendre l'objet" n'en avaient pas - parce qu'ils ne savent pas se mettre à leur place. Je peux, moi, puisque je suis passé par là. Je sais ce qui me reste à faire.

[Cincinnatus]

Ouais. Mais ça s'apprend, ça. Ça fait des années que je n'ai plus raccroché de téléphone au nez. Donc on peut progresser sur ce domaine. Donc on peut être un grand professionnel, sans, au départ, avoir ça dans sa besace.

Tu répondais aussi à "j'ai vu des dévs Cobol, très bons dans leur domaine, bloquer sur les concepts objets.". Présent. J'en ai chié sur ce tutoriel. Mais j'ai insisté. J'avais pris un truc tout con(en gros, un getter de base, un setter de base), et j'ai essayé de comprendre. Je suis resté deux jour devant ces 12 misérables lignes, à les voir marcher, et à ne pas comprendre. Puis, au matin du troisième jour, Dieu a mis le soleil dans le ciel. Et j'ai pigé. J'ai traduit ça en mes propres mots : "une classe, c'est une structure de données, avec en plus le code qui agit sur ces données. Comme un niveau 88 sous stéroïdes. Qui permet même de mettre un vrai code à la place d'une valeur en dur"(pour ceux qui ont la flemme de suivre le lien, un niveau 88 en COBOL, c'est comme une énum, mais en mieux, parceque ça gère les plages de données, voire les chevauchements. Mais on ne peux pas mettre de vrai code dedans, donc c'est quand même limité. J'adorais. Mais je comprends aujourd'hui pourquoi il n'y a pas d'équivalents dans les langages objets : pour les trucs compliqués, on se farcit directement une classe, et on garde les enums pour les cas simplistes).

Je dirais plutôt que le sens de la diplomatie, ça s'acquière. Bon, perso, je ne me souviens pas avoir raccroché au nez d'un interlocuteur (au boulot, hein, pas d'un téléopérateur infoutu de se présenter).

Quant à l'objet, j'ai commencé avec TP6 (Turbo Pascal 6 pour les non-connaisseurs) qui introduisait certains éléments de ce type de programmation en sus de la programmation structurée "habituelle". ça fait un bail, je n'étais pas encore développeur professionnel. Depuis je suis passé à C++, Python et principalement Java.

Quand j'évoquais les dévs Cobol, ça n'avait rien de péjoratif, c'était juste pour montrer que même des pointures dans un domaine peuvent avoir du mal à passer à quelque chose de conceptuellement différent.

Globalement, la plupart des connaissances et des comportements peuvent s'acquérir, en dév comme ailleurs. Par contre, il faut certaines tournures d'esprit à la base, qui ont été citées plus haut.

[el_slapper]

Je dirais plutôt que le sens de la diplomatie, ça s'acquière. Bon, perso, je ne me souviens pas avoir raccroché au nez d'un interlocuteur (au boulot, hein, pas d'un téléopérateur infoutu de se présenter).

Ben, c'est ce que je voulais dire. Je deviens civilisé et communiquant avec l'âge.

Quant à l'objet, j'ai commencé avec TP6 (Turbo Pascal 6 pour les non-connaisseurs) qui introduisait certains éléments de ce type de programmation en sus de la programmation structurée "habituelle". ça fait un bail, je n'étais pas encore développeur professionnel. Depuis je suis passé à C++, Python et principalement Java.

Une approche progressive, voilà qui me parait positif. Et qu'on ne trouve pas dans la plupart des tutoriels objets, ou des formations. Les gens qui "savent" ont une furieuse tendance à étaler leur savoir, je trouve, ce qui explique pas mal de rejet.

Quand j'évoquais les dévs Cobol, ça n'avait rien de péjoratif, c'était juste pour montrer que même des pointures dans un domaine peuvent avoir du mal à passer à quelque chose de conceptuellement différent.

Le souci, je pense, est moins dans le potentiel de la personne que dans les habitude qu'elle a prise. Le COBOL se programme d'une manière très linéaire, l'objet pousse à programmer de manière beaucoup plus circulaire. Chaque option a ses qualités et ses défauts, mais pour sortir d'une manière de penser, il faut accepter de se tordre le cerveau, de se faire violence. Et aussi avoir une leçon adaptée à nôtre profil. Le chat qui hérite de l'animal, c'est rigolo pour quelqu'un qui n'a jamais programmé. Pour quelqu'un avec 20 ans de bouteille et de dures batailles gagnées, c'est anti-pédagogique au possible.

Globalement, la plupart des connaissances et des comportements peuvent s'acquérir, en dév comme ailleurs. Par contre, il faut certaines tournures d'esprit à la base, qui ont été citées plus haut.

Ce que je voulais dire, c'est que pour un coboliste aguerri, les tournures d'esprit sont là; simplement, elles ont été puissamment entrainées à aller dans un sens. Pour aller dans l'autre, c'est violent. LE potentiel est là, mais il est fort difficille d'accès.

[Artemus24]

Salut à tous.

ton point de vue semble s'orienter sur quelque chose de similaire à l'âme ou l'esprit, quelque chose qui transcende le côté matériel du corps. Si je n'ai rien contre l'idée en soi, d'un point de vu explicatif ça me semble trop hors d'atteinte pour l'instant.

Oui, c'est bien cela. Maintenant je n'ai aucune explication à donner car comme tout le monde, j'ignore si c'est vrai et comment ça fonctionne. Mais l'idée me plait beaucoup car cela permet d'expliquer nos différences.
Si je devais résumer cette approche, je dirais que c'est l'influence de nos vies antérieures. Je tiens à préciser que c'est l'origine (selon moi) de ce qui fait de nous ce que nous sommes.
Après, je te rejoins sur l'influence de l'environnement, et de l'ADN. En fait, rien n'est figé et tout fluctue en permanence. Ce que tu aimes aujourd'hui, tu peux le détester demain. C'est ce qui fait de nous ce que nous sommes. Je voie cela comme une continuité un peu comme une route avec un paysage continuellement en train de changer.

En résumé de ce que j'essaye de dire, cela se résume à ce que l'on aime ou pas (notre être profond), ce que l'ADN nous donne comme capacité et des opportunités de notre environnement que l'on rencontre dans la vie. Au final, il nous restera l'expérience qui vient influencer notre être profond. L'important est d'être en phase avec tout cela.

@+

[guillaume07]

Je nuancerais 'tout le monde ne peut pas devenir développeur' en 'tout le monde ne veut pas vraiment devenir développeur'

Je pense que le développement est à la portée de beaucoup de monde (la plupart des gens), mais qu'il faut de la passion, de la persévérance, et surtout de la patience.

tout est dit

[Matthieu Vergne]

Lecture recommandée : The Cambridge Handbook of Expertise and Expert Performance

Quel que soit le domaine, les meilleurs sont ceux qui passent leur temps à s'améliorer. Mais ça c'est pour ceux qui visent le haut du panier. À force de bosser le sujet, même sans l'envie, les habitudes se créent et permettent d'atteindre un niveau relativement moyen, quel que soit le domaine, développement y compris. Seuls les plus motivés peuvent devenir les meilleurs développeurs mais, même s'il est mauvais, un développeur reste un développeur.

Quelle que soit la profession, il n'y a pas de bon s'il n'y a pas de mauvais, donc dire que les "vrai" ce sont les bons, c'est se tirer une balle dans le pieds : une fois ces "mauvais" retirés du panier, quels sont les bons et les mauvais dans ceux qui restent ? Au final, ce genre de raisonnement tend à réduire la notion de développeurs à une peau de chagrin, dont on ne fera bien évidemment pas partie, vu qu'il n'y en a pas beaucoup qui passent toute leur vie à faire uniquement du dév. Choisir à quel niveau s'arrêter pour éviter cette réduction excessive est de l'ordre de l'arbitraire et se résume généralement à dire que ceux qui en font moins que nous même sont de faux dévs, chacun y mettant du sien pour faire valoir sa propre vision comme valeur de référence. Vision parfois même pas mise en pratique, on se met donc dès le départ dehors. Dès lors, quelle est notre légitimité à dire ce qu'est un vrai dév si on n'en est pas un ?

On est tous passé par la case mauvais. Et s'il y en a qui visent le haut du panier, d'autres stagnes, et c'est pas forcément par manque de compétence. De mon point de vue, les mauvais dévs sont ceux qui se croient bon, et les bons dévs sont ceux qui ne veulent pas rester mauvais. Mais ce sont tous des dévs, y'a pas de faux ni de vrai dév dans le panier. Tout le monde peut devenir dév, mais tout le monde ne visera pas le haut du panier. Et c'est pas un mal.

[tomlev]

Ne s'applique pas en France, ici on est sous payé

Faut pas exagérer non plus... Oui, on est (beaucoup) moins bien payé que les développeurs aux États-Unis par exemple. Mais il faut pas oublier qu'on est quand-même largement mieux payés que la moyenne des salariés français...

[Cedvano]

C'est comme savoir conduire, ça ne fais pas de vous un taximan.

[Matthieu Vergne]

Dans ce cas tu commets non pas une mais deux erreurs :

a) Se croire plus compétent qu'on ne l'est != se croire plus compétent plus que les autres != se croire compétent.
b) Une relation de causalité n'implique pas que sa réciproque soit vraie (si être incompétent entraînait à se croire compétent, se croire compétent n'entraînerait pas que l'on soit incompétent).

Disons plutôt que mentionner l'effet est la seule mais grosse bourde que j'ai faite : l'effet en soi concerne la self-évaluation (se situer dans l'ensemble), et non par rapport aux autres (meilleur que X, moins bon que Y), contrairement à ta remarque. J'ai interprété ta remarque dans le premier sens, d'où la boulette.

N'empêche que je ne ferai pas confiance à un dév qui se valorise en disant qu'il est mieux qu'un autre, ne serait-ce que parce qu'on ne sait jamais tout de l'autre. Donc pour moi, se savoir moins mauvais n'est pas un bon argument quand même. {^_^}

[Matthieu Vergne]

Quoi que non, tu as bien dit "les bons dévs sont ceux qui se savent moins mauvais que les autres." et l'effet en question est justement sur ce point : "Alors que les scores les placent dans le 12e centile, ils ont estimé faire partie du 62e." On s'imagine donc bien être dans le top alors qu'on est en bas du panier. Tu m'embrouilles avec tes interprétations, mais ça correspond bien à ce que je voulais dire.

Par ailleurs, je te suis sur ton point b), mais je n'ai pas dit que ceux qui affirmaient ça étaient nécessairement mauvais, mais qu'il fallait s'en méfier. Même si je le justifierait davantage sur le fait que ce n'est pas un bon argument de vente plutôt que sur l'effet en lui-même.

[DonQuiche]

Quoi que non, tu as bien dit "les bons dévs sont ceux qui se savent moins mauvais que les autres." et l'effet en question est justement sur ce point : "Alors que les scores les placent dans le 12e centile, ils ont estimé faire partie du 62e."

Au temps pour moi. Mais encore une fois l'erreur de jugement porte non pas sur la position absolue mais sur l'écart entre la position perçue et la position réelle. Les cancres ne se prennent pas pour des génies et les génies ne se prennent pas pour des cancres. En revanche beaucoup de cancres se prennent pour des types moyens ou au-dessus de la moyenne quand beaucoup de génies se croient simplement bons.

Par ailleurs, je te suis sur ton point b), mais je n'ai pas dit que ceux qui affirmaient ça étaient nécessairement mauvais, mais qu'il fallait s'en méfier.

Pourtant je parie que ceux se déclarant bons sont en moyenne meilleurs que ceux se déclarant mauvais. Encore une fois la plupart des gens n'ont pas une appréciation significativement erronée d'eux-mêmes et savent vers quelle partie du spectre ils tendent.

[DonQuiche]

N'empêche que je ne ferai pas confiance à un dév qui se valorise en disant qu'il est mieux qu'un autre, ne serait-ce que parce qu'on ne sait jamais tout de l'autre. Donc pour moi, se savoir moins mauvais n'est pas un bon argument quand même. {^_^}

Et je pense quant à moi qu'il ne faut pas pousser l'humilité jusqu'à la tartufferie.