Discussion :

[zecreator]

Eh oui, à quoi bon travailler sans passion si ce n'est pour le fric ? ".

Voilà, t'as tout compris. Ta passion, tu la gardes pour toi sur ton temps perso. En entreprise, tu dois avant tout être rentable, sinon tu es vite considéré comme une prise d'eau dans le bateau. Tu dois justifier ton salaire par ton rendement, pas par ta passion.

Quand je vois le turn-over en informatique, où les mecs changent de boite comme ils changent de slip, non, définitivement non, ce n'est pas la passion du job qui les motivent, mais l'appât du gain.

[fredoche]

Il ne faut pas oublier de vivre zecreator, si possible bien, et il faut de l'argent pour cela.
L’appât du gain n'est pas mauvais en soi, c'est une forme de récompense légitime.
Le système est fait comme ça, donc il ne faut pas avoir de scrupules, vos employeurs n'en ont pas. Essayer de trouver les meilleures missions, au meilleur tarif, dans les meilleures conditions.

La passion, ça a été mon drapeau pendant longtemps. Aujourd'hui, cette image du passionné est totalement proscrite. La passion, ça ne marche plus auprès d'un recruteur. Ce qui marche c'est surtout tes succès, les projets que tu as mené à bien, et surtout la rentabilité de retour. Les mecs, ils s'en cognent de savoir que t'es tombé dans la programmation étant petit, que tu développes des jeux ou autres sur ton temps perso. Ils veulent surtout s'assurer que tu vas être rentable, par rapport à l'argent qu'ils vont investir sur toi.

Je me souviens d'un recruteur qui me disait : "La passion c'est vraiment l'argument de vente des mecs qui ne peuvent pas vendre leurs compétences.". Et y a un peu de vrai aujourd'hui...

Les gens qui t'embauchent vendent des compétences, sur catalogue quasiment.

Mais ils investissent peu, le recrutement est leur métier à mi-temps, ces boites recrutent tout le temps, du fait du turn-over notamment.
Ils ne te font pas des ponts d'or, des welcome packages payés cash, ils te placent, tu as 3 mois d'essai renouvelables, tu peux très bien te retrouver seul au milieu de nulle part dans des projets de dingue, à toi de faire tes preuves. sinon ciao suivant (ou autre SSII). Et en général chaque jour presté est rentable.

[Iwoksu]

Bonjour,

Je fait le même constat que vous.

Ayant régulièrement des stagiaires qui veulent devenir développeur professionnel.
En tant que tel, j'estime qu'il doivent avoir un minimum de bagages pour commencer à comprendre le fonctionnement d'un développement logiciel ou système.

Effectivement un développement, ne se résume pas au simple "codage". C'est d'abord une structuration de l'esprit, et un automatisme à avoir. dans cet usage Malheureusement et très souvent, ils n'ont pas acquéri ce dernier qui est la clé pour ouvrir la porte du futur professionnel.

En conséquence, ils connaissent les bases, mais ne savent pas les utiliser. De plus trop attacher au code, ils ne cherchent pas à comprendre ce qu'ils font et pour quoi ils le font.

