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ć.
[wasze-historie name=”Paweł” url=”https://www.linkedin.com/in/pawelkorzeniewski/”]
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.
