Radzenie sobie z moim przestarzałym współpracownikiem


28

Jestem dość młodym programistą i pracuję w dziale IT średniej wielkości firmy. Mam współpracownika, a on jest naprawdę dobrym programistą Visual Basic 6. I mam na myśli naprawdę dobrze. Szczerze. Potrafi dostarczyć działające aplikacje, zawierające bardzo niewiele błędów, w czasie, gdy muszę zdobyć pierwszą filiżankę kawy i uruchomić maszynę. On jest taki dobry.

Chodzi o to, że pracujemy z zespołem, a jego styl pracy jest całkowicie przestarzały. Nie wierzy w oprogramowanie do wersjonowania (jeśli upewnisz się, że kod jest poprawny, nie potrzebujesz tych bzdur). Nie wierzy we wdrożenie (mogę dostarczyć działający plik wykonywalny. Sposób, w jaki jest on wdrożony, zależy od sysadminów). Nie wierzy w abstrakcję. („jeśli chcesz utworzyć podprogram, śmiało, ale nie wywoływaj żadnych podprogramów z tego podprogramu. W ten sposób robi się bałagan, a kod jest trudny do przestrzegania. W ten sposób każdy może śledzić każdy krok po drodze. ”lub„ tak, na pewno możesz użyć tej biblioteki, aby zrobić to za Ciebie, ale w ten sposób tak naprawdę nie rozumiesz, co się dzieje ”) i na pewno nie wierzy w OOP. (pracujemy w VB.net)

Jest tak dobry w tym, co robi, że może dostarczać aplikacje znacznie szybciej niż ja. Ale to po prostu nie działa w zespole. Nasz drugi członek zespołu jest cichy i nie lubi się wypowiedzieć, choć zwykle się zgadza. Nasz menedżer uważa, że ​​robię ważne punkty, ale nie jest programistą.

Naprawdę mam trudności z utrzymaniem programów, które napisał, i nie zapewnia to dobrej atmosfery w zespole. Jak myślisz, co jest dla mnie najlepsze?


2
„„ tak, na pewno możesz użyć tej biblioteki, aby zrobić to za Ciebie, ale w ten sposób tak naprawdę nie rozumiesz, co się dzieje ””. Ma na myśli to, że ON nie rozumie, co się dzieje. Robimy :) Wydaje się, że boi się nauczyć czegoś innego, aby poprawić swoją wydajność.
Damien Roche,

7
Twój współpracownik nie jest przestarzały, po prostu opuścił kilka ważnych lekcji programowania 101. Wersjonowanie, abstrakcja itp. Były bardzo ważne 20 lat temu i dziś.
Jas

7
Termin „przestarzały” jest raczej obciążonym i nieoświeconym terminem. Mam kogoś, z kim pracuję, którego można opisać w podobny sposób, jak ty. Jest jednak znacznie MŁODSZY ode mnie.
Bill

1
Punkt dotyczący bibliotek jest całkiem poprawny. Naprawdę potrzebujesz zrozumienia tego, co robią - na przykład rzeczy w bibliotekach, które tworzą wątki lub zgłaszają wyjątki, mogą sprawić, że Twoje życie stanie się BARDZO nieszczęśliwe. Jednak szybki rzut oka na ich dokument lub kod źródłowy zazwyczaj wystarcza, aby zaspokoić ciekawość. To NIE jest argument, aby NIE używać rzeczy w bibliotekach, to tylko argument, aby wiedzieć, co robią (a następnie używać ich szczęśliwie zamiast w nieświadomości).
szybko_now

Odpowiedzi:


25

To brzmi jak jeden z tych „To dobry facet, ale…”, gdzie wiesz, że prawda nadchodzi. A prawda brzmi, jakby nie był tak dobrym inżynierem. Dobre oprogramowanie to nie tylko szybkość pracy i programowania. Chodzi również o inne rzeczy, o których wspominałeś - łatwość konserwacji, kompatybilność, abstrakcja (dla przyszłej wydajności) itp.

To powiedziawszy, wygląda na to, że masz na ręce programistę. Co gorsza dla ciebie jest to, że jest udowodniony i prawdopodobnie na swój sposób. Więc co możesz zrobić?

  • Obejdź go.
  • Staraj się tworzyć projekty według tak napiętego harmonogramu, jak on.
  • A jeśli nie możesz, uzyskaj lepszy wynik.
  • Z czasem te sprawdzone koncepcje, które odrzuci, zaczną się opłacać.

