Czy mam pozwolić mojemu przełożonemu to zrobić?

Tak, prawie na pewno. Jeśli jesteś w normalnym stosunku pracy, kod write należy do Twojej firmy i nie masz prawa odmówić Twojemu przełożonemu dostępu do Twojego kodu. Odmowa prawie na pewno byłaby postrzegana jako nierozsądna lub podejrzana i mogłaby spowodować postępowanie dyscyplinarne.

Chce sprawdzać mój kod tydzień po tygodniu

Jeśli to ci przeszkadza, dowiedz się, czego on naprawdę potrzebuje. Kiedy to się pojawi, porozmawiaj z nim o tym. Jeśli wzajemnie uznano, że nie programuje, zapytaj, co chciałby z tym zrobić i jak możesz mu w tym pomóc. Jeśli on chce liczb, a ty nie chcesz być oceniany na podstawie linii, znajdź alternatywne wskaźniki, które lepiej odzwierciedlają twoją pracę, np. zasięg testu.

Nie bądź defensywny, bądź dumny ze swojego kodu.

(Chyba że jest to naprawdę zły kod, w takim przypadku przestań pisać źle kod!)

Myślę, że chce kontrolować mój kod, licząc wiersze lub przekazując go swojemu przyjacielowi, który powie mu „to jest do bani, zapłać mi, a zrobię to za mniej”.

Możesz mieć rację.

Może chce liczyć wiersze. Może chce sprawdzić Twój styl kapitalizacji. Może chce zobaczyć, jak dobrze komentujesz. Może chce sprawdzić, czy postępujesz zgodnie z przewodnikiem stylu firmy. Może chce się czegoś nauczyć z twojego kodu. Tak naprawdę nie wiesz, a my najwyraźniej nie możemy wiedzieć. Ale nieważne - to i tak jego prawo. Pracujesz dla niego. Próba odmówienia szefowi dostępu do kodu, który piszesz, z pewnością będzie mieć negatywny wpływ na Twoją pracę.

Jeśli Twój menedżer naprawdę chce się ciebie pozbyć i zamiast tego zatrudnić swojego przyjaciela, prawie na pewno nie potrzebuje dostępu aby to zrobić.

Myślę, że udostępnienie mu mojego kodu tylko mnie spowolni.

Możesz mieć rację w tym przypadku.

Czy powinienem pozwolić mojemu menedżerowi to zrobić?

Tak, ale „zezwól” jest tu niewłaściwym słowem. Jeśli Twój przełożony każe Ci udzielić mu dostępu i jeśli w ogóle cenisz swoją pracę, nie masz wyboru.

Nie jesteś właścicielem kodu, ale robi to Twój pracodawca. Nie jesteś menadżerem, ktoś inny jest. Nie możesz decydować, kto ma dostęp do Twojego kodu, a kto nie, robi to Twój menedżer.

Twój menedżer nie potrzebuje Twojej zgody na dostęp do napisanego przez Ciebie kodu. Próba odmówienia dostępu do napisanego kodu może być szybkim sposobem na uzyskanie odmowy dostępu do swojej pracy.

Dziwnie brzmiące pytanie.

Zwykle w przypadku tworzenia oprogramowania zawsze masz system kontroli wersji, w którym każdy, kto ma prawa, może uzyskać dostęp do kodu i zobaczyć jego historię rozwoju. Twoje pytanie brzmi tak, jakbyś miał swój kod lokalnie lub w niedostępnym repozytorium ( co samo w sobie jest bardzo złym pomysłem, utrata danych jest zawsze nieuchronna ) albo twój menedżer nie wie, jak działa oprogramowanie przechowywane ( co sprawia, że ​​jest bezradny, jeśli zdecydujesz się odejść lub ciężarówka cię uderzy ).
To uruchamia dzwonki alarmowe, jak wszyscy inni już zauważyli, kod nie należy do Ty i nie masz absolutnie żadnego prawa do odmowy dostępu . Jedynym wyjątkiem jest sytuacja, gdy jesteś wolnym strzelcem i zastrzegłeś sobie swoje prawa do swojego kodu.

