Ist eine Firmenbestellung, zu einer bestimmten IDE zu wechseln, eine rote Fahne? [geschlossen]

Ich bin kürzlich einem schnell wachsenden Startup beigetreten. In den letzten 3 Monaten ist das Entwicklerteam von 4 auf 12 gewachsen. Bis jetzt waren sie sehr laissez-fair darüber, was Entwickler früher für ihre Arbeit getan haben. Tatsächlich war eines der Dinge, die ich anfangs an dem Unternehmen attraktiv fand, dass die meisten Programmierer Linux verwendeten oder welches Betriebssystem sie für ihre Bemühungen am besten hielten.

Jetzt ist ohne Diskussion der Befehl gekommen, dass jeder zu Eclipse wechseln soll. Ein guter Redakteur. Ich bevorzuge SublimeText2, aber es ist nur mein persönlicher Geschmack.

Um ganz klar zu sein: Wir sind ein JS-Team, das Backbone verwendet, und Eclipse ist einfach nicht gut darin, Backbone-Code zu verstehen. Dies bedeutet, dass diejenigen im Team, die eine / good / IDE (PHP Storm) verwenden, wieder eine Menge Dinge tun müssen, die vor drei Schritten gesucht und gefunden wurden Anstatt nur Strg + Klicken und Vor- / Zurück-Taste zu verwenden - verringert sich wahrscheinlich die Produktivität um 15% und die Freude um 50% ...

Ist das eine rote Fahne? Es scheint launisch und unangemessen zu sein, Entwicklern (Nicht-MS) mitzuteilen, welche IDE oder Tool-Sets sie verwenden sollen, wenn sie bereits etabliert und produktiv sind.

"Jetzt sind Befehle ohne Diskussion gekommen, dass jeder zu Eclipse wechseln soll."

Ich denke, das ist die echte rote Fahne. Ihr Team ist der Experte für Softwareentwicklung und derjenige, der von der Entscheidung betroffen ist, und dennoch haben Sie in der Diskussion, die zu dieser Bestellung geführt hat, kein Wort verloren?

Es hört sich an, als würden spitze Chefs überhand nehmen. Hat die entscheidende Person / das entscheidende Team relevante Einsichten für diese Entscheidung?

Angesichts der Tatsache, dass die Entscheidungsträger für eine solche Entscheidung qualifiziert genug sind, hat die Abwesenheit der Meinung des Entwicklerteams mindestens zwei Nachteile:

• Das Team fühlt sich nicht involviert. Die Einbeziehung des Teams sollte für das Management Priorität haben. Ich möchte nicht irgendwo als Entwickler arbeiten, wo meine Meinung zu zentralen Themen wie IDE nicht genug gewürdigt wird, um überhaupt gefragt zu werden. Zugegeben, dass es schlimmer sein kann, jemanden nach seiner Meinung zu fragen und sich dann dagegen zu entscheiden, aber in diesem Fall würde ich eine solide Begründung für diese Entscheidung erwarten.

• Das Management, wie erfahren es auch sein mag, arbeitet nicht zu 100% mit der Entwicklung dieses spezifischen Codes. Angenommen, die Leute, die überhaupt keine interessanten Einsichten haben, wären naiv. Natürlich kann es sein, dass die Manager an alles gedacht haben, was die Entwickler sich ausgedacht haben, aber der einzige Weg, dies zu wissen, ist zu fragen.

Wenn Sie an einem gemeinsamen Projekt arbeiten, ist es vernünftig, dass Sie auf jeder Workstation alle Tools zum Bearbeiten / Erstellen / Debuggen Ihrer Software zur Verfügung haben und dass die Kerntools für etwa 90% der Entwicklung jedem in bekannt sind Die Mannschaft. Dieses Ziel ist schwieriger zu erreichen, wenn Ihr Team wächst und jeder sein persönliches Lieblings-Toolset verwendet - je mehr Leute, desto mehr Meinungen. Und die administrative Arbeit wird auch einfacher, wenn Sie die Anzahl der Tools nicht mehr als nötig anwachsen lassen.

