Radzenie sobie z moim przestarzałym współpracownikiem

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?

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

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.

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.

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

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.

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.

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.

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

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.

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.

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

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

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.