Effectivement, connaître un langage/méthodes/outils de développement, savoir les utiliser, les comprendre c'est bien et ça demande beaucoup de temps. Mais pas suffisant pour devenir un professionnel. Je recommande souvent de pratiquer, et d'optimiser en permanence, partant de petit projet allant vers de plus en plus gros. (Un échec, n'en est jamais un en développement). Et après une longue pratique nous finissons par maîtriser et être professionnel.

Pour moi, le vrai professionnel de l'informatique doit être capable de changer de langage ou de paradigme de programmation passant de l'embarqué au Web en passant par des applications serveurs. Évidement, selon le contexte les besoins. Il est capable de passer du PHP au JS tout en passant par du Pascal / C / C ++ / LISP / Haskell / Cobol .... Sans bien sûr connaître la sémantique de ces langages par cœur, il faut connaitre leurs structures et philosophies. Et ça demande des années de pratiques. Ajoutons à cela tous les supports système tel que les VMs / Docker et autres jouets.

Et je vois beaucoup de dev. qui se revendique professionnel au lieu de dire spécialiste dans ... Effectivement, en quelques semaines d'apprentissage, nous pouvons dire je suis spécialiste du langage PHP ou MySQL. Voyez la grosse différence, professionnel du dev. et spécialiste dans un langage de développement.

Par contre, les études universitaire ne sont pas nécessaire en soit, mais c'est l'ensemble des outils contenue dans les cours universitaires qu'il le sont. Donc, le mieux c'est d'aller sur le banc des écoles.

En tant qu’autodidacte, j'ai acheté des livres de cours (universitaire), lu des thèses, et suivit des cours universitaires. J'ai donc passer des heures (années) de travailles personnels pour devenir un professionnel de l'informatique.

Loin de tout connaître, je maîtrise énormément d'outils et de technologies car je pratique tous les jours et tout le temps.

cordialement.
Iwoks.

[Marco46]

Effectivement, en quelques semaines d'apprentissage, nous pouvons dire je suis spécialiste du langage PHP ou MySQL.

Euh ... Non même pas. Même ça c'est de l'escroquerie.

[v1cent]

Oui en quelques semaines ont peut juste dire "j'ai appris les bases de PHP / MySQL"

Etre spécialiste PHP par exemple nécessite des années de pratique, moi je code quotidiennement en PHP depuis 5 ans, je suis pas sûr d'être un spécialiste ...

[zecreator]

Faut non plus exagérer. On est développeur, pas chirurgien. Il ne faut pas "des années" pour maîtriser un langage et ses concepts. Pour ma part, j'ai appris PHP, Java et Javascript en quelques mois. Et j'ai été très à l'aise sur les premiers projets que l'on m'a donné. Après, la passion aide beaucoup. Si on ne s'intéresse qu'à moitié au sujet, c'est sûr, ça prend plus de temps.

[Pill_S]

Je ne sais plus qui disait "pour être un spécialiste, quel que soit le domaine, il faut 10'000h de pratique minimum".

A environ 1700h par an + un peu à la maison, il faut facilement 5 ans voir plus. Et encore, le dév ça bouge tellement vite que je n'ai pas compté les heures de remise à niveau...

ça fait maintenant presque 15 ans que je bouffe du Java toute la journée. Est-ce que je suis spécialiste? Peut-être... Est-ce que je sais tout? Alors là, carrément pas et de loin ^^

[Luckyluke34]

Je ne sais plus qui disait "pour être un spécialiste, quel que soit le domaine, il faut 10'000h de pratique minimum".

https://en.wikipedia.org/wiki/Outliers_(book)#Synopsis
https://www.amazon.com/Outliers-Stor.../dp/0316017930

[Marco46]

Faut non plus exagérer. On est développeur, pas chirurgien. Il ne faut pas "des années" pour maîtriser un langage et ses concepts.

Pour ma part, j'ai appris PHP, Java et Javascript en quelques mois.

Ben si. Compétence = connaissance + expérience. Ou en d'autres termes "savoir-faire" = "savoir" et "faire".

Apprendre le langage c'est la partie connaissance. Après il faut passer ça dans une pratique et ça prend du temps.

Pour ton analogie avec le chirurgien c'est comme si tu disais il faut pas 5 ans pour apprendre l'anatomie, à partir du moment où tu sais où est l'appendice tu peux opérer l'appendicite. Ben non.

[Mister Nono]

Faut non plus exagérer. On est développeur, pas chirurgien. Il ne faut pas "des années" pour maîtriser un langage et ses concepts. Pour ma part, j'ai appris PHP, Java et Javascript en quelques mois. Et j'ai été très à l'aise sur les premiers projets que l'on m'a donné. Après, la passion aide beaucoup. Si on ne s'intéresse qu'à moitié au sujet, c'est sûr, ça prend plus de temps.

Tu réagis comme quelqu'un qui ne connait pas grand chose à l'informatique : je te conseille les cours sur l'algorithmie, le génie logiciel, les mathématiques discrètes, etc...

Quand tu auras Bac+5 en informatique, tu comprendras que l'Informatique ce n'est pas apprendre des langages : c'est apprendre à concevoir des Systèmes d'Informations performants, sécurisés, maintenables, etc.

A dans 5 ans...

[Pyramidev]

On est développeur, pas chirurgien.

En informatique, même une formation Bac+5 n'est pas assez complète. On est rarement fort en sortant d'école. Ce n'est pas pour rien que « code de stagiaire » est souvent synonyme de « mauvais code ».

Il ne faut pas "des années" pour maîtriser un langage et ses concepts. Pour ma part, j'ai appris PHP, Java et Javascript en quelques mois.

Avant d'apprendre Java, maîtrisais-tu déjà la programmation orientée objet dans un autre langage statiquement typé ? Si oui, alors tu connaissais déjà les concepts les plus importants du Java avant de commencer à l'apprendre. Or, maîtriser la programmation orientée objet, cela ne se fait pas en seulement quelques mois.

[Jamatronic]

(...) Or, maîtriser la programmation orientée objet, cela ne se fait pas en seulement quelques mois.

Parce que c'est inutilement compliqué ?

[zecreator]

OK, je vais prendre mon exemple : J'ai appris en 3 mois Java et la POO dans le cadre d'une formation DIF à l'Unoiversité de Jussieu Pierre et Marie Curie (Paris). Il y avait un projet à rendre en fin de formation, validé par des pros du secteur. Et bien croyez-le ou pas, j'ai obtenu mon DUT et 6 mois après, j'étais embauché dans une équipe J2EE et j'ai très bien fait le job.

Mais avant cela, j'ai obtenu un BTS IG (option développeur d'application) en VAE, juste sur mes acquis en auto-formation.
Et récemment, pour les besoins d'un projet client, j'ai du apprendre Laravel, j'avais 5 jours. Ben, le projet s'est très bien passé. Le client est ravie.

