Wasze Historie #13: Ciemna strona IT

21

Zapytano mnie: jaki jest Twój największy problem w zawodzie programisty? Na chwilę obecną ciężko mi taki określić. Od pewnego czasu dręczy mnie jednak kilka mniejszych problemów, które sprawiają, że nasza praca nie zawsze jest tak przyjemna i efektywna jak mogłaby być.

Niniejszy post jest częścią cyklu "Wasze Historie".
Autor: Paweł

Deficyt Seniorów

Takich prawdziwych. Przez wielkie “S”. Takich, którzy zawodowo spędzili z kodem 20-30 lat, a nie takich, których biologiczny wiek nie przekroczył jeszcze tej liczby. Takich, którzy projektowali i budowali systemy o różnej złożoności, w różnych domenach biznesowych, korzystając z różnych technik, wzorców oraz technologii. Takich, którzy poznali je w praktyce, dotknęli ich, mieli okazję poczuć kiedy się sprawdzają, a kiedy ich użycie nie ma sensu.

W każdym, tak bardzo lansowanym przez HRy, młodym, dynamicznym, kreatywnym i energicznym zespole, powinna być taka osoba, po to, aby tę młodą, kreatywną energię ukierunkować w stronę rozwiązań, które mają szansę się sprawdzić w danym przypadku, a nie w stronę narzędzi na które jest aktualnie hype. Być może wtedy mielibyśmy mniej systemów z którymi trzeba walczyć, a więcej takich z których przyjemnie się korzysta i które da się rozwijać.

Brak głębokiej i solidnej wiedzy

Wiedzy oraz mądrości opartej na solidnym zrozumieniu technologii oraz rozwiązywanych przez
nią problemów. Warto przytoczyć tu definicję słowa “grok” z jargon file:

“To understand. Connotes intimate and exhaustive knowledge. When you claim to ‘grok’ some knowledge or technique, you are asserting that you have not merely learned it in a detached instrumental way but that it has become part of you, part of your identity. For example, to say that you “know” LISP is simply to assert that you can code in it if necessary — but to say you “grok” LISP is to claim that you have deeply entered the world-view and spirit of the language, with the implication that it has transformed your view of programming.”

Zdarza się, że wiedza dostępna w zespole na temat używanych języków, frameworków czy wzorców jest powierzchowna. Następstwem tego są wysoce nieoptymalne rozwiązania potencjalnie prostych problemów. Po części przyczyną tego jest deficyt seniorów, guru, ale też…

Brak czasu oraz energii na własny rozwój

Rodzi to frustrację, przygnębienie, poczucie beznadziejności, chęć rzucenia tego gówna w cholerę, mniejsze przykładanie uwagi do jakości wykonywanej pracy oraz w skrajnych przypadkach depresję. Wyciska się z nas minimum 8 godzin dziennie przez 5 dni w tygodniu, oczekując, że przez cały ten czas będziemy klepać kod, dostarczać “ficzery” i łatać bugi.

Mało tego. Oczekuje się od nas, że będziemy to robić coraz szybciej i coraz lepiej. Nie dając nam przy tym potrzebnej przestrzeni na rozwój, który jest niezbędny do tego, aby podnosić swoją wydajność, skuteczność oraz efektywność. My chcemy się rozwijać, ale po 8-10 godzinach pisania kodu, po powrocie do domu, załatwieniu tego co trzeba załatwić w codziennym życiu najzwyczajniej w świecie się nie chce.

Człowiek jest zmęczony. A koło 30-tki to zmęczenie zaczyna się dość mocno nasilać. Nie ma więc siły na podłubanie we własnym projekcie czy wgryzienie się głębiej w jakiś techniczny temat. Poza tym od technologii też trzeba czasami odpocząć.

Praca przy projekcie którego główną działką jest utrzymanie, debugowanie i łatanie może prowadzić do zatrzymania rozwoju całego zespołu.

Powód?

Przy takich projektach zazwyczaj nie wymaga się poznawania “nowych rzeczy” tylko grzebania się w starych. A w godzinach pracy nikt nie pozwoli na szukanie najlepszych rozwiązań oraz poszerzanie wiedzy bo trzeba szybko załatać buga albo dowieźć ficzer tak, aby “działał”, a nie tak, aby rozwiązanie było optymalne.

Zdarzają się firmy i zespoły w których specyfika projektu wymaga poszerzenia wiedzy w godzinach pracy, aby dany projekt rozpocząć i w takim wypadku nie ma ucieczki od “przepalania czasu” na zdobywanie wiedzy. Z tym, że po jego rozpoczęciu zwykle się tej przestrzeni na rozwój już nie udostępnia bo przecież “coś tam jesteście w stanie dowieźć”.
Częściowym rozwiązaniem tego problemu mogłaby się wydawać funkcja lidera technicznego. I to prowadzi nas do kolejnego punktu…

