Discussion :

[Arsene Newman]

Même à l’heure du numérique les développeurs sont encore mal considérés par les entreprises
c’est l’avis d’un développeur logiciel

Même si le niveau de vie des développeurs est en perpétuelle amélioration et que leur salaire atteint une moyenne de 85.000 $ à San Francisco, les développeurs ne devraient pas se laisser aller, il est grand temps de réclamer plus de considérations, eux qui sont opprimés et méprisés par la classe dirigeante ! Voilà donc l’avis bien tranché de Michael O.Church, développeur logiciel basé à New York.

Preuve de cette réalité amère, Church revient sur l’histoire d’un ingénieur logiciel prénommé Bill, ce dernier va candidater pour deux postes différents « Ingénieur logiciel sénior » et « VP of Data Science ».

Sa candidature au poste technique d’ingénieur logiciel fait face à 5 entretiens techniques exténuants, dont le dernier se solde par un refus arbitraire. A contrario, lorsque Bill se présente pour le poste de « VP of Data Science » qui est un poste de gestionnaire, les choses se passent beaucoup mieux, Bill peut se lâcher plus et présenter ses différents points de vue et se voit finalement proposer une bonne offre.

Une analyse plus approfondie des candidatures de Bill révèle une certaine réalité selon Church : « En tant que candidat à un poste de gestionnaire, le président s’est entretenu avec Bill d’égal à égal et non pas de manière paternaliste, allant même à émettre certains conseils comme « Ceci est bon pour votre carrière ». Il y avait un ton d’égalité qu’un ingénieur logiciel ne pourra jamais avoir avec le président d’une entreprise IT de 100 personnes. »

Alors pourquoi une telle différence ? L’auteur rappelle en premier lieu que cette situation ne se retrouve pas chez certaines entreprises très centrées sur les développeurs comme Google ou Facebook.

Toutefois, d’autres entreprises tendent à considérer les développeurs comme des savants idiots cantonnés à leur monde technique, incapables de prendre des décisions importantes impactant l’entreprise, ce qui donne lieu à la mauvaise considération des développeurs et à la non-prise en compte de leurs opinions, par les cadres décideurs.

Mais, ces derniers devraient savoir que le développeur est lui aussi un décideur, décideur à l’échelle microscopique et non pas macroscopique, en répondant à différentes considérations techniques impactant directement le logiciel produit et donc les résultats de l’entreprise.

Alors, ne serait-il pas le temps de montrer plus de considérations vis-à-vis des développeurs ? Cela est déjà le cas pour la plupart des entreprises opérant dans le secteur du logiciel et de l’IT, mais beaucoup moins dans les secteurs non-IT, où les développeurs ne sont pas compris et sont considérés comme une main d’œuvre de bas étage.

Source : Blog de Michael O Church

Et vous ?
Qu’en pensez-vous ?

[deusyss]

Je suis assez d'accord avec cette analyse.

Elle m'a fait penser à une présentation qui existe sur les SSII qui caricature assez bien, ce que beaucoup vivent: le celebre en c u lator (desole pour le politiquement correct, mais c'est le nom du fichier).

Concernant l'entretien d'embauche justement, combien d 'entre nous ont eu droit au tests de logiques? Ou encore aux questions bidons? Pire encore, et là je me "gauss" (, désolé, pas pu m'en empecher): les lettres de motivations. Les cours et théorie sur ce sujet sont tellement semblable que je n'en voit pas du tout l'utilité.

Un bon entretien en direct avec un réel dialogue, et pas de questions/reponses bateaux, vaut bien plus, parce qu'alors on a un reel aperçu des candidats. C'est même d'ailleurs souvent là qu'on se rend compte qu'une partie des meilleurs candidats auraient été rejetés par le systeme classique, car pas les bons diplômes, ou les bonnes references. Mais pourtant leur feux sacrés font une sacré différence, car ce qui fait la personne ce ne sont pas ses diplômes, mais ses capacités. Et ce sont justement ces capacités qui feront la différences dans un travail.

La vie en SSII semble malheureusement souvent ressembler à:
01-Tres gentil, y compris à l'entretien d'embauche car on a besoin de toi
02-Le taf commence bien, mais l'ambiance se dégrade peu à peu.
03-La boite va mal, donc comme on a plus besoin de toi, dehors

Et à l'heure d'aujourd'hui, les devs semblent malheureusement être considérés comme du jetable, du simple consommable. Mais quand ceux ci se réveilleront, cela va faire mal aux directions. Car ils se rendront compte alors que ce sont les devs qui les font vivre et pas l'inverse.

