Czy „tak długo, jak to działa” jest normą? [Zamknięte]

Zobacz moje ostatnie pytanie: Czy programowanie to zawód w wyścigu do dna?

Mój ostatni sklep nie miał procesu. Zwinność w istocie oznaczała, że ​​w ogóle nie mieli planu, jak rozwijać lub zarządzać swoimi projektami. Oznaczało to „hej, jest mnóstwo pracy. Idź, zrób to za dwa tygodnie. Jesteśmy szybcy i zwinni”.

Wydali rzeczy, o których wiedzieli, że mają problemy. Nie obchodziło ich, jak się to pisze. Nie było recenzji kodu - mimo że było kilku programistów. Wydali oprogramowanie, o którym wiedzieli, że jest wadliwe.

W mojej poprzedniej pracy ludzie mieli nastawienie, dopóki działa, jest w porządku. Kiedy poprosiłem o przepisanie kodu, który napisałem, kiedy zasadniczo badaliśmy specyfikację, odmówili. Chciałem przepisać kod, ponieważ kod był powtarzany w wielu miejscach, nie było enkapsulacji i wiele czasu zajęło ludziom wprowadzanie zmian.

Tak więc zasadniczo mam wrażenie, że programowanie sprowadza się do następujących kwestii:

1. Czytanie książki o najnowszym narzędziu / technologii
2. Łączenie kodu na podstawie tego, unikając pisania dowolnego kodu, ponieważ firma nie chce „utrzymywać niestandardowego kodu”
3. Pokazując to i przechodząc do następnej rzeczy, „tak długo, jak to działa”.

Zawsze powtarzałem sobie, że w następnej pracy znajdę lepszy sklep. To się nigdy nie zdarza. Jeśli tak, to utknęłam. Technologie zawsze się zmieniają; jeśli jedynym zawodowym rozwojem jest czytanie najnowszej książki o technologii MS Press, to co zbudowałeś w ciągu 10 lat, ale powierzchowna znajomość różnych technologii? Martwię się o:

1. Najlepszy sposób na profesjonalne standardy
2. Jak zdobyć znaczącą wiedzę i doświadczenie w tej sytuacji

Pośrednio natknąłeś się na to, co uważam za kluczowy aspekt bycia dobrym programistą : znalezienie równowagi między „ tak długo, jak to działa ” i dobrze zaprojektowanym, eleganckim kodem.

Podobnie jak w polityce, o wiele łatwiej jest postawić swoją pozycję na jednym końcu spektrum, niż zająć bardziej zróżnicowaną pozycję na środku. Większość programistów, których spotkałem, należy do jednej z dwóch kategorii: kodowania kowbojskich hacków i architektów astronautów. Staram się znaleźć równowagę między nimi. To nie jest tak proste, jak się wydaje.

Aby bardziej bezpośrednio odpowiedzieć na twoje pytanie, tak, myślę, że „tak długo jak to działa” jest często normą. Ale spójrz na to z innej strony: jesteś w doskonałej pozycji, aby edukować swoich współpracowników i próbować wprowadzić lepsze praktyki. Ale nie sięgaj do końca i pamiętaj, dlaczego wszyscy to robimy: aby rozwiązać problemy naszych klientów.

>> W mojej poprzedniej pracy ludzie mieli nastawienie, dopóki działa, jest w porządku.

Być może jestem tutaj mniejszością, ale mam takie samo nastawienie i głęboko wierzę, że aby przepisać coś, powinny istnieć wyraźne dowody, dlaczego potrzebujemy tego. I nie mam na myśli czegoś takiego: „uf, nie podoba mi się, jak został zakodowany” - każdy programista ma swoje preferencje dotyczące kodu. Powinny wystąpić problemy z częścią, którą chcemy przepisać:

• Problemy z wydajnością
• Znaleziono więcej błędów niż w innych częściach systemu
• Programiści spędzają więcej czasu, pracując nad tą częścią
• itp.

Agile nie ponosi odpowiedzialności za decyzje o wydaniu błędnego oprogramowania przez ludzi; ludzie są.

To powiedziawszy, przywiązujesz dużą wagę do jakości i jest ona dobra. Jestem pewien, że jesteś perfekcjonistą i martwisz się o swoją wartość, jeśli nie dogonisz najnowszych technologii.

