Czy zamówienie firmy, aby przełączyć się na określone IDE, jest czerwoną flagą? [Zamknięte]

Niedawno dołączyłem do szybko rozwijającego się startupu. W ciągu ostatnich 3 miesięcy zespół programistów powiększył się z 4 do 12. Do tej pory byli bardzo otwarci na temat tego, co programiści wykonywali swoją pracę. W rzeczywistości jedną z rzeczy, które początkowo uważałem za atrakcyjne w firmie, jest to, że większość programistów używała Linuksa lub innego systemu operacyjnego, który według nich najlepiej pasował do ich wysiłków.

Teraz pojawiły się zamówienia, bez dyskusji, że wszyscy mają przejść na Eclipse. Świetny edytor. Wolę SublimeText2, ale to tylko mój osobisty gust.

Żeby było jasne: jesteśmy zespołem JS używającym Backbone, a Eclipse po prostu nie jest dobry w zrozumieniu kodu Backbone. Oznacza to, że osoby w zespole, które używają / good / IDE (PHP Storm), muszą wrócić do robienia wielu rzeczy typu szukaj-znajdź-och-czekaj-gdzie-był-ja-trzy-kroki-temu zamiast po prostu ctrl + kliknięcie i użycie wstecz / do przodu - prawdopodobnie zmniejsza produktywność o powiedzmy 15% i przyjemność o 50% ...

Czy to czerwona flaga? Wydaje się kapryśne i nieuzasadnione kontrolowanie, aby powiedzieć programistom (spoza MS), jakiego IDE lub zestawów narzędzi użyć, jeśli są już osiedleni i produktywni.

„Teraz rozkazy, bez dyskusji , spadły, że wszyscy mają przejść na Eclipse”.

Myślę, że to prawdziwa czerwona flaga. Twój zespół jest ekspertem w dziedzinie tworzenia oprogramowania i tym, na który ma wpływ decyzja, a mimo to nie powiedziałeś ani słowa w dyskusji, która doprowadziła do takiej kolejności?

To brzmi jak nadmierne zarządzanie przez spiczastych włosach szefów. Czy osoba / zespół podejmujący decyzję ma odpowiedni wgląd w tę decyzję?

Biorąc pod uwagę, że decydenci są wystarczająco wykwalifikowani do takiej decyzji, brak prośby o opinię zespołu programistów ma co najmniej dwa niedociągnięcia:

• Zespół nie czuje się zaangażowany. Zaangażowanie zespołu powinno być priorytetem dla zarządzania. Nie chciałbym pracować jako programista gdzieś, gdzie moja opinia na temat tak centralnych zagadnień, jak IDE, nie jest wystarczająco ceniona, aby o nią prosić. Przyznaję, że pytanie o czyjąś opinię, a następnie podjęcie decyzji przeciwko niej może być gorsze, ale w takim przypadku oczekiwałbym solidnego uzasadnienia tej decyzji.

• Kierownictwo, jakkolwiek doświadczone, nie działa w 100% przy opracowywaniu tego konkretnego kodu. Zakładając, że ludzie, którzy nie mają w ogóle interesującego wglądu, byliby naiwni. Oczywiście może być tak, że menedżerowie pomyśleli o wszystkim, co wymyślili twórcy, ale jedynym sposobem, aby się dowiedzieć, jest zapytanie.

Rozsądne jest, aby podczas wspólnej pracy nad wspólnym projektem mieć na każdym stanowisku roboczym wszystkie narzędzia do edycji / kompilacji / debugowania oprogramowania oraz że podstawowe narzędzia do wykonywania około 90% prac rozwojowych są znane wszystkim w drużyna. Ten cel jest trudniejszy do osiągnięcia, jeśli Twój zespół się powiększa, a każdy korzysta ze swojego ulubionego zestawu narzędzi - im więcej ludzi, tym więcej opinii. A praca administracyjna staje się łatwiejsza, jeśli nie pozwolisz, aby liczba narzędzi wzrosła więcej niż to konieczne.

Oczywiście, jeśli jeden programista nalega na użycie swojego ulubionego edytora, może to być w porządku, o ile może upewnić się, że źródło nie wygląda lub nie zachowuje się inaczej w głównym edytorze zespołu (w twoim przypadku Eclipse), więc jeśli programista B musi edytować źródło dev A, dev B nie powinien być zmuszony do nauki osobistego ulubionego edytora A, aby móc skutecznie zmieniać źródło. Ale uważaj, jeśli oba muszą od czasu do czasu współpracować przed tym samym wyświetlaczem (lub wykonać programowanie parami), rzeczy są często łatwiejsze, jeśli wybrany edytor jest dobrze znany przez oba.