Moja kryształowa kula sugeruje, że być może inne osoby mają dostęp i obawiasz się, że Twój przełożony jest pointy- z włosami szefem? Jest wiele powodów, dla których chce uzyskać dostęp do Twojego kodu, a niektóre są całkowicie nieszkodliwe.

• Tak naprawdę nie chce zaglądać do Twojego kodu, po prostu chce wiedzieć, jak jest przechowywany i jak można uzyskać do niego dostęp i jest zbyt dumny, by przyznać, że czuje się głupio. Żądając zobaczenia kodu, może rzucić to pytanie jako prawidłowe zapytanie bez utraty twarzy.

• W rzeczywistości próbuje ocenić twój kod, pokazując (jego części) innym osoby, które według niego mają wiedzę. Tak, nie mając pojęcia, że ​​to może przynieść ci odwrotny skutek, ponieważ nie może określić, czy druga osoba go bzduruje, ale jeśli nie, to jest całkowicie w porządku. Przeglądy kodu przez inne osoby posiadające wiedzę są standardową praktyką, zwłaszcza że ludzie mają określone zalety i wady: Unikają pewnych błędów, ale też wpadają w określone pułapki. Jeśli tego nie chcesz, problem leży po stronie Ciebie.

• Twój bezpośredni przełożony to osoba, która nie może przyznać, że jest bezsilna i stara się zachować pozory, że to on tu rządzi. Dlatego spotkania i prośby o zapoznanie się z kodem. Zależy to od osoby, czy jest to przeważnie nieszkodliwe (spotkanie polegające na marnowaniu czasu), czy też wyjątkowo irytujące (on naprawdę próbuje użyć bezsensownych metryk, głupio komentuje Twój kod lub znalazł nowego guru programowania, który ma na myśli srebrną kulę).

• Najgorszy przypadek: niektórzy ludzie uznali, że nie są zadowoleni z Twojej pracy i szukają zastępstwa. Teraz zdają sobie sprawę, że wydarzył się najbardziej wiarygodny wypadek: nie mają pojęcia, jak działa twój kod i próbują to naprawić. Kontrargument: gdyby tak było, jest bardziej prawdopodobne, że będzie on naciskał w tej sprawie na codziennych spotkaniach.

Żyj z tym, rób, co chce (dobrą odpowiedzią użytkownika52889 jest rozmowa, aby dowiedzieć się, czego naprawdę chce), a jeśli coś pójdzie nie tak, rozwiąż problem, narzekając do wyższej instancji lub ponieść konsekwencje.

Czy naprawdę możesz powiedzieć „Nie”? Jestem bardzo zaskoczony, że Twój menedżer musi o to zapytać. Fakt, że stawiasz opór, nie działa na Twoją korzyść. Jeśli trzymasz się swojego kodu, powinieneś być w stanie go obronić, zwłaszcza przed kimś mniej kompetentnym.

Nie potrafię sobie wyobrazić paranoicznej organizacji, w której pracujesz.

Inni odpowiedzieli na pytanie, czy należy przyznać dostęp. A także wady wynikające z nie wykonywania poleceń. Pozwólcie, że przedstawię perspektywę menedżera.

Załóżmy, że mam pracownika z umiejętnościami, których naprawdę nie jestem uprawniony do właściwej oceny. Coś produkują, może to działa, może ma problemy. Może nawet nie wiem, czy rodzaj i liczba zauważonych problemów jest „normalna”, czy też świadczy o złej pracy. Być może jest odwrotnie, a praca jest naprawdę wysokiego kalibru, ale nie mam pojęcia, a mój szef domaga się więcej.

Jako menedżer muszę się upewnić idą tak, jak powinny.