Przeładowanie liderów technicznych

Techniczni liderzy są zbyt często bezsensownie przeładowywani pracą, która mogłaby zostać wykonana przez większość programistów. Ich zadaniem powinny być 2 rzeczy.

Pierwsza to ciągłe poszerzanie wiedzy na temat narzędzi nowych oraz głównie tych używanych już w firmie po to, aby wycisnąć z nich maksimum. Często mamy gotowe rozwiązania w języku albo frameworku, ale rzeźbimy coś na około bo nie wiemy, że mamy to pod ręką.

Druga to dystrybuowanie tej wiedzy w zespole w przystępnej formie. W ten sposób zapewniamy zespołowi dopływ nowej wiedzy nie obciążając poszczególnych jego członków szukaniem informacji, ich selekcjonowaniem oraz samodzielnym zgłębianiem tematu. Przy dzisiejszym zalewie informacji odsianie syfu i badziewia pochłania olbrzymie ilości czasu i energii. Takie rozwiązanie pozwala oddelegować to zadanie do jednej osoby, która będzie źródłem technologicznej esencji.

Brak świadomości pracodawców

Na temat tego, że programista wypoczęty i odpowiednio zmotywowany jest w stanie dowieźć więcej w ciągu 5 godzin niż pogrążony w beznadziejności przez 8-10 godzin. Świeży umysł jest bardziej spostrzegawczy, kreatywny, efektywniej łączy fakty i przyswaja nowe informacje. Do efektywnej pracy potrzebujemy maksymalnej koncentracji.

Wysoki poziom koncentracji jesteśmy w stanie osiągnąć w momencie, gdy zaspokojone są wszystkie nasze podstawowe potrzeby. Jedną z podstawowych potrzeb u wielu programistów jest potrzeba rozwoju. Rozwój natomiast wymaga czasu i energii. Niestety duża ich część jest marnowana na spędzanie 8 godzin w biurze oraz 1-2 godzin w samochodzie bądź komunikacji miejskiej na dojazdach do i z biura.

Może warto więc pomyśleć nad sześciogodzinnym dniem pracy połączonym z przynajmniej dwoma dniami pracy zdalnej?

Ego

To problem z trochę innej kategorii, który potrafi skutecznie zepsuć atmosferę w zespole. Bardzo interesujący jest fakt, że tak wielu programistów przekonanych jest o zajebistości własnej i zarazem o “chujowości” innych. Jeszcze śmieszniejsze jest to, że to przekonanie jest często odwrotnie proporcjonalne do posiadanego doświadczenia. Chociaż da się to pewnie wytłumaczyć efektem Krugera-Dunninga.

Jeżeli na kawie jest kilku członków zespołu to wyśmiewają oni i krytykują tych, których nie ma. Drwią z ich kodu, z ich pomysłów. Jeżeli zespół jest w komplecie to krytykuje on i wyśmiewa inne zespoły. Jeżeli ktoś popełni błąd wynikający z niewiedzy to mówi się o tym na standupie z wielką pretensją. Przeważnie mówi o tym “pan zajebisty” i mówi to w sposób sugerujący, że wszyscy powinni wiedzieć wszystko od urodzenia. A przynajmniej wszystko to, co wie “pan zajebisty”. Nie ma miejsca na niewiedzę.

Jeżeli na code review zwróci się uwagę na detal to natychmiast ma miejsce wielkie oburzenie, że jak to można się przypieprzać o takie pierdoły, że robisz to na złość, i że generalnie “gówno wiesz”. Zamiast pomóc i podzielić się wiedzą oraz doświadczeniem to mają miejsce wieczne podśmiechujki, drwiny i krytyka. Byle podpompować swoje błyszczące ego.

Ego, które utrudnia współpracę. Nie pozwala na poważne potraktowanie pomysłów innych oraz nie pozwala na spokojne przyjęcie krytyki pomysłów własnych. W zamian proponuję poświęcić tą energię na współpracę, na dociekanie jak my możemy pomóc innym, oraz jak inni mogą pomóc nam. Darujmy sobie narzekanie i pieprzenie przy kawie jacy to inni są słabi, a jacy my zajebiści. Że my zrobilibyśmy to najlepiej. Po prostu weźmy i zróbmy!

Na zakończenie

Warto zaznaczyć, że duża część tego posta opiera się na dwóch założeniach…

Mamy do czynienia z PRZYZWOITYMI programistami

Programistami, którzy docenią otrzymane możliwości i nie zmarnują ich na jakieś niepotrzebne pierdoły. Jednak znalezienie takich ludzi i zbudowanie z ich pomocą zaufanego zespołu to temat na odrębną dyskusję.

