Là dessus, vite fait ma vision des choses.
 
Mon métier, c'est pas de coder, c'est de résoudre des problèmes. Que je le résolve en codant en Java, en PL/SQL, en Js ou en changeant complètement une architecture, je m'en fous, au final.  
 
Des gens qui croient être arrivés parce qu'il savent à peu près coder, il y en a beaucoup (je dis à peu près parce que quand je pose des questions sur 'final List machin = new ArrayList()' ou sur le rapport entre Set, equals et hashcode à des dévs expérimentés, le nombre de regards d'incompréhension que j'ai en retour est .. disons surprenant dans le mauvais sens. Et ne va pas croire que ce sont des questions théoriques : le jour où le bug dû à un hashcode instable sur une classe qu'on a collé dans un Set te tombe dessus, 100% des mecs qui ne savent pas ça sont incapables de le résoudre)
 
Des mecs qui ont la curiosité de dépasser le stade du code, et qui se posent des questions (comment ça part en prod? Quelles sont les volumétries? les temps de réponse attendus? Qui va utiliser mon truc? etc..) il y en a déjà beaucoup moins.
 
Et dans ma compréhension de mon métier, les premier ne sont pas beaucoup plus que des ouvriers spécialisés.  
Si la conception se limite à transcrire une spec en algo sans aller plus loin, alors on ne fait pas de conception. On fait de la traduction de spec, et il y a probablement des outils capables de le faire si la spec est exprimée dans le bon langage.
 
Mon expérience (longue) de mon métier de dév/tech lead/architecte (j'ai pas vraiment de nom, et je m'en fous), c'est que beaucoup de dévs se sont fait vendre du rêve en apprenant juste à coder, mais qu'ils n'ont pas compris ou pas envie d'aller plus loin. Et ça pose un énorme problème de qualité de la production.
L'ambiance générale autour de 42 ou des nouveaux programmes de l'éducation nationale accentue encore plus le problème.
 
Tout ça s'est déjà produit à l'époque où j'ai commencé : bulle internet, gros besoin de mecs pour sortir vite fait des sites en "oo", on prend tout ce qui a un vague diplôme en raport avec les maths : chimistes, biologistes, etvc.. ca tombe bien il y a  du chômage partout ailleurs.
Et ça a marché : les mecs ont sorti des trucs. Mais des trucs mal faits.  
 
Bref, n'apprenant rien de nos erreurs, on recommence avec les apps et les startups disruptives mescouilles. On a industrialisé la "formation" des pisseurs de code (42, les nouveaux programmes de l'EN, qui disent très clairement qu'ils apprennent à coder, alors qu'on sait que ça ne suffit pas. Ca veut pas dire qu'aucun mec très bon n'en sortira, mais par contre, ça assure que plein de mauvais en sortiront aussi)
 
Au passage, cette proportion de "codeurs" qui peut monter très haut chez les plus viandards des SSII, corrobore l'idée selon laquelle les dévs seraient interchangeables (parce que les codeurs le sont, pour la plupart)
 
Je persiste, et je pense pas que ceux qui font du recrutement de dévs me contrediront beaucoup : il y a parmi les dévs, énormément de "déchet", et pour moi LE critère principal qui fait que je vais (ou pas) considérer une offre d'emploi, c'est "est-ce que cette boite accepte de prendre ces mecs là? "
 
Dans ma boite actuelle, on les prend pas (du moins on essaie, ça arrive qu'il y en ait qui passent les qualifs sur un malentendu, mais généralement ils finissent pas leur période d'essai)
 
Une fois que tu as fait ce tri là, quelle que soit la techno, les conditions, etc.. aller bosser est tout de suite moins une contrainte. Même avec un client chant.
 
 
 

