Le fondateur a répondu qu'ils réagissent de manière excessive et qu'il a une confiance absolue dans les compétences du nouveau responsable, sur la base de son CV et de l'entretien, ce qui est exactement la raison pour laquelle il a attribué à cette personne le rôle de développeur principal en premier lieu.

Le responsable a parlé. Ce n'est pas un gouvernement ou un parti politique. Vous ne pouvez pas jeter quelqu'un dehors ou mener une insurrection.

Si vous n'êtes pas prêt à vous en occuper, vous avez vraiment une option. Vous pouvez vous regrouper et menacer de démissionner si quelque chose n'arrive pas.

Je dis bien que vous pouvez, et non que vous devriez. Il y a une chance extraordinaire que cela ne se termine pas bien. En fait, vous essayez de vous placer devant le patron qui a pris sa décision et les responsables n'aiment pas qu'on les conteste.

Je suppose que la chose “correcte” à vous dire est de trouver des techniques pour l'encourager à voir votre façon de penser. Mais je ne vais pas faire ça. Je suis un développeur senior de 30 ans et je peux vous dire que je me suis en grande partie fixé sur mes méthodes fondamentales. Non, je ne suis pas un luddiste comme lui et oui, je prends les suggestions. J'embrasse les nouvelles technologies, etc. Ce type a clairement tort sur beaucoup de choses. Cependant, ce que je peux vous dire, c'est que lorsque je suis fixé sur quelque chose et que je suis convaincu de prendre la bonne décision, je m'y tiens. Je ne prends pas bien les menaces et la coercition ou la manipulation, c'est encore pire.

Ce que je veux dire, c'est qu'il est convaincu d'être “le programmeur Jésus” (ce qui est une attitude triste et malheureuse) et vous ne le changerez jamais, pas à ce stade de sa carrière. Il est convaincu qu'il a raison et il pense que son expérience le soutient. Malheureusement, le patron aussi.

Honnêtement, ça ne vaut probablement pas le stress de vous et de votre équipe. *Je vous suggère à chacun de commencer à chercher un nouveau travail et de partir quand vous en aurez trouvé un. Lorsqu'une personne part, assurez-vous qu'elle dise au patron pourquoi elle le fait *Il finira peut-être par comprendre. Même dans ce cas, ce n'est pas une garantie.

RUN Sérieusement, je ne sais pas pourquoi quelqu'un voudrait être là. Demandez-vous s'il y a quelque chose dans ce que vous nous avez dit qui n'entraîne pas la mort du produit. Je suis sûr que vous le savez. Je mets en doute l'intelligence de base du fondateur à ce sujet. Les développeurs font généralement de très mauvais gestionnaires de projets/programmes. Il s'agit d'un ensemble de compétences distinctes et ils doivent s'équilibrer mutuellement. C'est comme dire “nous n'avons pas besoin de testeurs séparés, les tests des développeurs fonctionnent très bien”. Les deux sont des recettes pour le désastre. Bonne chance. Je suis sérieux.

La description de la situation par le PO est probablement unilatérale. C'est bon.

Je suis un développeur vieillissant (~54 ans) amené dans une entreprise non pas pour diriger, mais pour apporter une certaine expérience. Le personnel de développement était, dans l'ensemble, beaucoup plus compétent que toutes les équipes avec lesquelles j'avais travaillé auparavant. Ils m'ont beaucoup appris, surtout sur l'humilité ! Mais nous avons trouvé des endroits où leur magie technologique ne résolvait pas les problèmes et, dans certains cas, les cachait, les aggravant même. C'est là que j'ai pu vraiment apporter ma contribution.

Votre direction semble sévèrement autocratique. On dirait qu'il a été mandaté par le propriétaire. Le propriétaire n'est pas satisfait du personnel de développement et a fait appel à ce type “intransigeant et sans scrupules” pour améliorer la vitesse de livraison.

Tout d'abord, regardez votre personnel. Avez-vous des faiblesses - des développeurs qui ne “voient pas la matrice” ? Si oui, trouvez leur de nouveaux postes dans l'entreprise ou donnez-leur de bonnes références pour un employeur qui a besoin de leurs compétences uniques.

Il déteste les IDE