Problem polega na tym, że perfekcjonizm prowadzi do kunktatorstwa, a kunktatorstwo prowadzi do mierności .

Właśnie dlatego firmy będą traktować priorytetowo rzeczy takie jak czas na sprzedaż i stosować sprawne, aby szybko i w przewidywalnym tempie dostarczać wartość.

Ponieważ nie opisałeś strategii biznesowej swojej firmy, myślę, że powinieneś zacząć od zadawania pytań menedżerom.

Dzięki dostosowaniu się do ich celów i planów ( zatrudnili cię, aby pomóc im w ich osiągnięciu), będziesz w stanie lepiej zrozumieć, w jaki sposób możesz do nich przyczynić, zamiast skupiać się na własnych i osobistych celach.

Jestem pewien, że starając się docenić understandich wartość, będziesz mógł podzielić się swoją, a to będzie początek owocnej współpracy.

A jeśli odkryjesz, że nie wiedzą, co robią, jedyną opcją będzie wyjście .

Wszystko zależy od tego, co budujesz. Jeśli budujesz mikrostronę, która będzie dostępna online tylko przez miesiąc, i masz dziewięć dni na jej zbudowanie: to tak, dopóki działa.

Jeśli piszesz algorytmy fly-by-wire dla systemu FA-18, lepiej zbuduj go tak doskonale, jak to możliwe.

Tak jak w przypadku większości odpowiedzi technologicznych ... to zależy.

To zależy od firmy. Jednak wiele firm ma poważną konkurencję i presję czasu. To jeden typowy powód. Kolejnym byłoby duże obciążenie pracą, potencjalnie bez wystarczającej liczby pracowników. (Istnieją bardzo dobre powody braku personelu, które niekoniecznie są winą firmy.) To powiedziawszy, niektóre organizacje nie były w stanie wyjść z mokrej papierowej torby.

Myślę, że tutaj obowiązuje zasada 80/20. Zasadniczo musisz pogodzić się z tym gównianym 80% i dostać się do 20%. Pamiętaj jednak, że nawet oni będą musieli dokonać kompromisu. W biznesie zazwyczaj nie ma znaczenia, że ​​masz absolutną rację. Ważne, że masz to teraz.

jeśli jedynym zawodowym rozwojem jest czytanie najnowszej książki o technologii MS Press, to co zbudowałeś w ciągu 10 lat, ale powierzchowna znajomość różnych technologii?

Byłoby to raczej szczęście, ale w ciągu tej dekady mogły wystąpić spektakularne niepowodzenia. Widziałem wiele miejsc, w których pamiętam raczej konkretne rzeczy, które podobały mi się w pracy lub które nie sprawiały mi przyjemności, i dlatego kwestionowałbym to ponownie w moim nowym miejscu pracy. Czasami może pojawić się nowa praktyka, na przykład, gdy firma próbuje wdrożyć Scrum lub zastosować podejście oparte na testowaniu, mogą to być szanse, ale niekoniecznie postrzegane jako rozwój zawodowy, ponieważ nie jest to formalne ustawienie w klasie.

Znam różne miejsca, w których „tak długo, jak to działa” jest powszechne wraz z różnymi strategiami kodowania kowbojów. W kilku start-upach widziałem tego rodzaju mentalność, która może mieć sens, jeśli firma jest tak młoda, że ​​wciąż próbują wyjaśnić, co naprawdę chcą zrobić. W innych firmach, w których pracowałem, obawiam się, że dojrzałość, która może być całkiem dobra, ale niekoniecznie łatwa do znalezienia. Niektóre miejsca miały pewne procesy, które musiałem zobaczyć i przejść: „Podoba mi się. Będę pamiętać o tym w późniejszych sytuacjach w pracy”, a inne gdzie pójdę, „Naprawdę tego nie lubię. aby tego uniknąć w przyszłości ”.

Przez jakiś czas pracowałem w takim sklepie, w miejscu, w którym ich doganiało. Były aplikacje dwu- lub trzyletnie ze znanymi błędami, których dosłownie nie potrafiły rozwiązać. Pomyśl o pętli o długości 4000 linii z bieżącym obliczeniem szerokości i wysokości układu. Naprawienie fragmentu kodu w celu naprawy problemu w jednym przypadku spowodowałoby dwadzieścia problemów w innym miejscu, ponieważ wcześniejsi programiści mieli podobne problemy z pomocą zespołu poprzez arbitralne dostosowanie wyników obliczeń za pomocą magicznych liczb. Kod nie może być opisany jako inny niż toksyczny.