Z drugiej strony, jeśli jesteś zmuszony do pracy po swojemu, wyjdź.


Zgadzam się z tym tak samo jak odpowiedź @ Pierre 303. Opuści mroczną stronę, kiedy wydaje się, że ma piękne narzędzia, które mają dobrzy faceci.
Kortuk,

3
Bardzo mało zajmuje mu kodowanie, ale twój kod jest łatwy do utrzymania. Twoja wypłata pojawi się, gdy kod zostanie utrzymany. Dobry dział to śledzenie czasu poświęcanego na takie czynności, jak konserwacja i zobaczenie krótszego czasu poświęcanego na Twój kod, co sprawia, że ​​trochę więcej czasu warto.
Kortuk,

+1 za demonstrację przy użyciu dobrych praktyk pracy zespołowej.
Klaim

11

Nie próbuj zmieniać swojego kolegi. Opisujesz go jako osobę zdolną do dostarczenia działającego oprogramowania. Prawdopodobnie jest już za późno, aby zintegrować go z zespołem.

Masz dwie możliwości:

  • Dostosuj się. Może z czasem uda ci się go przekonać o użyteczności systemu kontroli źródła? Będziesz musiał zwiększyć swój krąg wpływów . Im bardziej jest odporny na zmiany, tym więcej czasu będziesz potrzebować.

  • Usuń się z team. Masz wiele punktów, aby to uzasadnić. Może powinieneś zostawić to, aby utrzymywało własne aplikacje w spokoju i poświęcić się nowym rzeczom.

  • Usuń się z company. Czasami jest to jedyne rozwiązanie.


4
303, myślę, że to najlepsza rada, nowy facet krytykujący kierownika bardzo kompetentnego i doświadczonego współpracownika wywoła pewne bardzo negatywne uczucia, z czasem możesz się przystosować i pomóc również innym. Mam nowych pracowników, którzy zaczynają ode mnie i myślą, że wiedzą coś, co działa lepiej, i udają się do szefa, mój szef słucha wszystkiego, ale to mnie wkurza, ponieważ za 3 miesiące odkrywają, dlaczego robiłem to tak, jak ja i narzekają na zmianę. Myślę, że jest to inny poziom, ponieważ my SVN i OOP, ale podstawowa przesłanka ma zastosowanie.
Kortuk,

3
Na świecie są 3 rodzaje ludzi - ci, którzy rozumieją binarny, a ci, którzy nie ...
Michael K

Sztuczka polega na tym, aby była łatwa w użyciu, ORAZ pokazała, że ​​istnieją istotne korzyści, gdy naprawdę ma to znaczenie. Podobnie jak pasy bezpieczeństwa ...

Nie zgadzam się. Niektóre praktyki są dobre tylko wtedy, gdy pracujesz solo, a ten facet wydaje się być ich pełen.
Boris Yankov

Wracając do tego pytania i tej odpowiedzi, po ponad roku opcja 3 okazała się właściwym rozwiązaniem
Martijn

6

Na twoim miejscu stworzyłbym teraz własny system kontroli źródła. Zacznij używać go do wszystkiego, co kodujesz, i administruj nim, aby inni członkowie zespołu mieli konta i mieli do niego dostęp. Twoi pozostali współpracownicy prawdopodobnie będą zachwyceni jego użyciem.

Twój kolega, który nie wierzy w takie praktyki, może nie być łatwy do przekonania. Jednak każdy kod, z którym jesteś zmuszony do pracy, który został napisany przez niego, powinien przejść do kontroli wersji, abyś mógł z nim pracować. Gdy potrzebuje dostępu do twoich zmian, wyślij mu prosty zestaw instrukcji krok po kroku, jak wyciągnąć kod z repozytorium.

Nie musisz być bojowy ani wychodzić poza niego, aby zaangażować go w bardziej nowoczesne procesy. Czasami po prostu pójście własną drogą i bycie liderem z działaniem jest bardziej skuteczne niż próba przekonania kogoś słowami. Dziecięce kroki. Jeśli zacznie bardziej reagować na kontrolę wersji, zacznij refaktoryzować podprogramy i dodawać testy jednostkowe w celu ochrony przed zmianami. Zautomatyzuj testy i pokaż mu, jak może uzyskać dostęp do wyników, gdy tylko dokona kontroli.

