Czas czytania: 7 min
Postanowiłem przeprowadzić z prezesem rozmowę. Pracowałem w firmie już ponad rok i robiłem tylko dobrą robotę (przynajmniej tak to wyglądało w mojej głowie). Podwyżka (i to konkretna) wydawała się sprawą formalną. Plan był taki. Wchodzę, rozmawiamy 15 minut i po temacie. Okazało się, że nie pójdzie tak różowo…
Rozmowa trwała 2 godziny. I była jedną z dwóch najważniejszych na mojej programistycznej drodze. O najważniejszej pisałem we wstępie artykułu 7 Umiejętności, które Znacząco Zwiększają Szanse na Awans.
Nie będę Cię okłamywał. Dostało mi się i to wielowątkowo! Wyciągnąłem z niej mnóstwo lekcji. Niektóre już na blogu były albo dopiero będą. Tym razem chcę się skupić na tym, do czego doszedłem samodzielnie po tej rozmowie.
Oczywiście bezpośrednio po rozmowie byłem oburzony. Jak to!? Jestem fasadą tej firmy. Jak tak można!? Niechaj szukają nowego pracownika, jak tacy są mądrzy! Refleksja, jak to zazwyczaj bywa, przyszła po kilku dniach…
Co ja tak właściwie zrobiłem podczas tego roku w firmie? Postanowiłem to spisać. Lista na szczęście składała się z kilku pozycji. Następnie zastanowiłem się, jaki był wynik tych prac, a więc czy:
- oddawałem solidny kod?
- klienci dostali rozwiązanie na czas?
- rozwiązanie było niezawodne (po polsku: nie posiadało zbyt wielu błędów)?
- utrzymanie i rozwój projektu sprawiało kłopoty?
Zauważyłem coś ciekawego. Moja praca, zarówno nad projektami, jak i pozycjonowaniem się w firmie była nierówna. I zacząłem rozumieć, co miał na myśli prezes. Niczym specjalnym się nie wyróżniałem. Po prostu dobry programista i tyle. A przychodzi czas, że to za mało!
Włączyło się we mnie z powrotem coś, czego nigdy nie powinienem wyłączać…
Upór
Zacznijmy od pytania do Ciebie. Zastanów się, nad najbardziej upartą osobą, jaka przychodzi Ci na myśl. Mamy to?
Pewnie wybór padł na kogoś, kto nie chce dać za wygraną podczas sporu, tak wierzy w swoje przekonania. Być może to ktoś z rodziny lub znajomy? Jestem pewny, że to dosyć uparta osoba, ale pozwól, że przedstawię moją listę:
- Arnold Schwarzenegger,
- Bill Gates,
- Orville i Wilbur Wrigth.
Nikt o zdrowych zmysłach nie pomyślałby, że to czego się podjęli jest wykonalne. Musieli się wykazać niesamowitym uporem. Każda z tych osób poniosła przynajmniej kilka porażek. Prawdopodobnie mierzyli się również z ciągłymi komentarzami i problemami, aby osiągnąć swój cel.
Dla nich nie było planu B. Nie było miejsca na rezygnację. Każde ich kolejne działanie zakończone sukcesem, czy porażką było wyłącznie drogą, z której uparcie nie chcieli zejść.
Oczywiście są to przykłady ekstremalne. Nam nie będzie potrzebny upór. Za to szczerze radzę pomyśleć nad jego siostrami: determinacji i dyscyplinie.
Dyscyplina
Nie ma znaczenia, jakiej używasz metodologii przy wytwarzaniu oprogramowania. Nie ma również znaczenia, jakie są ustalenia i dobre praktyki pisania kodu, jakie są Ci bliskie.
Dyscyplina:
- sprawia, że piszemy kod, który jest czysty i łatwo go utrzymać,
- powoduje, że zaczynamy od testów jednostkowych zanim zabierzemy się za zaprogramowanie konkretnej logiki biznesowej (TDD),
- nie pozwala nam zatopić się w odmętach perfekcjonizmu przed dostarczeniem działającego rozwiązania,
- sprawia, że kod jest udokumentowany w sposób, który jest użyteczny dla “przyszłych pokoleń”.
Dyscyplina to wybór pomiędzy tym czego chcesz teraz, a tym czego chcesz najbardziej
Abraham Lincoln
Co miał na myśli Pan prezydent? Według mnie mówił, że dyscyplina pomaga nam wybierać codziennie drogę, która przybliża nas do tego co chcemy najbardziej. Tylko ona trzyma nas w ryzach i pozwala pokonać opór przed trudniejszą drogą.
Dobrym przykładem są systemy kontroli wersji, na czele z wszechobecnym GIT’em.
Są zespoły, które sporo czasu poświęcają na łączenie swoich bujnych drzew kodu w jedną, spójną, działającą gałąź. Jednym słowem oddają się merge’owaniu.
Inne zespoły, z jakiegoś powodu nie mają takich problemów. Wydaje się, że prawie nigdy nie trzeba nic merge’ować, a gdy już się to wydarzy, to trwa to kilka minut.
Czym się różnią te zespoły? Wyłącznie dyscypliną. Posiadają zasady prowadzenia drzewa projektu. Nie pozwalają sobie na odstępstwa. Są konsekwentni. Nie szukają wymówek, o które tak łatwo gdy chce się “obejść system”. Który zespół na dłuższą metę ma więcej roboty?
Dyscyplina, a może motywacja?
Mam dla Ciebie sekret. Być może będziesz w szoku, bo wydaje się, że jedyne co nas otacza, to motywacyjne treści. Tylko, jak zawsze, proszę Cię! Nie mów nikomu!
Motywacja nie jest Ci do niczego potrzebna! Wystarczy, że będziesz konsekwentnie robić to co jest w tym momencie do zrobienia. Brzmi to jak dyscyplina, nieprawdaż?
Motywacja może być przydatna (nie niezbędna), aby ruszyć z miejsca. To znaczy na zrobienie pierwszego kroku. Długofalowe efekty przyniesie sukcesywne dążenie do celu. To zapewni wyłącznie dyscyplina.
Sam zmagałem się z tematem motywacji przez dłuższy czas, ale chyba udało mi się uciec z jej szponów. Jeżeli chcesz poczytać więcej, skąd u mnie taka twarda opinia na ten temat to daj znać pod artykułem 🙂
Code review
Jest to praktyka (przynajmniej mam nadzieję) gęsto stosowana, stąd nie będę się rozwodził nad każdym aspektem dobrego code review.
Zastanówmy się wspólnie tylko nad jednym pytaniem. Jaka jest główna zaleta tego, że dwie osoby siadają i ponownie rozważają ten sam kod?
Aby znaleźć błędy w kodzie i w rozumowaniu oczywiście! Tak. To jest przydatne, ale według mnie jest jeszcze coś o czym często zapominamy.
To potężne narzędzie powinno być stosowane również, aby utrzymywać zespołową dyscyplinę pod kątem reguł, jakie są ustalone w zespole. Być może kolega lub koleżanka postanowiła pójść na skróty albo uznała, że teraz nie ma czasu, aby to było zrobione porządnie. “Gdybym tylko miał/-a więcej czasu, to bym to zrobił/-a lepiej…”
Za tym twierdzeniem kryje się coś niepokojącego. Jeżeli osoba, która je wypowiada wie, jak coś powinno być zrobione, aby było lepiej, to dlaczego tego nie zrobiła? Z braku czasu? Z mojego doświadczenia wynika, że to wyłączenie wymówka. Jeżeli chcesz to sprawdzić, to zapytaj co konkretnie można poprawić, gdy będzie więcej czasu. Zazwyczaj odpowiedzi są niesatysfakcjonujące.
Pamiętajmy, że naszym obowiązkiem jest zwracanie uwagi, gdy standardy pisania kodu są naruszane. Niech to nawet będzie nazewnictwo czy konwencja notacji. Czasami stosunkowo niewielkie zmiany wprowadzają niespodziewany problem lawinowy.
Dyscyplina pozwoli zarówno nam pisać kod wysokiej jakości pomimo, że czasami nam się nie chce. Pomoże nam też podczas code review zdyscyplinować innych członków zespołu.
Nie szukaj dziury w całym
To też wymaga sporej dyscypliny. Myślę, że od czasu do czasu trafia Ci się od przełożonego polecenie, z którym się nie zgadzasz. To normalne. W takim przypadku najlepsze co możemy zrobić to skonfrontować nasze przemyślenia ze zlecającym, a najgorsze – zrobić po swojemu. Chwila, dlaczego najgorsze?
Nie zawsze jest czas, aby wszystko dokładnie wyjaśnić. Pozostaje nam zaufanie, że autor prośby wiedział coś o czym my nie wiemy. Widziałem to setki razy. “To było nadmiarowe. Zobacz jak to elegancko uprościłem.” Bez znajomości kolejnego kroku w implementacji to uproszczenie okazuje się po prostu błędną implementacją. Być może ta klasa była celowo rozszerzalna, a jej zamknięcie było błędem? Kto zapłaci za te opóźniania?
Nie zrozum mnie źle. Jeżeli coś wydaje się bez sensu to należy to konsultować. Być może masz rację! Wtedy dwa punkty dla Ciebie. Warto jednak pamiętać, że może się za tym kryć coś innego.
Potrzeba dużo wewnętrznej dyscypliny, aby trzymać się w ryzach. Lubimy się postrzegać (programiści) jako najmądrzejsi “w pokoju”. I być może często tak jest, ale nie jesteśmy wszechwiedzący. Warto o tym pamiętać!
Rozwój i dyscyplina
Jeżeli chcemy stać się ekspertem w naszej specjalizacji potrzebujemy się skupić nad rozwojem konkretnych umiejętności.
W obecnych czasach nowy framework wychodzi raz na tydzień. Każdy z nich (przynajmniej na papierze) jest rewolucyjnym podejściem. Nawet “oklepane” rozwiązania i języki zmieniają się w zawrotnym tempie. Niech za przykład posłuży nam poczciwy Angular, którego nowa wersja wychodzi średnio raz na pół roku. To nie żart. Na ten moment mamy już wersję 10!
Potrzeba dużej dyscypliny, aby pamiętać o swoim pomyślę na siebie i rozwijać swoje umiejętności w odpowiedni sposób.
Programista T-shape
W klasycznym rozumieniu chodzi o to, aby posiadać jedną umiejętność bazową na poziomie eksperckim (noga litery T) oraz umiejętności wspomagające na poziomie pozwalającym swobodnie się w nich poruszać (daszek litery T). Przybliżając temat do świata programistycznego, chodzi o osobę, która jest ekspertem w pisaniu aplikacji w React, która zna również zagadnienia związane z bazami danych, potrafi zbudować API oraz porozmawiać z klientem na temat funkcjonalności.
Zawsze powinniśmy budować na solidnej “nodze”. Trenuj dyscyplinę, która pomoże Ci zauważać, kiedy zamiast (czasami monotonnie) wzmacniać swoją główną umiejętność, ciągnie Cię w inne technologie. Na pierwszy rzut oka są sexy i trendy. Ich znajomość nie zaszkodzi! Niechaj nie przysłonią Ci jednak Twojego głównego celu. Potem niech dyscyplina pomoże Ci zbudować wokół niej inne umiejętności, które będą ją uzupełniały i stworzą taran do zamykania projektów.
Zasada powtórzeń
Gdy już wiemy, że dyscyplina jest ważna, to teraz warto wiedzieć jak ją trenować. Uważam, że wszystko (no prawie oczywiście) jest do ogarnięcia. Odkładamy wymówki na bok i wsłuchujemy się w głos byłego gubernatora Kalifornii:
Czymkolwiek się zajmujesz, wszystko sprowadza się do powtórzeń, albo do przebiegu. […] Jeżeli powtarzałeś, możesz bez obaw czekać na chwilę, gdy kamera pójdzie w ruch.
Arnold Schwarzenegger, “Pamięć absolutna”
Wiem jak to brzmi, ale to na prawdę działa.
Trzeba zacząć. Najlepiej z impetem. Następnie regularnie to robić, aż w miejsce impetu wejdzie zaangażowanie. Pierwsze wyniki powinny zapieczętować dyscyplinę. To trenowanie nawyków. Uważa się, że potrzeba od 50 do 100 dni, aby wyrobić sobie nawyk. Obawiam się, że nie ma drogi na skróty.
Czy czegoś Ci to nie przypomina? Przecież to kata wg Wujka Boba.
Dla niewtajemniczonych kata Wujka Boba to zestaw prostych zadań programistycznych, które wujek rekomenduje pisać codziennie, aby stały się dla programisty całkowicie automatyczne. Zazwyczaj jest jakiś algorytm lub znane i oklepane zagadnienie.
Rób to tak długo, aż przestaniesz o tym myśleć. Aż wejdzie Ci to w krew. Do momentu, gdy nie będziesz potrafić zrobić tego inaczej.
Odpowiedni zespół
Łatwo się pisze o idealnym świecie, ale taki on nie jest. Sam siebie zdyscyplinujesz. Nie próbuj z innymi dopóki nie ogarniesz siebie!
Bo zmiany trzeba zacząć od siebie i na sobie poprzestać.
Jacek Walkiewicz
Proszę Cię pamiętaj o słowach Pana Jacka. Wypowiedział je w jednej z moich ulubionych mów, która możesz w całości przesłuchać tutaj: Pełna moc możliwości.
Jak już sam masz w sobie dyscyplinę, szerz ją w zespole. Nie na zasadzie próby zmieniania innych. Świeć przykładem. Ty bądź osobą, która przypomina o ustalonej dyscyplinie. Twoje wyniki powinny być dla innych wystarczającym bodźcem do zmiany. W końcu wyłącznie Twoje starania w dużym projekcie na nic się zdadzą.
Jak kierujesz – dobieraj odpowiednich pracowników. Nie jest to tak proste, jak to napisać. Być może nad tym tematem też się pochylimy, w którymś z artykułów.
Podsumowanie
Nic tak nie przyspieszy Twojej drogi na programistyczne (oraz inne) wyżyny niż stara, dobra dyscyplina.
Zamień się w Arnolda i codziennie powtarzaj:
- dobrej jakości kod,
- solidne rozwiązania,
- dobre praktyki pisania oprogramowania,
- odpowiedni rozwój swoich umiejętności.
Nie będzie to na początku ani łatwe, ani przyjemne. Obiecuję Ci jednak, że z czasem będzie łatwiej, a rezultaty przejdą Twoje najśmielsze wyobrażania. I tego Ci życzę!
Jeżeli temat wydał Ci się ciekawy i chciałbyś o nim podyskutować nie krępuj się! Zostaw komentarz lub napisz do mnie poprzez formularz kontaktowy. Zawsze odpisuję!
Nie zapomnij pobrać dokumentu i zapisać się na newsletter. W ten sposób nie ominie Cię kolejny ciekawy artykuł.