Nie mogę po prostu uwierzyć Ci na słowo, ponieważ prawdopodobnie powiesz mi, że jakość Twojej pracy jest po prostu niesamowita - i możesz mieć zbyt zawyżoną opinię na temat

Mógłbym zatrudnić konsultantów do oceny pracy. Z drugiej strony, bez względu na to, jak wygląda praca, jeśli konsultanci uważają, że przez złe mówienie, dostaną ze mną mocniejszy kontrakt, a potem źle to zrobią. Więc mój poziom zaufania, idąc tą drogą, jest już niski.

Oznacza to, że muszę rozmawiać z ludźmi, którym ufam. Poproszę cię, żebyś spakował swoją pracę i pozwolił tym ludziom się temu przyjrzeć. Nie będą szukać daleko, bo to będzie osobista przysługa. Miejmy nadzieję, że faktycznie wiedzą, o czym mówią. To pozostawia kilka możliwości.

• Po pierwsze, są ekspertami i uważają, że to, co zrobiłeś, jest co najmniej wystarczająco dobre.
• Po drugie, są ekspertami i myślą, że Twoja praca to katastrofa.
• Po trzecie, nie są ekspertami, ale nie chcą się dalej angażować i po prostu mówią, że to dobrze.
• Po czwarte, nie są oni ekspertami ale nie chcę źle wyglądać i dlatego wybieraj raczej bezsensowne rzeczy, abyś się zmienił.

W każdym z tych scenariuszy jedynym , którym powinieneś się obawiać, jest to, czy szef rzeczywiście zna dobrych programistów, którzy uważają, że twoja praca to śmieć. Jeśli tak jest, najlepszym rozwiązaniem jest spotkanie z nimi, aby omówić swoje decyzje, uważnie słuchając tego, co mają do powiedzenia.

Szczerze mówiąc, fakt, że nie chcesz ktoś inny to widzi, sprawia, że ​​wierzę, że masz coś do ukrycia. Być może wiesz, że Twoja praca nie jest tak wspaniała i boisz się, co ktoś o niej pomyśli. W takim przypadku możliwość omówienia tego z osobą trzecią byłaby dla Ciebie bardzo dobra. Dlatego proponuję porozmawiać ze swoim przełożonym i zapytać, czy mógłby dokonać przeglądu kodu na miejscu, razem z Tobą. W ten sposób możesz zarówno uczyć się z ich doświadczenia, jak i wyjaśniać podjęte przez siebie decyzje.

Każdy świetny programista, którego znam, chce, aby ludzie przyjrzeli się jego pracy. Czemu? Ponieważ kodowanie jest trudne i nawet bardzo doświadczeni ludzie mogą popełniać podstawowe błędy. Czy to w samym kodzie, czy nawet w ogólnej architekturze. Wiemy, że jeśli zostanie złapany wystarczająco wcześnie, ból związany z naprawą jest zminimalizowany. Wiemy też, że nikt nie jest doskonały i wszyscy możemy się od siebie uczyć.

To rozsądna prośba, przynajmniej z pozoru. Jest wiele dobrych powodów, dla których twój szef może chcieć uzyskać dostęp do twojego kodu źródłowego i kilka wiarygodnych powodów, dla których mu go odmówisz. „Nie chcę, żeby utrudniał mi życie” nie jest uzasadnionym powodem.

Odmowa pokazania mu swojego kodu byłaby równoznaczna z niesubordynacją. Podsumowując, daj mu to, czego chce.

Kontekst: nie jest specjalistą i stara się głównie zmonopolizować dostęp do mojej wiedzy technicznej, np. jeśli chcesz używać technologii X, musisz przejść przeze mnie. Ale inni ludzie byli bardzo zadowoleni z mojej pracy i nikt nigdy nie narzekał.

1. Twój kierownik ma pełne prawo decydować, jakiej technologii użyć, nawet jeśli nie jest przygotowany do podjęcia takiej decyzji. Twoim obowiązkiem jest przedstawienie swojej sprawy popartej dowodami, które ceni. Mów o dolarach i centach, a nie o surowej sile wydajności lub duchowej wyższości.