Fondamentalement tu peux dire ça de n'importe quel boulot cadre, donc oui c'est un métier traditionnel. La question c'est plus si tu veux faire de ta vie ton métier ou pas. Il n'y a rien de mal à l'approcher comme un métier traditionnel et attendre que la veille, les formation, la R&D, … fasse partie du travail payé.
C'est ce que t'as dans un métier cadre classique. Un ingénieur en matériaux, un architecte, un juge, …, sa formation continue et sa recherche fait partie de son travail.
En fait elle est plus là la dichotomie et le manque de clarté dans le domaine, entre l'approche cadre et l'approche ouvrière. On fait très mal la différence entre les deux alors qu'elle est très claire genre dans le bâtiment.

Mouais, je suis pas d'accord avec tout : j'ai longtemps bossé au delà des horaires dans mes premières années.
Mais maintenant, j'ai plus le temps/ l'envie/l'énergie. Et il m'est quasiment impossible de me mettre à une techno sans un vrai projet dans le cadre pro derrière.
Je ne fais pas de veille techno chez moi (mais j'ai la possibilité de passer du temps pro sur des docs pour les AO, par exemple, ou d'échanger avec une communauté identifiée "d'archis" (on a pas d'autre qualificatif, mais ça convient pas vbraiment, o va dire de dévs de plus de 40 ans partageant la vision du métier, quoi)
Du coup, je demande à prendre des projets où je maîtrise pas toute la stack. Quand j'ai la possibilité je monte en compétence sur les bouts qui manquent en amont avec des formation internes, mais sinon, avec l'expérience on arrive quand même à pouvoir très très vite être opérationnel sur 90% de chaque techno (sur mon dernier projet : Ansible, Docker, Openshift et OpenAPI, par exemple)

 
non, mais sur le fond je suis d'accord.  
 
Le problème est en gras : dans beaucoup de boites - la majorité en fait, et surtout dans nos domaines où on a tendance à bombarder CP n'importe quel dév qui a plus de 2 ans d'XP - le management n'est pas bon. PAs sûr de lui. Donc il veut ses mecs près de lui, parce qu'il ne sait pas faire autrement pour exercer son contrôle qu'en les fliquant à vue.
 

A ton âge peut être, quand t'es junior, pour moi c'est inconcevable de pas bosser chez toi si tu veux être bon.

Notre métier évolue quand même beaucoup plus vite que les autres je trouve. Donc tu peux vite te retrouver larguer.
Après j'ai sans doute pas une bonne vision des autres métier.

Je trouve cette affirmation ahurissante. C'est quoi pour toi être "bon"? Etre performant tout de suite sur toutes les technos à la mode, ou avoir une "culture technique" et une adaptabilité suffisante pour devenir performant rapidement? Vu d'ici c'est l'option 2, et ça ne nécessite aucunement de sacrifier ton temps perso pour bosser.

 
A ton âge peut être, quand t'es junior, pour moi c'est inconcevable de pas bosser chez toi si tu veux être bon. Sauf si tu veux rester sur tes acquis que tu as en sortie d'école, c'est à dire rien. Y'a un fossé tellement abyssal entre un profil de passionné et un profil normal...
 
Après ça vient peut être de ma personnalité qui me pousse à toujours vouloir apprendre des trucs.

 
Notre métier évolue quand même beaucoup plus vite que les autres je trouve. Donc tu peux vite te retrouver larguer.
Après j'ai sans doute pas une bonne vision des autres métier.
 
A ton âge peut être, quand t'es junior, pour moi c'est inconcevable de pas bosser chez toi si tu veux être bon. Sauf si tu veux rester sur tes acquis que tu as en sortie d'école, c'est à dire rien. Y'a un fossé tellement abyssal entre un profil de passionné et un profil normal...
 
Après ça vient peut être de ma personnalité qui me pousse à toujours vouloir apprendre des trucs.

 
Je suis d'accord, le problème est très rarement lié aux employés et presque toujours aux managers. Un mauvais employé qui n'a rien à faire là mais qui reste quand même, c'est clairement la faute du manager qui soit n'est pas capable de l'identifier, soit n'a pas les couilles ou n'a pas le pouvoir de le virer.
Et pour les bons employés qui font de la merde, c'est encore et toujours un problème de management qui n'est pas capable de contrôler correctement le boulot des employés et/ou de donner les bonnes conditions de travail aux employés.
 
C'est quasi toujours un problème de management.

 
Ca c'est autre chose...tu fais du dev chez toi comme d'autres se fabriquent un établi ou font de la pâtisserie...c'est juste plus facilement transposable vers ton activité professionnelle.

 
A ton âge peut être, quand t'es junior, pour moi c'est inconcevable de pas bosser chez toi si tu veux être bon. Sauf si tu veux rester sur tes acquis que tu as en sortie d'école, c'est à dire rien. Y'a un fossé tellement abyssal entre un profil de passionné et un profil normal...
 
Après ça vient peut être de ma personnalité qui me pousse à toujours vouloir apprendre des trucs.

 
Je trouve cette affirmation ahurissante. C'est quoi pour toi être "bon"? Etre performant tout de suite sur toutes les technos à la mode, ou avoir une "culture technique" et une adaptabilité suffisante pour devenir performant rapidement? Vu d'ici c'est l'option 2, et ça ne nécessite aucunement de sacrifier ton temps perso pour bosser.

 
Je trouve cette affirmation ahurissante. C'est quoi pour toi être "bon"? Etre performant tout de suite sur toutes les technos à la mode, ou avoir une "culture technique" et une adaptabilité suffisante pour devenir performant rapidement? Vu d'ici c'est l'option 2, et ça ne nécessite aucunement de sacrifier ton temps perso pour bosser.

Du coup, où j'en serai dans 10 ans ... ? Complètement dépassé ?
 
Je gagne super bien ma vie aujourd'hui, et pourtant je n'arrive pas être serein quant à l'avenir, parce que j'ai toujours cette impression que "ça ne durera pas".

- objectivement on est plus productif à la maison, simplement parce que ça minimise les chances d'interruption. C'est un sujet très bien documenté, et c'est particulièrement vrai pour les taches qui demandent un effort intellectuel continu, ie être "dans la zone": coder bien sur, mais aussi faire un budget, bosser sur des slides, etc...

C'est ce qui m'inquiète dans le dev (ça doit être le cas dans d'autres métiers aussi), c'est que ça mute constamment (parce qu'à ce stade, je préfère parler de mutation plutôt que d'évolution), et je sens bien que plus le temps passe, plus je "fatigue".

Du coup, où j'en serai dans 10 ans ... ? Complètement dépassé ?

Je gagne super bien ma vie aujourd'hui, et pourtant je n'arrive pas être serein quant à l'avenir, parce que j'ai toujours cette impression que "ça ne durera pas".

Franchement, je crois pas. Tu as énormément d'opportunités pour apprendre au boulot. Perso j'ai eu mon premier môme en étant encore à l'école alors j'aime autant te dire que bosser chez moi ça a jamais vraiment été une option. Alors c'est sûr mon passage à l'université m'a aidé pour prendre le temps d'apprendre des trucs un peu orthogonaux à ma mission principale, mais ça m'a essentiellement servi à rattraper mon retard d'éducation (et quand tu dis que c'est rien, tu te gourres profondément). Le métier on peut très bien l'apprendre directement en faisant semblant qu'on sait ce qu'on fait. Dans un environnement sain, on a des mentors qui nous montrent nos conneries à temps et des barrière qui nous empêchent de foutre par terre le serveur de prod, et on peut faire ses erreurs en faisant son travail, sans avoir à faire des projets persos.
 
Maintenant, je veux pas dénigrer tes efforts, si tu bosses 2 fois plus tu progresses aussi plus vite. Perso je m'en fous, j'ai le temps.

je suis moyennement d'accord, pour 2 raisons :  
 
- on est pas obligé de TOUT apprendre : t'es pas obligé de faire tous les framework JS les un après les autres, je pense que beaucoup de devs gagneraient à mieux choisir leur batailles : tu peux pas être fluent en JS/HTML/CSS/Python/Java/Kotlin/C++/Go/Rust avec toutes les libs majeures de chaque language...et si tu peux, est-ce que ça vaut l'effort investi ?
- je reconnais qu'en info tout change souvent (serveur, outils, languages), mais au final pas tant que ça : si t'as investi sur le java par ex, et que t'as débuté en 2005, le language a évoué certes, mais ça reste rattrapable sans devoir perdre ta vie sociale, surtout que ça a pris 14 ans pour évoluer. Idem Python, si t'as commencé en Py2, tu peux passer à Py3 en un mois ou deux
- les autres jobs aussi se font disrupter, principalement à cause de l'informatique d'ailleurs. Je bosse proche du marketing, y'a encore 15 ans fallait connaitre tes segments télé, 2-3 règles de mises en page, et savoir leader un meeting de 3h pour le choix d'un pantone et t'étais le roi du pétrole. En 10 ans il faut connaitre tous les formats de pub numériques, les billing models (CPM, CPC, CPA et savoir décider lequel optimiser), faut être bon en data, comprendre les flux de données clients, comprendre les identités numériques (cookies, fingerprint, etc...)...je peux te dire que ça leur décole la pulpe du fond
 
 
c'est un problème intéressant, ma position a beaucoup évoluée sur le sujet avec l'expérience.
Au début j'étais assez partisan d'avoir les gens sous la main : facilité de communication, tu peux voir si les gens "branlent rien" plus facilement (meme après plus de 10 ans d'expérience dans le management, je persiste à trouver que mesurer la charge réelle d'une personne est un problème compliqué : y'a des gens qui se noient dans rien, d'autres qui font stoïquement le boulot de 3 personnes avant de gentiment faire un burnout au bout de 5 ans, sans que personne n'ait rien vu venir, etc...)
 
Mais avec le temps, je me rends compte que le boulot à distance, c'est bien :  
- laisser passer l'idée que peut être j'aurais pu obtenir plus de la personne en lui donnant plus de chose, mais peut etre pas...et que j'en saurais jamais rien. Au final tu peux benchmarker les gens par rapport à leurs livrables, le présentiel n'est pas un indicateur pertinent. Un gars de mon équipe m'a appris ça : il était clairement celui qui passait le moins de temps au taf. Il faisait 8h-17h tous les jours (alors qu'on bossait comme des cons jusqu'à pas d'heures). Au début ça m'a gonflé, et en fait ce type était une putain de machine : il faisait en 8h ce qu'on faisait en 12, avec une super qualité. J'ai jamais rien eu à lui reprocher, au contraire.
- de toute façon je bosse en équipe distribuée, donc j'ai JAMAIS la possibilité d'avoir tout le monde sous la main. Et au final, manager John dans le bureau de NY, ou manager Jean-Luis qui bosse en slip (mais avec un t-shirt pour que les VC restent dignes) depuis chez lui, ça fait aucune différence.
- ça oblige à manager au résultat, et pas à l'approche : fixer un objectif, négocier ensemble une deadline. Après tu te démerdes, tu veux bosser la nuit ? bosse la nuit, je m'en fou tant que le boulot est fait. Tu veux ne pas bosser de 16h à 19h pou t'occuper de tes gosses et bosser tranquilou après. Vas-y.
- objectivement on est plus productif à la maison, simplement parce que ça minimise les chances d'interruption. C'est un sujet très bien documenté, et c'est particulièrement vrai pour les taches qui demandent un effort intellectuel continu, ie être "dans la zone": coder bien sur, mais aussi faire un budget, bosser sur des slides, etc...

 
Tiens c'est marrant, Angular c'est pas un truc super hype vachement mieux que tout le reste et qui enterre les vieilles technos?

 
 
Personne me fera croire ici qu'entre un profil qui sort d'école, et le même, mais qui a fait mass veille ou projet persos, vous allez prendre le premier. On parle de deux profils équivalent en personnalité (pas de meilleur feeling ou autre).
 
 

 
Sur un type sortant d'école oui, sur un mec qui a >5 ans d'XP je m'en fout un peu qu'il ait des projets persos...

 
Là dessus, vite fait ma vision des choses.
 
Mon métier, c'est pas de coder, c'est de résoudre des problèmes. Que je le résolve en codant en Java, en PL/SQL, en Js ou en changeant complètement une architecture, je m'en fous, au final.  
 
Des gens qui croient être arrivés parce qu'il savent à peu près coder, il y en a beaucoup (je dis à peu près parce que quand je pose des questions sur 'final List machin = new ArrayList()' ou sur le rapport entre Set, equals et hashcode à des dévs expérimentés, le nombre de regards d'incompréhension que j'ai en retour est .. disons surprenant dans le mauvais sens. Et ne va pas croire que ce sont des questions théoriques : le jour où le bug dû à un hashcode instable sur une classe qu'on a collé dans un Set te tombe dessus, 100% des mecs qui ne savent pas ça sont incapables de le résoudre)
 
Des mecs qui ont la curiosité de dépasser le stade du code, et qui se posent des questions (comment ça part en prod? Quelles sont les volumétries? les temps de réponse attendus? Qui va utiliser mon truc? etc..) il y en a déjà beaucoup moins.
 
Et dans ma compréhension de mon métier, les premier ne sont pas beaucoup plus que des ouvriers spécialisés.  
Si la conception se limite à transcrire une spec en algo sans aller plus loin, alors on ne fait pas de conception. On fait de la traduction de spec, et il y a probablement des outils capables de le faire si la spec est exprimée dans le bon langage.
 
Mon expérience (longue) de mon métier de dév/tech lead/architecte (j'ai pas vraiment de nom, et je m'en fous), c'est que beaucoup de dévs se sont fait vendre du rêve en apprenant juste à coder, mais qu'ils n'ont pas compris ou pas envie d'aller plus loin. Et ça pose un énorme problème de qualité de la production.
L'ambiance générale autour de 42 ou des nouveaux programmes de l'éducation nationale accentue encore plus le problème.
 
Tout ça s'est déjà produit à l'époque où j'ai commencé : bulle internet, gros besoin de mecs pour sortir vite fait des sites en "oo", on prend tout ce qui a un vague diplôme en raport avec les maths : chimistes, biologistes, etvc.. ca tombe bien il y a  du chômage partout ailleurs.
Et ça a marché : les mecs ont sorti des trucs. Mais des trucs mal faits.  
 
Bref, n'apprenant rien de nos erreurs, on recommence avec les apps et les startups disruptives mescouilles. On a industrialisé la "formation" des pisseurs de code (42, les nouveaux programmes de l'EN, qui disent très clairement qu'ils apprennent à coder, alors qu'on sait que ça ne suffit pas. Ca veut pas dire qu'aucun mec très bon n'en sortira, mais par contre, ça assure que plein de mauvais en sortiront aussi)
 
Au passage, cette proportion de "codeurs" qui peut monter très haut chez les plus viandards des SSII, corrobore l'idée selon laquelle les dévs seraient interchangeables (parce que les codeurs le sont, pour la plupart)
 
Je persiste, et je pense pas que ceux qui font du recrutement de dévs me contrediront beaucoup : il y a parmi les dévs, énormément de "déchet", et pour moi LE critère principal qui fait que je vais (ou pas) considérer une offre d'emploi, c'est "est-ce que cette boite accepte de prendre ces mecs là? "
 
Dans ma boite actuelle, on les prend pas (du moins on essaie, ça arrive qu'il y en ait qui passent les qualifs sur un malentendu, mais généralement ils finissent pas leur période d'essai)
 
Une fois que tu as fait ce tri là, quelle que soit la techno, les conditions, etc.. aller bosser est tout de suite moins une contrainte. Même avec un client chant.
 
 
 

Personne me fera croire ici qu'entre un profil qui sort d'école, et le même, mais qui a fait mass veille ou projet persos, vous allez prendre le premier.  

Personne me fera croire ici qu'entre un profil qui sort d'école, et le même, mais qui a fait mass veille ou projet persos, vous allez prendre le premier. On parle de deux profils équivalent en personnalité (pas de meilleur feeling ou autre).
C'est bien que c'est utile de voir ou bosser d'autres trucs, ne serait-ce que pour comprendre des trucs, surtout quand tu débutes.

En sortie d'école, effectivement celui qui fait beaucoup de veille et de projets persos a de bonnes chances d'être aussi celui qui s'adaptera plus facilement par le simple fait d'avoir vu/testé des manières différentes de résoudre un problème via des technos variées - et éviter de rester bloqué sur les 2/3 technos ou méthodes vues en cours...mais pas nécessairement.

Et après quelques années j'aurais même tendance à me méfier un poil des mecs qui font beaucoup de projets perso - certains s'enferment dans les technos qui leur plaisent et ont beaucoup de mal à envisager les problèmes sous un angle différent, au final - alors que dans le bureau voisin j'ai l'exemple parfait du mec qui s'est retrouvé du jour au lendemain à devoir bosser sur des technos qu'il n'avait jamais touchées et abandonner totalement celles qu'il avait toujours pratiquées, et qui était raisonnablement opérationnel en quelques semaines...

https://www.lesechos.fr/pme-regions [...] on-1013629
 

 
Globalement oui, sur un projet perso autant prendre quelque chose de récent, et quand on est junior c'est un bon moyen de sortir du lot.
Par contre l'objectif primordial c'est de s'appuyer dessus pour très rapidement ne plus faire que des missions intéressantes où t'as des choses pertinentes à apprendre et où tu as des choses "bankable" à apprendre. Passé un certain cap dans une carrière, c'est plus absolument indispensable, ton expérience peut parler pour toi : je viens de débarquer dans une mission où y'a du docker, du kubernetes et bientôt du kafka, j'ai 0 expérience dans ces technos là, mais je sais que je peux monter en compétences dessus rapidement.
 
Le truc primordial à comprendre, c'est qu'à l'échelle de toute une carrière, bosser chez soi en extra pour faire de la veille ne doit pas être nécessaire au métier de développeur.
Si c'est ta passion et que tu t'éclates à le faire, fais-le évidemment. Mais j'ai énormément de mal avec une conception de notre métier qui valorise le mélange travail/vie privée. Ce n'est pas sain.

 
La nécessité d'en faire ça concerne vraiment le tout début de carrière quand tu dois prouver des choses concrètes à des recruteurs potentiels, ensuite ton parcours parle pour toi.
 
 

 
Sauf que pour être en position de force il faut des missions intéressantes. C'est là le hic en fait.

https://www.lesechos.fr/pme-regions [...] on-1013629
 

Autoriser un mec qui a 1 an d'XP, qui est encore en période d'essai ou pas loin, et qui procrastine régulièrement à regarder des vidéos sur YT à faire du remote, même si le mec reste efficace au global, c'est un risque.
Tant que t'as pas gagné la confiance, c'est pas choquant qu'on te l'accorde pas (ce veut pas dire qu'il y a pas des cas où il y a des blocages)

Là dessus, vite fait ma vision des choses.
 
Mon métier, c'est pas de coder, c'est de résoudre des problèmes. Que je le résolve en codant en Java, en PL/SQL, en Js ou en changeant complètement une architecture, je m'en fous, au final.  
 
Des gens qui croient être arrivés parce qu'il savent à peu près coder, il y en a beaucoup (je dis à peu près parce que quand je pose des questions sur 'final List machin = new ArrayList()' ou sur le rapport entre Set, equals et hashcode à des dévs expérimentés, le nombre de regards d'incompréhension que j'ai en retour est .. disons surprenant dans le mauvais sens. Et ne va pas croire que ce sont des questions théoriques : le jour où le bug dû à un hashcode instable sur une classe qu'on a collé dans un Set te tombe dessus, 100% des mecs qui ne savent pas ça sont incapables de le résoudre)
 
Des mecs qui ont la curiosité de dépasser le stade du code, et qui se posent des questions (comment ça part en prod? Quelles sont les volumétries? les temps de réponse attendus? Qui va utiliser mon truc? etc..) il y en a déjà beaucoup moins.
 
Et dans ma compréhension de mon métier, les premier ne sont pas beaucoup plus que des ouvriers spécialisés.  
Si la conception se limite à transcrire une spec en algo sans aller plus loin, alors on ne fait pas de conception. On fait de la traduction de spec, et il y a probablement des outils capables de le faire si la spec est exprimée dans le bon langage.
 
Mon expérience (longue) de mon métier de dév/tech lead/architecte (j'ai pas vraiment de nom, et je m'en fous), c'est que beaucoup de dévs se sont fait vendre du rêve en apprenant juste à coder, mais qu'ils n'ont pas compris ou pas envie d'aller plus loin. Et ça pose un énorme problème de qualité de la production.
L'ambiance générale autour de 42 ou des nouveaux programmes de l'éducation nationale accentue encore plus le problème.
 
Tout ça s'est déjà produit à l'époque où j'ai commencé : bulle internet, gros besoin de mecs pour sortir vite fait des sites en "oo", on prend tout ce qui a un vague diplôme en raport avec les maths : chimistes, biologistes, etvc.. ca tombe bien il y a  du chômage partout ailleurs.
Et ça a marché : les mecs ont sorti des trucs. Mais des trucs mal faits.  
 
Bref, n'apprenant rien de nos erreurs, on recommence avec les apps et les startups disruptives mescouilles. On a industrialisé la "formation" des pisseurs de code (42, les nouveaux programmes de l'EN, qui disent très clairement qu'ils apprennent à coder, alors qu'on sait que ça ne suffit pas. Ca veut pas dire qu'aucun mec très bon n'en sortira, mais par contre, ça assure que plein de mauvais en sortiront aussi)
 
Au passage, cette proportion de "codeurs" qui peut monter très haut chez les plus viandards des SSII, corrobore l'idée selon laquelle les dévs seraient interchangeables (parce que les codeurs le sont, pour la plupart)
 
Je persiste, et je pense pas que ceux qui font du recrutement de dévs me contrediront beaucoup : il y a parmi les dévs, énormément de "déchet", et pour moi LE critère principal qui fait que je vais (ou pas) considérer une offre d'emploi, c'est "est-ce que cette boite accepte de prendre ces mecs là? "
 
Dans ma boite actuelle, on les prend pas (du moins on essaie, ça arrive qu'il y en ait qui passent les qualifs sur un malentendu, mais généralement ils finissent pas leur période d'essai)
 
Une fois que tu as fait ce tri là, quelle que soit la techno, les conditions, etc.. aller bosser est tout de suite moins une contrainte. Même avec un client chant.

 
Tellement vrai.
 
En fait, j'ai l'impression que beaucoup de devs voient juste ça comme un métier traditionnel. En gros, tu fais tes 9h-18h et c'est tout.  
J'ai beaucoup d'amis dev, ou qui se sont reconverti, donc des profils juniors. Absolument aucun fait de la vieille chez lui. Ils rentrent et jouent. Alors, c'est normal aussi hein, je dis pas qu'il faille bosser h24, mais perso j'arrive pas à me dire que mon métier s'arrête à ces horaires là.  
 
Y'a tellement de truc à savoir, de lacunes, nouveaux langages/framework/outils ou autre cool à tester.
 
Et pour avoir fait quelques boites et SSII, je pense que ça rejoins le point 2. Tu as des mecs qui sont pas fait pour être dev. Suffit pas d'apprendre un métier et de le répéter pour être bon. Y'a une réflexion dans notre métier et surtout une logique à avoir. Du coup, entre les mecs qui bossent beaucoup et évoluent et ceux qui font juste 'du code', y'a un fossé qui se creuse de plus en plus au fil du temps.
 
Typiquement mon ancienne boite, les devs "expérimentés" était limite aussi bon que les juniors, ça donnait pas envie de venir travailler.

 
Notre métier évolue quand même beaucoup plus vite que les autres je trouve. Donc tu peux vite te retrouver larguer.
Après j'ai sans doute pas une bonne vision des autres métier.
 
A ton âge peut être, quand t'es junior, pour moi c'est inconcevable de pas bosser chez toi si tu veux être bon. Sauf si tu veux rester sur tes acquis que tu as en sortie d'école, c'est à dire rien. Y'a un fossé tellement abyssal entre un profil de passionné et un profil normal...
 
Après ça vient peut être de ma personnalité qui me pousse à toujours vouloir apprendre des trucs.

Ca, je pense que je comprendrais pas
Les projets perso que j'ai toujours fait (j'en fais encore de temps en temps), je me tape de la techno car le but c'est de répondre à un besoin fonctionnel (dans mon cas). Donc je fais au plus efficace. Et j'ai pas du tout besoin des dernières technos pour ça, au contraire.

 
Oui option 2. On a juste pas le même niveau d'exigence.  
 