Wenn ein Entwickler darauf besteht, seinen persönlichen Lieblingseditor zu verwenden, kann dies in Ordnung sein, solange er sicherstellen kann, dass die Quelle im Haupteditor des Teams (in Ihrem Fall Eclipse) nicht anders aussieht oder sich anders verhält B muss die Quelle von Entwickler A bearbeiten, Entwickler B sollte nicht gezwungen sein, den persönlichen Lieblingseditor von A zu lernen, um die Quelle effektiv ändern zu können. Aber Vorsicht, wenn die beiden von Zeit zu Zeit vor dem gleichen Display zusammenarbeiten müssen (oder eine Paarprogrammierung durchführen müssen), ist es oft einfacher, wenn der ausgewählte Editor beiden bekannt ist.

Aus Gründen der Paarbildung ist es schön, wenn beide Teilnehmer vor dem Bildschirm die gleichen Fähigkeiten haben, wenn sie die Tastatur verwenden. Es ist auch gut zu wissen, dass Ihr Projekt, wenn es in der IDE spezielle Konfigurationsanforderungen gibt, für alle gleich konfiguriert ist. Es ist einfacher, einen neuen Entwickler zu finden, wenn die Tools für alle gleich sind.

Aber wenn man das damit vergleicht, nur zu versuchen, am effektivsten zu sein, dann ist es das nicht wirklich wert

Ja, es ist ein bisschen wie eine rote Fahne, dass sich das Management ein besseres Urteil darüber bildet, mit welchen Tools Sie effizienter arbeiten als mit Ihnen.

Es ist keine rote Fahne für sich.

Manchmal muss das Management Entscheidungen treffen . Alle Probleme, bei denen eine Standardisierung erforderlich ist, fallen in diese Kategorie. Ich habe einmal bei einem Kunden gearbeitet, der ein paar Jahre lang zuließ, dass sich Standards ändern, und der über 20 verschiedene SCM-Tools verfügte. Was als unabhängige Entscheidung von verschiedenen Entwicklungsteams begann, wurde zu einem logistischen Albtraum, der den Austausch von Fähigkeiten und die Zusammenarbeit bei Code im gesamten Unternehmen erheblich beeinträchtigte. Integrierte Builds waren ..... ähm ..... nicht sehr integriert .....

Darüber hinaus ist es nicht praktisch oder notwendig, bei jeder Entscheidung alle zu konsultieren . Inwieweit dies getan werden muss, hängt von der Unternehmenskultur und der Wichtigkeit / Komplexität der Entscheidung ab. Normalerweise würden Sie eine dieser weniger beratungsintensiven Optionen wählen:

1. Treffen Sie die Entscheidung selbst, wenn Sie über ausreichende Kenntnisse der Vor- und Nachteile verfügen und diese Entscheidung nicht wichtig genug ist, um eine umfassende Beratung zu erfordern.
2. Wenden Sie sich an einige Schlüsselpersonen (die wahrscheinlich die erfahrensten Entwickler sind, die für die Entscheidung am besten geeignet sind).
3. Machen Sie alle Betroffenen darauf aufmerksam, dass Sie eine Entscheidung treffen (E-Mail, Rathaussitzung, Teambesprechungen). Sagen Sie, was Sie für die richtige Entscheidung halten, aber dass Sie bereit sind, dies zu ändern, wenn neue Beweise im Gegenteil auftauchen. Bitten Sie die Teilnehmer, sich einzeln zu äußern, wenn sie wichtige Ansichten haben
4. Bitten Sie die Mitarbeiter, ein Unterteam zu bilden, um die Optionen zu prüfen und eine Entscheidung zu empfehlen. Gute Option, wenn es sich wirklich um einen engen Anruf handelt, Sie die Antwort nicht kennen und möchten, dass die Beteiligten in die Entscheidung einbezogen werden.