[Sodium]

Les dirigeants ne peuvent souvent pas se représenter ce qu'est le travail d'un développeur. Dans le cas d'un graphiste par exemple, le chef de projet est incapable de faire le même boulot mais ce qu'il voit est concret, il peut se faire une image du processus de fabrication. Je me rappelle d'un patron qui passe derrière moi, voit des lignes de code et me sort "Ah bon, c'est comme ça qu'on fait un site web ? Mais comment tu changes la couleur du texte ??"

[bruneltouopi]

Cela reflète justement la pure réalité de la vie sociale de l'entreprise.Depuis le temps de l'industrialisation on néglige les ouvriers mais ce sont eux qui monte la construction.Les développeurs sont souvent marginalisés en tant que tacherons et sont en dessous de l'echelle de décision."On veut faire ceci et on a besoin de cela à tel date".Malheureusement c'est ce contraste qui fait à ce que les développeurs deviennent plus tard des managers et quittent peu à peu le code au fil des années dans leur carrière.Mais je pense que la considération des développeurs n'est qu'une question de temps car au vu de la numérisation de tous les services mondiaux ils seront dans le Top 2 des décisions managériales;Je n'en doutes pas une seule seconde

[pmithrandir]

J'en pense plusieurs choses...
Déjà que de généraliser 2 entretiens ne fait pas un exemple.
De plus que le biais personnel est bien trop important, et enfin que les positions étant totalement différentes, il avait peut être le profil requis pour l'un des postes plus que pour l'autre.

Après, sans cet exemple assez maladroit, je pense que les développeurs sont en train de passer d'un stade de cout a un stade ou l'on commence a comprendre qu'ils sont des vrais créateurs de valeur ajoutée.

Pour faire simple, le développement est le métier qui doit avoir le plus fort potentiel de création de VA en avec des coef multiplicateur par rapport au salaire qui frise les milliers, voir millions dans certains cas.
Si l'on enlève les SSII qui ne sont ni plus ni moins que des agence d'interim, donc sans vision a long terme dans une entreprise et que l'on se concentre sur les salariés, on s’aperçoit vite que par la mise en place d'une bonne idée, on peut pour des couts parfois très faible générer beaucoup de revenus ou d'économies. Le tout sans couter plus d'argent à son employeur.

Les entreprises sont pour moi en train de comprendre cet aspect des choses, et par exemple le fait que finalement, un bon dev qui coute 20% de plus pourra générer 200% de plus en valeur ajoutée.
Ce n'est peut être pas encore le cas en France ou assez visible, mais dans pas mal de pays, la guerre pour recruter les bons est lancée et elle est sanglante entre les sociétés.

Par ailleurs, conséquence de cette prise de conscience, les développeurs passent de charge a atouts pour la boite, et on a tendance a vouloir les internaliser... ce qui signerait le glas de pas mal de SSII.
Mais j'admets que cet aspect des choses est juste au stade de démarrage, et je ne pense pas qu'il soit visible de manière généralisée.

Pour revenir a l'exemple, j'ai eu l'occasion de me présenter en tant qu'employé et que contractuel. Et bien en tant qu'employé je vouvoyait mon patron et réciproquement alors qu'en tant que contractuel, donc en tant que patron, nous nous tutoyons naturellement. Le statut m'avait immédiatement donné une légitimité a ses yeux, et un point commun.

[tiresias54]

Il faut s'y faire: la classe ouvrière étant en voie de disparition, les devs sont les futurs prolos.

[Kihmé Xs]

Développeur, couturière, tourneur-fraiseur etc...

Ah un moment, il faudrait que l'on arrête de se voir plus beau que l'on est, sous prétexte que l'on travaille sur un ordinateur.

Franchement, je ne comprends pas ces pleurnicheries. Si vous en voulez plus, créez vos entreprises les copains.

[Darkzinus]

Développeur, couturière, tourneur-fraiseur etc...

Ah un moment, il faudrait que l'on arrête de se voir plus beau que l'on est, sous prétexte que l'on travaille sur un ordinateur.

Franchement, je ne comprends pas ces pleurnicheries. Si vous en voulez plus, créez vos entreprises les copains.

Je suis totalement d'accord. On a parfois l'impression que chacun derrière ce forum est un génie qui n'est pas reconnu à sa juste valeur ... Dans les valeurs notre métier n'est pas plus noble qu'un autre. De plus, notre secteur n'est pas le plus à plaindre quand même ...

[Saverok]