Wiele razy ludzie są odporni, ponieważ nie lubią zmian. Ale jeśli zmiany zostaną im przedstawione w sposób stopniowy i w sposób ułatwiający ich śledzenie, często szybko zobaczą korzyści.

Przede wszystkim spraw, aby było to dla niego jak najprostsze (Keep It Simple Stupid). Pozwól mu zacząć stosować się do tych praktyk na własnych warunkach. Ale niech cię to nie pociągnie.


Miałem złe doświadczenia z „próbowaniem świecić”: prywatne repozytorium niewiele pomaga, gdy nie ma definitywnej koncepcji „rewizji” (co zmienia się od współpracownika do integracji? Często, z ludźmi, którzy nie używają CVS, to tak: funkcja, ale nie te ”). To samo dotyczy testów automatycznych: co dobrego ma kompilacja, której nie naprawia ten, kto ją łamie? refaktoryzujesz i piszesz testy, on defromuje i przerywa testy. jeszcze raz: twoje słowo przeciwko jego, ale teraz twoje testy „zawodzą”, co „dowodzi”, że nie łapią niczego cennego. Nie może przewyższać przeciwko swojej drużynie.
keppla

4

Będę szczery, nie malujesz jego dobrego zdjęcia. Archaiczne metody, trudne w utrzymaniu oprogramowanie, uparte w nowych sposobach pracy, przeciwko abstrakcji itp

Z tego, co powiedziałeś, jeśli produkuje oprogramowanie w znacznie większym stopniu wolne od błędów SZYBCIEJ niż ty bez użycia bibliotek wielokrotnego użytku i wzorców projektowych mających na celu szybki rozwój aplikacji, to mówi więcej o tobie, niż o nim ...

..o nim .. tak, znajdź sposób, aby NIE z nim współpracować i NIE być związanym z jego pracą. Wygląda na to, że ma typowe samolubne podejście do swojej pracy. Nie możesz pracować z kimś takim, możesz tylko obserwować, jak pracują i sprzątać po nich (tak jak obecnie).


1
Mogę kodować znacznie szybciej, używając niczego specjalnego w małych projektach, ale, do diabła, lepiej utrzymujesz dobrze zaprojektowaną bazę kodu. To się opłaca dobry design. Cały projekt kodu oprogramowania opiera się na fakcie, że potrzeba więcej czasu na konserwację niż na kodowanie, aby naprawić błędy.
Kortuk,

kluczowa część „na małe projekty”. Wątpię, czy mówimy tutaj o małych projektach (czytaj: wysiłek zespołu).
Damien Roche,

całkowicie się nie zgadzam. nie mówi to nic o Walterze poza tym, że wie, jakie są te wszystkie dobre praktyki i jakie korzyści mogą przynieść zespołowi. nie stosowanie tych praktyk jest tym, o co chodzi w RAD, ponieważ spowalniają cię.
Ross

4

Widziałem to już wcześniej ,

I prawie jestem gotów się założyć: ten typ faceta pojawia się tylko „szybko”, ponieważ ma w głowie zestaw wypróbowanych i „wzorców”. 99% aplikacji Line of Business to CRUD , podstawowe rzeczy.

Prawdopodobnie używa ton Kopiuj i Wklej ze swojego istniejącego kodu (nic złego z tym).

Ale..

W momencie, gdy napotyka coś zdalnie złożonego, spada, dlaczego? ponieważ nie pasuje już do żadnego z podstawowych „wzorów”.

Małe wyzwanie ...

Stworzyłbym z boku projekt, złożony, który naprawdę korzysta z OOP i ponownego wykorzystania kodu.

Następnie pokaż mu ten projekt i poproś go o wdrożenie tej funkcji dla funkcji.

Zakładałbym wtedy, że jego kod prawie na pewno będzie 10 razy większy i 10 razy brzydszy, jeśli zaimplementuje go na swój sposób.


tak, zgadzam się, ale co on może z tym zrobić?
Ross

Po co spędzać czas na ponownym wdrażaniu projektu zabawki?

@Andersen, ponieważ niektóre programy, które nie chcą słuchać rozumu, akceptują dowody tylko wtedy, gdy zostaną przedstawione przed nimi
Darknight