J'en connais quelques-uns qui le détestent. Cela me fait rouler les yeux, mais en fin de compte, je m'en fiche. Si les gens produisent en utilisant vi, alors ok. J'aime mes IDEs.

Il ne refait pas le code, et ne se soucie pas du style (qui est incohérent dans son propre code)

Red flag sur la première partie. Est-il un copiste ? Je suis également coupable de ne pas me soucier du style, mais c'est parce que j'utilise mon IDE pour rendre mon code Python instantanément conforme au PEP8. Mais il n'utilise pas d'IDE…

En passant, le style était auparavant vérifié par un nightly build, qui a commencé à échouer depuis l'arrivée du nouveau lead.

Il rejette l'idée d'un nightly build, ainsi que les tests automatisés. Selon lui, “tout développeur professionnel teste son code de toute façon à la main, il n'y a donc aucune raison de perdre du temps à écrire des tests automatisés”. La compilation nocturne est également une perte de temps, selon lui.

Cela déclenche également un drapeau rouge, mais pour des raisons différentes de celles auxquelles on pourrait s'attendre. Avant que ce type ne soit engagé, combien de fois le propriétaire s'est-il fait dire qu'il ne pouvait pas faire X (donner une démo, utiliser le système, etc.) parce que le nightly build avait échoué ? Que se passe-t-il si le propriétaire perçoit que la construction nocturne est le problème ? Que pensez-vous qu'il dirait au chef de file de faire ?

Mais je m'inquiète de l'attitude du chef de file ; les tests automatisés sont étonnants. Comme avant, le patron ne comprend peut-être pas la valeur des tests, mais il sait sûrement que Y% des salaires du personnel de développement les payent. Lorsque je suis arrivé dans mon entreprise actuelle, la “mafia des tests à 100 %” avait pris le contrôle du personnel de développement et faisait grimper les coûts en flèche. Une mauvaise pomme plus tard, le personnel du développement ronronnait à nouveau.

Il pense que le contrôle de version est en grande partie inutile…

C'est un drapeau rouge de premier ordre. Il se trompe autant que possible. Il est irresponsable avec l'argent du propriétaire.

Il surestime l'importance de l'optimisation du code.

À l'époque, l'optimisation du code pouvait faire la différence. Aujourd'hui, les machines sont si rapides qu'elle est moins importante. Au lieu de cela, nous devons maintenant nous préoccuper des performances des bases de données et du débit du réseau. Mais son habitude de “l'optimisation du code” est difficile à rompre, croyez-moi. Je dois m'efforcer de ne pas pré-optimiser. Au moins, son comportement dans ce cas n'est pas destructeur, sauf pour le temps qu'il prend. (Avez-vous des chiffres pour sa “moitié de son temps” ou est-ce une hyperbole ? Si vous critiquez votre supérieur, aucune hyperbole ne peut être autorisée. Vous devez être pathologiquement objectif).

Il écrit tout le SQL à la main, et rejette l'idée d'un ORM.

Coupable comme accusé ! Je ne comprends pas la peur des gens face au SQL. Je ne comprends pas qu'on enterre le SQL, qui est un simple “dropdead”, sous des couches d'ORM qui obscurcissent. Je ne peux pas vous aider ici :-D Mais s'il vous plaît, jetez tout votre SQL au même endroit - ne le distribuez pas dans tout votre code.

et deux des cinq développeurs n'ont jamais utilisé le SQL auparavant.

C'est inacceptable. Nous sommes en 2016. Ils doivent se perfectionner.

Il rejette les frameworks et les bibliothèques tierces, considérant qu'il est beaucoup plus facile d'écrire des choses à partir de zéro.

Il ne pourrait pas avoir plus tort. Je doute que votre entreprise soit si spéciale que vos utilitaires doivent être écrits en interne. Nous avons eu quelques développeurs qui ont adopté des outils tiers - jusqu'à ce qu'ils fassent quelque chose d'une manière que le développeur n'aimait pas. C'était une excuse pour jeter l'outil et écrire le leur. Cela ne faisait qu'alourdir la charge de travail du personnel de développement, le ralentissant encore plus. Ce code inutile est coûteux à écrire, tester, déboguer et maintenir. Nous avons dépensé tant d'argent pour un bénéfice nul. Ces développeurs sont partis maintenant.