2. Czy istnieje formalny proces weryfikacji kodu? Jeśli nie, zacznij. W przeciwnym razie nie ma formalnego sposobu na uchwycenie opinii innych o Twoim kodzie. Może osoby, które wydawały się zadowolone z Twojego kodu, są tymi samymi, które krytykują go pod adresem Twojego kierownika. A może jesteś po prostu paranoikiem. Nie możesz tego wiedzieć bez formalnego sposobu na pociągnięcie Cię do odpowiedzialności za jakość kodu w ocenie innych. Nic nie jest w stanie powstrzymać tego samego wroga przed dźgnięciem cię w plecy, ale możesz przynajmniej stwierdzić, że „nie to powiedział podczas przeglądu kodu”.

3. Jak wielu innych powiedziało , cały kod powinien znajdować się w repozytorium na serwerze firmowym. W idealnym przypadku okresowe tworzenie kopii zapasowych, kolokacja itp. Jeśli w tej chwili nic nie jest skonfigurowane, uzasadnij to. („Jeśli uderzy mnie autobus, nadal masz dostęp bla bla bla…”)

4. Dokumentuj wszystko , od decyzji projektowych, przez proces tworzenia, po przypadki testowe. Opierając się na twoim pytaniu, mam wrażenie, że nie jesteś doświadczonym programistą w firmie, która nie ma żadnego doświadczenia w tworzeniu oprogramowania. Twój kierownik może nie wiedzieć, jak kodować, ale (mam nadzieję) jest wystarczająco logiczny i analityczny, aby zrozumieć dokumenty peryferyjne. Niekoniecznie muszą one być bardzo formalne, ale powinieneś zostawić wystarczającą ilość papierowych śladów (wirtualnych i / lub fizycznych), aby umożliwić kompetentnej osobie wejście w twoje buty bez większych trudności. Jeśli nie chcesz tego zrobić, powstrzymujesz się przed rozwojem i trzymasz firmę jako zakładnika.

5. Twój menedżer najprawdopodobniej nie ma prawa udostępniać Twojego kodu poza organizacja. Nie musisz się zbytnio martwić o wyimaginowanych „przyjaciół”.

Bądź otwarty na swoje obawy przed przełożonym. Dobra komunikacja i wzajemne relacje są niezbędne dla każdego udanego związku, w tym w środowisku zawodowym.

Gdybym był Twoim kolegą i zdawał sobie sprawę z tego, co robisz lub myślisz, jak wspomniano powyżej, byłbym bardzo zmęczony współpracą z tobą ... chyba że podzielę te same uczucia wobec twojego przełożonego. W takim przypadku muszę zapytać: „ta praca jest do niczego. Dlaczego nie szukasz nowej pracy?”

Jak OP wspomina w komentarzu do odpowiedzi @ blankip:

Jestem jedynym programistą i nikt inny nie używa repozytoriów. I nie mam zespołu.

Może po prostu Twój przełożony próbuje sprawdzić jakość Twojej pracy, jak każdy dobry menedżer powinien w ramach wzajemnej oceny.

Nawet jeśli Twój kierownik nie jest technicznie wystarczająco zdolny do samodzielnego przejrzenia kodu, może on działać jako „wycinanka z kartonu”, tj. jeśli zwerbalizujesz swoją pracę swojemu przełożonemu, być może zauważysz problemy, błędy itp., których inaczej byś nie zrobił.

Twoje ostatnie pytanie jest zatytułowane „Wszyscy chcą mnie ze względu na moje umiejętności, ale nie mam wsparcia i wszystko to wygląda jak polityczne przeciąganie liny”.