L'avis de ce blogueur est beaucoup trop tranché
Je partage son avis dans les grandes lignes mais avec nettement plus de nuance et moins d’agressivité et de désabusement

Le travail du développeur est très abstrait.
Nous travaillons dans le "virtuel"
Les dirigeants sont des gestionnaires et ne connaissent rien à la technique, c'est pourquoi ils ont besoin de se raccrocher à des points de repaires : les diplômes et certifications
Car sans cela, ils sont incapable d'évaluer les compétences d'un technicien
Mettre le développeur à l'essai serait une solution mais irréalisable en pratique car impossible de prendre à l'essai tous les candidats
Il faut bien qu'une sélection se fasse

Le grand tort de la plupart des développeurs est de croire que seules les compétences comptent
Le savoir être et aussi important, voir plus, que le savoir faire
Nous sommes des VRP
Nous devons savoir nous vendre et vulgariser notre métier aux "non initiés"

Quelque soit les métiers (techniques ou non), les personnes qui réussissent le mieux sont rarement les plus doués ou les plus qualifiés, mais ceux avec le plus de "bagou", le meilleurs feeling au premier contact
De très nombreux développeurs se permettent de venir au travail avec des looks et coupes de cheveux inconcevables dans les autres corps de métiers.
L'image que l'on revoit de notre personne à une incidence directe sur l'image de notre travail.
Même si c'est con et discriminatoire : bien présenter son travail (et donc sa personne) est plus important que bien savoir faire (dans la technique, rare sont les décisionnaires qui font la différence entre le "juste fait bancale" et le "bien fait")

Quand je parle de mon métier à mon entourage, je n'utilise aucun terme technique
Des mots aussi simples et génériques (pour nous) tels que Java, script ou processus ne sont jamais prononcés.
Je concentre mon discours sur les applications de mon travail.
Et plus le temps passe, et plus je fais de même en entretien d'embauche
Les responsables RH ont une liste de techno recherchées et son satisfait de retrouver les mêmes termes sur mon CV, ça les rassure et permet de passer le premier volet de sélection. En entretien, je ne parle que des domaines métiers des différents projets auxquels j'ai participé.
Car après tout, nous sommes au services du métier des entreprises, et non l'inverse.

Il nous paraîtrait complètement absurde qu'un électricien qui intervient dans un restaurant se permette de donner des conseils de cuisine au chef.
Et il paraît normal à tout le monde que le propriétaire de ce restaurant ne lui demande pas son avis sur la carte.
Par contre, l'avis du technicien sur comment réduire la consommation électrique de l'établissement est apprécié et recherché.
Pourquoi cela serait il différent pour un développeur ?

[Njörd]

Bonjour,

Car après tout, nous sommes au services du métier des entreprises, et non l'inverse.

Il nous paraîtrait complètement absurde qu'un électricien qui intervient dans un restaurant se permette de donner des conseils de cuisine au chef.
Et il paraît normal à tout le monde que le propriétaire de ce restaurant ne lui demande pas son avis sur la carte.
Par contre, l'avis du technicien sur comment réduire la consommation électrique de l'établissement est apprécié et recherché.
Pourquoi cela serait il différent pour un développeur ?

Je suis d'accord avec ton point de vue sauf sur le dernier point. Notre boulot, comme tu l'as dit, c'est de répondre à des besoins. En l’occurrence, ceux des différents services d'une entreprise. OK. Mais si tu ne connais pas un minimum le métier du service concerné, il est difficile de comprendre le besoin et donc, il est difficile de créer une application qui va répondre à ce besoin. De même pour un SI. Et ça, c'est une réelle plus-value. Un développeur doit avoir conscience de l'environnement de ses utilisateurs finaux.

Donc contrairement à l’électricien qui n'a pas à connaitre comment tourne un restaurant, le développeur, lui, se doit de connaitre le fonctionnement du restaurant. Il pourra ainsi optimiser les processus : le serveur prend la commande sur une tablette, celle-ci apparait directement en cuisine pour être préparée et enfin, on la retrouve facilement en caisse pour faire payer le client. De même, son traitement comptable est facilité puisque déjà enregistrée. On peut aller plus loin : en fonction des plats commandés, on peut gérer le stock des aliments par exemple.

Tu parlais de mettre l'accent sur le fonctionnel en entretien d'embauche. C'est cette capacité à parler fonctionnel sur différents corps de métiers qui n'est pas assez valorisé aujourd'hui (à mon sens). OK on est des petites mains, mais pas que.

[coolspot]

