kzen.dev
  • Pytania
  • Tagi
  • Użytkownicy
Powiadomienia
Nagrody
Rejestracja
Po zarejestrowaniu się, będziesz otrzymywać powiadomienia o odpowiedziach i komentarzach do swoich pytań.
Zaloguj się
Brak tłumaczeń pasujących do Twojego wyszukiwania Jeśli masz już konto, zaloguj się, aby sprawdzić nowe powiadomienia.
Za dodane pytania, odpowiedzi i komentarze przewidziane są nagrody.
Więcej
Źródło
Edytuj
 hackydude
hackydude
Question

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.

110 2020-04-01T10:21:15+00:00 5
Valeriu
Valeriu 55403
Edytowane pytanie 12. listopada 2020 в 2:17
Bernhard Barker
Bernhard Barker
Edytowane pytanie 1. kwietnia 2020 в 7:38
Miejscu Pracy
resume
Popular videos
Jak napisać najlepsze CV? Praktyczne porady rekrutera
Jak napisać najlepsze CV? Praktyczne porady rekrutera
1 rok temu
10 najczęstszych błędów w CV. Nie popełniaj ich!
10 najczęstszych błędów w CV. Nie popełniaj ich!
3 lata temu
Jak napisać CV w 5 min.
Jak napisać CV w 5 min.
6 lat temu
Jak napisać dobre CV? 5 informacji, które muszą znaleźć się w CV
Jak napisać dobre CV? 5 informacji, które muszą znaleźć się w CV
1 rok temu
Jak napisać dobre i skuteczne CV?
Jak napisać dobre i skuteczne CV?
3 lata temu
Jak napisać dobre CV i list motywacyjny - porady eksperta
Jak napisać dobre CV i list motywacyjny - porady eksperta
6 lat temu
cv gotowe wzory
cv gotowe wzory
6 lat temu
6 błędów, które możesz popełnić w swoim CV
6 błędów, które możesz popełnić w swoim CV
7 lat temu
Jak napisać CV? Krótki poradnik dla każdego.
Jak napisać CV? Krótki poradnik dla każdego.
5 lat temu
Jak napisać podsumowanie zawodowe w CV
Jak napisać podsumowanie zawodowe w CV
3 lata temu
Jak przygotować skuteczne CV? | Stwórz CV, które działa!
Jak przygotować skuteczne CV? | Stwórz CV, które działa!
1 rok temu
Jak napisać świetne CV?
Jak napisać świetne CV?
5 lat temu
PO WER pomoże Ci znaleźć pracę. Jak należy pisać CV?
PO WER pomoże Ci znaleźć pracę. Jak należy pisać CV?
6 lat temu
Skuteczne CV - Jakie umiejętności wpisywać do CV?
Skuteczne CV - Jakie umiejętności wpisywać do CV?
4 lata temu
Jak dobrze napisać CV?
Jak dobrze napisać CV?
6 lat temu
« Poprzedni
Następny »
To pytanie ma 1 odpowiedź w języku angielskim, aby je przeczytać zaloguj się na swoje konto.
Solution / Answer
 FooTheBar
FooTheBar
1. kwietnia 2020 в 10:36
2020-04-01T10:36:46+00:00
Więcej
Źródło
Edytuj
#42510362

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

Valeriu
Valeriu 55403
Edytowana odpowiedź 12. listopada 2020 в 2:18
 alkedr
alkedr
Edytowana odpowiedź 3. kwietnia 2020 в 10:02
xkcd: Is It Worth the Time?
xkcd.com
205
0
 image
image
2. kwietnia 2020 в 6:51
2020-04-02T06:51:55+00:00
Więcej
Źródło
Edytuj
#42510369

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

Valeriu
Valeriu 55403
Edytowana odpowiedź 12. listopada 2020 в 2:18
44
0
 motosubatsu
motosubatsu
1. kwietnia 2020 в 10:39
2020-04-01T10:39:35+00:00
Więcej
Źródło
Edytuj
#42510363

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.

 motosubatsu
motosubatsu
Edytowana odpowiedź 3. kwietnia 2020 в 11:04
38
0
Torsten Link
Torsten Link
1. kwietnia 2020 в 10:57
2020-04-01T10:57:54+00:00
Więcej
Źródło
Edytuj
#42510364

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

20
0
 gnasher729
gnasher729
2. kwietnia 2020 в 10:04
2020-04-02T10:04:37+00:00
Więcej
Źródło
Edytuj
#42510372

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.

Valeriu
Valeriu 55403
Edytowana odpowiedź 12. listopada 2020 в 2:18
3
0
Dodaj pytanie
Kategorie
Wszystkie
Technologia
Kultura / Rekreacja
Życie / Sztuka
Nauka
Profesjonalny
Biznes
Użytkownicy
Wszystkie
Nowy
Popularny
1
bran Bran
Zarejestrowany 1 dzień temu
2
Олечка Арапова
Zarejestrowany 1 dzień temu
3
Роман Азаров
Zarejestrowany 1 tydzień temu
4
Mansur Zakirov
Zarejestrowany 2 tygodnie temu
5
Тагир Мамедов
Zarejestrowany 2 tygodnie temu
DE
ES
FR
ID
IT
KO
NL
PL
PT
TR
ZH
© kzen.dev 2023
Źródło
workplace.stackexchange.com
na podstawie licencji cc by-sa 3.0 z przypisaniem