W końcu dostałem nowy projekt, który mój szef powiedział mi, że może wykorzystać ten istniejący kod do obsługi układów. Jakimś sposobem przekonałem go, by pozwolił mi to „zmienić”, więc dał mi trochę czasu. Wykorzystałem ten czas, aby zamiast tego napisać dobrze zaprojektowaną bibliotekę, aby pomóc w układzie. Błędy w tym nowym projekcie dosłownie zajęły mi 10 sekund. Mogłem zidentyfikować problemy, zanim nawet spojrzałem na kod, aby zobaczyć, co poszło nie tak.

Myślałem, że to przełoży się na punkt zwrotny dla mojego menedżera, ale wszystko, co dostałem, to poklepanie po plecach, a on zasadniczo powiedział mi, że „Twoja droga też działa, tak sądzę”.

Od tego czasu zacząłem pracować dla innego sklepu i tutaj jest lepiej. Chodzi o to, że nie możesz zmienić ich zdania. Po prostu idź do pracy gdzie indziej.

Nadal mam nadzieję, że w gospodarce istnieje pewien rodzaj procesu ewolucyjnego, który prędzej czy później wykopie takie firmy z biznesu. Być może jednak wysokie tempo postępu technologicznego powoduje powstanie zbyt wielu nowych nisz, więc nawet słabi konkurenci wciąż mogą znaleźć wystarczającą ilość „jedzenia”.

Jeśli chcesz zwiększyć swoje szanse na pracę w dobrym miejscu, poszukaj firmy, która ma produkt, który sprzedaje wielu klientom, zamiast pisać coś nowego co kilka tygodni. Powinno być większe zainteresowanie posiadaniem dobrej bazy kodu i możliwością dodawania nowych funkcji bez przerywania istniejącego kodu przez cały czas.

Przypomina mi mojego kolegę z college'u. Brał udział w zajęciach z projektowania VLSI i do swojej pierwszej pracy domowej wymyślił komponent rzędu mikrometrów szerokości i mili. Symulacje przebiegły idealnie.

Jego odpowiedź na krytykę brzmiała: „Wiem tylko, że moje gówno działa”.

Dość dobrą normą jest zasada Pareto

Mam doświadczenie w projekcie z zasadą 80-20 i zadziałało bardzo dobrze. Myślę, że pomocne mogą być również odpowiedzi na to pytanie „Gdzie wyznaczasz granice swojego perfekcjonizmu” .

Termin „zasada Pareto” może również odnosić się do wydajności Pareto. Zasada Pareto (znana również jako zasada 80-20, prawo nielicznych istot oraz zasada rzadkości czynników) stwierdza, że ​​w przypadku wielu zdarzeń około 80% skutków pochodzi z 20% przyczyn. Myśliciel ds. Zarządzania biznesem Joseph M. Juran zasugerował tę zasadę i nazwał ją włoskim ekonomistą Vilfredo Pareto, który zauważył w 1906 r., Że 80% ziemi we Włoszech należy do 20% populacji; rozwinął tę zasadę, obserwując, że 20% strąków grochu w jego ogrodzie zawiera 80% grochu. W biznesie jest to powszechna zasada; np. „80% sprzedaży pochodzi od 20% klientów”. Matematycznie, gdy coś jest dzielone między wystarczająco duży zestaw uczestników, liczba k musi wynosić od 50 do 100, tak aby „k% było zajęte przez (100 - k)% uczestników”. Liczba k może wynosić od 50 (w przypadku równego podziału, tj. 100% populacji ma równy udział) do prawie 100 (gdy niewielka liczba uczestników stanowi prawie wszystkie zasoby).Matematycznie nie ma nic szczególnego w 80%, ale wiele prawdziwych układów ma gdzieś wokół tego regionu pośredniej nierównowagi w rozkładzie. Zasada Pareto jest tylko stycznie związana z wydajnością Pareto, która została również wprowadzona przez tego samego ekonomistę. Pareto opracował obie koncepcje w kontekście podziału dochodu i bogactwa wśród ludności.

Link do źródła