Je suis assez d'accord avec cette analyse.

Elle m'a fait penser à une présentation qui existe sur les SSII qui caricature assez bien, ce que beaucoup vivent: le celebre en c u lator (desole pour le politiquement correct, mais c'est le nom du fichier).

Concernant l'entretien d'embauche justement, combien d 'entre nous ont eu droit au tests de logiques? Ou encore aux questions bidons? Pire encore, et là je me "gauss" (, désolé, pas pu m'en empecher): les lettres de motivations. Les cours et théorie sur ce sujet sont tellement semblable que je n'en voit pas du tout l'utilité.

Un bon entretien en direct avec un réel dialogue, et pas de questions/reponses bateaux, vaut bien plus, parce qu'alors on a un reel aperçu des candidats. C'est même d'ailleurs souvent là qu'on se rend compte qu'une partie des meilleurs candidats auraient été rejetés par le systeme classique, car pas les bons diplômes, ou les bonnes references. Mais pourtant leur feux sacrés font une sacré différence, car ce qui fait la personne ce ne sont pas ses diplômes, mais ses capacités. Et ce sont justement ces capacités qui feront la différences dans un travail.

La vie en SSII semble malheureusement souvent ressembler à:
01-Tres gentil, y compris à l'entretien d'embauche car on a besoin de toi
02-Le taf commence bien, mais l'ambiance se dégrade peu à peu.
03-La boite va mal, donc comme on a plus besoin de toi, dehors

Et à l'heure d'aujourd'hui, les devs semblent malheureusement être considérés comme du jetable, du simple consommable. Mais quand ceux ci se réveilleront, cela va faire mal aux directions. Car ils se rendront compte alors que ce sont les devs qui les font vivre et pas l'inverse.

Ca peut bouger en effet mais pour ca il y a plusieurs conditions à respecter.
Tout d'abord arrêter avec la fable du "je suis cadre je compte pas mes heures". C'est de la fumisterie, on a beau avoir un contrat cadre, on est les ouvrier du service. On a ni plus de considération ni un meilleur salaire ni un cadre de management.

Ca c'est le point qui m'énerve le plus toute cette tripoté de gus qui font des heures gratuites en quittant l'entreprise après 18h en étant arriver avant 9h en sortant l'excuse du "je suis cadre, je compte pas mes heures" et le "il faut être professionnel". Vous croyez que la direction s'en rappelle de ce genre de truc lorsqu'ils faut augmenter les salaires non.
Non parce que ces gus là qui sont trop nombreux à travailler gratuitement pour l'entreprise donnent de mauvaise habitude à la direction au lieu de bien l'éduquer. Ce qui fait que toi après quand tu veut faire respecter ton contrat de travail t'es mal vu parce que la direction trouve pas ca normal que tu sois le seul ou un des seuls à pas faire d'heures gratuite sous couvert que "faut s'impliquer dans son travail"

Ensuite, la deuxième chose : - syndiquez-vous bordel.
Vous n'imaginez pas le pouvoir qu'on peut avoir si on est suffisamment nombreux à se syndiqué et donc s'organiser pour pas se faire enfler. Suffit par exemple d'une journée de grève qui fera des pénalité de retard sur des livraisons de projet et je vous garanti que la direction accouera dans l'heure pour venir négocier les augmentation de salaire.
Alors que non la plupart des gens au lieu de faire ca s'en tiennent au discours du : "les syndicats ca sert à rien, juste à faire chier en manif", "de toute façon je me débrouille mieux tout seul" (c'est les même qui sont bien content d'avoir un DS lorsque ca tourne mal pour eux et qu'il ont un entretien préalable pour licenciement)
Et bien entendu c'est totalement vérifié qu'un salarié tout seul face aux ogre style SSII est mieux armé que collectivement. , la direction ne va pas lui sortir le fameux : "en ce moment c'est la crise on peut pas mais promis l'année prochaine si tu fait encore 250h d'heures sup gratuite on réévaluera ca".
Bien sur ca marche 1 an ou 2 après le salarié postule dans une autre SSII ou on lui refera le coup même si il aura pu avoir son augmentation de changement de boite (au prix de pas avoir de vacance pendant 1 an) Et la SSII en prendra un autre gugus sortis de l'école pour refaire le même manège et se goinfrer sur son dos pendant 2,3 ans.