[zecreator]

En France, on a cette certitude que si on fait une Grande Ecole, et/ou que l'on a plusieurs années d'études, on est forcément au-dessus de la pile, on est l'élite. Le nombre d'années d'études n'a rien à voir avec la capacité à faire les choses et l'intelligence. Une bûche, même après 5 ans d'études, reste une bûche.

[Pyramidev]

Sur quels critères t'es-tu basé pour savoir que tu avais « très bien fait le job » ? Est-ce uniquement par ce que le client était content ou bien aussi parce que toi et/ou tes collègues avaient jugé que ce que le résultat de ton travail allait être facile à maintenir même après que tu sois parti ?

Un jeune programme bien fait, ce n'est pas seulement un programme qui rend content le client à court terme. C'est un programme conçu de telle sorte qu'il sera encore maintenable 20 ans plus tard, à un stade où sa complexité aura tellement augmenté que personne ne connaîtra entièrement ce programme.
À ce moment là, si le programme avait été bien conçu alors, pour modifier son fonctionnement, il ne serait pas difficile d'enquêter sur les impacts que cela aurait avant de commencer à modifier le code et il ne serait pas difficile d'implémenter cette modification sans créer de régressions.

Faire apparaître une nouvelle fonctionnalité sur un programme en début de vie, c'est facile. Pour cela, il n'y a pas besoin d'être expert. Il y a plein de manières d'implémenter la même chose et il suffit presque de choisir la première bêtise qui nous passe par la tête.
Par contre, concevoir un programme maintenable à long terme, c'est dur.

Concernant la POO, à moins d'être un génie, il n'est pas possible d'architecturer correctement le code quand on n'a que quelques mois de pratique.

[zecreator]

Sur quels critères t'es-tu basé pour savoir que tu avais « très bien fait le job » ? Est-ce uniquement par ce que le client était content ou bien aussi parce que toi et/ou tes collègues avaient jugé que ce que le résultat de ton travail allait être facile à maintenir même après que tu sois parti ?

Je bossais sous la validation des développeurs du client. Si comme tu sembles le croire, le code faisait le job mais était pourri à maintenir, je pense qu'ils me l'auraient dit. Vu que c'est un projet qui va être utilisé et maintenu très longtemps.

Un jeune programme bien fait, ce n'est pas seulement un programme qui rend content le client à court terme. C'est un programme conçu de telle sorte qu'il sera encore maintenable 20 ans plus tard, à un stade où sa complexité aura tellement augmenté que personne ne connaîtra entièrement ce programme.
À ce moment là, si le programme avait été bien conçu alors, pour modifier son fonctionnement, il ne serait pas difficile d'enquêter sur les impacts que cela aurait avant de commencer à modifier le code et il ne serait pas difficile d'implémenter cette modification sans créer de régressions.

Faire apparaître une nouvelle fonctionnalité sur un programme en début de vie, c'est facile. Pour cela, il n'y a pas besoin d'être expert. Il y a plein de manières d'implémenter la même chose et il suffit presque de choisir la première bêtise qui nous passe par la tête.
Par contre, concevoir un programme maintenable à long terme, c'est dur.

OK, je te suis, mais je ne comprends pas ce que tu sous-entends ?

Concernant la POO, à moins d'être un génie, il n'est pas possible d'architecturer correctement le code quand on n'a que quelques mois de pratique.

Ben, je dois être un génie alors lol.

Franchement la POO, ça m'a parut presque naturelle. Le concept Objet, l'héritage, les interfaces, l'abstraction, les accès aux attributs d'une classe, les différents constructeurs, c'est pas compliqué à comprendre. Franchement, ça m'a parut assez évident à comprendre. J'ai rapidement pû l'utiliser en Java, PHP, C++, C#... C'est tout de même assez simple une fois que t'as pigé le truc.