Für so etwas wie Developer Tooling (was ein potenziell umstrittenes Problem ist) würde ich wahrscheinlich 2 gefolgt von 3 oder 4 machen. Dh es würde definitiv einige Personen geben, mit denen ich nicht persönlich über das Problem sprechen würde, aber auf der anderen Seite die meisten von den Schlüsselpersonen würden eine Wahrscheinlichkeit erhalten, zur Entscheidungsfindung beizutragen.

Für mich wäre die echte rote Fahne da, wenn Sie das Gefühl hätten, dass eine falsche Entscheidung getroffen wurde (falsch == es schadet dem Unternehmen und nicht nur Ihrem Lieblingswerkzeug, das nicht ausgewählt wurde). Wie reagiert das Management, wenn Sie dieses Problem ansprechen:

• Gutes Management wird auf Ihre Argumentation hören, sich aufrichtig für das Feedback bedanken und ihre Position überdenken, falls Sie neue Erkenntnisse gewonnen haben . Sie stimmen möglicherweise immer noch nicht mit Ihnen überein und halten möglicherweise an ihrer Entscheidung fest, aber sie werden es zu schätzen wissen, dass Sie sie angesprochen haben, und Sie die Höflichkeit haben zu sagen, warum sie an ihrer Entscheidung festhalten. Sie könnten in Zukunft sogar die Art und Weise ändern, in der sie solche Entscheidungen treffen, und wenn Sie gute Argumente vorgebracht haben, könnten Sie auf ihre Liste der "klugen Leute" gesetzt werden.
• Schlechtes Management wird defensiv, sagt, dass "die Entscheidung getroffen wird" und andere solche Taktiken, um zu vermeiden, dass sie sich der Tatsache stellen, dass sie möglicherweise eine falsche Entscheidung getroffen haben. Sie können Sie als "Unruhestifter" sehen. Das Unternehmen leidet ebenso wie Ihr Vertrauen in das Management. Das ist eine echte rote Fahne! Geh raus, solange du kannst!

Wenn Sie Maven oder ähnliches verwenden, sollte es keine Rolle spielen, welche IDE Sie verwenden. Es kann Fälle geben, in denen man an eine bestimmte IDE wie Eclipse gebunden ist, wenn es Plugins gibt, auf die Sie sich verlassen können.

Ich denke, Sie sollten in der Lage sein, Ihre eigene IDE zu wählen, die IDE, in der Sie am produktivsten sind. Wie ich jedoch bereits sagte, gibt es Fälle, in denen es sinnvoll ist, eine Standard-IDE zu verwenden.

Ich hätte die "Corporate Mandated" -ID installiert, würde aber trotzdem den größten Teil meiner Arbeit in der von mir gewünschten IDE erledigen - es ist nicht so, als könnte jemand sagen, mit welcher IDE eine Quelldatei bearbeitet wurde.

Auf der IDE vs. Editor Front ... für fast alle Sprachen, ich stark ein IDE (IntelliJ) bevorzugen , weil es einfach so viel mehr ist es für Sie als Redakteur kann tun können. Es gibt einige Dinge, für die ich auf ST2 oder Emacs zurückgreife, aber für die tägliche Codierung gewinnt die IDE fast immer, obwohl ich beide ST2 / Emacs mag.

Jedes Team, in dem ich jemals war, hatte eine Vielzahl von IDEs und Editoren: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - das war noch nie ein Problem. Noch nie.

Für mich spricht dies für ein Missverständnis auf hoher Ebene der Organisation, was wirklich wichtig ist. Was zählt, ist, gute Programmierer tun zu lassen, was sie tun müssen, und die Werkzeuge zu verwenden, die sie am bequemsten machen. Die Einheitlichkeit der IDE hat sehr wenig mit der tatsächlichen Kommunikation zu tun, die über die wesentlichen Fragen der Objektarchitektur, der Komponententests, der Algorithmen usw. stattfindet.