Bref les développeurs (ingé dev) seront mieux respecté quand il seront pour la plupart plus respectable et pas faire les carpettes de l’entreprise à faire des heures gratuites au prétexte qu'on a un statuts "cadre" ou ne jamais s'organiser pour faire un blocus contre des avantages qui sont dénoncés ou des augmentation qui viennent pas (au lieu de ca t'en a la moitié qui accepte de se faire enfiler et se résigne et ta l'autre moitié qui joue les mercenaires à changer de boite tous les 1-2 ans mais qui vont vers les même requins)

[GLDavid]

Ca peut bouger en effet mais pour ca il y a plusieurs conditions à respecter.
Tout d'abord arrêter avec la fable du "je suis cadre je compte pas mes heures". C'est de la fumisterie, on a beau avoir un contrat cadre, on est les ouvrier du service. On a ni plus de considération ni un meilleur salaire ni un cadre de management.

Ca c'est le point qui m'énerve le plus toute cette tripoté de gus qui font des heures gratuites en quittant l'entreprise après 18h en étant arriver avant 9h en sortant l'excuse du "je suis cadre, je compte pas mes heures" et le "il faut être professionnel". Vous croyez que la direction s'en rappelle de ce genre de truc lorsqu'ils faut augmenter les salaires non.
Non parce que ces gus là qui sont trop nombreux à travailler gratuitement pour l'entreprise donnent de mauvaise habitude à la direction au lieu de bien l'éduquer. Ce qui fait que toi après quand tu veut faire respecter ton contrat de travail t'es mal vu parce que la direction trouve pas ca normal que tu sois le seul ou un des seuls à pas faire d'heures gratuite sous couvert que "faut s'impliquer dans son travail"

Ensuite, la deuxième chose : - syndiquez-vous bordel.
Vous n'imaginez pas le pouvoir qu'on peut avoir si on est suffisamment nombreux à se syndiqué et donc s'organiser pour pas se faire enfler. Suffit par exemple d'une journée de grève qui fera des pénalité de retard sur des livraisons de projet et je vous garanti que la direction accouera dans l'heure pour venir négocier les augmentation de salaire.
Alors que non la plupart des gens au lieu de faire ca s'en tiennent au discours du : "les syndicats ca sert à rien, juste à faire chier en manif", "de toute façon je me débrouille mieux tout seul" (c'est les même qui sont bien content d'avoir un DS lorsque ca tourne mal pour eux et qu'il ont un entretien préalable pour licenciement)
Et bien entendu c'est totalement vérifié qu'un salarié tout seul face aux ogre style SSII est mieux armé que collectivement. , la direction ne va pas lui sortir le fameux : "en ce moment c'est la crise on peut pas mais promis l'année prochaine si tu fait encore 250h d'heures sup gratuite on réévaluera ca".
Bien sur ca marche 1 an ou 2 après le salarié postule dans une autre SSII ou on lui refera le coup même si il aura pu avoir son augmentation de changement de boite (au prix de pas avoir de vacance pendant 1 an) Et la SSII en prendra un autre gugus sortis de l'école pour refaire le même manège et se goinfrer sur son dos pendant 2,3 ans.

Bref les développeurs (ingé dev) seront mieux respecté quand il seront pour la plupart plus respectable et pas faire les carpettes de l’entreprise à faire des heures gratuites au prétexte qu'on a un statuts "cadre" ou ne jamais s'organiser pour faire un blocus contre des avantages qui sont dénoncés ou des augmentation qui viennent pas (au lieu de ca t'en a la moitié qui accepte de se faire enfiler et se résigne et ta l'autre moitié qui joue les mercenaires à changer de boite tous les 1-2 ans mais qui vont vers les même requins)

Coolspot,