Il a décidé d'abandonner toutes les bibliothèques et tous les frameworks JavaScript sauf jQuery, affirmant que lorsqu'il a commencé à programmer en JavaScript il y a quinze ans, il n'y avait pas de frameworks, et la vie était beaucoup plus facile.

Celui-ci n'est pas aussi clair. La raison en est que la vie était beaucoup plus facile il y a quinze ans la demande des entreprises était beaucoup plus simple. C'est de là que vient le problème. Le web a été inventé comme un système par lots (remplir un formulaire, le soumettre, obtenir une réponse, répéter) et maintenant nous essayons d'écrire des applications web qui se comportent comme des applications de bureau. Son observation est juste, les choses sont difficiles maintenant. Mais il ne réalise pas pourquoi. La complexité des outils est une réponse à une demande plus complexe des entreprises. Il fait donc de mauvais choix.

Nous utilisons AngularJS et cela semble être correct. Comme tous les outils puissants, il peut être utilisé pour le bien ou le mal.

Il pense que les appareils mobiles (y compris les tablettes) ne sont qu'un battage publicitaire, il n'y a donc aucune raison de perdre un temps précieux à assurer la compatibilité du site avec ces appareils et à faire une conception adaptée. Le produit est une application web publique qui ne devrait pas être beaucoup utilisée à partir d'appareils mobiles.

Il se trompe encore. Ce n'est pas du battage publicitaire. Elles sont là pour rester parce qu'elles sont utiles. MAIS l'entreprise n'en a pas besoin. Ne développez pas des choses dont vous n'avez pas besoin. C'est cher.

Le design réactif, cependant, pourrait être très intéressant à avoir pour cette application, …

Est-ce si intéressant que vous payeriez pour le développement personnellement ? Si c'est une bonne idée, vous devriez pouvoir vendre l'idée au propriétaire. Sinon, ne dépensez pas un centime dessus.

Il demande à l'équipe d'arrêter d'utiliser Internet (surtout StackOverflow) et de se fier à leur cerveau, à la documentation hors ligne (je ne savais même pas que Microsoft vendait encore des CD MSDN !) et aux livres.

Il a tort. L'internet est parfait pour cela. Si l'équipe de développement fait du copier-coller à partir de Stackoverflow sans comprendre comment le code fonctionne, alors ils ont également tort. Y a-t-il du temps pour la formation et l'amélioration personnelle dans le programme de développement ? Il est difficile de ne pas faire du copier-coller robotisé quand on est toujours sous pression.

Bien que j'aie des informations limitées, il y a beaucoup de problèmes ici. Il semble que le propriétaire n'ait pas obtenu le code qu'il paie aussi vite qu'il l'espérait. On dirait qu'il a entendu beaucoup d'excuses pour des choses dont il ne se soucie pas ; il est concentré sur le résultat. Si j'ai raison, vous avez une blessure auto-infligée, et vous l'avez rouverte plus d'une fois. Cette piste est la solution du propriétaire au problème que le personnel de développement a posé, et étant donné ses informations limitées, elle est compréhensible.

Je parie aussi que vous dirigez un magasin non agile et que vous avez une mauvaise définition des exigences qui change au gré du vent. Il n'y a pas une couche d'isolation entre le personnel de développement et le propriétaire. A l'exception de cette piste.

Maintenant, que pouvez-vous faire ?

1) Former la piste que l'utilisation de tests automatisés et la gestion du code est la voie à suivre. Cela peut prendre du temps pour gagner en crédibilité auprès de lui - le propriétaire lui a probablement dit que le personnel est défectueux. Voyez si vous pouvez l'empêcher d'imposer des mandats de balayage tels que “supprimer toutes les conneries de tests inutiles et réorienter le serveur SVN”. Cela vous donnera le temps de montrer votre valeur.

2) Continuez à utiliser la gestion de code à un niveau personnel. Au moins, vous pourrez alors vous remettre de vos propres erreurs. Ne lui dites pas que vous faites cela, mais ne lui mentez pas non plus.

3) Continuez les tests automatisés (tests unitaires, si ce n'est rien d'autre) à un niveau personnel. Comme précédemment, ne le mentionnez pas, mais ne le cachez pas.

