Un ordre d'entreprise pour passer à un certain IDE est-il un drapeau rouge? [fermé]

J'ai récemment rejoint une startup en pleine croissance. Au cours des 3 derniers mois, l’équipe de développement est passée de 4 à 12 personnes. Jusque-là, elle laissait beaucoup de côté pour ce que les développeurs faisaient auparavant. En fait, l’un des attraits que j’ai initialement attiré au sein de la société est que la plupart des programmeurs utilisent Linux, ou le système d’exploitation qu’ils jugent le mieux adapté à leurs efforts.

Maintenant, les ordres, sans discussion, sont descendus que tout le monde doit passer à Eclipse. Un bon éditeur. Je préfère SublimeText2, mais c'est juste mon goût personnel.

Soyons clairs: nous sommes une équipe JS qui utilise Backbone et Eclipse n’est tout simplement pas bon pour comprendre le code Backbone. Cela signifie que les membres de l'équipe qui utilisent un / good / IDE (PHP Storm) doivent recommencer à faire beaucoup de recherches pour trouver-oh-attendre-où-était-je-trois-étapes-il y a genre de choses au lieu de simplement ctrl + clic et utilisation de l’arrière / de l’avant - diminuant probablement la productivité de 15% et le plaisir de 50% ...

Est-ce un drapeau rouge? Il semble capricieux et déraisonnable de contrôler de dire aux développeurs (non-MS) quels IDE ou ensembles d'outils à utiliser s'ils sont déjà installés et productifs.

"Maintenant, les ordres, sans discussion , sont descendus que tout le monde doit passer à Eclipse."

Je pense que c'est le drapeau rouge. Votre équipe est l’expert en développement de logiciel et celle qui sera touchée par la décision. Pourtant, vous n’avez pas eu le droit de dire un mot dans la discussion qui a abouti à cet ordre?

Cela ressemble à une gestion excessive par des patrons pointus. La personne / l'équipe responsable de la prise de décision a-t-elle un aperçu pertinent de cette décision?

Étant donné que les décideurs sont suffisamment qualifiés pour prendre une telle décision, ne pas demander l'avis de l'équipe de développement présente au moins deux inconvénients:

• L'équipe ne se sent pas impliquée. L'implication de l'équipe devrait être une priorité pour la gestion. Je ne voudrais pas travailler en tant que développeur quelque part où mon opinion sur des questions aussi essentielles que IDE n’est pas suffisamment valorisée pour pouvoir être sollicitée. Accepter que demander l’avis de quelqu'un et décider de ne pas le prendre soit pire peut être, mais dans ce cas, je m'attendrais à une solide justification de cette décision.

• La direction, quelle que soit son expérience, ne travaille pas à 100% avec le développement de ce code spécifique. Il serait naïf de supposer que ceux qui le font n’ont pas du tout de perspicacité. Bien sûr, il se peut que les responsables aient pensé à tout ce que les développeurs proposent, mais le seul moyen de savoir est de demander.

Il est raisonnable que lorsque vous travaillez ensemble sur un projet commun, vous disposiez sur tous les postes de travail de tous les outils disponibles pour éditer / construire / déboguer votre logiciel, et que les principaux outils permettant de réaliser environ 90% du développement sont connus de tous. l'équipe. Cet objectif est plus difficile à atteindre si votre équipe grandit et si chacun utilise son ensemble d'outils préféré: plus de gens, plus d'opinions. Et le travail administratif devient également plus facile si vous ne laissez pas le nombre d'outils augmenter plus que nécessaire.

Bien sûr, si un développeur insiste pour utiliser son éditeur préféré, cela peut être correct tant qu'il peut s'assurer que le code source ne se présente pas ou ne se comporte pas différemment dans l'éditeur principal de l'équipe (dans votre cas, Eclipse), alors B doit éditer la source de dev A, dev B ne devrait pas être obligé d'apprendre l'éditeur favori personnel de A pour pouvoir changer la source efficacement. Mais attention, si les deux doivent travailler ensemble de temps en temps devant le même écran (ou faire de la programmation en binôme), les choses sont souvent plus faciles si l'éditeur choisi est bien connu des deux.