Dla programowania w parach dobrze jest, jeśli obie strony przed ekranem mają takie same umiejętności podczas korzystania z klawiatury. Miło jest również wiedzieć, że jeśli twój projekt ma specjalne potrzeby konfiguracyjne w IDE, to jest skonfigurowany w ten sam sposób dla wszystkich. Rozpoczęcie pracy z nowym programistą jest łatwiejsze, gdy narzędzia są takie same dla wszystkich.

Ale jeśli porównasz to z próbą bycia najbardziej skutecznym, to naprawdę nie jest tego warte

Tak, to trochę czerwona flaga, że ​​kierownictwo uważa się za lepszego oceniania, z których narzędzi byłbyś bardziej wydajny niż jesteś.

To nie jest sama czerwona flaga.

Czasami kierownictwo musi podejmować decyzje . Wszelkie problemy wymagające standaryzacji na czymś należą do tej kategorii. Kiedyś pracowałem u klienta, który pozwalał na znoszenie standardów przez kilka lat, a oni mieli ponad 20 różnych narzędzi SCM. To, co zaczęło się jako niezależny wybór różnych zespołów programistów, przerodziło się w logistyczny koszmar, który poważnie utrudnił dzielenie się umiejętnościami i współpracę w zakresie kodu w całej organizacji. Zintegrowane kompilacje były ... eee ..... niezbyt zintegrowane ...

Co więcej, nie jest praktyczne ani konieczne konsultowanie się ze wszystkimi przy każdej decyzji . Zakres, w jakim należy to zrobić, zależy od kultury organizacji i znaczenia / złożoności decyzji. Zazwyczaj wybierasz jedną z tych opcji, które wymagają mniej konsultacji:

1. Podejmij decyzję samodzielnie, jeśli masz wystarczającą wiedzę na temat zalet / wad i nie jest to wystarczająco ważna decyzja, aby wymagać szerokich konsultacji.
2. Skonsultuj się z kilkoma kluczowymi osobami (prawdopodobnie najlepszymi programistami najlepiej wykwalifikowanymi do podjęcia decyzji).
3. Podnieś fakt, że podejmujesz decyzję dla wszystkich, których może to dotyczyć (e-mail, spotkanie w ratuszu, spotkania zespołu). Powiedz, co uważasz za właściwą decyzję, ale że jesteś gotów to zmienić, jeśli pojawią się nowe dowody przeciwne. Poproś ludzi, aby wystąpili indywidualnie, jeśli mają jakieś ważne poglądy
4. Poproś ludzi, aby utworzyli pod-zespół, aby przejrzał opcje i zalecił decyzję. Dobra opcja, jeśli jest to naprawdę bliskie połączenie, nie znasz odpowiedzi i chcesz, aby zaangażowani w nią byli zaangażowani w podejmowanie decyzji.

W przypadku narzędzi programistycznych (co jest potencjalnie kontrowersyjnym problemem) prawdopodobnie zrobiłbym 2, a następnie 3 lub 4. tzn. Zdecydowanie byłyby pewne osoby, z którymi osobiście nie rozmawiałbym w tej sprawie, ale z drugiej strony większość kluczowych osób miałoby szansę na udział w podejmowaniu decyzji.

Dla mnie prawdziwa czerwona flaga byłaby w pobliżu, jeśli masz wrażenie, że podjęto złą decyzję (zła == szkodzi firmie, a nie tylko wybranemu ulubionemu narzędziu). Jak reaguje kierownictwo, gdy podniesiesz ten problem:

• Dobre zarządzanie wysłucha twoich argumentów, dziękuję szczerze za opinie i ponownie rozważę ich stanowisko w przypadku, gdy uzyskałeś nowe spostrzeżenia . Mogą nadal nie zgadzać się z tobą i mogą trzymać się swojej decyzji, ale docenią to, że podniosłeś ją wraz z tobą i uprzejmie powiesz, dlaczego trzymają się tej decyzji. Mogą nawet zmienić sposób, w jaki podejmują takie decyzje w przyszłości, a jeśli zrobisz dobre punkty, możesz umieścić cię na liście „inteligentnych ludzi do zapytania”.
• Złe zarządzanie stanie się defensywne, powiedz, że „decyzja została podjęta” i inne takie taktyki, aby uniknąć zmierzenia się z faktem, że mogli oni podjąć złą decyzję. Mogą postrzegać cię jako „sprawcę problemów”. Cierpi firma, podobnie jak twoja wiara w zarządzanie. To jest prawdziwa czerwona flaga! Wyjdź, póki możesz!

