Co powinienem napisać w swoim CV, jeśli dostałem awans za obniżenie jakości kodu, aby dotrzymać terminów?
Byłem na 12-miesięcznym kontrakcie (mieszkam w kraju, gdzie nie jest to normalne dla nowych programistów) aż do kilku tygodni temu, kiedy kierownictwo mojej firmy dało mi ofertę i podwyżkę, abym stał się dla nich stałym pracownikiem. Lubię, aby moje CV było zawsze aktualne (szczególnie biorąc pod uwagę COVID), więc wygooglowałem temat umieszczenia go w moim CV.
Porady, które znalazłem były takie, że generalnie powinienem wymienić, jakie osiągnięcie spowodowało zatrudnienie. Wystarczająco dobrze.
Problem w tym, że tym osiągnięciem było zawsze dotrzymywanie napiętych terminów klientów i szczerze mówiąc, zrobiłem to decydując, że inżynieria może być mniej niż gwiezdna w określonych przypadkach (na co zgodziło się kierownictwo).
Ja'jestem stosunkowo młodszym devem w zespole 6 programistów. Jednak szybko stałem się jednym z tych, którym kierownictwo ufa najbardziej, jeśli chodzi o dostarczanie rzeczy, kiedy mówię, że je dostarczę i informowanie ich o względnych kompromisach w dotarciu do celu. W moim krótkim czasie pracy tutaj, zawsze byłem w stanie dostarczyć coś, kiedy powiedziałem, że mogę to zrobić.
Miałem kilka takich przypadków, ale to jest ten, który zrobiłem tuż przed tym, jak zaproponowano mi stałą pracę. Jednym z naszych produktów jest API wsadowe, które jest wywoływane raz dziennie przez jednego klienta. Nie musi on zwracać niczego poza CSV nieudanych wpisów przez e-mail. Chcieli, aby dodać nową funkcję i sprzedawca miał umownie zgodził się mieć go dla nich do końca miesiąca. Z różnych powodów, że wniosek funkcja nie'zrobić to w dół do nas aż do poniedziałku w ostatnim tygodniu miesiąca.
Starszy programista powiedział menedżerowi, że rozwój nie może'być wykonany prawidłowo i powiedzieć klientowi, że nie może być zrobione. Nie zaprzeczam starszym devom na spotkaniach planowania sprintu, ale może to było oczywiste, że nie zgadzałem się ze starszym facetem. Na przykład, nie nie zgadzałem się, ale istniała opcja z pewnymi kompromisami. Inni devowie są również dość pasywni, więc nikt inny nie sprzeciwił się mu. Manager nie był z tego powodu zadowolony, ponieważ klient jest już na nas zły za to, że nie wywiązujemy się z umowy, kiedy obiecujemy, że to zrobimy. Po spotkaniu manager wezwał mnie do swojego biura, aby zapytać, czy widzę jakąś alternatywę. Powiedziałem mu, że mogę sprawić, że coś zadziała, ale prawdopodobnie podwoi to czas przetwarzania API (co doda 4 minuty), ponieważ nie mam specjalistycznych umiejętności SQL. Kierownik zgodził się i najwyraźniej klient nawet nie zauważył.
Nie jestem pewien, jakie byłyby konsekwencje niedotrzymania terminu, ale były one na tyle poważne, że prezes naszej 1000 osobowej firmy wysłał do mnie maila z podziękowaniami za dostarczenie go.
Inny przypadek nie przyciągnął tak dużej uwagi, ale był to proces, który musieliśmy uruchomić na bazie danych. Właściwym sposobem na zrobienie tego byłoby napisanie odpowiedniego procesu wsadowego w mega systemie Java, którego używamy, wysłanie go przez wszystkie regularne procesy QA i pozwolenie mu wyskoczyć na końcu dwa tygodnie później. Zaproponowałem menedżerowi skrypt w Pythonie, który musiałby być uruchamiany ręcznie i byłby horrendalnie nieefektywny (musiałby działać w nocy), ale jeśli byłby uruchamiany raz w miesiącu, utrzymałby problem w ryzach do czasu pojawienia się stałej poprawki. Był to problem produkcyjny, więc zgodził się na to jako środek tymczasowy. Była to w zasadzie tylko tania pętla for, która sprawdzała wiersze pod kątem pewnego rodzaju błędnych danych i przeformatowywała je.
Czy istnieje sposób, aby wymienić tego typu rzeczy w moim CV, które nie sprawi, że będę wyglądał jak programista, który podkopuje starszych devów? Przyznaję, że moje rozwiązania nie są technicznie solidne, ale były one solidne dla potrzeb biznesowych w tym czasie, a kompromis nieefektywności był w dużej mierze nieistotny w większości przypadków.
Znalazłeś kilka skutecznych (nie efektywnych) sposobów na rozwiązanie problemów bez ich nadmiernego inżynierowania i "Gotowe jest lepsze niż doskonałe"
Znalezienie rozwiązania, które jest po prostu wystarczająco dobre, jest ważną umiejętnością dla inżyniera, ponieważ w przeciwnym razie spędziłbyś dużo czasu na optymalizacji czegoś, co nie jest warte optymalizacji. Jeśli coś nie jest często używane, to często nie warto tego optymalizować. Jest taki fajny XKCD-Comic z tabelą, która mówi, ile czasu powinieneś w coś zainwestować.
Rozwiązanie jest coś warte tylko wtedy, gdy jest (lub może być) używane, więc z hackiem umożliwiłeś klientowi kontynuowanie pracy aż do uzyskania rozwiązania.
Nie ma powodu, aby powiedzieć komukolwiek, że nie zgodziłeś się z przełożonym. Po prostu idź na coś w stylu "Umiejętność tworzenia skutecznych rozwiązań pod presją czasu".
Przyznaję, że moje rozwiązania nie są technicznie dobre, ale były one rozsądne dla potrzeb biznesowych w tym czasie, a handel nieefektywnością off był w dużej mierze nieistotne w większości przypadków.
Miałeś jedno zadanie: "znaleźć rozwiązanie, które działa w ramach limitów czasowych, które rozwiązuje zadanie". I to jest dokładnie to, co zrobiłeś.
Mam wrażenie, że tylko kierownictwo udzielało tu odpowiedzi, ponieważ nie było nic poza pochwałami za trzymanie się nierozsądnych terminów.
Jest tu jeszcze jeden punkt widzenia. Nie należy lekceważyć zakłóceń społecznych, które zapala się w zespole devów, gdy kierownictwo pokonuje zakręty i ignoruje opinie starszych deweloperów. Jest takie powiedzenie, które mówi mniej więcej tak samo:
Dopóki jest ktoś, kto ciągle gasi pożar, kierownictwo nie przestanie bawić się zapałkami.
To jedna rzecz, jeśli raz/ dwa razy pójdziesz w dół hacky road, bo jesteś do tego zmuszony, ale zupełnie inna, jeśli jest to coraz bardziej normalne. I z twojego opisu wydaje mi się, że kierownictwo stało się całkiem wygodne z praktyką wykorzystywania cię do pokonywania zakrętów. Powinieneś poważnie zastanowić się nad podniesieniem tej kwestii do swojego kierownictwa i starszych pracowników, aby utrzymać zdrowe środowisko pracy. Firma to równowaga pomiędzy dev a kierownictwem, a nie tylko struktura odgórna. Istnieje powód, dla którego słowo "nie" istnieje i należy praktykować jego stosowanie.
Jest to jednak nadal bardziej kwestia zarządzania niż twoja. Dlatego nie ma powodu, aby w jakiś sposób wspominać o tym w swoim życiorysie. Więc ja bym się zgodził:
zdolny do dotrzymania terminów
Jak mówi powiedzenie "Doskonałe jest wrogiem dobrego" - dokonywanie technicznych kompromisów w celu zaspokojenia potrzeb biznesowych jest niemalże de rigueur. Dobrzy devs/programiści/inżynierowie to ci, którzy potrafią zidentyfikować akceptowalne kompromisy, które można osiągnąć.
W twoim przykładzie API klient był wyraźnie bardziej skłonny do zaakceptowania 4 minutowego opóźnienia w przetwarzaniu dla czegoś, co działało i zostało dostarczone na czas.
Idealnie byłoby, gdybyś szukał minimalizacji długu technicznego podczas zawierania tych kompromisów - ale to wszystko jest częścią i częścią doświadczenia i wiedzy, gdzie można zaoszczędzić czas, a kiedy trzeba się upewnić, że coś jest zrobione "dobrze", aby zaoszczędzić więcej czasu w dłuższej perspektywie.
Moje podstawowe pytanie brzmi, czy istnieje sposób, aby wymienić te rodzaje rzeczy na moim CV, które nie'sprawia, że wyglądam jak programista hack, który podważa starszych devs?
Jeśli chodzi o CV, nie ma potrzeby, aby dostać się do specyfiki swojego rozwiązania - można po prostu powiedzieć, że masz dobrą historię dostarczania do terminów w projektach wrażliwych na czas i wspomnieć przykłady bez szczegółów rzeczywistej realizacji.
To co robisz to NIE jest "hacking", to jest "szukanie rozwiązań".
Pracuję jako programista i konsultant od 20 lat, i tej umiejętności szukają pracodawcy: Nie pomijaj tego w swoim CV, ale dokładnie to podkreślaj: Próbujesz znaleźć rozwiązania, nawet jeśli oznacza to pójście "nietypowymi" ścieżkami.
Nie pisz, że robisz to za plecami starszych programistów, ale że robisz to zawsze, gdy jesteś proszony o rozwiązania, nawet jeśli bardziej doświadczeni faceci nie zgadzają się / mówią, że to niemożliwe.
Jest taki świetny cytat, który podobno pochodzi od Alberta Einsteina, który dokładnie opisuje Twoją sytuację:
Każdy wiedział, że to niemożliwe, dopóki nie pojawił się głupiec, który nie wiedział i nie zrobił tego.
Pracowałem razem z wieloma programistami i znam każdy aspekt tego zagadnienia:
Pracowałem z programistą, który jest wśród 1% najlepszych ekspertów JavaScript na stackoverflow. Jest on geniuszem i naprawdę podziwiam każdą linijkę kodu, którą pisze. Ale dość często nie kończył swoich projektów: On'wolałby nie skończyć czegoś, niż skończyć to, gdy nie był zadowolony z piękna kodu.
A ja pracowałem z programistami, którzy byli niezwykle wydajni, ale przez to szli na skróty, co czyniło ich rozwiązania niemalże niemożliwymi do utrzymania (hardcoded paths, magic numbers, etc.).
I zawsze wolałem "zrobione" od "pięknego" i w końcu moi klienci też tak robili: Oni'wolą mieć "coś", kiedy jest deadline, niż "nic, ale będzie piękne za jakiś czas X"
Tylko jedna rzecz: Obejścia / skróty / "hacki" muszą być zrozumiałe, udokumentowane i możliwe do utrzymania, wtedy nie ma nic przeciwko rozwiązaniom takim jak Twoje
Stworzyłeś więc jakieś oprogramowanie, którego uruchomienie zajęło cztery minuty (ponieważ Twój kod nie był zbyt dobry). Jeśli ręczne wykonanie pracy zajmuje mi 12 godzin, Twoje oprogramowanie oszczędza mi 11 godzin i 56 minut. Jeśli napisałeś lepszy kod, który działa w 1 sekundę, to oszczędza mi to 11 godzin, 59 minut, 59 sekund. Jeśli lepszy kod został dostarczony tydzień później, więc musiałem wykonać pracę ręcznie pięć razy, dodatkowe 3 minuty i 59 sekund nigdy nie zrekompensują mi straconego czasu.
Albo uczynić go bardziej ekstremalnym. Oprogramowanie musi działać w ciągu 24 godzin. Twój kod jest zły, więc potrzebujemy komputera za 5000 dolarów, żeby uruchomić go w 24 godziny. Przy lepszym kodzie, komputer za 2 000 dolarów może uruchomić go w 24 godziny. Oszczędność 3000 dolarów. Jeśli przyspieszenie kodu zajmie ci dwa tygodnie, to jest to całkowita strata.
Zdolność do dostarczenia kodu, gdy jest potrzebny, to bardzo, bardzo dobra rzecz. Ponadto, bardzo dobry programista może napisać zły kod w taki sposób, aby można go było później łatwo poprawić. Zły programista pisze zły kod, który jest bólem, aby naprawić go w dobrej formie, dobry programista pod presją czasu pisze zły kod, który jest łatwy do poprawienia.