Personne me fera croire ici qu'entre un profil qui sort d'école, et le même, mais qui a fait mass veille ou projet persos, vous allez prendre le premier. On parle de deux profils équivalent en personnalité (pas de meilleur feeling ou autre).
C'est bien que c'est utile de voir ou bosser d'autres trucs, ne serait-ce que pour comprendre des trucs, surtout quand tu débutes.
 
Dans mon ancienne boite, mon CTO ne fait pas de veille car enfant, famille en dehors et plus l'envie et j'ai aucun soucis avec ça. Mais première chose, le taff permettait de faire de la veille sur notre temps travaillé, et c'était même vivement recommandé + organisation de workshop/talk. Et deuxièmement, c'est pas un débutant. Il a un background, il sait de quoi il parle.
 
C'est exactement ce que je fais, projet perso, et pour d'autres clients en AE.

 
Ah mais j'ai aucun soucis avec ça. Et je dis pas ça pour être le meilleur ou autre. Je bosse pour moi, parce que j'ai envie d'apprendre plein de trucs. Que ça me serve ou pas.  
J'ai fais des stages et un cursus en ingénierie réseau, juste pour savoir comment ça fonctionnait, pas du tout pour en faire mon métier. Ça m'a juste permis de valider une double compétence.
 
Après vous avez peut-être eu de bonne boite. Mais mes premières expériences, j'avais pas de mentors, et je devais gérer des stacks seul, pas de temps pour faire de la veille, et sur de technos qui me serviront jamais. Sauf pour la culture dev en général.
Donc pour moi c'était nécessaire de bosser chez moi pour faire ce que j'avais envie de faire et apprendre.

Je suis absolument d'accord. J'ai jamais dit qu'il fallait tout savoir.  
Je dis juste que pour moi, un junior, au moins les deux premières années, doit faire de la veille pour avoir un niveau acceptable.  
Y'a bien entendu des exceptions. Que ce soit au point de vu profil, ou même carrément entreprise qui permettent de te faire monter en compétence très vite. Ça n'a pas été mon cas.
 
Quand je vois le niveau des devs chez PlamCorp, je me dis qu'heureusement que j'ai bossé un minimum car je serais complètement larguer sinon... Ou alors j'suis ptete juste nul et donc j'dois bosser deux fois plus qu'un dev normal.    

mais tu es en position de force ? tu es sur un marché de plein emploi, où les gens se battent pour trouver des devs.
Fais pas ton Harko, t'es pas obligé de rester dans une mission de merde. Prospecte, renseigne-toi, et trouve un truc où tu vas apprendre des choses.

 
Pour prendre un exemple tout con, si j'attends d'être en mission pour expérimenter avec Java 9+, je peux attendre longtemps.