Jeśli używasz maven lub czegoś podobnego, nie powinno mieć znaczenia, którego IDE używasz. Mogą istnieć przypadki, w których jeden jest powiązany z konkretnym IDE, takim jak eclipse, jeśli istnieją wtyczki, na których można polegać.

Myślę, że powinieneś mieć możliwość wyboru własnego IDE, IDE, w którym jesteś najbardziej produktywny. Jednakże, jak już powiedziałem, są przypadki, w których sensowne jest użycie standardowego IDE.

Miałbym zainstalowane IDE „korporacyjne”, ale nadal większość pracy wykonywałbym w dowolnym IDE, jakie chciałem - to nie jest tak, że nikt nie może powiedzieć, jakiego IDE użyto do edycji pliku źródłowego.

Na froncie IDE vs. edytor ... dla prawie wszystkich języków zdecydowanie wolę IDE (IntelliJ), ponieważ jest o wiele więcej możliwości dla ciebie niż edytor. Są pewne rzeczy, dla których powracam do ST2 lub Emacsa, ale do codziennego kodowania, pomimo tego, jak bardzo lubię oba ST2 / Emacs, IDE prawie zawsze wygrywa.

Każdy zespół, w którym kiedykolwiek byłem, miał wiele IDE i edytorów: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - nigdy nie było problemu. Nigdy.

Dla mnie świadczy to o nieporozumieniu na wysokim szczeblu organizacji, co do tego, co naprawdę ma znaczenie. Ważne jest, aby pozwolić dobrym programistom robić to, co muszą, i korzystać z narzędzi, które zapewniają im najwygodniejszy komfort. Jednorodność IDE ma bardzo niewiele wspólnego z prawdziwą komunikacją, która zachodzi w podstawowych kwestiach dotyczących architektury obiektu, testowania jednostek, algorytmów itp.

Posiadanie tego samego IDE co następny facet oznacza po prostu, że oboje wiemy, jak przeglądać kod przy użyciu tych samych skrótów i jak konfigurowana jest nasza kompilacja / konfiguracja. Nic z tego nie będzie miało znaczenia, gdy mówimy o prawdziwych problemach z kodem.

Patrz, jest znośny, w zależności od innych czynników w firmie. Zawsze możesz użyć własnego preferowanego edytora do codziennych czynności. A może twoja grupa robi inne wspaniałe rzeczy, które tworzą wspaniałą kulturę. Ale obowiązkowe IDE to ogromny błąd IMO. Dla mnie, jeśli ja były rozmowy z firmą, a oni poinformował mnie, który byłem IDE wolno używać, chciałbym podziękować im grzecznie za ich czas.

W naszym sklepie Ruby istnieje silna rekomendacja używania IDE, którą lubi większość zespołów (RubyMine), ponieważ wiemy, że spełnia swoje zadanie i możemy się uczyć skrótów itp.

Programiści mogą swobodnie korzystać z różnych IDE, ale wymagamy od nich posiadania solidnych umiejętności w tym edytorze, jeśli tak wybiorą. Jeśli widzimy, że ktoś stara się poruszać projektem lub edytować tekst w niestandardowym FooEdit, to dla niego jest to RubyMine.

Jeśli programista jest ekspertem w danym środowisku IDE, powinien go użyć. Jeśli nie są ekspertami w żadnym IDE, prawdopodobnie istnieje jeden lub dwa, które są bardzo powszechne w twoim języku programowania lub w zespole, i prawdopodobnie ma sens, aby się go uczyli.

Bycie zmuszonym do standaryzacji na IDE brzmi jak okropny pomysł.

