Gérer mon collègue désuet


28

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?


2
"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" ". Ce qu'il veut dire ici, c'est qu'IL ne comprend pas ce qui se passe. Nous le faisons :) Semble qu'il a peur d'apprendre autre chose pour améliorer sa productivité.
Damien Roche

7
Votre collègue n'est pas dépassé, il vient de manquer quelques leçons importantes de programmation 101. Le contrôle de version, l'abstraction, etc., tous ces éléments ont été très importants il y a 20 ans ainsi qu'aujourd'hui.
Jas

7
Le terme «archaïque» est un terme plutôt chargé et non éclairé. J'ai quelqu'un avec qui je peux être décrit en des termes similaires à ceux que vous avez utilisés. Cependant, il est considérablement plus jeune que moi.
Projet de loi du

1
Le point sur les bibliothèques est tout à fait valable. Vous avez vraiment besoin de comprendre ce qu'ils font - par exemple, les choses dans les bibliothèques qui créent des threads ou lèvent des exceptions peuvent rendre votre vie TRÈS misérable. Un rapide coup d'œil à leur doco ou code source est généralement suffisant pour satisfaire la curiosité. Ce n'est PAS un argument pour NE PAS utiliser les choses dans les bibliothèques, c'est juste un argument pour savoir ce qu'elles font (et ensuite les utiliser avec bonheur plutôt que dans l'ignorance).
quick_now

Réponses:


25

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.


Je suis d'accord avec cela tout autant que la réponse de @pierre 303. Il quittera le site sombre quand il aura l'air d'avoir de beaux outils avec les gentils.
Kortuk

3
Il lui en faut très peu pour le coder, mais votre code est maintenable. Votre gain s'affichera lorsque le code sera conservé. Un bon service suit le temps passé sur des choses comme la maintenance et verra le temps passé sur votre code plus court, ce qui en vaut un peu plus à l'avance.
Kortuk

+1 pour la démonstration en utilisant les bonnes pratiques de travail en équipe.
Klaim

11

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.


4
303, je pense que c'est le meilleur conseil, un nouveau gars critiquant un collègue expérimenté très compétent au manager va entraîner des sentiments très négatifs, avec le temps vous pouvez vous adapter et aider les autres à s'adapter aussi. J'ai eu de nouvelles embauches avec moi et je pense qu'ils savent quelque chose qui fonctionne mieux et vont au patron, mon patron écoutera tout mais cela me rend fou, car en 3 mois, ils comprennent pourquoi je le faisais comme je l'ai fait et se plaignent du changement. Je pense que c'est un niveau différent, comme nous SVN et OOP, mais la prémisse de base s'applique.
Kortuk

3
Il y a 3 types de personnes dans le monde - ceux qui comprennent le binaire et ceux qui ne le comprennent pas ...
Michael K

L'astuce est de le rendre facile à utiliser ET de montrer qu'il y a des avantages substantiels quand cela compte vraiment. Tout comme les ceintures de sécurité ...

Je ne suis pas d'accord. Certaines pratiques ne sont bonnes que lorsque vous travaillez en solo, et ce gars semble en être plein.
Boris Yankov

Pour en revenir à cette question et à cette réponse, après plus d'un an, l'option 3 s'est avérée être la bonne solution
Martijn

6

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.


J'ai eu de mauvaises expériences en `` essayant de briller '': un référentiel privé n'aide pas beaucoup quand il n'y a pas de concept définitif de `` révision '' (quels changements du collègue à intégrer? Souvent, avec des gens qui n'utilisent pas CVS, c'est comme `` ceci fonction, mais pas celles '). Même chose pour les tests automatisés: à quoi sert une build qui n'est pas réparée par celui qui la casse? vous refactorisez et écrivez les tests, il défacteurs et casse les tests. encore une fois: votre parole contre la sienne, mais maintenant vos tests «échouent», ce qui «prouve» qu'ils n'attrapent rien de précieux. Vous ne pouvez pas exceller contre votre équipe.
keppla

4

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).


1
Je peux coder beaucoup plus rapidement en n'utilisant rien de spécial sur les petits projets, mais, bon sang, vous maintenez mieux une base de code bien conçue. C'est là qu'un bon design est payant. Toute la conception de la révision du code logiciel repose sur le fait qu'il faut plus de temps pour la maintenance que pour le codage pour corriger les bogues.
Kortuk

partie clé "sur les petits projets". Je doute fort que nous parlions ici de petits projets (lire: effort d'équipe).
Damien Roche

totalement en désaccord. cela ne dit rien sur Walter, sauf qu'il sait quelles sont ces bonnes pratiques et comment elles peuvent bénéficier à l'équipe. RAD ne sert pas à ces pratiques, car elles vous ralentissent.
Ross

4

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.


oui, d'accord, mais que peut-il y faire?
Ross

Pourquoi passer du temps à réimplémenter un projet de jouet?

@Andersen parce que certains programmes qui ne veulent pas écouter la raison n'acceptent les preuves qu'une fois qu'elles sont disposées devant eux
Darknight

@Darknight, probablement pas, mais quand même, pourquoi même envisager de passer du temps à réimplémenter des projets de jouets qui ne s'appliquent pas à des problèmes réels?

3

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.


2

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.


"recovery" == rollback.

2

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


5
monter dans la chaîne de commandement fait des ennemis de chaque personne sur laquelle vous avez marché, et ne donne souvent pas de bons résultats.
Kortuk

1

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.


1
C'est s'il veut changer ..
Walter

3
Beaucoup de managers que j'ai eu dans le passé n'apprécient pas que le nouveau gars change quelque chose qui semble fonctionner. Ils apprécient un produit fait rapidement car ils ne comprennent pas parfaitement ce que vous faites. Il semble que vous ayez un patron qui ne soit pas technique, ce qui pourrait nuire grandement à votre section.
Kortuk

1
S'il ne le fait pas, il est encore plus important que le gestionnaire (en supposant qu'il y en ait un) le sache.
Otávio Décio

@Kortuk - c'est un très bon point, et si c'est vrai, l'OP est vraiment en difficulté.
Otávio Décio

Je pense que si le PO tente d'agir pour essayer de changer soudainement ces choses et de les forcer, les doigts se mettent à marcher. Cela fait des ennemis et pourrait nuire à un environnement de travail où il pourrait apprendre beaucoup de son collègue.
Kortuk

1

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.


1

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).


1

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 ...


le contrôle de version fournit également l'historique. Important lorsque les gens ne sont plus là.

0

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.


1
marcher constamment sur les pieds des uns et des autres est un signe que le logiciel est mal architecturé. Cela n'a rien à voir avec le contrôle de source et peut même empirer.
deadalnix

@deadlnix Cela pourrait être la raison aussi, mais je pense que cela peut aussi être attribué, dans certains cas, à une utilisation trop zélée de la branche quand ce n'est pas la solution appropriée.
Nicole
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.