Pour la programmation en paires, il est bon que les deux parties situées devant l'écran possèdent les mêmes compétences lors de l'utilisation du clavier. Il est également intéressant de savoir que, si votre projet a des besoins de configuration particuliers dans l'EDI, il est configuré de la même manière pour tout le monde. Obtenir un nouveau développeur est plus facile lorsque les outils sont les mêmes pour tout le monde.

Mais si vous comparez cela à simplement essayer d'être le plus efficace possible, cela ne vaut vraiment pas la peine

Oui, c’est un peu le signe que la direction se considère comme un meilleur juge des outils avec lesquels vous seriez plus efficace que vous ne l’êtes.

Ce n'est pas un drapeau rouge en soi.

Parfois, la direction doit prendre des décisions . Toute question nécessitant une normalisation sur quelque chose a tendance à tomber dans cette catégorie. J'ai déjà travaillé chez un client qui avait laissé les normes dériver pendant quelques années et qui disposait de plus de 20 outils SCM différents. Ce qui a commencé comme un choix indépendant par différentes équipes de développement s'est transformé en un cauchemar logistique qui entravait gravement le partage des compétences et la collaboration sur le code au sein de l'organisation. La construction intégrée était ..... euh ..... pas très intégrée .....

De plus, il n'est ni pratique ni nécessaire de consulter tout le monde pour chaque décision . La mesure dans laquelle cela doit être fait dépend de la culture de l'organisation et de l'importance / de la complexité de la décision. Généralement, vous prenez l'une de ces options moins consultées:

1. Prenez la décision vous-même, si vous connaissez suffisamment le pour et le contre et que ce n'est pas une décision suffisamment importante pour nécessiter une large consultation.
2. Consultez quelques personnes clés (qui seraient probablement les développeurs principaux les plus qualifiés pour prendre la décision).
3. Soulignez le fait que vous prenez une décision pour toutes les personnes susceptibles d'être touchées (courrier électronique, assemblée publique, réunions d'équipe). Dites ce que vous pensez que la bonne décision est, mais que vous êtes prêt à changer cela si de nouvelles preuves démontrent le contraire. Invitez les gens à se manifester individuellement s'ils ont des points de vue importants
4. Invitez les gens à former une sous-équipe pour examiner les options et recommander une décision. Bonne option s'il s'agit véritablement d'un proche appel, vous ne connaissez pas la réponse et vous voulez que les personnes impliquées soient impliquées dans la décision.

Pour quelque chose comme l’outillage de développeur (qui est une question potentiellement litigieuse), je ferais probablement 2 suivis de 3 ou 4. c’est-à-dire qu’il y aurait certainement des personnes avec lesquelles je ne parlerais pas personnellement, mais la plupart des autres des personnes clés aurait une chance de contribuer à la prise de décision.

Pour moi, le véritable drapeau rouge serait visible si vous estimez fermement que la mauvaise décision a été prise (mauvais == cela nuit à la société plutôt qu’à votre outil préféré non choisi). Comment réagit la direction lorsque vous soulevez ce problème:

• Une bonne direction sera à l'écoute de vos arguments, merci sincèrement pour vos commentaires et réexaminez leur position au cas où vous auriez soulevé de nouvelles idées . Ils peuvent toujours ne pas être d'accord avec vous et s'en tenir à leur décision, mais ils comprendront que vous leur en avez parlé et vous font la courtoisie de dire pourquoi ils s'en tiennent à leur décision. Ils pourraient même changer la façon dont ils prennent de telles décisions à l'avenir, et si vous faites valoir des arguments judicieux, vous pourrez être inclus dans leur liste de "personnes intelligentes à demander".
• Une mauvaise gestion deviendra défensive, affirmant que "la décision est prise" et d'autres tactiques similaires pour éviter de faire face au fait qu'ils ont peut-être pris une mauvaise décision. Ils peuvent vous voir comme un "fauteur de troubles". La société souffre, tout comme votre confiance en la direction. C'est un vrai drapeau rouge! Sortez pendant que vous le pouvez!

