Czy w każdej firmie będę zmuszony do walki z głupotą szefa czy menedżera, względnie z mamtowdupizmem lub idiotyzmem poprzedników? Jak znaleźć firmę gdzie będę mógł robić coś ambitnego?
Dopóki zajmowałem się programowaniem jako hobby (czy to na studiach czy przed studiami) to było dość fajnie, a teraz to już jest lipa totalna. Nie mam nawet siły na rozwój po godzinach.
Zaloz wlasna firme ;)
Czy w każdej firmie będę zmuszony do walki z głupotą szefa czy menedżera
Na rozmowie kwalifikacyjnej zawsze pytaj czy Twój przełożony ma techniczny background. Jeżeli nie to kijem przez szmate nie tykać takiej firmy.
względnie z mamtowdupizmem lub idiotyzmem poprzedników?
Jeżeli chodzi Ci o takie rzeczy jak w bajzel w kodzie, brak testów to prawdopodobnie będziesz musiał przywyknąć. Rzadko się zdarza, żeby duże projekty miały piękny kod.
Jak znaleźć firmę gdzie będę mógł robić coś ambitnego?
A co oznacza dla Ciebie coś ambitnego?
Skoro pracujesz z typowo klepaczowymi technologiami to nie oczekuj niczego innego. Prawda jest taka, że większość firm nie potrzebuje kompetentnych i "myślących" pracowników, programista jest od nakurwiania kolejnych linijek kodu™, nie od ambitnych rozwiązań. Zapotrzebowanie jest przede wszystkim na wyrobników, artystą możesz być po godzinach. Po prostu poszukaj sobie bardziej niszowej dziedziny IT, która stawia znacznie większe wymagania pod względem umiejętności, tam zwykle jest względnie spokojnie. Trafisz co najwyżej na zwierzchnika z kryzysem wieku średniego, ale to chyba idzie jeszcze przeżyć?
Zaloz wlasna firme
Trzeba mieć sensowny biznes-plan i trochę środków. W sumie to środki można by uzbierać na np rok, ale jak wtedy nie wypali to zostanę z gołym tyłkiem. A i tak pomysłu nie mam na biznes.
Na rozmowie kwalifikacyjnej zawsze pytaj czy Twój przełożony ma techniczny background.
Hmm, teoretycznie mój przełożony, tak jak i poprzedni w Comarchu, mają "techniczny background". Obecny ma 6 lat tzw komercyjnego doświadczenia (chyba to jakoś tak określał).
A co oznacza dla Ciebie coś ambitnego?
Jako że algorytmiką się nie zajmuję (w robocie oczywiście), a bardziej inżynierią oprogramowania, to chciałbym pisać np zwięzły, czytelny, testowalny i zmodularyzowany kod. Jeśli kod jest zmodularyzowany to już jest jakiś sukces, bo moduły można wtedy sukcesywnie poprawiać.
Po prostu poszukaj sobie bardziej niszowej dziedziny IT, która stawia znacznie większe wymagania pod względem umiejętności, tam zwykle jest względnie spokojnie.
Niszowa dziedzina IT? Hmm, lubię programować, a nie np administrować. Jako programista znalazłem dość niszowy, a na pewno w Polsce, język Scala. Myślę, że w lipcu wyklaruje mi się sytuacja, tzn będę wiedział czy uda mi się załapać jako programista Scali w Polsce.
Odkąd ja sam stałem się przełożonym doszedłem do wniosku że ilość wtfów na projekt zależy od mamtowdupizmu przełożonego. Dzięki temu w moich projektach jest tendencja wysoce spadkowa :D
Oprócz tego: na bank da się znaleźć "coś" co da się załapać pod Twoje wymagania. ale nie oczekuj zbyt wiele...
@Wibowit może FogCreek? Oni się chwalą że zależy im na jakości a jeśli stosują się do tego co Spolsky pisze na swoim blogu to powinno być spoko ;)
Wibowit napisał(a):
Niszowa dziedzina IT? Hmm, lubię programować, a nie np administrować. Jako programista znalazłem dość niszowy, a na pewno w Polsce, język Scala. Myślę, że w lipcu wyklaruje mi się sytuacja, tzn będę wiedział czy uda mi się załapać jako programista Scali w Polsce.
To jest właśnie Twój problem, "niszowy język"... Znasz się na czymś jeszcze poza używaniem języka programowania? Bezpieczeństwo informatyczne, fizyka, ekonomia, biologia i medycyna? Masz coś ciekawego do zaoferowania, coś dającego dostęp do "bardziej obiecujących" projektów? Rynek potrzebuje przede wszystkim wyrobników pracujących przy tandecie i w tandetnych warunkach, którzy tylko "znają język", musisz być kimś więcej albo mieć cholerne szczęście.
Wibowit, niestety powielasz pewien schemat, wśród tych z IT którzy mają więcej "miękkich" skilli mowi się, że problemem wielu "technicznych" IT'owcow jest ego do którego nie dociera, że informatyka "komercyjna" jest jedynie narzędziem do prowadzenia biznesu, takie google może tworzyć cuda i zatrudniać geniuszy, ale kasa idzie i tak z czegośc tak prozaicznego jak reklamy.
Jak chcesz tworzyc cos ambitnego to rob to po godzinach lub znajdz sobie nisze, tylko, że problem z niszami jest taki, że im bardziej niszowy produkt tym mniej osob jest w stanie za niego zapłacic - jak to mowia, lepiej mieć 1% z miliona niż 100% z tysiąca :S
Taki mała obserwacja: http://en.wikipedia.org/wiki/List_of_companies_by_revenue firma informatyczna jest dopiero na 29 miejscu, a Google nawet nie weszło do rankingu ;)
@cepa to nawet nie chodzi o to że informatyka sluzy tylko zarabianiu kasy. Chodzi o bardziej o to że informatyka czemuś służy a nie jest sztuką dla sztuki ;)
Pracuje aktualnie w miejscu gdzie nikt nie myśli o zyskach, ale mimo to zadaniem koderów jest "żeby działało" a nie żeby ładnie wyglądało. Więc czy informatyka będzie na usługach biznesu, czy nauki czy czegoś jeszcze innego, to nie ma znaczenia, istotne jest że nigdy nie jest sama dla siebie.
Co to są soft-skills?
Soft skills is a sociological term relating to a person's "EQ" (Emotional Intelligence Quotient), the cluster of personality traits, social graces, communication, language, personal habits, friendliness, and optimism that characterize relationships with other people.
Nie widzę na tej liście zdolności do prowadzenia biznesu.
Wiem, że firmy informatyczne nie żyją powietrzem, ale żyją z produktów, które się komuś przydają. Oczywiście chciałbym robić rzeczy, które się przydają ludziom i to niekoniecznie informatykom.
Taki mała obserwacja: http://en.wikipedia.org/wiki/List_of_companies_by_revenue firma informatyczna jest dopiero na 29 miejscu, a Google nawet nie weszło do rankingu
Chyba z 90% obrotów z tej listy to ropa i gaz. Wniosek taki, że mam się zająć szukaniem pól roponośnych? Struktura firm o mniejszych przychodach zapewne się znacznie różni, nie wiem po co miałbym się tą listą sugerować.
Może przedstawię przyczynę obecnego stanu rzeczy, tzn fatalnej jakości kodu w projektach - moim zdaniem (wyobrażeniem) oczywiście. Otóż można wydzielić dwie główne strategie strategie projektowania systemu (tutaj upraszczam sprawę, ale chyba złapiecie o co mi chodzi):
Ogólnie w pewnym stadium życia projektu podejście numer 2. zaczyna się opłacać, a wraz ze wzrostem złożoności systemu opłacalność podejścia numer 2. drastycznie rośnie. To jak szybko nastąpi ten punkt przełamania zależy od użytych technologii i doświadczenia/ podejścia programistów.
Wibowit napisał(a):
Co to są soft-skills?
Soft skills is a sociological term relating to a person's "EQ" (Emotional Intelligence Quotient), the cluster of personality traits, social graces, communication, language, personal habits, friendliness, and optimism that characterize relationships with other people.
Nie widzę na tej liście zdolności do prowadzenia biznesu.
i widzisz kolego... na studiach pewnie o tym nie powiedzieli, ale "personality traits, social graces, communication, language, personal habits, friendliness, and optimism" to są dokladnie skille które są niezbędne do prowadzenia biznesu, bo biznes opiera sie wlasnie na obcowaniu z innymi ludzmi
Wibowit napisał(a):
Chyba z 90% obrotów z tej listy to ropa i gaz. Wniosek taki, że mam się zająć szukaniem pól roponośnych? Struktura firm o mniejszych przychodach zapewne się znacznie różni, nie wiem po co miałbym się tą listą sugerować.
ta lista to taki zimny prysznic, pokazuje czarno na białym jakie jest rozłożenie pieniądza w skali całego świata, mówiąc trywialniej z czego jest hajs a z czego nie
i na tym polu technologie informatyczne o dziwo szczególnie nie błyszczą
Wibowit napisał(a):
- Można zacząć robić projekt "szybko", tzn nie martwiąc się testowalnością, nie pisząc testów, nie dzieląc kodu na moduły, nie przejmować się zasadami typu SOLID, czy wzorce projektowe (chociaż mam awersję do nadgorliwego stosowania wzorców, zwłaszcza jeśli chodzi o kwestie niejednoznaczne). W takim wypadku stworzenie aplikacji, która można komuś pokazać jest relatywnie krótkie, natomiast dość szybko dochodzi się do momentu w którym rozwijanie systemu jest wybitnie nieprzyjemne i bardzo powolne, a skoro wolne to i kosztowne. Tak więc w tym podejściu koszty tworzenia nowych funkcjonalności na początku są małe, ale z czasem gwałtownie rosną. Taką strategię stosuje jednak, jak mniemam, zdecydowana większość firm.
Zgadza się, jak to nazwał pewien CTO z le Silicon Valley z którym miałem przyjemnośc pracować: "high revenue opportunity", ot czasami trzeba napierdalać zeby zarobic, a później sie pomyśli jak tanio zrobić zeby było ładniej na przyszłość
Wibowit napisał(a):
- Można zrobić projekt od razu z myślą o sukcesywnym jego przebudowywaniu, co wymaga pisania testów i dzielenia kodu na warstwy, moduły etc Takie podejście powoduje duży koszt na starcie, tzn trzeba stworzyć dość duży szkielet aplikacji zanim zacznie się go wypełniać funkcjonalnościami, które można komuś zademonstrować czy na nich zarabiać. Jednak gdy system osiągnie już stadium produkcyjne, to i tak dalej koszt dodania nowych funkcjonalności będzie rósł co najwyżej powoli.
Jasne, tylko, że niestety wiele firm oferuje "usługi" a więc wszelkie "customy" dostosowane do klienta, i tutaj sztuką jest prowadzić projekt tak aby uzyskać kompromis pomiędzy jakością a ceną.
Wibowit napisał(a):
Ogólnie w pewnym stadium życia projektu podejście numer 2. zaczyna się opłacać, a wraz ze wzrostem złożoności systemu opłacalność podejścia numer 2. drastycznie rośnie. To jak szybko nastąpi ten punkt przełamania zależy od użytych technologii i doświadczenia/ podejścia programistów.
Zgoda, ale znowu firm, które mają projekty "żyjące długo" nie jest znowu az tak wiele, przynajmniej na naszym rynku.
Osobiście wolałbym być włascicielem jakiejs malej sieci budek z kebabem i lezec na plazy z laptopem gdzies w strefie rownikowej, zdala od zgielku cywilizacji, robiąc projekty na jakie w danej chwili mam ochote, niz marnowac sobie zycie i zdrowie, siedzac w szklanym biurowcu na ntym pietrze od rana do nocy...
Taką strategię stosuje jednak, jak mniemam, zdecydowana większość firm.
Taką strategię stosują bo jest to biznesowo znaczniej bardziej opłacalne. Lepiej wypierdzielić dużo kasy na projekt, który ma niskie szanse powodzenia w imię dobrych praktyk programistycznych i niepewnej przyszłości czy może lepiej najpierw zbudować coś co działa za mniejszą kasę a następnie wydać pieniądze na utrzymanie projektu, który sam na siebie zarabia?
W ogóle jeżeli czegoś mnie nauczyła moja 2 letnia praca w korporacji to szacunek do działającego kodu, nieważnie jak ch*jowo napisanego i jak trudnego w utrzymaniu. IMHO jak nie wykształcisz sobie wysokiego progu tolerancji na słabo napisany kod to szybko skończysz zfrustrowany i wypalony. Szkoda nerwów.
i widzisz kolego... na studiach pewnie o tym nie powiedzieli, ale "personality traits, social graces, communication, language, personal habits, friendliness, and optimism" to są dokladnie skille które są niezbędne do prowadzenia biznesu, bo biznes opiera sie na wlasnie na obcowaniu z innymi ludzmi
A co obcowanie z innymi ludźmi ma do podejścia do projektowania systemu?
ta lista to taki zimny prysznic, pokazuje czarno na białym jakie jest rozłożenie pieniądza w skali całego świata, mówiąc trywialniej z czego jest hajs a z czego nie
i na tym polu technologie informatyczne o dziwo szczególnie nie błyszczą
A muszą błyszczeć na tej liście? Piszesz tak jakby to była lista wynagrodzeń dla poszczególnych profesji. Czy firma X mająca Y zysków z wyciągania ropy z ziemi płaci 90 % zysków ludziom, którzy kopią w ziemi? Czy te firmy nie mają własnych oddziałów zajmujących się pisaniem skomplikowanych systemów, które służą np do przewidywania wielkości złóż w danym miejscu?
Zgadza się, jak to nazwał CTO z le Silicon Valley z którym miałem przyjemnośc pracować: "high revenue opportunity", ot czasami trzeba napierdalać zeby zarobic, a później sie pomyśli jak tanio zrobić zeby było ładniej na przyszłość
(...)
Jasne, tylko, że niestety wiele firm oferuje "usługi" a więc wszelkie "customy" dostosowane do klienta, i tutaj sztuką jest prowadzić projekt tak aby uzyskać kompromis pomiędzy jakością a ceną.
(...)
Zgoda, ale znowu firm, które mają projekty "żyjące długo" nie jest znowu az tak wiele, przynajmniej na naszym rynku.
Zdaję sobie sprawę, że w większości przypadków "napierdalanie kodem" jest po prostu koniecznością, żeby rozkręcić biznes, ale przecież są firmy, które robią już n-ty projekt, mają już duży budżet do wykorzystania i robią długie projekty, a i tak odwalają badziewie. Przecież to się w ogóle nie opłaca. W takim np Comarchu słyszałem że niektóre projekty są mega skopane, ale je rozwijają, aż dojdą do tak grubej ściany, że wielomiesięczne walenie w nią głową nie pomaga. Stworzenie projektu, który dałby się sukcesywnie małymi kawałkami poprawiać byłoby wg mnie dużo bardziej opłacalne na dużą metę.
Lepiej wypierdzielić dużo kasy na projekt, który ma niskie szanse powodzenia w imię dobrych praktyk programistycznych i niepewnej przyszłości czy może lepiej najpierw zbudować coś co działa za mniejszą kasę a następnie wydać pieniądze na utrzymanie projektu, który sam na siebie zarabia?
Ale przecież są duże firmy, które mają duży budżet i mogą sobie pozwolić na ryzyko. W USA popularne jest na przykład kupowanie startupów za nierealistycznie wysokie (na pierwszy rzut oka) kwoty, które to startupy często są nietrafionym zakupem. Mimo to czasem te startupy dostarczają na tyle fajnych rozwiązań technologicznych, że poniesione ryzyko zwraca się z nawiązką.
ostatnimi czasy zastanawiałem się odnośnie wzorców projektowych i ich wykorzystaniem w projektach, a dokładniej ich braku (mvc często jest wymuszony przez używaną technoglogię więc takowe pomijam). Tak się zastanwiałem że przecież w wielu miejscach to jest rozwiązanie pomocne i niby wszyscy wokół o tym wiedzą. Tylko teraz jak to wprowadzić do kodu. Z doświadczenia (jakieś tam jest) widze że najczęściej jest tak - jest sobie system i są taski. Task jest wyceniony dajmy na to na 4h. Później pojawia się kolejny task na kolejne 4h i tak jeszcze kilka. Oczywiście programista dostanie taska i w sumie może i ma świadomość że to co robi nie jest najlepsze, ale skoro wyceniono na 4h to będzie się w tym próbował zmieścić. Dajmy na to że z te zadania mogą się fajnie dać zaimplementować jako jakiś tam wzorzec i późniejsze taski będą krótsze.
Tylko teraz programista siada do pracy i... No właśnie widzi że coś jest nie tak, że można lepiej (załóżmy że koledzy z jakiegoś powodu nie zauważyli możliwości wzorca) i co zrobić - rozwiązać taska tak aby wszyscy byli szczęśliwi i pokazać że potrafi rozwiązać powierzone mu zadanie, czy zacząć refaktoryzować kod? A może iść szefa i powiedzieć że można lepiej?
I co powie szefo?
-A co nam to da?
i tak pewnie jest w wielu wielu miejscach. Tyle odnośnie wzorców - i softSkili
Takie moje małe przemyślenia przed snem :P
Wibowit napisał(a):
Czy w każdej firmie będę zmuszony do walki z głupotą szefa czy menedżera, względnie z mamtowdupizmem lub idiotyzmem poprzedników?
Głupota szefa/przełożonego, "mamtowdupizm" czy idiotyzm poprzedników - to raczej subiektywna ocena pracownika, czasami właściwa a czasami nie.
Wibowit napisał(a):
Jak znaleźć firmę gdzie będę mógł robić coś ambitnego?
Moim zdaniem w każdej firmie można robić coś ambitnego, wystarczy nie ograniczać się do poleceń/zleceń przełożonych a wybiegać ponad to co każą. To również sprawdzian dla samego siebie, ważniejsze jest wyrobić się w czasie danym na zadanie czy zrobić to zadanie przede wszystkim dobrze, nawet kosztem naciągnięcia terminu?
"Zjebki" od przełożonych pewnie są i będą za przekraczanie terminów, ale i sygnał, że komuś zależy na czymś więcej niż na zmieszczeniu się w terminie też idzie wyżej. Jak myślisz jak przełożony widzi pracowników którzy ograniczają się tylko do zmieszczenia się w terminach? i powielają błędy swoich poprzedników? mamtowdupizm? idiotyzm? głupota?
Jak ktoś wyżej zauważył rozmowa z przełożonym i zasypywanie go "technicznym bełkotem" jak można by coś zrobić lepiej tylko trochę więcej czasu na to trzeba nie skutkuje, lepiej poskutkuje postawienie przełożonego raz, drugi, trzeci przed faktem dokonanym, czyli najpierw coś zrobić a potem pokazać różnicę pomiędzy tym co on proponował a tym co się samemu z własnej inicjatywy zrobiło. Ale nie na zasadzie "Patrz ciemna maso jak to JA zrobiłem i porównaj to do tego gówna które ty proponowałeś" tylko, grzecznie, rzeczowo, z przygotowaną argumentacją dlaczego tak a nie inaczej, dlaczego uważasz ze tak jest lepiej perspektywiczniej itp.
Wibowit napisał(a):
Dopóki zajmowałem się programowaniem jako hobby (czy to na studiach czy przed studiami) to było dość fajnie, a teraz to już jest lipa totalna. Nie mam nawet siły na rozwój po godzinach.
Cos musisz zmienic skoro takie masz wnioski, pracę, otoczenie, godziny snu czy zajęcia pozapracowe. Innej opcji nie ma.
PS. Pisałem z perspektywy ogólnie firmy, nie pracuje w branży IT ale wydaje mi się ze pewne sprawy mają wszedzie wspolny mianownik.
PS. Pisałem z perspektywy ogólnie firmy, nie pracuje w branży IT ale wydaje mi się ze pewne sprawy mają wszedzie wspolny mianownik.
Buu, nie pracujesz w IT. Moim zdaniem to co jest drastycznie inne w IT niż w innych branżach jest to, że ciężko jest poprawiać wytworzony produkt przy typowym podejściu. W jakiejś fabryce na przykład można kupić pojedynczą nową linię produkcyjną, fryzjer może zrobić nowy wystrój w jednym pokoju, itp itd natomiast w branży IT jeśli jest projekt pisany przez wiele lat to i tak często jest ciągnięty nawet mimo iż jest maksymalnie skopany i jego rozwój jest kosztowny, a, co najważniejsze, jest tak zespawany, że ciężko wyrzucić jakąś jego pojedynczą część i zrobić od nowa. Trzeba przerobić praktycznie całość naraz, a to wiąże się z dość długim czasem, kiedy nie jest widoczna na zewnątrz (tzn dla użytkowników końcowych) żadna nowa funkcjonalność.
Wibowit napisał(a):
Buu, nie pracujesz w IT. Moim zdaniem to co jest drastycznie inne w IT niż w innych branżach jest to, że ciężko jest poprawiać wytworzony produkt przy typowym podejściu. W jakiejś fabryce na przykład można kupić pojedynczą nową linię produkcyjną, fryzjer może zrobić nowy wystrój w jednym pokoju, itp itd natomiast w branży IT jeśli jest projekt pisany przez wiele lat to i tak często jest ciągnięty nawet mimo iż jest maksymalnie skopany i jego rozwój jest kosztowny, a, co najważniejsze, jest tak zespawany, że ciężko wyrzucić jakąś jego pojedynczą część i zrobić od nowa. Trzeba przerobić praktycznie całość naraz, a to wiąże się z dość długim czasem, kiedy nie jest widoczna na zewnątrz (tzn dla użytkowników końcowych) żadna nowa funkcjonalność.
Nadal uważam, że tu i tu są wspólne mianowniki, pracowałem w firmach produkujących elektronikę, w tym m.in. elektronikę pracującą w strefach zagrożonych wybuchem (mierniki, układy monitorujące do kopalń, stacji paliw itp) i w przemyśle samochodowym (produkcja elementów mających wpływ na bezpieczeństwo pasażerów).
Po Twojej wypowiedzi wydaję mi się że nie zdajesz sobie sprawy jak w takich firmach są "zespawane" ze sobą wszelkie procesy produkcyjne. Mowa o zatwierdzonych dostawcach materiałów i półwyrobów, potwierdzeniach badań dopuszczających, pełnej dokumentacji technicznej, technologicznej, produkcyjnej do tego system instrukcji i procedur zgodnych z ISO dla każdej składowej procesu itp. Nie ma opcji wprowadzania żadnych zmian do zatwierdzonego procesu produkcyjnego, ponieważ proces staje się niezgodny a tym samym - zaczynamy produkować coś czego nie możemy wprowadzić do obrotu bez poniesienia ostrych konsekwencji (utrata klienta to najłagodniejsza konsekwencja).
Co więcej w żadnej z tych firm ustawiony proces na żadnym produkcie nie był ustawiony idealnie (i nigdy nie będzie). A to czas produkcji, a to koszt produkcji a to użyte materiały (jakość), a to kupiony na pałę sprzęt i wciskany do procesu tylko po to aby nie stał bezużytecznie (ewentualnie aby zamaskować to że szefostwo trochę dało ciała z nietrafionym zakupem). Tak jak w oprogramowaniu wymogi się zmieniają od strony klienta, od strony dostawcy materiałów albo z działu konstrukcyjnego (nowsze wersje). Od razu się wszystkiego nie pozamiata, i nie ustawi na ideał bo ideał nie istnieje, ponadto każda większa zmiana wymaga zatrzymania produkcji - kolejnych wdrożeń, kolejnych zatwierdzeń i dopuszczeń. To są miesiące o ile nie lata. Dlatego przestój o ile w ogóle może być, ma trwać jak najkrócej. A żeby to zapewnić trzeba się odpowiednio przygotować, zacząć od odpowiednich rewirów i systematycznie poszerzać zakres zmian tak aby możliwie uprościć, skrócić i zapewnić powodzenie wdrożenie nowego rozwiązania w zgodzie z nowo zatwierdzonym procesem (refaktoryzacja). I tu jest miejsce na własną inwencję, podpieranie się własnym doświadczeniem w poprzednich firmach czy po przebytych szkoleniach, uzyskanych certyfikatach itp. To trwa, i tu jest potrzebna cierpliwość i konsekwencja.
Rotacja ludzi jest wszędzie, i wszędzie zdarzają się ludzie z różnym podejściem (czy to przełożony czy kolega z działu). Firma zatrudniając nowego człowieka chce liczyć na wprowadzenie świeżości od tego nowego, nowe pomysły, na to aby trochę pozamiatał w nowej firmie bo starzy pracownicy już wrośli w nawarstwiający się syfek i dla nich jest dobrze jak jest. Nikomu nie chce się tego zmieniać bo wiadomo ile roboty się z tym wiąże. Co więcej wiadomo, że prędzej czy później ten nowy trochę pozamiata a potem też odpuści i wrośnie, i znów potrzebna jest świeża krew, nowe siły do działania.
Dlatego wydaje mi się że kluczową sprawą dla własnego rozwoju jest nie "typowe podejście", tylko mobilizacja siebie do jak najdłuższej zdolności do wyłapywania tych firmowych syfków, mobilizowania siebie do ich usuwania, i zdolności ciągłego wyłapywania nowych syfków. Jak się straci te zdolności to znaczy ze wrosłeś i de facto się cofasz w rozwoju. Tego firmowego syfku nigdy nie zabraknie i nigdy się nie wyeliminuje, trzeba się nauczyć z tym żyć, można ofensywnie ;)
Co więcej istnieje też coś takiego jak propaganda firmowa, aby się nie sfrustrować doszczętnie, wygodnie jest założyć, że:
Wydaje mi się, że powyższe sprawy, co prawda na pewnym poziomie abstrakcji ale to właśnie wspólny mianownik pomiędzy firmami IT a wszystkimi innymi.
PS. Swoją drogą mam wrażenie że uważasz, że branża IT jest czymś szczególnym i czymś postawionym w każdym aspekcie wyżej ponad te "fabryki" i "fryzjerki", moim zdaniem każdy orze jak może i dla zminimalizowania ryzyka "sfrustrowania ostatecznego" proponuję zweryfikować swoje podejście do tych spraw (ego). Mówię na swoim przykładzie, z pierwszej firmy przechodziłem do drugiej z myślą "jaki jestem zajebisty" w swoim fachu, sporo straciłem czasu, nerwów i pieniędzy (brak podwyżek) przez to że nie miałem do nowego miejsca i ludzi odpowiedniej dawki pokory i szacunku.
Wibowit napisał(a):
Zdaję sobie sprawę, że w większości przypadków "napierdalanie kodem" jest po prostu koniecznością, żeby rozkręcić biznes, ale przecież są firmy, które robią już n-ty projekt, mają już duży budżet do wykorzystania i robią długie projekty, a i tak odwalają badziewie. Przecież to się w ogóle nie opłaca. W takim np Comarchu słyszałem że niektóre projekty są mega skopane, ale je rozwijają, aż dojdą do tak grubej ściany, że wielomiesięczne walenie w nią głową nie pomaga. Stworzenie projektu, który dałby się sukcesywnie małymi kawałkami poprawiać byłoby wg mnie dużo bardziej opłacalne na dużą metę.
Jakość kodu nie zależy od wielkości firmy,czasu projektu czy budżetu tylko w największym stopniu od zespołu. Najlepsi programiści z Polski w większości siedzą za granicą, na rynku jest bardzo dużo młodych, niedoświadczonych koderów i trochę mniej przeciętnych. Średnio na zespół 6 osobowy przypadają 1-2 dobre osoby. Te dobre osoby nie uciągną całego projektu same i nie mają czasu poprawiać kodu po swoich mniej doświadczonych kolegach.
Kolejna sprawa - pisanie od 0 to zamrożenie produkcji na N miesięcy, podczas których nie masz możliwości walczenia na rynku a całość inwestycji jest obarczona ogromnym ryzykiem (bo nikt Ci nie zagwarantuje, że jak przepiszesz połowę kodu, to będzie lepiej, a z drugiej strony masz gwarancję, że w tym czasie nie zrealizujesz nowych featureów/założeń biznesowych).
Ponadto w niektórych firmach panuje takie podejście, że każdego programistę można zastąpić skończoną liczbą studentów - przy takim podejściu raczej ciężko o dobry kod.
BTW polecam książkę: http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 . W książce jest opisane jak radzić sobie z utrzymaniem starego słabo napisanego kodu, jak go refaktoryzować, poprawiać bugi, żeby nie zepsuć reszty itd. Jak już opanujesz tą sztukę to może się okazać, że praca ze starym kodem potrafi być całkiem przyjemna.
Warto też przeczytać artykuł: http://typicalprogrammer.com/?p=122 .
cepa napisał(a):
ta lista to taki zimny prysznic, pokazuje czarno na białym jakie jest rozłożenie pieniądza w skali całego świata, mówiąc trywialniej z czego jest hajs a z czego nie
i na tym polu technologie informatyczne o dziwo szczególnie nie błyszczą
Jakie ma znaczenie, że sieć hipermarketów ma większy przychód niż Google, skoro generuje stratę? :|
Dla Google 25% przychodu jest zyskiem, to zapewne większy odsetek niż w przypadku większości firm z tej listy. Podobnie wygląda sprawa z Oracle czy Microsoftem.
Sorry Panowie, ale twierdzenie, że "musimy pisać dziadowski kod, bo tak chce biznes" jest równie mądre jak twierdzenie, że "musimy wrzucić dziewicę do wulkanu, bo inaczej bogowie zniszczą naszą wioskę".
Gówniany kod nie bierze się z wymagań klienta ani kierownika projektu tylko z niechlujstwa, lenistwa, braku umiejętności oraz głupoty jego twórców. Napisanie porządnej aplikacji wcale nie jest bardziej czasochłonne niż odwalenie jej byle jak (nie dotyczy projektów studenckich na 15 minut), po prostu zamiast rzucać się jak szczerbaty na suchary i klepać, trzeba najpierw przemyśleć architekturę i zaprojektować strukturę aplikacji. To oczywiście wymaga doświadczonej osoby, która potrafi to zrobić, żeby nie okazało się w połowie projektu, że brakuje dwóch warstw. Do tego programiści powinni znać język i technologię, w której piszą, żeby nie sadzić dziwnych kwiatków i nie wynajdować koła na nowo, a poza tym być solidni i nie stosować copy-paste, który pozwala zaoszczędzić głupie pięć minut kosztem stworzenia potwora na lata.
To od nas zależy, czy rozwijając słabo wykonany projekt zrobimy tylko to, co nam kazali, czy przy okazji coś poprawimy.
Najpierw idziemy na rozmowę kwalifikacyjną, żeby przez kilka godzin udowadniać jakimi jesteśmy świetnymi programistami, a potem mamy pisać kod, który jest słaby. Gdzie tu logika?
Pracowałem dotąd w 4 firmach związanych jakoś z IT o dość różnym profilu:
Firmę szkoleniową pomijam, bo tam raczej kodu nie pisałem, ale co do pozostałych to mogę z całą pewnością napisać, że:
Najbardziej poryty kod można było pisać na uczelni. Tak naprawdę nikogo nie obchodziło w czym piszesz, jak piszesz, czy liczyło się tydzień czy 10 minut - ma być na końcu z tego dobra publikacja. :D
W przypadku projektu komercyjnego na tejże uczelni, w sumie niewiele się zmieniało, poza tym, że przynajmiej technologia i framework były w miarę ustalone. Co do ambitności projektów, to jak sobie ktoś wymyślił i pozyskał środki, to miał ambitny, ale i tak gubiło się to w ogólnie panującym chaosie, biurokracji, dydaktyce i projektach komercyjnych robionych bo "z czegoś przecież trzeba żyć". Jak ktoś nie lubi robić 10 rzeczy na raz, to nie polecam, choć ludzie bardzo fajni, a pieniądze wcale nie takie cienkie jak się powszechnie uważa. :)
Co do firm prywatnych, to z doświadczenia napisanie porytego kodu (pójście na skróty) prawie zawsze kończyło się źle. Tu potrzebny jest zdrowy rozsądek, nawet jeśli to projekt na zamówienie z zabójczym 3 miesięcznym terminem realizacji. Jeśli napisanie czegoś porządnie zajmuje tylko 10% więcej czasu niż byle jak, ale potencjalnie oszczędzi tydzień debugowania, bo jakiś debil synchronizował wątki za pomocą Thread.sleep, to trzeba pisać porządnie. Firma zatrudniła kiedyś dwóch koderów piszących w stylu spaghetti i szybko wylecieli - wcale nie pisali kodu szybciej, ale za to poprawianie czegokolwiek w ich kodzie to była masakra.
Z drugiej strony są sytuacje, kiedy coś trzeba naprawić szybko taśmą klejącą i sznurkiem, byle działało i klient nie zauważył. Tego się nie da uniknąć. Ale zawsze do tego wracamy w następnym wydaniu i staramy się zrobić przyzwoicie. Dodam, że w obecnej firmie mamy jakieś 90% kodu odziedziczonego, z killku projektów opensource, który jest bardzo różnej jakości. Wbrew pozorom, daje się z tym pracować. Chyba nawet jest większy fun szukać bugów w cudzym kodzie niż własnym. :D
Odnośnie pytania, jak znaleźć coś ambitniejszego to mam takie dwie rady: nie zawężaj się do rynku polskiego i przyjrzyj się lepiej projektom opensource.
Są firmy skłonne zatrudniać programistów zdalnie. Np. firmie gdzie teraz pracuję nie przeszkadza nawet 9h różnica strefy czasowej. Mam też kumpla który tak pracuje w innej firmie, też z USA. Zaleta jest taka, że nie dość że masz większy wybór, to jeszcze zarobki potencjalnie znacznie lepsze.
Co do opensource, to są firmy skoncentrowane wokół projektów opensource. Można się załapać w takim projekcie (oczywiście wybieramy ambitny i aktywny projekt, nie byle co), firmy często rekrutują spośród committerów.
0x200x20 napisał(a):
Na rozmowie kwalifikacyjnej zawsze pytaj czy Twój przełożony ma techniczny background. Jeżeli nie to kijem przez szmate nie tykać takiej firmy.
I co to tak naprawdę daje? Może trochę zmniejsza ryzyko, ale jeśli ten "techniczny background" polega na umiejętności klepania jednowarstwowego, statycznego kodu metodą kopiuj-wklej, to będzie tylko gorzej. Zwłaszcza, jeśli gość jest uparty i uważa swoje podejście za jedyne słuszne.
0x200x20 napisał(a):
Taką strategię stosują bo jest to biznesowo znaczniej bardziej opłacalne. Lepiej wypierdzielić dużo kasy na projekt, który ma niskie szanse powodzenia w imię dobrych praktyk programistycznych i niepewnej przyszłości czy może lepiej najpierw zbudować coś co działa za mniejszą kasę a następnie wydać pieniądze na utrzymanie projektu, który sam na siebie zarabia?
To dotyczy może startupów, ale nie przy przewidzianym na kilka lat tworzeniu projektu dla konkretnego klienta. Tu można się skupić na testach i dobrym projekcie od początku, bo to przyniesie profity w ciągu kilku miesięcy. Bo wtedy już widać, jak łatwo/trudno jest poprawiać błędy oraz dodawać nowe funkcjonalności.
Ja we wrześniu myślałem, że trafiłem do porządnej firmy. Masakrycznie trudna techniczna rozmowa kwalifikacyjna, z pytań które dostawałem, wynikało, że kładą nacisk na jakość kodu i stosowanie dobrych praktyk. Do tego pracuje tam mój kolega z poprzedniej firmy, i bardzo polecał. (Tyle, że on ma własny niemalże jednoosobowy projekt.)
Jaka jest praktyka? Wzięty został prawdopodobnie jedyny przemyślany pod względem testowalności i elastyczności produkt M$ (ASP.NET MVC) i zrobiono z niego jakieś g**no. Jakby Hanselman to zobaczył, to by chyba wpadł w śpiączkę hiperglikemiczną z miejsca.
Piszemy praktycznie jednowarstowego ERPa, w którym wszystko: walidacja, logika biznesowa, logika prezentacji, i dostęp do danych odbywa się w kontrolerach. Taka "architektura" wymusza, że jakakolwiek nowa funkcja (np. import/eksport danych do pliku) również musi być dodana w kontrolerach (albo w projekcie, w którym się znajdują), bo nic nie da się wydzielić. Dzięki temu wszystkiemu, projekt webowy ma referencje do chyba wszystkich możliwych .NETowych dllek, jakie powstały.
Ktoś wpadł na genialny pomysł, żeby dodać do projektu modelbinder (czyli klasę, która z założenia jest odpowiedzialna za parsowanie żądania HTTP i np. tworzenie z danych formularza obiektu) zapisujący dane do sesji NH... W efekcie nie da się prawie nic przetestować bez środowiska WWW.
Zero SRP, zero SoC, zero myślenia, za to 100% PR zarządu, który gada o tym, że jesteśmy najlepszym zespołem programistycznym w Polsce. [rotfl]
Wygląda to wszystko przekomicznie, zwłaszcza w kontekście tego, że klientem jest poważna firma zagraniczna, a w założeniach projektu jest mowa o odpowiedniej ilości testów jednostkowych i poziomie jakości kodu. Jeśli np. zlecą jakiś audyt tego sytemu jakiemuś zewnętrznemu specjaliście, to mój pracodawca się nie pozbiera. (I mam szczerą nadzieję, że tak się stanie.)
Ogólnie mam wrażenie, że większość ludzi podchodzi do programowania w ten sposób, że jeśli kod się kompiluje, to znaczy, że jest prawidłowy. No, i że użycie frameworka z literkami MVC w nazwie, magicznie sprawia, że projekt jest dobry.
Więc jak znaleźć firmę bez WTFów? Nie mam pojęcia. Ale jak tak popatrzę na wyczyny "fachowców" z mojej firmy, to powinienem być jakimś über-senior-architektem i zarabiać 20k netto.
somekind napisał(a):
jak tak popatrzę na wyczyny "fachowców" z mojej firmy, to powinienem być jakimś über-senior-architektem i zarabiać 20k netto.
Najsmieszniejsze jest to, ze oni gdzie indziej (a moze nawet w tym samym temacie, nie czytalem calego) wypowiadaja sie tak samo o Tobie...
somekind napisał(a):
Zero SRP, zero SoC, zero myślenia, za to 100% PR zarządu, który gada o tym, że jesteśmy najlepszym zespołem programistycznym w Polsce. [rotfl]
Może to w kontekście tego że jeszcze ogarniacie jakoś ten projekt :)
Zero SRP, zero SoC, zero myślenia, za to 100% PR zarządu, który gada o tym, że jesteśmy najlepszym zespołem programistycznym w Polsce
Może wasz produkt ma po prostu dobre wyniki? Jeżeli projekt generuje wartość biznesową to już znaczy, że odniósł skukces a brak testów, błedny design, etc. to są kwestię drugorządne. Szczególnie dla zarządu, który często nie ma nawet pojęcia co to jest test jednostkowy.
Rozumiem, że skoro narzekasz na design to sam do projektu dołączyłeś później i nie miałeś na niego wpływu? Błędny design często powstaje np. przez zmieniające się wymagania projektowe, presje czasową dopiero później przez niskie umiejętności programistów. Jeżeli nie wiesz jak te kwestie wyglądały na początku to nie jesteś na pozycji do oceniania swoich współpracowników.
0x200x20 napisał(a):
Może wasz produkt ma po prostu dobre wyniki? Jeżeli projekt generuje wartość biznesową to już znaczy, że odniósł skukces a brak testów, błedny design, etc. to są kwestię drugorządne. Szczególnie dla zarządu, który często nie ma nawet pojęcia co to jest test jednostkowy.
U nas zarząd to programiści, przynajmniej tak się określają.
Czy produkt ma dobre wyniki? Nie wiem, jak się biznes określa "dobre wyniki", ale nie dotrzymaliśmy jeszcze ani jednego terminu oddania modułu do klienta, ogólnie jest wykonane może 2/3 tego, co miało być zrobione, a do tego co już zostało oddane, klient zgłasza masę błędów. Ostatnio okazało się, że połowa modułu X, który miał być gotowy we wrześniu, jest teraz do przepisania, bo jedna z kluczowych funkcjonalność została źle wykonana. A nowo tworzony moduł Y, który wymaga współpracy ze "starym" modułem Z, również wymaga przepisania go w połowie.
Rozumiem, że skoro narzekasz na design to sam do projektu dołączyłeś później i nie miałeś na niego wpływu? Błędny design często powstaje np. przez zmieniające się wymagania projektowe, presje czasową dopiero później przez niskie umiejętności programistów. Jeżeli nie wiesz jak te kwestie wyglądały na początku to nie jesteś na pozycji do oceniania swoich współpracowników.
Raczej małe szanse, żebym miał wpływ na design w projekcie, skoro architekt jest wartościowym pracownikiem firmy, kolegą szefów, kierownika projektu, itp. A ja to kto? Mam pięć razy krótszy staż od niego, więc zapewne z punktu widzenia "góry" na niczym się nie znam.
Nie chcę oceniać moich kolegów-programistów, którzy tak jak ja, klepią, co im kazano w założonej konwencji. Spieprzenie design to wina architekta i jego doradców. Dla mnie brak podstawowego podziału na warstwy w tak dużej aplikacji, to kompletna porażka.
No cóż "twardogłowi" architekci to poważny problem. Najczęściej ludzie, którzy przestali się rozwijać X lat temu ale uważają, że są tacy dobrzy bo mają Y lat doświadczenia. Trzeba uważać, żeby czasem samemu nie stać się kimś takim za kilkanascie lat...
Spotkałem się też z przegięciem w drugą stronę: architekt, który unika decyzji (a więc i konsekwencji) o architekturze produktu zwalając wszystko na programistów. Skutki też nie były pozytywne.
Jakby się dało jakoś na rozmowie kwalfikacyjnej dowiedzieć z jakim architektem będziemy współpracować to można by uniknąć pracy w takiej firmie, ale pewnie trzeba by być niezłym dyplomatą, żeby takie informacje wyciągnąć.
To i ja coś dorzucę od siebie.
Pracowałem w dwóch firmach (jedna mała, druga korporacja gdzie aktualnie siedzę).
W małej firmie pracowało 3 programistów, a projekty nie miały jakiegoś ultra deadline. Pomyśleć naturalnie można, że w takim przypadku jakość kodu mogła być doskonała, bo przecież czas mimo, że gonił to nie był tragiczny, zespół był mały, a projekty nie były kobyłąmi 20-letnimi.
Realnie to wyglądało tak, że był sobie starszy Pan programista, który jeb*ł projekt za projektem gorzej niżby to był student bez doświadczenia. Całość praktycznie statyczna, co jednocześnie wyklucza testy jednostkowe (jakiekolwiek testy w sumie), facet nie miał pojęcia co to UML (gość z 10-letnim doświadczeniem zawodowym!!!), a jego jakość kodu można było opisać krótko: masakracja. Funkcje długie na 100 linijek, na dodatek powtórzenia i elementarne braki w wiedzy na temat czystego kodu.
Co, więcej zespół do siebie nie pasował. Starszy programista to był burak nawet dla własnej żony (dla mnie coś niepojętego) oraz dla koleżanek - grafików.
Drugi programista był zastraszony przez tego starszego.
Młodszy mówi: "Wiesz co, lepiej zróbmy to tak" (i faktycznie miał rację)
Starszy mówi: "NIE!"
Młodszy mówi: "eee... ok."
Tak to wyglądało. Spierdo*łem stamtąd szybciej niż samolot :) Na dodatek szefunio też był niezłym cwaniaczkiem.
Po tej akcji szukałem pracy trochę bardziej wybredniej. Odrzuciłem mnóstwo ofert, w tym opowiem Wam małą historię z mojej pewnej rozmowy kwalifikacyjnej.
Wysłałem CV do pewnej firmy. Face zadzwonił po kilku godzinach od wysłania i mówi, że chciałby na początek poznać mnie przez telefon, moje oczekiwania, to czym się zajmowałem itd. Taka rozmowa kwalifikacyjna, ale przez telefon.
Wszystko w miarę szło ok, dopóki gość nie spytał: "A jak u Pana z finansami?"
WTF sobie myślę, ale ok, odpowiadam: "Nie narzekam, dziękuję. Nie mam, ani nigdy nie miałem żadnych długów, a moja aktualna sytuacja jest stabilna."
Na co słyszę w słuchawce... UWAGA:
"Ach... szkoda"
Uszom normalnie nie wierzyłem co usłyszałem :D
Zaskoczony lekko i rozbawiony pytam: "ooo a dlaczego szkoda?".
Na co facet odpowiada totalnie poważnie: "Wie Pan, z doświadczenia wiem, że jak ktoś nie ma problemów finansowych to ma mniej motywacji do pracy.".
Padłem i dalsza dyskusja z owym pracodawcą nie miałą sensu. Odpowiedziałem jedynie: "No cóż, wie Pan zależy to od mentalności danego programisty. Jeden nie przykłada się do swojej pracy niezależnie od swojej sytuacji finansowej, wszak ważne są umiejętności, ja zaś ze swej strony mogę zaoferować..." itd...
Po kilku miesiącach facet znów do mnie zadzwonił czy jednak jestem chętny tam pracować :D Pewnie wziął kilku frustratów co mu naje*li w kodzie babole i się facet ocknął. Oczywiście odmówiłem.
No i tak sobie szukałem pracy z 3 tygodnie, aż w końcu trafiłem do korporacji. Kod tam pisany jest... słaby. Ani testów nie ma w kodzie, ani też super wybitnych programistów. Jestem osobom młodą w zespole, a mimo to bez skrupułów upominam osoby starsze ode mnie (dużo starsze) by pisały ładniej. Przykład: Pisałem konstruktor i zauważyłem, że w kodzie ktoś pisał 4 prawie identyczne konstruktory. Zgłosiłem to autorowi i powiedziałem, że to poprawiam w ten sposób i żeby patrzył, by potem nie popełnił tego błędu raz jeszcze.
Powtórzenia w kodzie zdarzają się np w takich miejscach jak:
if (cos || cos || aaa && bb || cos || cos && aa || aaaaa)
{
// cos robi
}
if (cos || ddd|| aaa && bb || cos || cos && aa || aaaaa)
{
// cos robi
}
if (cos || eee|| aaa && bb || cos || cos && aa || aaaaa)
{
// cos robi
}
if (cos || fff|| aaa && bb || cos || cos && aa || aaaaa)
{
// cos robi
}
Jak to zobaczyłem to pierwszy mój efekt był wymiotny. Potem zgłosiłem to znów autorowi i powiedziałem, by tego nie pisał tak, bo gdy dojdzie do edycji pewnych powtarzających się danych to będzie udręka. Na co usłyszałem... "Ale to nie ulegnie zmianie"
WTF!!!
Mówię do niego: "Skąd Ty to możesz wiedzieć? Przecież za rok ten kod może wyglądać zupełnie inaczej."
i wystarczyło zrobić funkcję:
private bool Verify(int data)
{
return (cos || data|| aaa && bb || cos || cos && aa || aaaaa)
}
i ify wyglądały już dużo lepiej:
if (Verify(cos))
{
// cos robi
}
if (Verify(ddd))
{
// cos robi
}
if (Verify(eee))
{
// cos robi
}
if (Verify(fff))
{
// cos robi
}
Mimo tych przeciwności losu, firma jest bardzo fajna. Atmosfera jest świetna, nikt nikogo nie zmusza do pracy jakby był niewolnikiem.
Każdy się lubi, i nikt gburem nie jest. Co więcej przełożeni mają łeb na karku i potrafią utrzymać projekt w miarę w sensownym stanie.
Wiecie co?
problem złej jakości kodu wynika z tego, że ludzie boją się upominać kogoś. Widzimy zły kod to, albo go olejemy, albo nie powiemy autorowi, że dał d**y po całości. W ten sposób ten słaby programista dalej będzie klepał babole, a my po nim będziemy poprawiać.
Jednak, czy istnieje firma gdzie kod jest czysty i piękny? Taaaa pewnie tak wygląda niebo programisty :)
Za mało jest dobrych programistów, by znaleźć firmę gdzie kod jest taki jakbyśmy tego chcieli. A sami pracodawcy (co udowodniłem powyżej o tym mistrzu z finansami) nie zdają sobie sprawy z tego czym kończy się zatrudnianie partaczy.
Dacie wiare ze pracuję w małej firmie gdzie naprawde wdrożył się taki system rozwiązywania problemów?, nic konstruktywnego nie idzie zaszczepić, tylko "od siebie". Pacując poprzednio w większych firmach z rozbudowaną biurokracją nie zauważyłem czegoś takiego, a na pewno nie w skali dotyczącej większości pracowników.
O co tu chodzi, jakim cudem to się kręci? Aktualne w waszych firmach?