4) Travaillez avec le responsable pour déterminer quels sont les problèmes réels perçus. Faites preuve d'ouverture d'esprit ; je parie qu'il y a de vrais problèmes avec le personnel. Travaillez avec le responsable pour résoudre les problèmes, pas les symptômes.

5) Discutez avec le responsable de divers sujets de développement, tels que les avantages de la chute d'eau et de l'agilité. Aucun des deux n'est parfait. Posez-lui des questions telles que “Dans quelles circonstances un test automatisé serait-il utile” ? S'il donne une réponse douteuse, demandez-lui comment des entreprises prospères comme Google ont réussi à prospérer malgré cela.

Vous pouvez donc voir que j'ai à cœur d'engager le chef de file et de voir où il a la tête. Construire la confiance. S'entendre sur les problèmes par rapport aux symptômes. Ce n'est pas toujours facile, surtout lorsque vous avez l'impression qu'il est comme Godzilla et qu'il détruit votre travail.

Il y a une chance qu'il ne puisse pas faire de compromis. Il écrasera les tests automatisés. La gestion des codes est destinée aux personnes négligentes. My Way or the Highway.

Mais s'il est arrivé à ce point, il sera temps pour vous de partir. Travailler dans un atelier sans outils, et je veux dire des logiciels et des outils de génie logiciel - ne construit pas votre CV. Vous commencerez à pourrir de la même façon que le plomb a pourri. Dans ce cas, passez à autre chose.

vingt-cinq ans dans l'informatique […] changer son attitude

Ça ne va pas marcher, désolé.

Votre vrai problème n'est pas le développeur principal incompétent. Ce problème est insignifiant par rapport au vrai problème que vous décrivez :

Votre fondateur fait plus confiance à un étranger incompétent qu'à ses employés actuels.

Vous devez comprendre comment l'équipe a perdu sa confiance, et comment la regagner. Cela aurait été plus facile si cela avait été fait avant que l'étranger ne soit engagé. Maintenant, c'est difficile, parce que tout bon travail sera attribué au nouveau chef d'équipe, et tout mauvais travail sera attribué à vous tous - donc vous ne pouvez pas le réparer en travaillant plus dur.

Il n'y a que 2 choses auxquelles je peux penser, pour améliorer la situation à ce poste :

1. Trouver un médiateur. Y a-t-il plusieurs fondateurs, ou quelque chose comme des membres du conseil d'administration ?
2. Peut-être que la question de la confiance est une question de visibilité. Dans ce cas, tout ce qui contribue à la visibilité vous aide. Par exemple, rendez les démonstrations de sprint suffisamment excitantes et intéressantes pour que le fondateur y assiste et apprenne le statut et les progrès de l'équipe.

*Même si la plupart des points soulevés par le PO ne rendent pas nécessairement l'étranger incompétent, son approche du contrôle de version et de l'intégration continue dans une équipe de 5 personnes le fait certainement.

Cette réponse peut être défavorable et considérée comme grossière par certains mais…

Le premier drapeau rouge est For a few years, the founder was unhappy about the technical skills of the employees

Les employés ont-ils tenté de remédier au malheur ? Il est difficile de créer un système efficace si les développeurs ne sont pas familiers avec les technologies de base et ne comprennent pas vraiment ce que l'ORM cache. Il est difficile d'imaginer que two of the five developers never used SQL before a été réellement prononcé, mais je vais le prendre au pied de la lettre et vous croire. Cependant, considérez le premier drapeau rouge que j'ai mentionné et le “malheur” auquel le fondateur a dû faire face pendant des années… !

A cela, j'ajoute : vous connaissez le malheur du fondateur depuis des années !

Comment cette information vous a-t-elle été divulguée ?

J'ai tendance à penser que ce type fait précisément ce pour quoi il a été engagé : vous mettre en forme.

Vous mettre en forme ne signifie pas adopter les mauvaises pratiques du nouveau, mais cela implique de vous sortir de votre zone de confort pour apprendre à un niveau plus profond.

Pendant quelques années, le fondateur était mécontent des compétences techniques des employés, et il a récemment engagé un développeur senior pour le double rôle de responsable technique et de chef de projet. Il a été le seul à passer un entretien, et le seul à décider d'engager cette personne.