Si vous utilisez maven ou quelque chose de similaire, peu importe l'EDI que vous utilisez. Il peut y avoir des cas où l'un est lié à un IDE spécifique comme eclipse, s'il existe des plugins sur lesquels vous comptez.

Je pense que vous devriez pouvoir choisir votre propre IDE, celui dans lequel vous êtes le plus productif. Cependant, comme je l’ai déjà dit, il est parfois judicieux d’utiliser un IDE standard.

J'aurais l'IDE "mandaté par l'entreprise" installé, mais je ferais quand même l'essentiel de mon travail dans l'IDE que je voulais - ce n'est pas comme si tout le monde pouvait dire quel IDE était utilisé pour éditer un fichier source.

Sur le plan IDE vs éditeur ... pour presque toutes les langues, je préfère fortement un IDE (IntelliJ) car il peut faire beaucoup plus pour vous qu'un éditeur ne le peut. Il y a des choses pour lesquelles je retourne à ST2 ou à Emacs, mais pour le codage quotidien, malgré le fait que j'aime les deux ST2 / Emacs, l'IDE gagne presque toujours.

Chaque équipe dans laquelle j'ai été formé a eu une multiplicité d'IDE et de rédacteurs: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - cela n'a jamais été un problème. Jamais.

Pour moi, cela témoigne d'un malentendu aux niveaux supérieurs de l'organisation quant à ce qui compte vraiment. Ce qui compte, c'est de laisser les bons codeurs faire ce dont ils ont besoin et d'utiliser les outils qui les rendent plus à l'aise. L'uniformité des IDE a très peu à voir avec la communication réelle qui a lieu sur les questions essentielles de l'architecture des objets, des tests unitaires, des algorithmes, etc.

Avoir le même IDE que le prochain type signifie simplement que nous savons tous les deux comment parcourir le code avec les mêmes raccourcis et comment notre compilation / configuration est configurée. Rien de ce qui importera quand on parle de vrais problèmes de code.

Regardez, c'est habitable, en fonction d'autres facteurs de l'entreprise. Vous pouvez toujours utiliser votre propre éditeur préféré pour les tâches quotidiennes. Et peut-être que votre groupe fait d’autres choses formidables qui créent une culture remarquable. Mais les IDE mandatés sont un énorme faux pas, OMI. Pour moi, si j'interviewaient avec une compagnie et ils m'a informé que je IDE autorisé à utiliser, je les remercier poliment pour leur temps.

Dans notre atelier Ruby, il est fortement recommandé d’utiliser l’EDI (RubyMine) qui plait à la plupart des membres de l’équipe, car nous savons que cela fait le travail et que nous pouvons nous apprendre des raccourcis, etc.

Les développeurs sont libres d’utiliser un IDE différent, mais nous leur demandons d’avoir de solides compétences dans cet éditeur s’ils le souhaitent. Si nous voyons quelqu'un qui a du mal à naviguer dans son projet ou à éditer du texte dans son FooEdit personnalisé, RubyMine l'est pour eux.

Si un programmeur est un expert dans un IDE donné, il devrait l’utiliser. S'ils ne sont pas experts dans un IDE, il y en a probablement un ou deux qui sont très courants pour votre langage de programmation ou au sein de votre équipe, et il est probablement logique qu'ils l'apprennent.

Être obligé de standardiser sur un IDE semble une idée terrible.

