Jako pracownik firmy, kiedy piszesz kod, czujesz, że masz do niego przywiązanie? Czy uważasz, że masz jakąś własność kodu? Czy też piszesz to całkowicie oderwane od niego bez obawy o to, co się z nim stanie po przejściu na coś innego?
EDYCJA: Nie mówię o pisaniu złego kodu, a następnie uruchamianiu ...
Odpowiedzi:
Po 30 latach pracy jako wykonawca jest mieszany.
Wszystko jest jednorazowe. Pracowałem z setkami klientów. Nigdy więcej nie zobaczę kodu. Po co się przywiązać? Nie ma poczucia własności.
To jest bardzo widoczne. Jest droższy niż wewnętrzny kod, więc zyskuje dużo kontroli. Ponieważ nie będzie mnie w pobliżu, aby go utrzymać, uzyskuje się bardzo dużą kontrolę. Przejścia i przekazywanie kodu są bardzo ważne. W rzemiośle jest trochę dumy. Ale brak poczucia własności.
Mój rekord to 17 lat produkcji. 12 z tych lat przy zerowym utrzymaniu jakiegokolwiek rodzaju.
Wiem, bo dostałem telefon. Dokonali przeglądu swoich systemów księgowych i chcieli wiedzieć, jak zastąpić sprytny algorytm alokacji kosztów, który zbudowałem wiele lat temu. Spojrzałem na kod, a pliki pozostały niezmienione od ostatniego rozszerzenia 12 lat temu. (Nie jest to poprawka, AFAIK.)
Kolejny najdłuższy okres - o którym wiem - to 7 lat bezbłędnego działania. To jednak wiązało się z poważnym problemem Y2K i wymagało pewnych przeróbek, aby używać nazw plików, które miały 4-cyfrowe lata. Wszystkie wewnętrzne algorytmy były poprawne, ale pliki dziennika byłyby wyświetlane w niewłaściwej kolejności.
Znów wiem, że był bezbłędny, ponieważ pliki nie zostały zmienione od czasu ostatniego wydania, które wydałem.
Tak, tak, w rzemiośle jest dużo dumy.
Ale nie ma „własności”. To ich kod, nie mój. Ja tylko to buduję.
Jako mniej lub bardziej solo programista, obawa przed zachowaniem tego, co piszę, jest głównym kierowcą za mną, który próbuje nie pisać okropnego kodu.
W pracy część kodu jest moja, podobnie jak krzesło, na którym siedzę. Napisałem to, zrobiłem to tak dobrze, jak mogłem, czuję się zaborczy, ludzie będą mnie pytać o zmiany, a ludzie będą nazywać to moim. I, podobnie jak moje krzesło, kiedy odejdę z firmy, nigdy więcej go nie zobaczę i nie będę już więcej przywiązany emocjonalnie.
Słowo „moje” ma wiele różnych znaczeń. „Moja żona” i „moja szczoteczka do zębów” nie są ściśle równoległe.
Jeśli napiszesz kod dla siebie, możesz sobie pozwolić na jego uczucia. Jeśli piszesz kod dla firmy, musisz okrutnie oczyścić te uczucia, gdy tylko jest to możliwe. Nie mogę policzyć, ile razy dobrzy programiści wywołują smutek, wywołując emocje związane z kodem.
Powiedz sobie: „Zrobiłem to, jest dobre, ale nie jest moje i mogę zrobić więcej”. Jeśli w to uwierzysz , to kiedy 6 miesięcy twojego życia stanie się przestarzałe, ponieważ przedstawiciel handlowy gorszego produktu dał szefowi BJ podczas lunchu, nie tracisz pracy za szaleństwo na nim.
Pamiętaj, że ci płacą. Wszyscy chcielibyśmy robić fajne rzeczy, ale jeśli płacą nam za kopanie dziur, a następnie wypełnij je ponownie, to ich przywilej. Właśnie miałem sytuację, w której napisałem aplikację internetową, potem spędziłem miesiące na wprowadzaniu okropnych funkcji, a potem kolejne miesiące na kodowanie jej z powrotem do stanu pierwotnego. Ostatnie dwa tygodnie „pracy” wyciągnąłem z mojego repozytorium SVN, a następnie poleciłem go z nowymi numerami wersji. I nic mi nie jest.
Nie, ale naprawdę nie lubię naprawiać błędów wprowadzonych przez innych w kodzie, który napisałem pierwotnie. Byłbym szczęśliwszy, gdyby zmiana została mi przypisana. Nienawidzę tego jeszcze bardziej, gdy poprawka jest całkowicie poza oryginalnym projektem, np. Poprzez utworzenie okrągłej zależności z modułem wyższego poziomu.
Tak i nie.
Tak - jest to coś, co stworzyłeś i dlatego masz przywiązanie, tak jak projektant samochodów jest dumny lub zawstydzony, gdy widzi samochody, które zaprojektował na drodze.
Nie - jeśli chodzi o własność, zwykle rezygnujesz z niej w zamian za wynagrodzenie za pracę w firmie. Pracownicy fabryki, którzy budują samochody, nie otrzymują prawa własności do każdego, który zjeżdża z linii, ponieważ otrzymują wynagrodzenie za swój czas.
Czuję się bardzo zastrzeżony w związku z kodem, który piszę; przedstawia decyzje, które podjąłem, jak rozwiązać dany problem, a zatem odzwierciedla moją zdolność racjonalnego przemyślenia problemu i opracowania logicznego i miejmy nadzieję eleganckiego rozwiązania. To powiedziawszy, wszystko, co piszę w czasie pracy firmy, należy do firmy. Mam nadzieję, że żaden z nich nie powróci, by mnie ugryźć, wolałbym prosić o naprawienie własnego kodu, ale jeśli nie, to nie. (I mógłbym dodać, że facet, który pisał kod trzy miesiące temu i umieszczał na nim moje imię w kontroli źródła, jest idiotą).
Ani trochę. Kiedy go zamelduję, nie jest już „mój”. Oczywiście zajmę się konserwacją i rozwiązywaniem problemów, ale nie czuję do tego poczucia odpowiedzialności.
Znam ludzi, którzy czują się bardzo przywiązani do swojego kodu, do tego stopnia, że denerwują się, gdy ktoś inny naprawi błąd lub jakoś go zmodyfikuje bez uprzedniego uruchomienia go. Nigdy tak się nie czułem. Proszę tylko, że jeśli znajdziesz problem w moim kodzie i go naprawisz, powiedz mi, na czym polegał problem i jak został rozwiązany, aby nie popełnić tego samego błędu w przyszłości.
Uwielbiam kody, które piszę. Rozumiem je i dostosowuję, aby inni też. Kiedy ludzie podchodzą do mnie i mówią: „Stary, wciąż używamy skryptu, który dla nas napisałeś. Jest taki stabilny i przenośny”, uwielbiam to poczucie dumy i własności.
Przywiązanie do kodu nie zaszkodzi, jeśli zobaczysz, dokąd to się skończy, tj. Jeśli wszystko to działa wewnętrznie i wiesz, dla kogo lub dla czego programujesz, powiedziałbym, że dobrze jest dostać przywiązany . Bo pokochasz tylko tworzenie większej ilości błyskotliwości, o wiele więcej.
Z drugiej strony (w pełni świadomy, że mogę powtarzać to, co powiedział @ S. Lott), jeśli kod ma stać się własnością klienta, nie ma sensu się nad nim sentymentować. To jak ... dbanie o szczeniaka twojego przyjaciela, kiedy wyjeżdża na wakacje. : - /
Kontrahenci i konsultanci, którzy mogą nigdy więcej nie zobaczyć swojego kodu, prawdopodobnie nie są idealnym kandydatem do emocjonalnego przywiązania do swojego kodu. Konieczność ciągłego „porzucania” go prawdopodobnie po pewnym czasie unicestwi kreatywny popęd konsultantów.
Jeśli spojrzymy na to z perspektywy pracownika, a nie kontrahenta, powiedziałbym, że chciałbym, aby wszyscy członkowie mojego zespołu czuli się właścicielami kodu, który piszą i wszystkiego, co tworzą. Ta własność i duma powinny objąć cały zespół. Poczucie dumy i własności stwarza przywiązanie do produktu w pytaniach oraz nadaje sens i sens pracy członka zespołu. Widziałem, jak to znacznie poprawia wydajność w małych i dużych zespołach.
Czego należy unikać, a czego nie lubię, ludzie, którzy wydają się emocjonalnie przywiązani do określonych linii kodu, które napisali, i bronią go do grobu. Nie chcą wprowadzania zmian, spoglądają w dół i odrzucają wszelkie pomysły na zmiany lub ulepszenia i starają się to uzasadnić czymś, co wydaje się wiarygodne. Z mojego własnego doświadczenia często sprowadza się to do strachu przed zmianą i strachu przed nieznanym. Problem polega na tym, że tak naprawdę nie rezygnują ze starych wierszy kodu. Zamiast tego musi wziąć na siebie coś nowego, czasem nie napisanego przez ciebie, i strach przed niepowodzeniem.
Tego rodzaju „chore” przywiązanie do kodu jest czymś, nad czym ciężko pracuję, aby temu zapobiec. Ale „zdrowe” emocjonalne połączenia z produktem, a co za tym idzie, napisany kod, to coś, co zachęcam.
To interesujące pytanie i zgadzam się z jednym z powyższych postów: tak i nie - ale z różnych powodów.
Czy przywiązuję się do kodu? Zdecydowanie tak. Ale nie sądzę, że to sam kod , ale ogólna architektura i aplikacja. Zwykle musisz przeprowadzić wiele badań specyficznych dla domeny, zanim naprawdę umiesz zakodować to, czego chcą ludzie biznesu (chyba że piszesz IDE - wtedy na pewno utkniesz w rekurencji).
Z drugiej strony: Nie ma wielu rzeczy, które lubię bardziej niż wyrzucanie przestarzałych części bazy kodu. Bez względu na to, jak trudne może być pisanie. Podróż ma większe znaczenie niż produkt (przynajmniej dla ego, oczywiście sam produkt również musi działać).
Czy istnieje poczucie własności? To zależy od sytuacji w projekcie. Jeśli nigdy więcej nie zobaczysz kodu (ponieważ Twoja część projektu się skończyła i nadal się rozwijasz), dlaczego masz się tak zachwycać? Jeśli jednak nadal będziesz go wspierać (w jakikolwiek sposób), poczucie przywiązania jest dobrą rzeczą! Kiedy zależy Ci na budowanym przez Ciebie produkcie, szanse są dość duże, że starasz się dostarczać artefakty wysokiej jakości.
Podsumowując, staram się przyjąć pragmatyczną „relację” z kodem, który piszę.
Cholera, tak, kiedyś pobiłem współpracownika, ponieważ był wystarczająco arogancki, aby zmienić nazwę kilku zmiennych.
Nie, nie bardzo. Otrzymuję wynagrodzenie za rozwój oprogramowania. Chociaż przyznaję, zobaczenie poprawek zrobionych w moim kodzie przez innych deweloperów ma wpływ na ego.