Wygląda na to, że Twój menedżer zdaje sobie sprawę, że jest więcej pracy, niż jesteś w stanie znieść, ale nie wie, co z tym zrobić. Wydaje się, że chce monitorować, jaką pracę wykonujesz dla kogo, co powinien wykonać: jeśli ma zasób, powinien wiedzieć, który dział z niego korzysta. Traktujesz to jako „monopolizowanie”, ale jeśli jesteś zasobem swojego bezpośredniego przełożonego, inni nie powinni pomagać sobie w Twoim czasie. Myślę, że dobrym pomysłem byłoby przechowywanie kart czasu pracy. Przedyskutuj to ze swoim przełożonym.

Tak, powinieneś udostępnić mu swój kod. W końcu to kod firmy, a nie Twój.

Coś musi się zmienić. Musi zaistnieć jedna z następujących sytuacji.

1. Zatrudniają młodszego programistę.
2. Zatrudniają starszego programisty.
3. Szkolisz menedżera kodu (wygląda na to, że właśnie to próbuje zrobić, ponieważ nie ma budżetu na poprzednie dwie opcje).
4. Odchodzisz.

Twoja obsługa sytuacja spowoduje różnicę między 1 a 2. Którą z nich chcesz? Jeśli zatrudniają innego programistę, czy chcesz wziąć udział w procesie rozmowy kwalifikacyjnej?

Sugeruję, abyś skorzystał ze spotkań ze swoim kierownikiem, aby omówić obciążenie pracą i przyszłość wewnętrznego rozwoju oprogramowania.

Jest piąta opcja: zostaniesz zwolniony, a oni dostaną innego programistę lub outsourcing. Wydaje się to mało prawdopodobne, ponieważ istnieje teraz kod, który napisałeś i który najlepiej rozumiesz. Ale jeśli odmówisz współpracy, stanie się to realistyczną możliwością.

Konsensus w odpowiedziach wydaje się być taki, że tak, musisz pozwolić mu zobaczyć / uzyskać dostęp do kodu, jeśli sobie tego życzy, i być przygotowanym na ewentualne konsekwencje. W najlepszym przypadku chce po prostu zobaczyć, co się dzieje, w najgorszym przypadku jest to czerwona flaga, że ​​coś jest nie tak, ale w każdym razie nie masz wyboru.

Jednak, chociaż wątpliwe, że dotyczy to ciebie, ja chciałem zwrócić uwagę na jeszcze jedną rzecz: w niektórych branżach dostęp do Twojego kodu lub przynajmniej możliwość jego modyfikacji może być w rzeczywistości zły lub nawet niezgodny z prawem. Nie jestem tutaj ekspertem, ale jeśli twoje miejsce pracy wymaga zgodności z czymś takim jak PCA lub SOX (pomyśl: branże finansowe / bankowe), może to być duży problem w audycie, jeśli szef przeglądał lub modyfikował kod źródłowy. Teoria głosi, że oddzielenie problemów zapobiega zanieczyszczeniu. Jest to podobne do powodów, dla których w większości miejsc programiści nie mają dostępu do danych produkcyjnych. W niektórych scenariuszach audytu musisz być w stanie jednoznacznie stwierdzić, że tylko programiści mają dostęp do kodu źródłowego, a menedżerowie - którzy mogą mieć dostęp do danych produkcyjnych, w przeciwieństwie do programistów - nie.

Teraz oczywiście przenosi się to na terytorium prawne i nie powinieneś w żaden sposób korzystać z porady prawnej od Stack Exchange, ale tak jak w przeciwieństwie do powyższych odpowiedzi, istnieje sytuacja, w której z powodów prawnych twój szef nie może mieć dostępu do kod źródłowy, nawet gdyby chciał. Jeśli tak, możesz zwrócić się do niego ze swoimi obawami, że próbujesz uchronić was oboje od kłopotów. Twój przebieg może się różnić, skonsultuj się ze swoimi przełożonymi, nieważne, jeśli zabronione, itp.

W relacjach w miejscu pracy, zwłaszcza z szefem, zawsze pamiętaj:

Nie zajdziesz zbyt daleko, mówiąc ludziom, czego NIE zamierzasz robić.