Les raisons pour lesquelles une entreprise doit forcer un éditeur particulier ou un logiciel en général sur ses développeurs doivent être examinées. La partie paranoïaque (peut-être pas le mot que je cherche) pense que le suivi de la productivité pourrait s’ajouter à l’éclipse qu’ils demandent aux développeurs d’installer. Une pensée beaucoup moins paranoïaque (encore) serait qu’ils ont passé du temps à ajouter à cet IDE des outils de génération de produit qui faciliteraient beaucoup les choses si tout le monde appuyait sur le même bouton pour tester et construire leur branche de code.

Quoi qu’il en soit, ce que je veux dire, c’est que c’est probablement plus qu’une simple bureaucratie, ou une méthode pour déconner avec les développeurs.

C'est un drapeau rouge massif. Chaque entreprise a quelques idées stupides, mais si d’autres drapeaux rouges continuent de venir, quittez-les.

Il est facile de perdre la motivation qui sous-tend certaines décisions - en particulier avec une équipe en croissance rapide. La motivation pour passer à Eclipse pourrait bien être simplement due au fait que la plupart des développeurs semblent perdre beaucoup de temps à la simple configuration de l'EDI et que l'expertise de votre entreprise est limitée.

Je voudrais simplement prendre l’ordre de passer à Eclipse comme signifiant que vous devriez avoir la configuration d’Eclipse au cas où vous en auriez besoin, mais continuez votre travail dans votre éditeur favori. (Vous devrez peut-être passer progressivement à Eclipse si votre société commence à déployer des outils intéressants dans Eclipse.)

Drapeau rouge: J'attendrais s'il y a quelques commandes de plus irrationnelles avant de m'inquiéter.

Une start-up essaie généralement de rester agile assez longtemps pour élaborer un modèle d'entreprise durable. Une fois que l’argent est compris, la direction intervient pour développer l’entreprise. C’est généralement à ce moment que tous les premiers employés du secteur de la technologie commencent à partir, alors que les processus techniques se resserrent.

Comme vous le savez, vous ne savez pas ce que le code fera réellement jusqu'à ce que vous l'exécutiez. Turing l'a prouvé à ses débuts en informatique. Cela signifie qu’il n’existe pas de mesure significative de la productivité en matière d’écriture de logiciels. Cependant, pour que la direction puisse faire son travail, la productivité doit être lisible. Puisque vous ne pouvez pas mesurer le code (et que les gens ont essayé - des lignes de code, par exemple), ils mesureront ce qu'ils peuvent voir. Les programmeurs sont plus lisibles que les logiciels qu'ils développent. L’équipe de gestion type essaie de contrôler les programmeurs afin de leur rendre ces informations lisibles (au lieu de faire leur vrai travail: se mettre à l’écart). Et comme ils mesurent les mauvaises choses, cela ne fonctionne pas très bien.

Cela dit, vous pouvez toujours aller très loin avec une équipe faiblement couplée. L'équipe de développement de Github compte environ 50 personnes et enfreint chaque règle des manuels de gestion d'entreprise. Ils semblent bien se porter. Les bugs sont corrigés (éventuellement). Les fonctionnalités sont ajoutées. Les incendies sont éteints.

Ce qui est un gros drapeau rouge, c’est qu’ils essaient d’agrandir les choses sans savoir comment gagner de l’argent. À ce stade, vous devez vous demander quelle est la valeur de vos options et de vos subventions non acquises.

C'est sûrement une mauvaise idée. Il est inévitable que l'équipe devienne moins productive car elle doit apprendre à utiliser de nouveaux outils. Et même dans ce cas, ils ne seront pas aussi efficaces qu'avec les outils déjà utilisés .

Depuis que j'ai moi-même essayé divers outils, j'ai toujours eu à un moment donné le sentiment que "ça alors, cet éditeur me gêne avec <insérez un bogue / une différence parmi les outils préférés>". Ce sera donc un inconvénient moral.

Mais bien sûr, il y a aussi des pros pour que toute une équipe utilise les mêmes outils. Partage des configurations, skripts, plugins et tout ce genre de choses. Ce qui ne serait pas possible avec une diversité d'outils.

D'un autre côté ... ce dernier élément ne serait pas nécessaire si tout le monde utilisait son logiciel préféré. ;)

