Poprzedni wpis (Kolejne dobre winko) | Następny wpis (EuroPython 2008)
Pasanie owieczek
Po ponad roku pracy z młodzieżą zebrało mi się na kilka refleksji dotyczących całej branży robienia softu. Raczej przygnębiających.
Po pierwsze, i najważniejsze, większość z programistów przed 30-tką, jakich spotkałem w ciągu tego roku, nie ma pojęcia o projektowaniu aplikacji. Umieją napisać kod, który robi to, co założyli, ale zazwyczaj cała aplikacja nie robi tego, co miała robić. Ich horyzont widzenia kodu zamyka się w jednym, najwyżej w dwóch modułach, więc każda większa zmiana skutkuje zwykle załamaniem się innego fragmentu aplikacji. A o czymś takim, jak zastanawianie się nad konsekwencjami zmian w kodzie zwykle sobie nie pozwalają. Powiedziałbym ogólnie, że myślenie nie jest ich najmocniejszą stroną, albo inaczej — są świetni w rozwiązywaniu problemów, które sami sobie stworzyli (by sparafrazować Kisiela). I to jest ta przygnębiająca konkluzja.
Przyczyna tego stanu rzeczy wydaje się leżeć głębiej, a jest ona chyba jeszcze bardziej przygnębiająca. Otóż, według mnie, głównym czynnikiem, który sprawia, że młodzi programiści nie dojrzewają do projektowania aplikacji, jest nacisk managementu na to, żeby jak najszybciej dostarczyć działający kod, byle by był. Management żyje w świecie złudzeń (podtrzymywanych przez samych programistów), jakoby zawsze można było poprawić źle działający kod później, ale z drugiej strony, żeby się z tych złudzeń wyleczyć, to trzeba napisać sporo kodu, którego nikt nigdy nie poprawił z powodu braku czasu. Autor nie poprawi, bo nie ma kiedy (zajmuje się przecież czymś innym, również na już), a jego następca też nie poprawi, bo kodu nie rozumie (autor mu nie wytłumaczy, bo nie ma czasu, zresztą prawdopodobnie sam już nie pamięta).
I co teraz? Założę się, że nic, będzie tak, jak poprzednio.
Etykiety: praca programowanie
Komentarze (8)
#2 jarek skomentował(-a) 15 maja 2008 o 14:05
Ja jeszcze miałem szansę nauczyć się projektowania. Koledzy w moim wieku również. Obecni 23-25 latkowie takiej szansy nie mają i nie będą mieli.
Ale oczywiście myśleć możesz...
#3 piotrb skomentował(-a) 15 maja 2008 o 14:44
"ale z drugiej strony, żeby się z tych złudzeń wyleczyć, to trzeba napisać sporo kodu, którego nikt nigdy nie poprawił z powodu braku czasu."
Raczej poprawić trochę takiego kodu, który już obrósł mchem.
Co do młodzieży - będzie jeszcze gorzej - patrząc po sytuacji na uczelniach.
#4 Eluś skomentował(-a) 15 maja 2008 o 20:13
@piotrb:
Mi się zdaje, że Jarek w tym wpisie obwinia raczej management, a nie młodych. I nie wiem co do tego wszystkiego mają uczelnie.
#5 jarek (ale nie zgoda) skomentował(-a) 16 maja 2008 o 04:53
W wielu polskich firmach brakuje porządnego managementu dla którego fakt że człowiek przychodzący odrazu po studiach tak naprawdę nie wie czym jest "projektowanie aplikacji". Nie dowie się tego przez 1 projekt na uczelni który zajmuje mu i tak małą częsć czasu jaką powinien na to poświęcić. Na uczelniach rzadko (nigdy) jest czas aby omówić pojedynczy przypadek i wyciągnąć z niego wnioski. Trudno tu myśleć o tym ( w większości przypadków) aby nabrali oni wprawy w projektowaniu - nie rozwijają aplikacji pod presją czynników które występuja w normalnej pracy. Budują proste programy które nie są bardzo rozległe platformowo.
Magement zazwyczaj nie dostrzega tego że lepiej wyszkolić porządnie jednego pracownika, niż zatrudniać 2 kolejnych do utrzymywania jego wypocin.
#6 jarek skomentował(-a) 16 maja 2008 o 09:29
To nie jest tak, że kiedyś ludzie rodzili się z umiejętnością projektowania softu, a teraz nie. Tej umiejętności nabywa się w miarę ćwiczenia, a żeby ćwiczyć, to trzeba mieć po temu okazję. Obecny model pisania aplikacji w firmach nie daje możliwości nauczenia się projektowania, bo łatwiej (i rzeczywiście taniej, ale na krótką metę) jest dołożyć trochę "żelaza", niż poświęcić trochę zasobów na zaprojektowanie aplikacji tak, żeby się dobrze skalowała w różnych kierunkach, była przygotowana na rozwój i nadawała się do utrzymywania.
O tym, jak bliski jest dystans między kolejnymi "dołożeniami żelaza" można się przekonać samemu, gdy dodanie każdej nowej funkcjonalności skutkuje tym, że aplikacja "przysiada" a żeby ją przywrócić do normalnego działania trzeba dokładać jeszcze więcej "żelaza". Źle zaprojektowane aplikacje nakręcają spiralę wydatków (zarówno na sprzęt, jak i ludzi potrzebnych do ich utrzymywania i rozwijania), ale takie rzeczy można dostrzec dopiero mając kilkuletni horyzont widzenia życia aplikacji.
#7 matchil skomentował(-a) 16 maja 2008 o 12:42
"My którzy przycinamy cegły musimy mieć wizje katedry"
#8 jarek skomentował(-a) 17 maja 2008 o 23:13
@piotrb:
Poprawianie kodu "obrośnietego mchem" nie jest takie złe, pod warunkiem jednak, że jest to dobrze napisany kod -- a ja takiego jeszcze nie widziałem (dobry kod nie obrasta mchem, bo jest "w obrocie" przez cały czas). Dawanie takiego zadania początkującemu programiście (a w szczególności zaraz po szkole, jako pierwszy task w nowej pracy), to jakby proponowanie mu "weź, zajmij się może czymś ciekawszym, np. jeżdżeniem na widlaku, albo nie wiem co...", to tylko pogłębianie poczucia beznadziei, które narasta w człowieku z każdym dniem, gdy musi się grzebać w gównie.
Szkoły nie uczą projektowania, ale z drugiej strony na pierwszej linii frontu ja też nie umiem uczyć projektowania, mając za plecami klienta pałającego żądzą kodu, a nad sobą management, który na każdym kroku daje do zrozumienia, że jakość nie jest na pierwszym miejscu. Po prostu nie umiem wytłumaczyć, że kod od początku musi być oddawany w jakości dobrej, z testami, dokumentacją itd. Jak do tej pory tylko raz udało mi się wymusić poprawienie ewidentnego gówna, przy ogólnym zdziwieniu i mimo jawnych protestów, "bo przecież działa". To bardzo przygnębiająca konstatacja i pewnie gdyby nie to, że nie umiem robić niczego innego, to rzuciłbym pracę programisty.
#1 fisher skomentował(-a) 15 maja 2008 o 13:23
Myślę, że ten problem dotyczy również programistów po 30-tce.