Po pierwsze, jest twoim szefem i każda praca, którą wykonujesz, jest w zasadzie jego. Dotyczy to również sytuacji, gdy coś schrzanisz, to jego wina.

Najlepszym sposobem na poradzenie sobie z tym jest zaangażowanie się. Jeśli potrzebuje twojego kodu z konkretnego powodu, zapytaj go, co to jest i pomóż mu go zdobyć. W ten sposób masz przynajmniej jakąś kontrolę lub wgląd w to, do czego go używa.

Wymaganie dostępu do kodu i zmiana spotkań z dwutygodniowych na cotygodniowe to objawy menedżera, który nie czuje się w pełni poinformowany o Twoim statusie i postępach.

Oczywiście powinieneś dostarczyć wszelkie artefakty, które wyprodukowane w trakcie pracy, które Twój kierownik chce zobaczyć. Ponadto zastanów się, co oferujesz, i zobacz, czy możesz zrobić więcej, aby go informować.

Jedna strategia, której użyłem w sytuacji, gdy mój menedżer nie miał kwalifikacji do bezpośredniej oceny moich postępów , Brałem udział w projekcie jednoosobowym, a mój projekt miał kluczowe znaczenie dla celów firmy: uzgodniliśmy serię przypadków testowych i dat, a co tydzień informowałem, które przypadki testowe zdały. to tylko przykład. Ty i Twój menedżer musicie wspólnie wypracować, jakich informacji potrzebuje co tydzień w Twojej konkretnej sytuacji.

Jeszcze jedna rzecz, o której jeszcze nie wspomniałem.

Weź pod uwagę, że masz menedżera „odcisków palców”. Czuje, że jeśli nie jest częścią pracy, nie wykonuje swojej pracy. Dlatego chce zobaczyć, co robisz.

Miałem zaszczyt pracować z kilkoma okazami z nich. Wydaje się, że nie ma dla nich znaczenia, że ​​nie rozumieją przepływu pracy lub tego, co robisz. Ważne jest to, że mogą coś zmienić, cokolwiek. Ułatw mu to.

1. Kod nie jest Twój - należy do zespołu i osoby, która Ci zapłaciła.
2. Kod należy udostępnić - ze względów jakościowych.
3. Powinieneś być dumnym, pokazując kod innym.
4. Jeśli odmówisz pokazania kodu, jako pracodawca będę podejrzliwy co do twoich zamiarów. Czy sprzedajesz to rywalowi? Czy zaimplementowałeś rzeczy, które mogą być użyte do oszustwa?
5. Jeśli twój kod jest "gówniany", być może przyniesie to korzyści innym osobom. Zawsze uczysz się od innych. Nawet ja, który byłam w tym biznesie odkąd pamiętam.

Cokolwiek robisz, odpowiadaj e-mailem, aby mieć doświadczenie i być bardzo pozytywnym i pomocnym. To nie jest TWÓJ kod, to kod, który napisałeś dla swojego pracodawcy.

Rzecz w tym, że jeśli chcą cię zwolnić, wiele stanów ma zatrudnienie „na życzenie”… więc on może to zrobić… i nie potrzebuje uzasadnienia. Bardziej prawdopodobne jest, że ma inny plan, wtedy musisz mu pomóc.

Zazwyczaj, gdy jestem niechętny, aby pokazać kod, który napisałem (a nie „mój kod” ), to dlatego, że działa, ale nie jest ładne ...

Więc po wyrażeniu zgody na udostępnienie / pokazanie kodu, powiedz mu, że kod nie został udokumentowany, aby mógł być zrozumiany przez Jeśli chce, aby było to częścią Twoich standardowych praktyk operacyjnych, z pewnością możesz to zrobić, ale będziesz musiał zrewidować swoje szacunki / koszty projektu w górę. Zapytaj go również, czy istnieją jakieś wytyczne lub standardy kodowania, których chciałbyś, abyś przestrzegał.