Je suis d'accord et pas d'accord avec toi. Au regard de ce que propose l'auteur du texte, je suis parfaitement en ligne avec toi: les heures supplémentaires gratuites que nous offrons à l'entreprise n'ont pas lieu d'être. Je vois la même chose que toi. Des cadres qui font du 12h par jour sous couvert d'une fidélité à l'entreprise encore plus grande qu'envers leurs épouses ou époux. Fumisterie que tout ça ! J'ai vu énormément de haut cadres se faire jeter comme des malpropres parce qu'un jour, ils ont osé être en désaccord avec l'EXCOM sur un point. Je m'amuse parfois de faire un parallèle entre un régime communiste et l'entreprise: même goût de la glorification de la personne pour le CEO (je suis Dieu Tout-Puissant, créateur de l'entreprise et tenant du porte-feuille), même constat de hiérarchie fortement maintenue par les haut-cadres à l'image des haut-dignitaires, plan quiquennal et partage du travail entre l'ouvrier et l'agriculteur...pardon entre le technicien et le "cadre" que l'on appelera ici l'ingénieur.

Cependant, un point me chagrine dans ton propos, la syndicalisation. Est-ce dû au fait que j'en ai eu une mauvaise expérience ? Peut être. Je me rappelle de l'entreprise souhaitant baisser nos RTT et congés payés parce qu'en France, vous avez trop de congés, donc, vous nous coutez de l'argent. Même si ces congés sont légaux, l'entreprise a tout fait pour baisser nos congés. Notre syndicat s'est battu... mais s'est vite résigné. L'argument patronal du "Ok, vous gardez vos congés mais on vire X personnes" a gagné. Du coup, comme des moutons, nous avons accepté cette diminution des jours de congés, sous les applaudissements de certains haut-cadres. Comme en Corée du Nord, celui qui s'arrête le premier d'applaudir sera tué... non viré, on en est par encore là.

Pour moi, il me semble plus adéquat de faire nos heures. Ok pour dépasser si on est à la bourre pour rendre un projet mais à nous d'organiser NOTRE temps. On est tenu de faire 8-9h jour, OK, mais à nous de le gérer ce temps. La syndicalisation est une bonne idée mais je serais plus en faveur d'une participation plus active et représentative aux conseils d'administration ou autres meetings de gouvernance des employés. Après tout, si l'entreprise vit, c'est par notre travail, nous avons donc notre mot à dire sur la direction à suivre et les projets.

Mais ceci n'est que mon humble avis,

@++

[Aurelien Plazzotta]

Bonjour,

Je ne suis pas d'accord avec l'auteur du blog. Les concepteurs-développeurs et autres architectes techniques ont une vision systémique de l'entreprise et non limitée à la microscopie. Lors d'une conception ou d'une évolution d'une base de données notamment, il est de notre devoir de raisonner plus loin que le fondateur de l'entreprise lui-même.

Néanmoins, l'auteur a réussi son coup de gueule et le buzz est lancé

[nikau6]

Malgré les apparences, ces personnes se comportent de la sorte avec les développeurs tous simplement parce qu'ils développent, face à eux ( à nous), un sentiment d'infériorité. Ils sont donc victimes de ce que l'on appelle un complexe d'infériorité, et leur attitude est une façon pour eux de se protéger. L’intelligence du développeur est quantifiable, la leur est plus que relative et ils le savent bien, pour la plupart.

[fredinkan]

Malgré les apparences, ces personnes ce comportent de la sorte avec les développeurs tous simplement parce qu'ils développent, face à eux ( à nous), un sentiment d'infériorité. Ils sont donc victimes de ce que l'on appelle un complexe d'infériorité, et leur attitude est une façon pour eux de se protéger. L’intelligence du développeur est quantifiable, la leur est plus que relative et ils le savent bien, pour la plupart.

C'est un gros troll, mais d'une certaine façon tu n'as pas tout à fait tort.
Avant de me ramasser des moins, je vais m'expliquer

Nous avons un métier qui nécessite pas mal de facultés cognitives, particulièrement une logique développée et un esprit d'analyse. C'est très fréquent de voir dans les pros de l'IT des gens affichant un bon score de QI. On a besoin de logique et c'est bien ce que ce score montre.
Bon par contre des fois, je me demande si ça s'applique encore aux "pisseurs de code" que même nous, nous applons comme ça (oui oui, ceux qui ne connaissent qu'un framework, mais qui ne sont pas capable de sortir quelque chose sorti de leur framework).

Le problème pour les managers, c'est qu'avec nos esprits logiques et analytiques (et critiques aussi, si on sait développer ce sens), nous allons forcément chercher le plus d'informations possible en cas de problème.. Dans certains cas on peut parfois être définis comme "fouille-mer**", car pour résoudre un problème on va essayer de tout comprendre pour améliorer l'existant.
Et ça... Ben forcément ils ne l'aiment pas... Améliorer un processus métier ? C'est normalement le rôle d'un manager ou d'un business analyst...

Maintenant, comment faudrait-il revaloriser ça ?
Le plus simple serait d'avoir du pisseur de code qui écrit EXACTEMENT ce qui est écrit dans la spec (qui ne DOIT PAS changer). Et d'un autre côté, avoir quelqu'un, qui sera défini comme "décideur" et apprécié du management qui lui fera cette spec. Mais c'est clair qu'un manager (au sens large) ne pourra pas le faire.
Et ça, c'est dans un mode de bisounours.

[gabriel.klein]