Dieselbe IDE wie der nächste zu haben, bedeutet nur, dass wir beide wissen, wie man den Code mit denselben Verknüpfungen durchsucht und wie unsere Kompilierung / Konfiguration eingerichtet ist. Nichts davon wird von Bedeutung sein, wenn es um echte Code-Probleme geht.

Schauen Sie, es ist lebenswert, abhängig von anderen Faktoren im Unternehmen. Sie können für alltägliche Aufgaben immer Ihren eigenen bevorzugten Editor verwenden. Und vielleicht macht Ihre Gruppe andere großartige Dinge, die eine großartige Kultur schaffen. Aber mandatierte IDEs sind ein großer Fehltritt der IMO. Für mich, wenn ich mit einem Unternehmen wurde interviewt und sie teilte mir mit, welches IDE wurde ich erlaubt zu bedienen, ich sie höflich für ihre Zeit danken würde.

In unserem Ruby-Shop gibt es eine starke Empfehlung, die IDE zu verwenden, die das meiste des Teams mag (RubyMine), weil wir wissen, dass es die Arbeit macht und wir uns gegenseitig Abkürzungen beibringen können usw.

Entwicklern steht es frei, eine andere IDE zu verwenden, aber wir fordern von ihnen solide Kenntnisse in diesem Editor, falls sie dies wünschen. Wenn wir jemanden sehen, der Schwierigkeiten hat, in seinem Projekt zu navigieren oder Text in seinem benutzerdefinierten FooEdit zu bearbeiten, ist es RubyMine.

Wenn ein Programmierer ein Experte für eine bestimmte IDE ist, sollte er diese verwenden. Wenn sie keine IDE-Experten sind, gibt es wahrscheinlich einen oder zwei, die in Ihrer Programmiersprache oder in Ihrem Team sehr häufig vorkommen, und es ist wahrscheinlich sinnvoll, dass sie dies lernen.

Auf einer IDE standardisieren zu müssen, klingt nach einer schrecklichen Idee.

Die Gründe für ein Unternehmen, einen bestimmten Editor oder eine bestimmte Software generell seinen Entwicklern aufzuzwingen, sollten untersucht werden. Der paranoide (vielleicht nicht das Wort, nach dem ich suche) Teil von mir glaubt, dass es eine Art Produktivitäts-Tracking geben könnte, das zu der Sonnenfinsternis hinzugefügt wird, die Entwickler installieren sollen. Ein viel weniger paranoider Gedanke wäre, dass sie Zeit damit verbracht haben, dieser IDE Produktbuilding-Tools hinzuzufügen, die die Dinge viel einfacher machen würden, wenn jeder die gleiche Taste zum Testen und Erstellen seines Code-Zweigs drücken würde.

Was ich damit sagen will, ist wahrscheinlich mehr als bloße Bürokratie oder eine Methode, mit den Entwicklerköpfen herumzuspielen.

Dies ist eine massive rote Fahne. Jedes Unternehmen hat ein paar solche dummen Ideen, aber wenn andere rote Fahnen kommen, gehen Sie einfach.

Es ist leicht, die Motivation hinter einigen Entscheidungen zu verlieren - insbesondere bei einem schnell wachsenden Team. Die Motivation für den Umstieg auf Eclipse ist möglicherweise die Tatsache, dass die meisten Entwickler anscheinend viel Zeit mit der Konfiguration der IDE verschwenden und dass nur begrenztes Fachwissen in Ihrem Unternehmen vorhanden ist.

Ich würde einfach den Befehl annehmen, zu Eclipse zu wechseln, um zu bedeuten, dass Sie Eclipse einrichten sollten, falls dies erforderlich ist, aber Ihre Arbeit in Ihrem bevorzugten Editor fortsetzen. (Möglicherweise müssen Sie schrittweise zu Eclipse wechseln, wenn Ihr Unternehmen mit der Bereitstellung cooler Tools in Eclipse beginnt.)