Kiedy poprosiłem o przepisanie kodu, który napisałem, kiedy zasadniczo badaliśmy specyfikację, odmówili. Chciałem przepisać kod, ponieważ kod był powtarzany w wielu miejscach, nie było enkapsulacji i wiele czasu zajęło ludziom wprowadzanie zmian.

Bez obrazy, ale jako kierownik przeczytałem to zdanie gdzieś w stylu:

„Kiedy poprosiłem o dwukrotną zapłatę za przepisanie kodu, który już napisałem, moja firma nie chciała płacić. Chciałam, aby dodatkowe pieniądze posprzątały bałagan, który popełniłem, gdy napisałem go po raz pierwszy, i mój koledzy byli na mnie wściekli za utrudnianie im życia.

Jeśli narzekasz na swój własny kod - nie masz za co stać.

AKTUALIZACJA

Rozumiem, że ten POV jest niepopularny. Ale nie wydaje mi się, żeby było to w ogóle niezgodne z obowiązkami i postawami profesjonalnego dewelopera.

Jeśli na początku piszesz czysty kod (i istnieje wiele powodów, aby to zrobić - niezależnie od tego, czy uważasz, że Twój kod będzie wykorzystywany w celach produkcyjnych, czy nie), problem ten będzie występować o wiele rzadziej.

Jeśli uwzględnisz czysty kod i czas refaktoryzacji w swoich szacunkach, będziesz również mieć harmonogram, aby utrzymać porządek w bazie kodu. Jeśli z powodu presji harmonogramu nie masz potrzebnego czasu - twoje przyszłe szacunki powinny wzrosnąć w wyniku radzenia sobie z zaciągniętym długiem technicznym.

W pewnym momencie twoje przyszłe szacunki (lub niepewności związane z twoimi szacunkami) dadzą ci siłę do argumentowania o przepisanie (kiedy twój menedżer prosi cię o przyspieszenie procesu). Jeśli nie, zaakceptuj szacunek firmy i wolisz zapłacić koszty bieżące niż za wymianę. To wyłącznie decyzja biznesowa - nie techniczna.

Pamiętaj, że czas na negocjowanie harmonogramów upływa zanim napiszesz kod - a nie później. Po napisaniu kodu (i „zadziałaniu”) klienci, menedżerowie i kierownictwo nie chcą widzieć kolejnego rachunku za „konserwację”, który zbliża się lub przekracza pierwotny koszt. Jeśli czujesz się tak mocno, jak myślisz, że firma powinna, możesz napisać go w swoim własnym czasie - właśnie o to prosisz.

Z punktu widzenia menedżera, przepisanie harmonogramu przepisywania stawia jego tyłek na linii. Kiedy nie dostarczysz lub nie zwiększysz produktywności o tyle, ile mówisz - to on trzyma torbę. W porównaniu do stosunkowo niewielkiej niedogodności związanej ze słuchaniem, narzekaj, zgadnij, który z nich będzie preferował.

Jeśli jest to rodzaj pracy, którą możesz uzyskać, po prostu skup się na pisaniu lepszego kodu za każdym razem, zamiast wracać i przepisywać stary kod. Nadal istnieje zakres jakości, w którym możesz się przenieść w dziedzinie klejenia razem pakietów stron trzecich.

Jeśli masz czas i chcesz poprawić kod istniejącego komponentu, który zarządzasz, czy nie możesz tego zrobić bez pytania o pozwolenie, o ile działa to, co robisz? Uwzględnij czas w swoich szacunkach dla następnego projektu, który używa komponentu.

W przypadku programowania niższego poziomu, jeśli nie możesz czerpać satysfakcji z pracy, to może czas przyjrzeć się projektowi typu open source?

q303, uznałem twoje pytanie za interesujące i uznałem, że warto przeczytać to pytanie programistów, aby dowiedzieć się, jak przekonać menedżerów, aby pozwolili programistom rozwiązać problemy techniczne.

Myślę, że generalnie tak, to norma. Zrozum, że działające, ale mniej niż optymalne oprogramowanie jest znacznie lepsze niż niedziałające oprogramowanie. Istnieje również argument, że definicja „pracy” może się różnić w zależności od postrzegania i uprzedzeń poszczególnych osób. Kiedy wdrażasz nowy system, zawsze znajdzie się ktoś, kto powie, że uważał, że stary system jest lepszy. A kiedy rozmawiasz z programistą, prawdopodobnie niechętnie przyzna się, że pracował nad kiepskim oprogramowaniem.