L'équipe a cependant beaucoup moins apprécié son profil au cours des deux derniers mois. J'ai eu l'occasion de parler avec trois des cinq membres de cette équipe, et ils ont tous souligné trois problèmes :

• Selon eux, le type est un connard, et n'a aucun respect envers les autres membres de l'équipe. Une citation récente de lui parlant à un programmeur junior devant l'équipe est très illustrative : “J'ai travaillé pendant vingt-cinq ans dans cette industrie, et vous ? Qu'avez-vous fait ? Vous avez été un singe de code pendant trois ans. Alors tais-toi, crétin ! Personne ne se soucie de ton opinion, a****.”

On dirait que tu n'as qu'une seule version de l'histoire. Je peux imaginer quelques situations où je pourrais avoir besoin de gifler un jeune je-sais-tout moi-même, et je l'ai fait. Je joue juste l'avocat du diable ici, mais on dirait qu'il a été provoqué. Quelle était la provocation ?

• Dans le passé, les décisions étaient prises par tous les membres de l'équipe. Lorsque les membres n'étaient pas d'accord, ils en discutaient tous ensemble et parvenaient à un accord, ou du moins expliquaient le raisonnement à ceux qui n'étaient pas d'accord.

Apparemment, les pratiques passées n'ont pas produit les résultats que le fondateur voulait.

Maintenant, toutes les décisions importantes sont prises exclusivement par le développeur principal. Ces décisions ne peuvent pas être remises en question ou discutées, même si les cinq membres de l'équipe trouvent qu'une décision n'a pas de sens.

Encore une fois, cela ressemble à un vote de défiance de la part du fondateur. Il a fait appel à ce type de personne pour une raison. Il semble que la raison était de mettre le reste de l'équipe en forme.

1. Il déteste les IDE, l'auto-complétion, et les fonctionnalités qui sont destinées à aider les programmeurs à écrire du code plus rapidement, et affirme que l'équipe devrait utiliser Notepad++ pour être productive. Bien que cela ait du sens dans différentes circonstances, il est difficile d'imaginer que les développeurs C# abandonnent soudainement Visual Studio pour Notepad++.

IDEs peuvent vous ralentir si vous êtes un programmeur rapide. Notepadd ++ est supérieur à certains pour le codage rapide. L'idée est que vous écrivez votre code, puis que vous le déposez dans l'EDI pour une correction rapide au lieu d'interruptions constantes.

1. Il ne refaçonne pas le code, et ne se soucie pas du style (qui est incohérent dans son propre code), la raison étant que “il ne se soucie que des choses qui comptent vraiment”. A noter que le style était auparavant vérifié par un nightly build, qui a commencé à échouer depuis l'arrivée du nouveau lead. Les normes de la boutique

sont quelque chose à discuter avec le fondateur, surtout que vous le faites passer par le nightly build. Mais là encore, en lisant entre les lignes, il semble que le fondateur ne vous fasse pas confiance.

1. Il rejette l'idée d'un build nocturne, ainsi que les tests automatisés. Selon lui, “tout développeur professionnel teste son code de toute façon à la main, il n'y a donc aucune raison de perdre du temps à écrire des tests automatisés”. La compilation nocturne est également une perte de temps, selon lui.

Il a raison, les tests automatisés n'expliquent pas le pur génie d'un idiot qui fait quelque chose qui n'est pas prévu. J'ai personnellement cassé plusieurs programmes qui ont été soumis à des tests automatisés. Il pense que le contrôle de version est pour la plupart inutile et semble mal comprendre comment l'utiliser. Cela conduit à des situations où il développe une fonctionnalité seul pendant trois à cinq jours, et lorsqu'il commet enfin ses modifications, il “prend la mienne” pour tous les conflits. Si d'autres membres de l'équipe se plaignent que leur code a été effacé, il les invite à le réécrire. À plusieurs reprises, d'autres membres ont fait de même, en effaçant le code du développeur principal. Il a eu l'air surpris (il semble qu'il ne sache pas comment utiliser svn log ou diffs), et a refait ses modifications, se plaignant qu'elles “étaient mystérieusement perdues” et accusant SVN d'avoir merdé.

Tout le monde est en faute ici. Personne ne fait de sauvegarde ? S'il a des problèmes avec le contrôle de version, c'est la responsabilité de l'équipe de travailler en équipe et non pas de lui en faire baver.

1. Il surestime l'importance de l'optimisation du code. Son approche est correcte, c'est-à-dire qu'il utilise un profileur, détermine un goulot d'étranglement et le corrige ; le problème est qu'il n'y a pas d'exigences de performance non fonctionnelles, et aucun élément indiquant que les utilisateurs pourraient considérer l'application comme lente (et hébergée sur des VM de développement de faible niveau, l'application semble très réactive). En revanche, il passe pratiquement la moitié du temps à optimiser le code.