On vit un peu dans un autre monde en tant que développeur / ingénieur en développement.

Ce qui est dommage, c'est que notre monde a une richesse qui pourrait être mieux utilisée. On a une manière de voir, d'approcher certains problèmes qui est extrêmement efficace et qui mériterait d'être mieux comprise. On peut par exemple citer l'approche Scrum qui permet de résoudre nombre de problèmes de communication dans une petite équipe - et pas seulement des développeurs!

Mais c'est aussi notre métier... savoir rendre accessible à des gens non initiés ce que nous faisons. Vivant dans un monde extrêmement complexe, une personne qui n'a pas notre compétence aura de la difficulté à comprendre la complexité de ce monde.

On a tendance à oublier que beaucoup d'entre nous sont des universitaires, font de la formation continue tout le temps, et qu'on a parfois le même niveau d'études qu'un médecin, qu'un avocat.

En effet faire des tests de logique d'une SSII, quand j'ai fait des études très poussées, je trouve cela limite dénigrant. C'est comme faire venir un médecin, lui montrer un stéthoscope, et lui demander comment on utilise cet outil! Maintenant c'est aussi à nous de ne pas accepter de rentrer dans ce jeu, ou dire ouvertement: "J'ai un peu peur de l'intérêt du travail que je vais faire chez vous en voyant les tests que vous me faite faire... Est-ce que ma tâche se résumera à ces tests? Pourquoi les faire si cela ne représente qu'un petit aspect de ma tâche future?"

Le pire que j'ai vécu c'est un test qui m'a pris la journée à faire.... pas payé! Et très peu de retours sur la raison pour laquelle ma candidature n'avait pas été retenue. (Oh désolé il n'est pas la, désolé il n'a pas le temps.). Un interview n'est pas une discussion à sens unique, ce n'est pas juste une évaluation "online" (comme le fait facebook), c'est aussi un apprentissage pour le candidat et l'entreprise. Le candidat a le droit d'avoir quelque chose en retour même en cas de refus.

[r0d]

Je m'amuse parfois de faire un parallèle entre un régime communiste et l'entreprise

Ça marche aussi avec le fascisme

Les dirigeants sont des gestionnaires et ne connaissent rien à la technique