@Ciemno, prawdopodobnie nie, ale dlaczego warto zastanawiać się nad ponownym wdrażaniem projektów zabawek, które nie dotyczą rzeczywistych problemów?

3

Spójrz na to od strony biznesowej.

Więcej czasu zajmuje tworzenie kodu buggiera. Dajesz mniejsze przychody, więc ssiesz.

Jeśli z czasem możesz to odwrócić, możesz to odwrócić.

Ale może, może tylko, ten przestarzały programista może nauczyć cię kilku rzeczy na temat szybkiego tworzenia kodu, który jest tak wolny od błędów? Może jego techniki nie są tak stare, jak myślisz?

Podejrzewam, że ktoś może stworzyć tak świetny kod bez bardzo dobrych praktyk. Możesz nauczyć się tych praktyk i zastosować je do „najlepszych praktyk” i modnych rzeczy, które rozumiesz.


2

Jeśli twój menedżer nie jest programistą, postaraj się wyrazić to w sposób zrozumiały.

  • Powinniśmy użyć sourecontrol, ponieważ jeśli nie, moglibyśmy mieć duże problemy z odzyskaniem

  • Zajmuje mi to x więcej czasu, ponieważ odmawia wykonania kilku dość podstawowych procesów.

Z drugiej strony, upewnij się, że nie jesteś zbyt pochłonięty perfekcją, tj. Jest to najlepsza praktyka, którą musimy przestrzegać. Prawdopodobnie twój współpracownik ma wiele do dodania, być może będziesz musiał powoli popychać go we właściwym kierunku.


„odzyskiwanie” == wycofanie.

2

Wygląda na to, że twój współpracownik nigdy nie rozwijał się w zespole. Tego rodzaju partner guru solo nie pozwala na dobrą dynamikę grupy. Więc powiedz o tym swojemu przełożonemu i spróbuj omówić zalety i wady z partnerem, który to zrobił. Jeśli mógłbyś to zrobić w lepszy sposób, ale jeśli on odmówi, idź w górę w szeregach dowodzenia


5
wspinanie się po łańcuchu dowodzenia czyni wrogów każdą osobą, której nadepnąłeś, i często nie przynosi to dobrych rezultatów.
Kortuk,

1

Porozmawiaj ze swoim menedżerem, tak jak tutaj. Tutaj jest potencjał do wzrostu - jeśli twój współpracownik jest dobry, jak mówisz, to nie powinno go przekonać, aby zaczął przechodzić na kontrolę źródła i .Net z odpowiednimi koncepcjami OO.


1
To znaczy, jeśli chce się zmienić ...
Walter,

3
Wielu menedżerów, których miałem w przeszłości, nie ceni nowego faceta zmieniającego coś, co wydaje się działać. Cenią produkt wykonany szybko, ponieważ nie rozumieją w pełni tego, co robisz. Wygląda na to, że masz bossa, który nie jest techniczny, co może być poważną szkodą dla twojej sekcji.
Kortuk,

1
Jeśli tego nie zrobi, jeszcze ważniejsze jest, aby kierownik (zakładając, że był) wiedział o tym.
Otávio Décio,

@Kortuk - to bardzo dobry punkt, a jeśli to prawda, OP ma poważne kłopoty.
Otávio Décio,

Myślę, że jeśli OP podejmie działania, aby nagle zmienić te rzeczy i zmusić je, aby nadepnęły palce. To czyni wrogów i może zaszkodzić środowisku pracy, w którym mógłby wiele się nauczyć od swojego kolegi.
Kortuk,

1

Rozmawiałbym z innymi, aby uzyskać szerszy obraz tego, jak rzeczy wyglądają tam, gdzie jesteś. Być może istnieją pewne separacje, aby jego kod nie musiał się zbytnio mieszać z innymi, ponieważ istnieje potencjał, aby segregować go we własnym obszarze w jeden sposób, który można by sobie z tym poradzić, chociaż jest to bardziej na wyższym poziomie jak dyrektor lub dyrektor ds. informatycznych, a nie programista.

Może zechcesz z nim porozmawiać, aby dowiedzieć się, jakie większe systemy zbudował, ponieważ istnieją systemy dużych przedsiębiorstw, które są zwykle elementami składowymi, w których kod spaghetti może trafić do krainy: „Och, właśnie dlatego OOP może być dobry! ” czasami zdarza się tak, że okazuje się całkiem użyteczne sprawdzenie, jak może to być przydatne w przyborniku.