Powody, dla których firma wymusza na programistach określony edytor lub ogólnie oprogramowanie, powinny zostać zbadane. Paranoiczna część (może nie tego słowa, której szukam) uważa, że ​​do zaćmienia, do którego zainstalowania prosi deweloperów, można dodać śledzenie wydajności. O wiele mniej paranoiczne (znowu) sądzi się, że spędzili czas dodając narzędzia do budowania produktu do tego IDE, co znacznie ułatwiłoby, gdyby wszyscy nacisnęli ten sam przycisk, aby przetestować i zbudować swoją gałąź kodu.

W każdym razie próbuję powiedzieć, że jest to prawdopodobnie coś więcej niż zwykła biurokracja lub metoda na bałagan z głowami programistów.

To jest masywna czerwona flaga. Każda firma ma kilka takich głupich pomysłów, ale jeśli nadal pojawiają się inne czerwone flagi, po prostu wyjdź.

Łatwo jest zgubić motywację do podjęcia niektórych decyzji - szczególnie w przypadku szybko rozwijającego się zespołu. Motywacją do przejścia na Eclipse może być fakt, że większość programistów wydaje się tracić dużo czasu na samą konfigurację IDE i że wiedza na temat Twojej firmy jest ograniczona.

Po prostu przejdę do przejścia na Eclipse, co oznacza, że ​​powinieneś mieć konfigurację Eclipse na wypadek, gdyby była potrzebna, ale kontynuuj pracę w swoim ulubionym edytorze. (Może być konieczne stopniowe przejście do Eclipse, jeśli Twoja firma zacznie wdrażać fajne narzędzia w Eclipse).

Czerwona Flaga: Poczekałbym, zanim pojawi się jeszcze kilka takich irracjonalnych rozkazów.

Start-up zazwyczaj stara się pozostać zwinnym wystarczająco długo, aby znaleźć zrównoważony model biznesowy. Po ustaleniu części dotyczącej pieniędzy zarząd przenosi się, aby zwiększyć skalę działalności. Zasadniczo wtedy wszyscy początkujący pracownicy technologiczni zaczynają odchodzić, ponieważ procesy inżynieryjne zostają zaostrzone.

Jak wiesz, nie wiesz, co właściwie zrobi kod, dopóki go nie uruchomisz. Turing udowodnił to we wczesnych dniach komputerów. Oznacza to, że nie ma czegoś takiego jak miarodajna miara produktywności, jeśli chodzi o pisanie oprogramowania. Jednak, aby kierownictwo wykonało swoje zadanie, wydajność musi być czytelna. Ponieważ nie możesz zmierzyć kodu (a ludzie próbowali - na przykład wiersze kodu), zmierzą to, co mogą zobaczyć. Programiści są bardziej czytelni niż oprogramowanie, które opracowują. Typowy zespół zarządzający próbuje kontrolować programistów, aby uczynić te rzeczy czytelnymi (zamiast wykonywać swoje prawdziwe zadania: zejść im z drogi). A ponieważ mierzą niewłaściwe rzeczy, nie działa to zbyt dobrze.

Powiedziawszy to, nadal możesz przejść długą drogę z luźno powiązanym zespołem. Zespół programistów Github ma około 50 osób i łamią wszelkie zasady zawarte w podręcznikach zarządzania biznesem. Wydaje się, że wszystko w porządku. Błędy zostaną naprawione (ostatecznie). Funkcje zostaną dodane. Pożary gasną.

Wielką czerwoną flagą jest to, że próbują zwiększyć skalę, nie wiedząc, jak zarabiać pieniądze. W tym momencie zastanawiasz się, ile naprawdę warte są twoje niezainwestowane opcje i granty.

Z pewnością to zły pomysł. Jest nieuniknione, że zespół będzie mniej produktywny, ponieważ będzie musiał nauczyć się korzystać z nowych narzędzi. I nawet wtedy nie będą tak skuteczne, jak w przypadku narzędzi, które już grokują .

Ponieważ sam próbowałem różnych narzędzi, zawsze miałem wrażenie, że „kurde, ten edytor denerwuje mnie <wstaw błąd / różnicę w stosunku do preferowanego narzędzia>”. Będzie to więc także moralna wada.

Ale oczywiście są też profesjonaliści, aby cały zespół korzystał z tych samych narzędzi. Udostępnianie konfiguracji, skryptów, wtyczek i innych tego typu rzeczy. Nie byłoby to możliwe przy różnorodności zestawów narzędzi.

Z drugiej strony… ten ostatni kawałek nie byłby konieczny, gdyby wszyscy korzystali z jego preferowanego oprogramowania. ;)