Je pense que le nœud du problème est là. Et moi personnellement (ça n'engage que moi, je ne généralise pas), ça me pourrit mon quotidien. Je suis réellement amoureux de mon métier, c'est une passion, je fais du dev au boulot, chez moi, tout seul, avec des amis, j'anime des workshop, je participe à des projets, etc. Et en plus de 10 ans en tant que développeur, je n'ai jamais travaillé pour un patron qui connaissait ne serait-ce qu'un minimum le métier du logiciel. Et c'est un énorme problème selon moi. Le développement logiciel ne se réduit pas à l'écriture d'un programme, ça concerne aussi toute la qualité (tests unitaires/globaux, intégration, etc.), la maintenabilité, la robustesse, la documentation, la gestion des sources et des ressources, les choix techniques, les choix fonctionnels, le design technique, le design fonctionnel, le design graphique, l'ergonomie, etc, etc, etc...
Or, lorsqu'on commence à parler de ces choses-là à quelqu'un qui n'y comprend rien et qui s'en fiche, c'est au mieux une perte de temps. Et moi ça me bousille d'être contraint d'implémenter des trucs débiles, de travailler sur des technos inadaptées, de ne pas avoir le temps de faire les choses bien, tout ça parce que mon N+1 est un putain de gestionnaire et qu'il ne connait pas le métier. Erf, pardon pour la vulgarité, mais bon, je supporte de moins en moins cette situation.

[pmithrandir]

Pour répondre a ceux qui râlent contre les tests trop simple, je suis en charge du recrutement, et 50% des personnes éliminées l'on été sur ce genre de tests.


Quelque chose de complexe, ca s'évaluera très bien dans la période d'essai, ou dans une discussion. Mais dans un entretien technique, on a le facteur stress qui bloque pas mal de gens.(or on ne recrute pas uniquement des gens pour une résistance au stress)

Au final, un algo tout simple et après on regarde comment les gens se débrouillent dessus.

Pour mes recrutements, je tests 3 choses :
- un algo simple(le genre qu'on sait faire avec 2 mois de programmation dans les pates)
- la compréhension du modèle objet (héritage, interface...)
- des concept de bases du langage(synchronisation en java par exemple)
- Un poil de SQL

Et bien avec ces sujets simple, on arrive assez bien a voir les points forts et faible des gens sans y passer la journée.

Pour moi, le but de ces tests simple est aussi d'éliminer ceux qui bluffe les RH sans trop perdre de temps.

[el_slapper]

Ça marche aussi avec le fascisme

Je pense que le nœud du problème est là. Et moi personnellement (ça n'engage que moi, je ne généralise pas), ça me pourrit mon quotidien. Je suis réellement amoureux de mon métier, c'est une passion, je fais du dev au boulot, chez moi, tout seul, avec des amis, j'anime des workshop, je participe à des projets, etc. Et en plus de 10 ans en tant que développeur, je n'ai jamais travaillé pour un patron qui connaissait ne serait-ce qu'un minimum le métier du logiciel. Et c'est un énorme problème selon moi. Le développement logiciel ne se réduit pas à l'écriture d'un programme, ça concerne aussi toute la qualité (tests unitaires/globaux, intégration, etc.), la maintenabilité, la robustesse, la documentation, la gestion des sources et des ressources, les choix techniques, les choix fonctionnels, le design technique, le design fonctionnel, le design graphique, l'ergonomie, etc, etc, etc...
Or, lorsqu'on commence à parler de ces choses-là à quelqu'un qui n'y comprend rien et qui s'en fiche, c'est au mieux une perte de temps. Et moi ça me bousille d'être contraint d'implémenter des trucs débiles, de travailler sur des technos inadaptées, de ne pas avoir le temps de faire les choses bien, tout ça parce que mon N+1 est un putain de gestionnaire et qu'il ne connait pas le métier. Erf, pardon pour la vulgarité, mais bon, je supporte de moins en moins cette situation.

ça, ça a été mon quotidien pendant 15 ans en SSII. Des gens qui rognent en permanence sur les environnement de TEST au nom de la SÉCURITÉ, ça m'a toujours fait halluciner. Bon, dans 3 semaines, je commence chez un éditeur de logiciel qui a l'air plus sérieux à ce niveau là(on verra bien).
sans budget.
Ce que j'ai souvent fait, quand même, c'est faire ce que j'avais à faire en sous-marin. Sans budget. Ca m'a souvent valu des réactions en deux temps :
(1)P****n de c*****d de m***e!!! on ne t'as pas demandé de faire ça!!!
(2)Bon, y'a moyen de rajouter des fonctionnalités?
voire même dans un troisième temps : el_slapper s'en va? On va tous mourir!!!(j'exagère à peine, au moins deux fois les gens étaient paniqués à l'idée de mon départ, pour démission ou limite des 3 ans).

Parce qu’évidemment, nous sommes des professionnels, et que quand nous faisons ce que nous avons à faire, sans se contenter de ce qu'on nous demande, les choses se passent beaucoup mieux. Et que le management intermédiaire se rend bien compte que les choses se passent mieux quand quelqu'un qui ose faire son boulot est présent. Après, le management supérieur, lui, n'en a pas conscience, et pousse au contrôle maximum des personnels. En bref, de recruter les gens les plus intelligents possibles, pour leur demander de se servir le moins possible de leur intelligence. En SSII, franchement, les risques encourus pour s'en servir sont faibles - si on a pas peur des engueulades. Qui ne sont pas toujours la règle, d'ailleurs, j'ai aussi croisé l'incompréhension, le doute, l'indifférence, voire l'enthousiasme vis-à-vis de mes initiatives.

Je suis d'autant plus enclin à faire proprement ce qu'on me demande de faire salement que l'expérience m'a montré que ça allait plus vite. En bancaire, j'ai reçu l'ordre direct et écrit de "livrer à chaud la correction sans la tester". Je suis passer par la procédure normale(assez performante de toutes façons), et j'ai pris le temps de vérifier les modifications en intégration(ça m'a pris une heure). Résultat : il y avait un petit bug, qui aurait provoqué plus de dégâts que ce que j'étais censé corriger. Encore une fois, en tant que (1)professionnel et (2)prestataire, c'est mon rôle, et je ne risque(risquait) pas grand chose.

En plus, personne n'a remarqué que je l'avais fait. Tant mieux.

[bilgetz]

Ce que j'ai souvent fait, quand même, c'est faire ce que j'avais à faire en sous-marin. Sans budget. Ca m'a souvent valu des réactions en deux temps :
(1)P****n de c*****d de m***e!!! on ne t'as pas demandé de faire ça!!!

Le truc c'est que souvent c'est des chose qui aurai pu être facturé au client.
J'ai même vu des simplification de code être facturé au client ou montré comme un geste commercial.