Après, je suis passionné à l'extrême par le développement. J'ai une facilité à apprendre dans ce domaine. Et je teste beaucoup de code sur mon temps dispo.

Du coup, j'ai peut-être aucun mérite.

[zecreator]

Et pourquoi cette certitude qu'un développeur autodidacte, qui n'a pas un parcours classique, serait moins bon qu'un développeur sorti d'école d'ingé ? Les ingénieurs n'ont pas le monopole du métier. D'ailleurs, la plupart des ingé que j'ai vu sur le terrain étaient souvent enfermés dans un conformisme. Il n'y avait aucune marge de manœuvre. Dès que ça sortait de ce qu'ils avaient appris en école, c'est très vite compliqué.

[Pyramidev]

Faut non plus exagérer. On est développeur, pas chirurgien. Il ne faut pas "des années" pour maîtriser un langage et ses concepts.

Ben, je dois être un génie alors lol.

Franchement la POO, ça m'a parut presque naturelle. Le concept Objet, l'héritage, les interfaces, l'abstraction, les accès aux attributs d'une classe, les différents constructeurs, c'est pas compliqué à comprendre. Franchement, ça m'a parut assez évident à comprendre. J'ai rapidement pû l'utiliser en Java, PHP, C++, C#... C'est tout de même assez simple une fois que t'as pigé le truc.

Je ne peux pas juger ton cas personnel sans voir ton code. Mais je maintiens qu'une personne normale ne maîtrisera pas la POO en seulement quelques mois.

En POO, ce qui est difficile, ce n'est pas d'apprendre les règles du langage, mais d'architecturer correctement le code. Où faut-il introduire de l'abstraction via un héritage d'interface ? Où faut-il éviter d'ajouter prématurément de l'abstraction ? Si on fait de l'héritage de classe à tel endroit, se tire-t-ton une balle dans le pied pour faire évoluer le code plus tard ? Où faut-il ajouter une couche d'encapsulation ? Comment encapsuler de telle sorte que l'implémentation puisse facilement changer plus tard ?

Si tu regardes comment codent ceux qui ne sont pas encore assez fort en POO, tu verras qu'ils utilisent de l'héritage un peu au hasard et que l'encapsulation n'est pas assez souvent faite correctement.

Et pourquoi cette certitude qu'un développeur autodidacte, qui n'a pas un parcours classique, serait moins bon qu'un développeur sorti d'école d'ingé ?

Ce n'est pas mon opinion, mais peut-être que tu réagissais au message de Mister Nono.

[zecreator]

En POO, ce qui est difficile, ce n'est pas d'apprendre les règles du langage, mais d'architecturer correctement le code.

La POO, c'est 5% d'apprentissage de règles, 10% de syntaxe et 85% de logique. Tu peux avoir pratiqué la POO pendant 20 ans, si tu n'as pas de logique, tu coderas tes architectures n'importe comment. Avoir eu des cours d'algo, de génie logiciel ou toutes autre formes de math ne changera rien. Si tu n'as pas une vision "mécanique" de ton architecture avant même de la développer, c'est mort.

Avant l'arrivée de la POO, tout était une question de logique "mécanique". C'était d'ailleurs LE pramier critère d'embauche avant de connaitre le niveau de programmation : le candidat est-il logique ?

Je ne connais pas trop le contenu des formations en école d'ingé, mais je trouve que beaucoup trop de développeurs sortant de ces formations ont un trop plein de certitudes, que l'on a graver dans leur crâne à l'école. Ils sont enfermés dans des conformismes, des méthodes de développement, ils utilisent tous les mêmes outils et sont souvent incapables de s'adapter rapidement à une situation qui les obligent à travailler autrement.

Après, ils sont formatés pour le marché. En fait, ils sont tous prêt à l'emploi dans les SSII. Il y a d'autres typer d'entreprises qui font du dev informatique, et parfois de manière différente (sans pour autant faire du code pourri et temporaire). Faut pas généraliser et imposer les choses sous prétexte que c'est la seule chose que l'on connaisse.

[v1cent]

Tu dit toi même que tu as validé un diplôme en VAE avec ce que tu as appris avant.

Donc tu n'as pas appris la programmation en 3 mois, tu as appris en 3 mois + tout le temps passé en auto-formation avant où tu as dû quand même apprendre pas mal de choses.
D'ailleurs l'apprentissage est facilité par le fait que tu avais de l'expérience par le passé donc que tu était probablement capable de mettre en application mentalement les concepts dont on te parle au moment où on les explique.

pour le constat sur les écoles d'ingés je suis plutôt d'accord avec toi, sachant que toutes ne sont pas au même niveau évidement ...