Apatia może być kolejnym podejrzanym, by sprawdzić, czy właśnie dlatego odrzucił niektóre rzeczy, które uważam za fundamentalne pod względem tego, jak mam tendencję do projektowania kodu, ale może wtedy miałem za dużo pomocy Kool.


1

Rzuć mu wyzwanie (w dobry sposób), aby udowodnić, że jest inaczej, pokaż mu fajną stronę narzędzi i praktyk. Nie patronuj.

Na przykład być może nie wierzy w wersjonowanie jako pomoc, ale pokaż mu, jak rozgałęzianie / scalanie i jak może pracować nad kilkoma eksperymentalnymi funkcjami bez potrzeby nadmuchiwania plików.

Jeśli chodzi o OOP, pokaż mu kilka fajnych / skomplikowanych wzorców projektowych, takich jak wzorzec poleceń, wzorzec zadań i jak może zaoszczędzić cenny czas i cały swój zespół.

Jeśli nie interesujesz się nim w najmniejszym stopniu ... to może być przegrana sprawa, ale z drugiej strony masz narzędzia dla swojego zespołu i możesz go przewyższyć. Spróbuj użyć oprogramowania do repozytorium, które pokazuje / zatwierdza wiadomości e-mail, które widzi Twój menedżer, co zwiększy przejrzystość twojego menedżera i pozostawi współpracownika poza obrazem (bitbucket.org ma darmowe prywatne repozytoria z nieograniczoną przestrzenią, jeśli używasz merkurialu).

W końcu nie próbuj przekonywać słowami, ale niepodważalnymi czynami, to najlepszy sposób na radzenie sobie z upartymi ludźmi IMHO (czasami działa też psychologia odwrotna, lol).


1

no cóż, wspomniane techniki są oczywiście dobre, ale musisz również zadać sobie pytanie, czy popychasz je jako ideologię. Uważam, że młodsi programiści są nieco ewangeliczni w kwestii tego, co zdobyli na studiach. pamiętaj, że te techniki są dobre ze względu na wyniki: kontrola wersji umożliwia równoczesne programowanie, jaśniejsze śledzenie projektu, programowanie, testowanie, etapy naprawiania błędów. jeśli twoje projekty są naprawdę krótkoterminowe, wiele z nich jest po prostu nieodpowiednich i skończy się sprawiając, że będziesz mniej zwinny. po prostu nie jest tak, że najlepsza praktyka oznacza stosowanie każdej możliwej najlepszej praktyki. na przykład abstrakcja, przynajmniej czasami, może być bardziej zobowiązaniem niż pomocą. kontrola wersji jest najbardziej sensowna, gdy masz rozszerzone ramy czasowe programowania, złożony kod, wielu programistów - istnieje pewien rodzaj synergii, która trudno uzyskać przyczepność przy częściowym przetwarzaniu.

Myślę, że miejscem, od którego należy zacząć, jest pilnowanie potencjalnego ponownego wykorzystania - w miarę upływu czasu projekty, pomyśl o podobieństwach lub bardziej ogólnych ramach. próba wyjścia przed projekty byłaby potężnym posunięciem i pozwoliłaby ci pracować w większej technice ...


Kontrola wersji zapewnia również historię. Ważne, gdy nie ma już ludzi w pobliżu.

0

Powinieneś poprosić swojego przełożonego o przygotowanie prezentacji dla KAŻDEGO, dlaczego oprogramowanie do „wersjonowania” jest dobre. Nie wyróżniaj swojego współpracownika.

Sceptycznie podchodzę do oprogramowania do kontroli źródła, ponieważ widzę, że ludzie cały czas go niewłaściwie używają - jako sposób na uniknięcie pracy.

Moi współpracownicy stale się łączą, nieustannie nadepną na siebie nawzajem. Ale dobry przyjazny wykład na temat jego zalet byłby miły i pobudziłby dyskusje.


1
nieustanne stawianie sobie czoła jest oznaką złej architektury oprogramowania. Nie ma to nic wspólnego z kontrolą źródła i bez tego może się pogorszyć.
deadalnix

@deadlnix To też może być powód, ale myślę, że w niektórych przypadkach można to również przypisać nadmiernie gorliwemu korzystaniu z rozgałęziania, gdy nie jest to właściwe rozwiązanie.
Nicole
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.