On ne peut pas surestimer l'importance de l'optimisation du code. Le but de l'optimisation du code n'est pas de s'assurer qu'il fonctionne correctement aujourd'hui le but est de l'optimiser de sorte que vous ne réparez pas un problème qui aurait pu être évité dans trois ans grâce à l'optimisation du code.

Si vous ne vous souciez que du bonheur des utilisateurs aujourd'hui, vous allez les voir frapper à votre porte demain.

1. Il écrit tout le SQL à la main, et rejette l'idée d'un ORM. Il faut noter que le produit actuel est basé sur l'Entity Framework ORM de Microsoft, et que deux des cinq développeurs n'ont jamais utilisé SQL auparavant.

Deux des cinq développeurs devraient alors être licenciés. Si vous vous appuyez sur un ORM, vous ne pourrez jamais passer sous le capot et réparer les choses manuellement. Je commence à comprendre pourquoi il a traité quelqu'un de “singe de code” par frustration. Les ORM sont très bien, mais vous devez comprendre le SQL si vous voulez dépasser les limites d'un ORM. Il rejette les frameworks et les bibliothèques tierces, considérant qu'il est beaucoup plus facile d'écrire des choses à partir de zéro. Il a décidé d'abandonner toutes les bibliothèques et frameworks JavaScript sauf jQuery, en prétendant que lorsqu'il a commencé à programmer en JavaScript il y a quinze ans, il n'y avait pas de frameworks, et la vie était beaucoup plus facile.

Il a raison. Les frameworks et les bibliothèques tierces ont des limites, et si vous ne comprenez pas assez pour y aller et le réparer vous-même, vous ne comprenez pas le code. Un argument peut être avancé dans un sens ou dans l'autre. Cependant, si personne dans l'équipe ne peut coder sans utiliser les frameworks, alors vous avez une équipe très faible. Il pense que les appareils mobiles (y compris les tablettes) ne sont qu'un battage publicitaire, il n'y a donc aucune raison de perdre un temps précieux à assurer la compatibilité du site avec ces appareils et à faire une conception réactive. Le produit est une application web publique qui ne devrait pas être beaucoup utilisée à partir d'appareils mobiles. Cependant, il pourrait être très intéressant d'avoir un design réactif pour cette application, puisque même sur les ordinateurs de bureau, elle sera affichée sur des écrans de 19 pouces ainsi que sur de grands écrans haute résolution.

D'après tout ce que vous avez dit, on dirait qu'il a été amené à faire le ménage. Si les appareils mobiles ne sont pas un acteur majeur pour la ou les applications, passer trop de temps est une perte de temps. Bien qu'il puisse être “agréable à avoir” sur un bureau, un “agréable à avoir” n'est pas une nécessité pour le déploiement.

1. Il demande à l'équipe d'arrêter d'utiliser Internet (en particulier StackOverflow) et de se fier à leur cerveau, à la documentation hors ligne (je ne savais même pas que Microsoft vendait encore des CD MSDN !) et aux livres.

Tant mieux pour lui. On dirait qu'il veut savoir qui peut faire ses propres devoirs et qui a triché.

Les membres de l'équipe se sont plaints au fondateur de la société de leur nouvelle piste sur ces trois points. Le fondateur a répondu qu'ils réagissaient de manière excessive et qu'il avait une confiance absolue dans les compétences du nouveau lead, sur la base de son CV et de l'entretien, ce qui est exactement la raison pour laquelle il a attribué à cette personne le rôle de lead developer en premier lieu.

Que doit faire l'équipe pour :