Możesz „używać” Eclipse podczas pisania w SublimeText2.

Oznacza to, że Eclipse jest zainstalowany i skonfigurowany do twoich projektów i przyśpieszasz go, abyś był równie wygodny w użyciu, jeśli, powiedzmy, programowanie w parę. Nikt nie będzie (a przynajmniej nie powinien) dbać o to, jakiego edytora rzeczywiście użyłeś do wpisania kawałka kodu, pod warunkiem że utrzymanie równoległej konfiguracji nie zajmuje zbyt wiele czasu i nie odcinasz się od standardowe środowisko programistyczne.

Jeśli korzystasz z Git, a Twoje rozgałęzienia są wyłączone, nie powinieneś i tak używać innych edytorów. Możesz po prostu pchnąć gałąź i poprosić innego dewelopera, aby uruchomił ją, jeśli naprawdę nie jest w stanie zrozumieć twojego zestawu narzędzi. Zmuszanie wszystkich do korzystania z tego samego edytora brzmi jak zamówienie jakiegoś szefa firmy, który chce wyglądać elegancko, ale tak naprawdę nie rozumie, jak działacie.

Jeśli myślisz o tym z punktu widzenia zarządzania, powodem tego może być zgodność z prawem. Firma jest odpowiedzialna za zapewnienie, że każde użyte narzędzie jest używane zgodnie z prawem, a także nie będzie obciążać opracowywanego produktu. (Niektóre edytory są bezpłatne do użytku osobistego, ale nie są bezpłatne do żadnych innych celów itp.) Audyt każdego narzędzia, z którego może chcieć korzystać każdy programista, może być kosztowny. Widziałem, że w projektach, w których terminy są napięte, zarządzanie będzie ostrożne w kwestii tego, które narzędzia / biblioteki / itp. Są używane w celu zminimalizowania zmian w późniejszym etapie projektu, które są kierowane przez osoby prawne.

W projektach o wyższym bezpieczeństwie istnieje również obawa, gdzie IDE przechowują pliki tymczasowe i jakie informacje są przechowywane między sesjami.

Wszystko zależy od powodów, dla których muszą polecać Eclipse. Jeśli programiści mają problemy z konfiguracją swojego środowiska, ponieważ wszyscy organizują coś inaczej, może istnieć powód, aby polecić kaftan bezpieczeństwa. Jeśli jednak wszyscy byli szczęśliwi i produktywni, wykorzystując to, czego chcieli, nie ma powodu, aby wprowadzać zmiany w czymś tak głęboko zaangażowanym w proces twórczy.

Eclipse to znacznie więcej niż edytor - możesz nadal używać swojego ulubionego edytora do edytowania kodu i polegać na Eclipse do kontroli źródła, debugowania i wszystkiego innego, czego wymaga korporacyjny obieg pracy.

I ostatnia rzecz - proces egzekwowania na tym poziomie może wskazywać, że firma zamierza rozszerzyć zespół programistów i chce mieć pewną strukturę, aby nowi członkowie drużyny mogli szybciej uzyskać wydajność. Jeśli uważasz, że Railsy (lub Django) są „opiniotwórczym” środowiskiem, zorientujesz się, że struktura pomaga łatwiej zrozumieć nowe aplikacje.

Czerwona flaga to nie tyle, że na każdego programistę nakłada się jedno IDE / edytor, ale że ta decyzja, a zwłaszcza decyzja o tym, który IDE / edytor miał zostać zastosowany, nie została podjęta przez wszystkich programistów, a być może żaden z nich im!?!

Z pewnością najlepiej byłoby, gdyby programiści osiągnęli konsensus, szczególnie dlatego, że są najwyraźniej najlepiej wykwalifikowani do podjęcia decyzji (przynajmniej co do tego, który edytor / IDE). Może istnieć dobry powód, aby się dostosować i taka decyzja powinna uwzględniać preferencje kierownictwa, ale który redaktor / IDE powinien być decyzją wszystkich programistów.

Zdobycie 12 programistów, którzy oddadzą kilka głosów, byłoby łatwe. Z pewnością było wystarczająco dużo czasu, aby to zrobić! Wniosek byłby i tak bolesny dla niektórych, a może nawet skończyłby się Eclipse, ale oznaczenie wymogu jako „czerwonej flagi” w tym przypadku byłoby znacznie bardziej dyskusyjne.