Załóżmy, że pracujesz dla firmy i tworzysz dla nich oprogramowanie. Nie masz pojęcia o dużym obrazie, a może drobnym. To, co masz, to zadania przypisane do ciebie przez system śledzenia problemów. Otrzymujesz zadania, sprawiasz, że działają tak, jak je opisuje zadanie, odsyłasz je z powrotem. Jak dodanie 2 liczb całkowitych:
function add(a,b){return a + b;}
Ale później, w miarę postępu projektu, zauważasz, że w miarę jak add
staje się bardziej złożony, zdajesz sobie sprawę, że powinien on potrzebować jakiejś formy architektury, więcej niż funkcji, która dodaje parametry i zwraca wartość. Jednak tego nie wiedziałeś. Po pierwsze, wszystko, czego potrzebowali, było takie proste add
. Nie spodziewałeś się, że add stanie się tak skomplikowany.
Projekt rozwija się z większą liczbą funkcji, których nie spodziewałeś się po pierwsze. I na koniec, gromadzisz kolejne hacki i warstwa po warstwie funkcji, aby uniknąć łamania / przepisywania istniejącego kodu.
Jak sobie radzisz z tymi sytuacjami? Jak walczysz z długiem technicznym jako „najniższy programista”?
Wyjaśnienie:
Jesteś „implementatorem”, najniższym w hierarchii.
Widzisz problem, ale nie masz nic do powiedzenia w tej sprawie.
Nie liczę długu technicznego ani nie szukam narzędzi.
Odnośnie trzeciego „duplikatu”
- Refaktoryzacja i przepisywanie - Jesteś zablokowany dla swoich zadań. Nie otrzymujesz dodatkowych opłat.
- Przegląd architektury - znasz cały system, ale nie masz pojęcia o architekturze.
- Zamrożenie kodu - to nie twoje połączenie. Nie jesteś zarządem.
- Modularyzacja - brak pomysłu na architekturę. Moduły zmieniają się wraz ze zmianami wymagań.
- Zautomatyzowane testy - Brak.
Odpowiedzi:
Za każdym razem, gdy zauważysz coś takiego, wprowadź nowy bilet do swojego systemu śledzenia problemów.
Przyzwyczaj się do używania narzędzia do śledzenia problemów jako podstawowego narzędzia do komunikowania takich rzeczy, ponieważ od tego momentu będzie łatwo wybierać, oceniać i ustalać priorytety dla starszych pracowników / kierownika / kierownika / osoby odpowiedzialnej za śledzenie problemów w projekcie .
Użyj odpowiedniego narzędzia do pracy. Robię to zawsze i zdecydowanie polecam zrobić to samo.
Jako przykład, oto bilet, który utworzyłem około miesiąc temu. Po zakończeniu konkretnej funkcji odkryłem, że kod stał się znacznie bardziej skomplikowany niż wcześniej, ale nie mogę tego naprawić w terminie podanym na wdrożenie funkcji.
(Nazwy funkcji, biletów i kodu używane w prawdziwym module śledzącym są ukryte, ale tekst jest kopiowany w niezmienionej postaci).
FWIW moja rada obowiązuje niezależnie od tego, jakim jesteś „poziomem”.
Używam go na twoim obecnym („najniższym”) poziomie i używam go teraz, kiedy mój poziom jest dość daleki od „najniższego” i mam zadowalające „powiedz”, jak to nazywasz, i zamierzam go użyć zawsze bez względu na wszystko.
Pomyśl o tym, bez żadnego poziomu, bez względu na to, ile masz władzy, po prostu nie ma lepszego sposobu.
Jeśli powiesz „ hej ”, mamy problem , to tylko grzechotanie powietrza. I nawet jeśli twój szef / dowódca się zgodzi i powie, że masz rację, mamy problem , to nic nie zmienia - to tylko grzechotanie powietrzem po raz kolejny i nie może być niczym innym.
Użyj odpowiedniego narzędzia do pracy. Śledzenie problemów jest właściwym narzędziem dla opisywanego zadania .
Zauważysz problem, wprowadzasz go do systemu przeznaczonego do śledzenia go, a on zajmuje się resztą w najlepszy możliwy sposób - po prostu dlatego, że został zaprojektowany do tego :
Niezależnie od innych środków komunikacji, posiadanie biletu w trackerze ułatwi ci to.
Nawet jeśli wolisz grzechotać w powietrzu , powiedzenie „Chciałbym omówić BILET-54321 ...” stanowi bardziej solidny punkt wyjścia niż „Słuchaj, chciałbym porozmawiać o jakimś fragmencie kodu, z którym miałem do czynienia jakiś czas temu ... ”I możesz bezpiecznie przekazać referencje do biletu pocztą: nawet jeśli poczta zaginie, problem nadal będzie występował w module śledzącym, wraz ze wszystkimi szczegółami, o których chciałeś powiedzieć.
źródło
Co sprawia, że czuję się źle z powodu twojego scenariusza, to dokładnie to, co napisałeś w nagłówku i wielokrotnie w tekście pytania:
Jesteś najniższym programistą w łańcuchu
Dlaczego ten punkt jest tak ważny? Po pierwsze, i z czysto technicznego punktu widzenia masz rację. Jesteś zatrudniony jako „implementator” rzeczy, pszczoła robotnicza, która działa na podstawie wydanych poleceń.
Ale nawet jeśli jesteś najniższym deweloperem pod względem rangi, nadal nie jest to w porządku. Kluczem tutaj jest uświadomienie sobie, że postrzegasz siebie jedynie jako najniższego programistę. Czy kiedykolwiek próbowałeś przezwyciężyć to postrzeganie siebie i faktycznie przejąć odpowiedzialność za coś ?
Brać! Nie czekaj, aż ktoś uczyni cię odpowiedzialnym.
Zazwyczaj jest odwrotnie: zarabiasz więcej, a twoja opinia jest szanowana bardziej, gdy pokażesz, że jesteś wart swojej ceny . To „zrób wcześniej”, a nie na odwrót.
Od ludzi w moim zespole oczekuję dokładnie tego: poczucia odpowiedzialności za projekt lub produkt, który staramy się zbudować i za wszystkie procesy związane z tym wysiłkiem. Gdy ktoś w moich robi na mnie wrażenie zespołu przejmując odpowiedzialność, np proponowanie usprawnień lub nawet lepszy start do poprawy rzeczy na własną rękę, to są ludzie, którzy będą awansować.
Innymi słowy: nikt nie promuje robotniczych pszczół, ludzi biernie czekających na przydzielone im zadania, pozbawionych nawet najmniejszego mrugnięcia inicjatywą „ ponieważ nie są za to wynagrodzeni ”, w końcu jęcząc, że nigdy nie mieli szansy.
Oczywiście wszystko to znowu zależy od kultury twojej firmy, do czego Joel odnosi się w „Two Stories” powiązanych przez Arthura. Jeśli menedżerowie firmy są naprawdę tak głupi, aby blokować swoim ludziom postęp, wówczas wskaźnik fluktuacji jest już prawdopodobnie bardzo wysoki i może być czas na wyciągnięcie z tego wniosków. Ale jeśli tak nie jest, prawdziwy problem może tkwić w tobie.
źródło
Jesteś profesjonalistą. Twój pracodawca zatrudnił Cię jako profesjonalistę. Tak więc traktuj swoje obawy w taki sam sposób, w jaki zatrudniani przez Ciebie profesjonaliści traktują ich profesjonalne opinie . W szczególności oczekujesz, że inni specjaliści dokonają po drodze niezbędnych optymalizacji i poprawek, pod warunkiem, że te optymalizacje nie zwiększą nieoczekiwanie kosztów.
Załóżmy na przykład, że zabierasz samochód do mechanika, aby wymienić lampę. Mechanik zauważa cztery rzeczy:
Każdy z tych scenariuszy, i jestem pewien, że inne, mają podobieństwa w tworzeniu oprogramowania - szczególnie jeśli uważasz się za profesjonalistę na dowolnym poziomie . Jako profesjonalista, z bardzo nielicznymi wyjątkami, Twoim zadaniem jest osiągnięcie celu końcowego, jakim jest ulepszenie produktu w określony sposób, zgodnie z Twoim profesjonalnym zrozumieniem .
źródło
Robisz to w ten sam sposób, w jaki urzędnik w kancelarii walczy z nieetycznymi zachowaniami, pracownik fast foodu walczy z niehigienicznymi zachowaniami, a funkcjonariusz parkingu walczy z korupcją policji.
W podanym przykładzie z
add
funkcją, która uległa całkowitemu pełzaniu funkcji, poświęć kilka minut i szkicuj, co by to poprawiło. Wyślij to do kogokolwiek, kto będzie potrzebował zgody na jego wdrożenie, i przejdź dalej.Zakładając, że twoje przedsiębiorstwo było zarządzane przez wyjątkowo kompetentnych ludzi i posiadało prawidłową strukturę, albo twoja obawa zostanie skierowana do właściwego projektanta systemu w celu podjęcia decyzji, albo będziesz mieć swobodę w realizacji swojej sugestii. Jako młodszy programista martwię się bardziej o naukę działania twojego przedsiębiorstwa niż dług techniczny - a jeśli znasz ten pierwszy, to jak sobie poradzić z tym drugim, powinno być oczywiste.
źródło
Nigdy nie słyszałem o organizacji, która nie chciałaby, aby uczestniczyli w niej pracownicy. Mówisz, że zarabiasz tylko za wykonywanie zadań. Szczerze wątpię, czy masz na myśli właściwe zadania. Ponieważ otrzymujesz wynagrodzenie za pisanie dobrego oprogramowania.
Weź na siebie odpowiedzialność. Powiedz „nie”, aby dodać funkcje, jeśli nie możesz obsługiwać bazy. Poradzić klientowi swoją wiedzę. Wciśnij hamulce teraz, zanim będzie za późno i musisz wyrzucić cały projekt, ponieważ nie będzie już można go utrzymać.
źródło