Rote Fahne: Ich würde warten, wenn es noch ein paar solche irrationalen Befehle gibt, bevor ich mir Sorgen mache.

Ein Startup versucht im Allgemeinen, lange genug agil zu bleiben, um ein nachhaltiges Geschäftsmodell zu finden. Sobald der Geldanteil ermittelt ist, zieht das Management ein, um das Geschäft zu vergrößern. In der Regel treten alle frühen Tech-Mitarbeiter aus dem Unternehmen aus, da die Engineering-Prozesse verschärft werden.

Wie Sie wissen, wissen Sie nicht, was Code tatsächlich tut, bis Sie ihn ausführen. Turing hat das in den Anfängen des Rechnens bewiesen. Dies bedeutet, dass es beim Schreiben von Software kein aussagekräftiges Maß für die Produktivität gibt. Damit das Management seine Arbeit erledigen kann, muss die Produktivität lesbar sein. Da Sie den Code nicht messen können (und die Benutzer beispielsweise Codezeilen ausprobiert haben), messen sie, was sie sehen können. Programmierer sind besser lesbar als die von ihnen entwickelte Software. Das typische Managementteam versucht, Programmierer zu kontrollieren, um diese Dinge für sie lesbar zu machen (anstatt ihre eigentlichen Aufgaben zu erledigen: aus dem Weg zu gehen). Und weil sie die falschen Dinge messen, funktioniert es nicht sehr gut.

Trotzdem kann man mit einem locker gekoppelten Team noch einen weiten Weg gehen. Das Entwicklungsteam von Github besteht aus rund 50 Mitarbeitern, die alle Regeln der betriebswirtschaftlichen Lehrbücher brechen. Ihnen scheint es gut zu gehen. Bugs werden (irgendwann) behoben. Features werden hinzugefügt. Feuer werden gelöscht.

Was ist eine große rote Fahne ist, wenn sie versuchen, die Dinge zu vergrößern, ohne herausgefunden zu haben, wie man Geld verdient. Zu diesem Zeitpunkt mussten Sie sich fragen, wie viel Ihre nicht erworbenen Optionen und Zuschüsse wirklich wert sind.

Sicher ist das eine schlechte Idee. Es ist unvermeidlich, dass das Team weniger produktiv wird, da es lernen muss, mit neuen Werkzeugen umzugehen. Und selbst dann werden sie nicht so effektiv sein wie mit den Werkzeugen, die sie bereits haben .

Da ich verschiedene Tools selbst ausprobiert habe, hatte ich immer das Gefühl, dass dieser Editor mich nervt mit <Fehler / Unterschied zum bevorzugten Tool einfügen>. Es wird also auch ein moralischer Nachteil sein.

Aber es gibt natürlich auch Profis, die ein ganzes Team die gleichen Werkzeuge benutzen lassen. Teilen von Configs, Skripten, Plugins und all diesen Dingen. Was mit einer Vielzahl von Toolsets nicht möglich wäre.

Andererseits ... wäre das letzte Stück nicht nötig, wenn jeder seine bevorzugte Software verwenden würde. ;)

Sie können Eclipse "verwenden", während Sie noch SublimeText2 eingeben.

Dies bedeutet, dass Sie Eclipse für Ihre Projekte installiert und konfiguriert haben und sich auf dem Laufenden halten, damit Sie es auch bei der Paarprogrammierung verwenden können. Niemand wird (oder sollte) sich darum kümmern, welchen Editor Sie tatsächlich verwendet haben, um einen Code einzugeben, den Sie festgeschrieben haben, solange die parallele Einrichtung nicht übermäßig viel Zeit in Anspruch nimmt und Sie sich nicht vom Code abkoppeln Standard-Entwicklungsumgebung.