Z drugiej jednak strony zabieranie możliwości pracy zdalnej i czasu na rozwój z obawy przed nieprzyzwoitymi programistami sprawia, że tracą na tym ci przyzwoici.
Nieprzyzwoici i tak będą dymać pracodawców w ten czy inny sposób bez względu na to czy pracują 8 godzin w biurze czy 6 godzin w domu.
Natomiast przyzwoici i ambitni będą mieli trzy wyjścia.

Pierwsze to rezygnacja z ustawicznego i świadomego rozwoju.
Drugie to rozwój kosztem swoich hobby oraz czasu spędzanego z rodziną i przyjaciółmi.
Trzecie wyjście to zmiana pracy.

Niezbędne jest tutaj obustronne zaufanie.
Z łudzeniem się, że 8 godzinny pobyt w biurze przełoży się ograniczenie czasu spędzanego na blogach, facebookach, youtubach czy kawach to tak jak łudzenie się, że DRM zatrzyma piractwo. Ani to piractwa nie zatrzyma, ani nawet nie ograniczy w znaczącym stopniu. Natomiast bardzo skutecznie uprzykrzy korzystanie z cyfrowych treści uczciwym użytkownikom.

Przyzwoici skorzystają z otrzymanych możliwości zwiększając dystans w jakości dostarczanych rozwiązań pomiędzy tymi nieprzyzwoitymi. Natomiast zwiększenie tego dystansu pozwoli na łatwiejsze wyłapanie tego kto należy do której grupy i wyciągnięcie na podstawie tego konsekwencji.

Rozwój odbywa się w sposób strategiczny i ustrukturyzowany.

I tutaj pojawia się pole do popisu dla firm i osób specjalizujących się w szkoleniach. Z tym, że szkolenia są najczęściej krótkie, jednorazowe, oderwane od kontekstu firmy. Potrzeba kogoś, kto potrafi przygotować długofalowy program rozwoju kompetencji w danym zespole, który zakłada jego systematyczne realizowanie i uwzględnianie w planowaniu pracy zespołu.

Można też wspólnie ustalić jakiej wiedzy i jakich kompetencji brakuje w zespole. Następnie przygotować materiał i odpowiednio podzielić pomiędzy programistów. Po zgłębieniu tematu każdy byłby odpowiedzialny za dystrybucję tej wiedzy. Dodatkowym plusem takiego podejścia może być to, że skuteczne przekazanie wiedzy wymaga jej uprzedniego ustrukturyzowania oraz głębokiego zrozumienia więc zwiększa szanse na rzetelne podejście do tematu.

Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET i współorganizator konferencji Programistok. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook, YouTube.