Vous pouvez "utiliser" Eclipse tout en continuant à taper dans SublimeText2.

Cela signifie qu’Eclipse doit être installé et configuré pour vos projets et s’y familiariser pour que vous puissiez l’utiliser aussi facilement si, par exemple, la programmation par paires. Personne (ou du moins ne devrait) se soucier de l’éditeur que vous utilisiez pour taper un morceau de code que vous avez engagé tant que le maintien de votre configuration parallèle ne prend pas trop de temps et que vous ne vous coupez pas les environnement de développement standard.

Si vous utilisez Git et que votre branche est en panne, vous ne devriez de toute façon pas utiliser les éditeurs des autres. Vous pouvez simplement pousser une branche et demander à un autre développeur de la tirer pour la faire fonctionner s'il ne peut vraiment pas comprendre votre ensemble d'outils. Forcer tout le monde à utiliser le même éditeur ressemble à une commande émanant d'un chef d'entreprise qui veut paraître intelligent mais ne comprend pas vraiment la façon dont vous opérez.

Si vous pensez à cela du point de vue de la direction, la raison pour laquelle ils peuvent le faire est pour la conformité légale. Il incombe à la société de veiller à ce que chaque outil utilisé soit utilisé légalement et ne gêne pas le produit en cours de développement. (Certains éditeurs sont gratuits pour un usage personnel, mais pas à d'autres fins, etc.) L'audit de chaque outil que chaque développeur peut utiliser peut coûter cher. J'ai vu que sur des projets où les délais sont serrés, la direction sera prudente quant aux outils / bibliothèques / etc. utilisés pour minimiser les modifications ultérieures du projet dirigées par les juristes.

Sur les projets de sécurité supérieure, il est également important de savoir où les IDE stockent les fichiers temporaires et quelles informations sont stockées entre les sessions.

Tout dépend des raisons pour lesquelles ils doivent recommander Eclipse. Si les développeurs rencontrent des difficultés pour configurer leurs environnements parce que tout le monde organise les choses différemment, il peut y avoir une raison de recommander une camisole de force. Cependant, si tout le monde était heureux et productif d'utiliser ce qu'il voulait, il n'y a aucune raison d'imposer un changement à quelque chose d'aussi profondément impliqué dans le processus de création.

Eclipse est bien plus qu'un éditeur: vous pouvez continuer à utiliser votre éditeur favori pour éditer votre code et à vous fier à Eclipse pour le contrôle de source, le débogage et tout ce que le flux de production mandaté par la société souhaite utiliser.

Une dernière chose - le processus de mise en application à ce niveau peut indiquer que la société a l'intention d'élargir l'équipe de développement et de mettre en place une certaine structure afin que les nouveaux coéquipiers puissent être productifs plus rapidement. Si vous pensez que Rails (ou Django) est un framework "basé sur l'opinion", vous vous rendrez compte que la structure facilite la compréhension des nouvelles applications.

Le drapeau rouge n’est pas tant qu’un seul éditeur / éditeur est imposé à tous les développeurs, mais que cette décision, et en particulier la décision concernant le choix de l’éditeur / éditeur, n’a pas été prise par tous les développeurs, et peut-être même aucun des leur!?!

Certes, il serait préférable que les développeurs parviennent à un consensus, en particulier parce qu'ils sont évidemment les mieux qualifiés pour la décision (du moins sur quel éditeur / IDE). Il peut y avoir de bonnes raisons pour se conformer et cette décision devrait peser de préférence dans les préférences de la direction, mais quel éditeur / IDE aurait dû être la décision de tous les développeurs.

Il serait facile de faire voter 12 développeurs. Certes, il y avait suffisamment de temps pour le faire! De toute façon, la conclusion aurait été pénible pour certains et elle aurait peut-être même fini par devenir Eclipse, mais il serait beaucoup plus discutable de qualifier l’exigence de "drapeau rouge".