• Soit jeter le lead hors de l'équipe ou de l'entreprise,

• Soit le forcer à changer son attitude envers l'équipe ?

• Que diriez-vous de travailler avec lui et de ne pas saboter chacun de ses mouvements ?

En toute honnêteté, on dirait qu'il a été amené à faire le ménage, étant donné ce que vous avez posté, cela semble plus que justifié.

Le propriétaire n'est PAS satisfait de votre performance. Il vous appartient de suivre ses conseils pour ce qu'ils valent. Nous, les reliques, avons un peu d'expérience et nous savons ce que les livres ne vous apprendront jamais. Pourtant, plutôt que de considérer cela comme une occasion d'apprendre et de se développer, votre équipe fait une crise de nerfs.

Je ne sais donc pas jusqu'à quel point les membres de votre équipe se sont plaints à votre patron au sujet du développement principal. Mais avez-vous eu une bonne conversation autour de la table avec eux ? Expliquez à votre patron les problèmes que vous rencontrez avec le développeur principal et donnez-lui sa version des faits.

La démission ne devrait être qu'un dernier recours.

Le propriétaire doit engager un responsable du personnel

D'autres réponses ont laissé entendre cela, mais l'éléphant dans la pièce est que le propriétaire (de façon compréhensible) semble avoir des difficultés à remplir avec succès les fonctions du personnel comme l'embauche, la formation, le licenciement, etc. Exemple : le propriétaire emploie une équipe sous-performante, la supporte pendant des années, puis engage un vétéran de 25 ans pour réparer les choses, puis engage un consultant lorsque le vétéran de 25 ans ne peut pas réparer les choses. Le propriétaire ne semble pas savoir comment gérer le volet personnel de l'entreprise. Ce n'est pas grave, il y a des gens qui font cela pour gagner leur vie, et c'est pourquoi la plupart des organisations ont des gestionnaires de personnel. Le propriétaire doit en embaucher un immédiatement. Cela permettra au propriétaire de se concentrer sur l'aspect stratégique de l'entreprise, donc c'est une victoire. Peut-être qu'OP pourrait aider à l'entretien (après tout, le propriétaire semble avoir besoin d'aide à cet égard) ?

Une “ride” que je n'ai pas encore vue ici. Il est assez fréquent que des personnes ayant beaucoup d'expérience se mettent sur la défensive parce qu'elles ne sont pas au courant des développements actuels. J'avais l'habitude de voir la même chose avec les gens qui disaient à quel point le VB6 était horrible par rapport au merveilleux .Net, quand ces gens répétaient simplement des choses qu'ils avaient entendues sur le VB6 et n'en savaient pas vraiment beaucoup. Mais cela ne veut pas dire qu'elles le sont toutes, comme vous le dites. Peut-être que M. 25 ans peut ouvrir son esprit et synthétiser son approche avec le meilleur du statu quo, mais pas s'il a peur d'être moins que parfait et s'il nie avoir peur. En ce qui me concerne, c'est là le vrai problème. Il peut y avoir d'autres problèmes avec les juniors (sur la défensive à cause de leur manque d'expertise, par exemple), mais cela semble être le problème sous-jacent ici.

Si tout le monde se réunit et aborde ses craintes de manière ouverte et honnête, alors ils devraient commencer à aller dans une direction plus positive. Je ne peux pas dire que cela semble être une probabilité élevée, mais c'est ce qu'il faut faire.

1. Toute l'équipe a-t-elle parlé à ce développeur et essayé de lui expliquer les avantages de choses comme le contrôle de version et les IDE ? Une discussion franche en masse peut aider

2. Je suis d'accord qu'insulter d'autres développeurs n'est pas professionnel et cela doit lui être expliqué avec force. Demandez-lui s'il est heureux que les autres adoptent le même ton

3. Demandez-lui s'il subit un quelconque stress au niveau national ou s'il a un problème de santé comme le diabète qui le rend irritable

4. Demandez-lui s'il est heureux de devenir un vieux grincheux dont l'esprit s'atrophie à mesure qu'il n'apprend rien de nouveau

5. Si tout le reste échoue, dites que toutes ses erreurs seront documentées pour sauver votre propre peau et que les conversations avec lui peuvent être enregistrées