21 Comments

  1. Podziękowania dla Pawła za ten post! Prawdopodobnie nie wpłynie on na tych małostkowych programistów ale każdy wchodzący (i nie tylko) do branży niech to przeczyta i postanowi sobie “będę przyzwoitym programistą”. Karma is a b*tch!

  2. Grzegorz on

    Bardzo interesujące spostrzeżenia, choć z niektórymi nie do końca bym się zgodził.

    Często problemem są szefowie, a właściwie właściciele firmy. Nawet jeżeli mają dobre pojęcie o programowaniu, to przeważnie mówią dużo o rozwoju, nowoczesności itp, ale to tylko puste frazesy. Realne działania sprowadzają się do tego, żeby w krótkim czasie dużo zarobić.

    Z jednej strony po to się zakłada firmę, żeby zarobić. Mądry człowiek jednak rozumie, że inwestowanie w rozwój jest kosztem tylko na początku, bo w perspektywie bilans strat i zysków jest dodatki. Kiedyś myślałem, że skoro ktoś założył firmę i widać, że powoli ją rozbudowuje, to pewnie to rozumie. Problem w tym, że inwestycje w koszty są bardziej widoczne, niż późniejsze teoretyczne zyski. W dodatku z wielkim zdziwieniem zauważyłem, że nie tylko kierownicy, ale również właściciele wielu firm często nie wybiegają w przyszłość poza bieżący i następny miesiąc.

    Jestem takim seniorem, o którym Paweł napisał w pierwszym akapicie. Mam grubo ponad 20 lat doświadczenia w zawodzie. Nie zjadłem wszystkich rozumów, ale pracowałem w kilku różnych firmach, w różnych projektach. Zdobyłem sporo doświadczenia. Sęk w tym, że wbrew pozorom, szefowie na ogół nie są tym zainteresowani. Dlaczego? Pewnie z przekonania, że skoro są szefami, to oni wiedzą najlepiej. Mam wśród swoich doświadczeń i takie, gdy deklarowałem, że mam w jakimś temacie duże, wieloletnie doświadczenie, ale szef postanowił to zrobić po swojemu.

    • Myślę że nie inwestuje się w rozwój młodych programistów bo rynek wygląda tak jak wygląda i pracodawca obawia się że za rok taki programista z nową wiedzą przeskoczy do konkurencji.

  3. ja bym dodał do tego problemy z kręgosłupem itp

    na swoim przykładzie mogę powiedzieć: dbajcie o to, żeby co jakiś czas wstać, zrobić kilka przysiadów, pompek lub przynajmniej iść na spacer. Przynajmniej 2-3 razy w tygodniu poświęćcie godzinę do półtorej na jakiś sport (np ja mogę polecić crossfit, niektórzy polecają kalistenikę) który wzmocni ogólnie mięśnie ciała a najlepiej te około kręgosłupa i nie dopuści do ich zastania. Do tego warto co jakiś czas odwiedzić fizjoterapeutę, żeby sprawdzić czy mięśnie nie zlepiają się od siedzenia

    samy siedzeniem prędzej czy później dopadnie Was ból kręgosłupa i programowanie przestanie sprawiać radość

    • Grzegorz on

      Generalnie warto dbać o zdrowie. W Internecie można znaleźć artykuły o ergonomii pracy przy komputerze. Na podstawie swojego wieloletniego doświadczenia mogę potwierdzić, że opłaca się stosować do tych zaleceń.

  4. Moim największym problemem w zawodzie (oprócz postrzegania mnie przez pryzmat tego, co mam w majtkach, a nie w głowie) jest presja społeczna na sukces. Jeśli nie zarabiasz 3k * liczba przepracowanych lat, toś frajer albo debil. Zewsząd leją się artykuły o zdesperowanych pracodawcach, którzy zgarniają pracowników zza wschodniej granicy, bo w Polsce niby brakuje XXX tysięcy ludzi – co jest totalnie sprzeczne ze standardami rekrutacji oraz samej pracy. Albo ten dowcip, że okres bezrobocia to był najtrudniejszy kwadrans w życiu programisty. Gdyby było tak różowo, to na rynku mielibyśmy jakąś elitę firm, do których świetni programiści naganiają innych świetnych programistów, oraz odpady, gdzie lądują programiści słabi, bo nikt normalny nie chce. A chyba nie mamy, skoro pojawiają się takie wypowiedzi.

    • Ehh… wiesz co, to się zmieni. Zawód się coraz bardziej otwiera. Coraz bardziej “powszechna” stanie się wiedza, że ten “programista 15k” istnieje, ale nie wszędzie i nie zawsze.
      Poza tym sukces to nie tylko zarobki.
      Robić swoje, olać opinie, nie porównywać się… i będzie dobrze!

    • Grzegorz on

      Jeżeli atmosfera w pracy jest niefajna, to warto zacząć rozglądać się za lepszym miejscem na spędzanie 1/3 życia.

      Dobrą atmosferę w pracy cenię sobie wyżej, niż wysokie zarobki.

  5. Czyli nie jestem osamotniony w moich poglądach! Podpisuję się rękami i nogami pod tym co Paweł napisał. Mało która firma jest świadoma tego, że inwestowanie w rozwój pracownika to budowanie lojalności tej osoby oraz budowanie wyspecjalizowanej kadry, która będzie produkować wysokiej jakości systemy.

    A czy już wspominałem, że to świetny artykuł? :)

  6. Maverick on

    Miałem przyjemność obserwować pewną młodą firmę deweloperską od środka przez ostatnich kilka lat. Tak 50+ dev’ów. Sam nie jestem dev’em. Oto moje obserwacje: Gdy managerowie w spółce przyjęli założenie, że mają do czynienia z “przyzwoitymi programistami” liczba produktywnych godzin ustawicznie malała, aż do wywołania sytuacji kryzysowej, że żaden projekt nie odnotowywał iteracyjnego przyrostu wartości produktu. Po prostu każdy miał “coś ważnego” do załatwienia poza pracą i dezorganizował pracę reszty zespołu. Natomiast po wprowadzeniu restrykcyjnej polityki rejestracji czasu pracy (niemal jak przy taśmie), atmosfera w firmie zjechała w dół, ale projekty zaczęły być “dowożone” w czasie, który był akceptowalny przez klientów. Ale w głowie mi się nie mieści, że w organizacji, która w porywach dochodziła do 100 dev’ów różnych technologii, nie było dostatecznej próbki “przyzwoitych programistów” potrafiących zrozumieć czym jest etos pracy? Coś źle z rekrutacją w tej firmie było? Rozmowy na spotkaniach i na korytarzach tego nie potwierdzały. Być może ludzie przed 30, tego nie rozumieją…

  7. Ja bym jeszcze dodał, że w branży pojawia się coraz więcej nie programistów, czyli ludzi z innym wykształceniem, którzy skuszeni dobrymi zarobkami przekwalifikowali się i często idą po najmniejszej linii oporu i robią tylko to co muszą i nagle w projekcie pojawia się wszechogarniająca bylejakość, że ręce opadają i nie ma siły z tym walczyć

Leave A Reply