Gérer mon collègue désuet

Je suis un programmeur assez jeune et je travaille au service informatique d'une entreprise de taille moyenne. J'ai un collègue et c'est un très bon programmeur Visual Basic 6. Et je veux dire vraiment bien. Honnêtement. Il peut fournir des applications fonctionnelles, contenant très peu de bogues, dans le temps dont j'ai besoin pour prendre ma première tasse de café et démarrer ma machine. Il est juste si bon.

Le fait est que nous travaillons avec une équipe et son style de travail est complètement dépassé. Il ne croit pas au logiciel de version (si vous vous assurez juste que votre code est correct, vous n'avez pas besoin de toutes ces bêtises). Ne croit pas au déploiement (je peux fournir un exécutable qui fonctionne. La façon dont cela est déployé est pour les administrateurs système de comprendre). Ne croit pas à l'abstraction. ('Si vous voulez créer un sous-programme, allez-y, mais n'appelez aucun sous-programme à partir de ce sous-programme. Cela devient désordonné de cette façon et le code est difficile à suivre. De cette façon, chacun peut suivre chaque étape du chemin. 'ou' ouais, bien sûr, vous pouvez utiliser cette bibliothèque pour le faire pour vous, mais de cette façon, vous ne comprenez pas vraiment ce qui se passe ') et ne croyez certainement pas en la POO. (nous travaillons sur VB.net)

Il est si bon dans ce qu'il fait, il peut livrer des applications beaucoup plus rapidement que moi. Mais cela ne fonctionne tout simplement pas en équipe. Notre autre membre de l'équipe est calme et n'aime pas s'exprimer, même s'il a tendance à être d'accord. Notre manager pense que je fais valoir des arguments valables, mais ce n'est pas un programmeur.

J'ai vraiment du mal à maintenir les programmes qu'il a écrits, et cela ne crée pas une bonne ambiance d'équipe. Selon vous, quelle est la meilleure chose à faire pour moi?

Cela ressemble à l'un de ces "C'est un bon gars mais ..." où vous savez que la vérité arrive. Et la vérité sonne comme s'il n'était pas vraiment un bon ingénieur. Un bon logiciel ne concerne pas seulement la vitesse de travail et de développement. Il s'agit également des autres choses que vous avez mentionnées - maintenabilité, compatibilité, abstraction (pour une efficacité future), etc.

Donc, cela étant dit, il semble que vous ayez un développeur de problème sur les mains. Ce qui est pire pour vous, c'est qu'il a fait ses preuves et s'est probablement mis en travers de ses voies. Alors que peux-tu faire?

• Travaillez autour de lui.
• Efforcez-vous de produire vos projets selon un calendrier aussi serré que lui.
• Et si vous ne le pouvez pas, produisez un meilleur résultat.
• Au fil du temps, ces concepts éprouvés qu'il rejette commenceront à porter leurs fruits.

D'un autre côté, si vous êtes obligé de travailler à sa façon, partez.

N'essayez pas de changer votre collègue. Vous le décrivez comme quelqu'un capable de fournir un logiciel fonctionnel. Il est probablement trop tard pour l'intégrer dans l'équipe non plus.

Vous avez donc deux choix:

• Adaptez- vous. Peut-être qu'avec le temps vous pourrez le convaincre de l'utilité d'un système de contrôle de source? Vous devrez augmenter votre cercle d'influence . Plus il est résistant au changement, plus vous aurez besoin de temps.

• Retirez-vous du team. Vous avez beaucoup de points pour justifier cela. Vous devriez peut-être le laisser gérer ses propres applications et vous consacrer à de nouvelles choses.

• Retirez-vous du company. Parfois, c'est la seule solution.

Si j'étais vous, je mettrais en place mon propre système de contrôle des sources dès maintenant. Commencez à l'utiliser pour tout ce que vous codez et administrez-le afin que les autres membres de votre équipe aient des comptes et puissent y accéder. Vos autres collègues seront probablement enthousiastes à l'idée de l'utiliser.

Votre collègue qui ne croit pas à de telles pratiques n'est peut-être pas facile à convaincre. Cependant, tout code avec lequel vous êtes obligé de travailler et qui a été écrit par lui doit être placé dans le contrôle de version afin que vous puissiez travailler avec. Lorsqu'il a besoin d'accéder à vos modifications, envoyez-lui un simple ensemble d'instructions étape par étape pour extraire votre code du référentiel.

Vous n'avez pas besoin d'être combatif ou d'aller au-dessus de lui pour l'impliquer dans des processus plus modernes. Parfois, suivre votre propre chemin et être un leader dans l'action est plus efficace que d'essayer de convaincre quelqu'un avec des mots. Pas de bébé. S'il commence à être plus réactif au contrôle de version, commencez à refactoriser les sous-programmes et à ajouter des tests unitaires pour vous protéger contre les changements. Automatisez les tests et montrez-lui comment il peut accéder aux résultats dès qu'il effectue les checkins.

Souvent, les gens résistent simplement parce qu'ils n'aiment pas le changement. Mais si les changements leur sont présentés de manière progressive et d'une manière qui les rend faciles à suivre, ils verront souvent les avantages très rapidement.

Surtout, rendez-lui le plus simple possible (Keep It Simple Stupid). Permettez-lui de commencer à suivre ces pratiques à ses propres conditions. Mais ne vous laissez pas traîner.

Je vais être honnête, tu ne peins pas une bonne image de lui. Méthodes archaïques, logiciels difficiles à maintenir, tenaces à de nouvelles façons de travailler, contre l'abstraction, etc., etc.

D'après ce que vous avez dit, s'il produit un logiciel largement sans bogue PLUS RAPIDEMENT que vous ne l'êtes sans utilisation de bibliothèques réutilisables et de modèles de conception visant à un développement rapide d'applications, cela en dit plus sur vous-même que lui ...

..à propos de lui..yeh, trouvez un moyen de NE PAS travailler avec lui et de NE PAS être associé à son travail. On dirait qu'il a une attitude égoïste typique envers son travail. Vous ne pouvez pas travailler avec quelqu'un comme ça, vous ne pouvez que les observer travailler et ranger après eux (comme vous l'êtes actuellement).

J'ai déjà vu ça avant ,

Et je suis presque prêt à parier: ce type de gars n'apparaît que "vite" parce qu'il a un ensemble de "schémas" éprouvés dans sa tête.99% des applications Line of Business sont CRUD , des trucs de base.

Il utilise probablement une tonne de copier-coller à partir de son propre code existant (rien de mal à cela).

Mais..

Au moment où il rencontre quelque chose de complexe à distance, il tombe, pourquoi? car il ne correspond plus à aucun des "motifs" de base.

Un petit défi ...

Je créerais un projet sur le côté, un projet complexe qui bénéficie vraiment de la POO et de la réutilisation du code.

Montrez-lui ensuite ce projet et demandez-lui de l'implémenter fonctionnalité par fonctionnalité.

Je parierais alors que son code sera presque certainement 10 fois plus grand et 10 fois plus laid s'il l'avait implémenté à sa manière.

Regardez cela du côté des entreprises.

Vous prenez plus de temps pour produire du code plus bogué. Vous produisez moins de revenus donc vous sucez.

Si, au fil du temps, vous pouvez inverser cela, vous pouvez inverser cela.

Mais peut-être, juste peut-être, ce programmeur désuet peut réellement vous apprendre quelques choses sur la production rapide de code qui est si exempt de bogues? Peut-être que ses techniques ne sont pas aussi anciennes que vous le pensez?

Je trouve suspect que quelqu'un puisse produire un si bon code sans de très bonnes pratiques. Vous pourrez peut-être apprendre ces pratiques et les appliquer aux "meilleures pratiques" et aux choses à la mode que vous comprenez.

Si votre manager n'est pas un programmeur, essayez de le dire en termes qu'il comprendra.

• Nous devrions utiliser sourecontrol parce que si nous ne le faisons pas, nous pourrions avoir de gros problèmes de récupération

• Cela me prend x temps de plus car il refuse de suivre des processus assez basiques.

D'un autre côté, assurez-vous de ne pas trop vous laisser prendre à la perfection, c'est-à-dire que c'est une meilleure pratique que nous devons suivre. Il est probable que votre collègue ait beaucoup à ajouter, vous devrez peut-être le pousser lentement dans la bonne direction.

On dirait que votre collègue n'a jamais évolué en équipe. Ce genre de partenaire gourou en solo ne permet pas une bonne dynamique de groupe. Donc, parlez-en à votre supérieur et essayez de discuter des avantages et des inconvénients avec votre partenaire pour le faire. Si vous pouviez le faire de la meilleure façon, mais s'il refuse, montez dans le commandement

Parlez à votre manager, simplement et simplement comme vous l'avez fait ici. Il y a un potentiel de croissance ici - si votre collègue est bon comme vous dites qu'il ne devrait pas être très convaincant pour le faire commencer à se convertir à l'utilisation du contrôle de source et de .Net avec des concepts OO appropriés.

Je parlerais aux autres pour obtenir une image plus large de l'apparence des choses où vous êtes. Peut-être y a-t-il des séparations afin que son code ne doive pas trop se mélanger avec d'autres car il y a le potentiel de le séparer dans sa propre zone d'une manière que cela pourrait être géré, bien que ce soit plus pour un plus haut comme un directeur ou CIO à faire plutôt qu'un développeur.

Vous voudrez peut-être lui parler pour voir quel type de systèmes plus grands il a construit car il existe de grands systèmes d'entreprise qui ont tendance à être beaucoup de blocs de construction où le code de spaghetti peut se heurter au pays de "Oh, c'est pourquoi OOP peut être bon! " bien que cela prenne parfois le cas où il s'avère très utile de voir comment cela peut être une chose utile à avoir dans sa boîte à outils.

L'apathie peut être un autre suspect pour voir si c'est pourquoi il rejetterait certaines choses que je considérerais comme fondamentales en termes de la façon dont j'ai tendance à concevoir du code, mais alors j'ai peut-être eu trop de Kool-aid.

Mettez-le au défi (dans le bon sens) de vous prouver le contraire, montrez-lui le côté cool des outils et des pratiques. Ne patronnez pas.

Par exemple, il ne croit peut-être pas au versionnage comme une aide, mais lui montre comment créer des branches / fusionner et comment il peut travailler sur plusieurs fonctionnalités expérimentales sans avoir besoin d'avoir une multitude de fichiers.

En ce qui concerne la POO, montrez-lui quelques modèles de conception sympas / complexes, tels que le modèle de commande, le modèle de tâche et comment cela peut lui faire gagner un temps précieux, et toute votre équipe.

Si vous ne l'intéressez pas le moins du monde ... c'est peut-être un cas perdu, mais là encore, vous avez les outils pour votre équipe et vous pour le surpasser. Essayez d'utiliser un logiciel de référentiel qui affiche / envoie par e-mail des messages de validation que votre gestionnaire peut voir, ce qui apportera de la transparence à votre gestionnaire et laissera votre collègue hors de l'image (bitbucket.org a des référentiels privés gratuits avec un espace illimité, si vous utilisez mercurial).

En fin de compte, n'essayez pas de convaincre avec des mots mais avec des actions irréfutables, c'est la meilleure façon de traiter les personnes têtues à mon humble avis (la psychologie inversée fonctionne parfois aussi, lol).

eh bien, les techniques que vous mentionnez sont évidemment bonnes, mais vous devez également vous demander si vous les proposez comme idéologie. Je trouve que les programmeurs plus jeunes ont tendance à être un peu évangéliques à propos de ce qu'ils ont appris au collège. rappelez-vous que ces techniques sont bonnes à cause de résultats: le contrôle de version permet un développement simultané, un suivi plus clair de la conception, du développement, des tests, des étapes de correction de bogues. si vos projets sont vraiment à court terme, beaucoup d'entre eux sont tout simplement inappropriés et finiront par vous rendre moins agiles. ce n'est tout simplement pas le cas que la meilleure pratique signifie utiliser toutes les meilleures pratiques possibles. l'abstraction, par exemple, peut certainement être plus un passif qu'une aide, au moins quelques fois. le contrôle de version est plus logique lorsque vous avez des délais de développement étendus, du code complexe, plusieurs programmeurs - il y a une sorte de synergie, qui est difficile à obtenir au coup par coup.

Je pense que le point de départ est de surveiller la réutilisation potentielle - au fur et à mesure que les projets avancent, pensez à des points communs ou à des cadres plus généraux. essayer de sortir devant les projets serait un geste puissant, et pourrait vous permettre de travailler avec plus de technique ...

Vous devriez demander à votre superviseur de faire une présentation pour TOUS sur les raisons pour lesquelles le "versionnage" du logiciel est bon. Ne démarquez pas votre collègue.

Je suis moi-même sceptique vis-à-vis des logiciels de contrôle des sources, car je vois des gens en abuser tout le temps - comme un moyen d'éviter le travail.

Mes collègues fusionnent constamment, marchant constamment les uns sur les autres. Mais une bonne conférence amicale sur ses avantages serait une bonne chose et stimulerait les discussions.