Wenn Sie Git verwenden und Ihre Verzweigung unterbrochen ist, sollten Sie ohnehin nicht die Editoren des anderen verwenden müssen. Sie können einfach auf einen Zweig drücken und ihn von einem anderen Entwickler ziehen lassen, um ihn zum Laufen zu bringen, wenn er Ihr Toolset wirklich nicht herausfinden kann. Jeden dazu zu zwingen, denselben Editor zu verwenden, klingt nach einer Anweisung eines Geschäftsführers, der schlau aussehen möchte, aber nicht wirklich versteht, wie ihr arbeitet.

Wenn Sie aus Managementsicht darüber nachdenken, liegt der Grund möglicherweise in der Einhaltung der gesetzlichen Bestimmungen. Das Unternehmen ist dafür verantwortlich, dass jedes verwendete Werkzeug legal verwendet wird und das zu entwickelnde Produkt nicht belastet. (Einige Editoren sind frei für den persönlichen Gebrauch, aber nicht frei für andere Zwecke usw.) Die Prüfung aller Tools, die jeder Entwickler verwenden möchte, kann teuer werden. Ich habe gesehen, dass bei Projekten mit engen Zeitplänen das Management vorsichtig sein wird, welche Tools / Bibliotheken / usw. verwendet werden, um Änderungen im späteren Verlauf des Projekts zu minimieren, die von den Angehörigen der Rechtsberufe gesteuert werden.

Bei Projekten mit höherer Sicherheit geht es auch darum, wo die IDEs temporäre Dateien speichern und welche Informationen zwischen Sitzungen gespeichert werden.

Es hängt alles von den Gründen ab, aus denen sie Eclipse empfehlen müssen. Wenn Entwickler Probleme haben, ihre Umgebungen einzurichten, weil jeder die Dinge anders organisiert, kann es einen Grund geben, eine Zwangsjacke zu empfehlen. Wenn jedoch alle glücklich und produktiv waren, was immer sie wollten, gibt es kaum einen Grund, etwas zu ändern, das so tief in den kreativen Prozess involviert ist.

Eclipse ist viel mehr als ein Editor - Sie können Ihren bevorzugten Editor für die Bearbeitung Ihres Codes verwenden und sich bei der Quellcodeverwaltung, dem Debugging und allen anderen Aufgaben, für die der von Unternehmen vorgegebene Workflow verwendet werden soll, auf Eclipse verlassen.

Eine letzte Sache - die Durchsetzung des Prozesses auf dieser Ebene könnte darauf hindeuten, dass das Unternehmen beabsichtigt, das Entwicklungsteam zu erweitern, und eine gewisse Struktur wünscht, damit neue Teammitglieder schneller produktiv werden können. Wenn Sie Rails (oder Django) als ein "eigenwilliges" Framework betrachten, werden Sie feststellen, dass eine Struktur das Verständnis neuer Anwendungen erleichtert.

Die rote Fahne ist nicht so sehr, dass jedem Entwickler ein einziger IDE / Editor aufgezwungen wird, sondern dass diese Entscheidung und insbesondere die Entscheidung, welcher IDE / Editor verwendet werden soll, nicht von allen Entwicklern getroffen wurde, und vielleicht auch nicht von allen Sie!?!

Mit Sicherheit wäre es für die Entwickler am besten, einen Konsens zu erzielen, zumal sie offensichtlich für die Entscheidung am besten qualifiziert sind (zumindest für welchen Editor / welche IDE). Es mag gute Gründe für eine Anpassung geben, und diese Entscheidung sollte die Präferenz des Managements einschränken, aber welcher Editor / welche IDE die Entscheidung aller Entwickler gewesen sein sollte.

Es wäre einfach, 12 Entwickler zur Stimmabgabe zu bewegen. Sicher war genug Zeit dafür! Die Schlussfolgerung wäre für einige ohnehin schmerzhaft gewesen und hätte am Ende sogar zu Eclipse geführt, aber die Kennzeichnung der Anforderung als "rote Fahne" wäre in diesem Fall viel fragwürdiger.