7 najważniejszych sposobów na wykazanie się w nowym projekcie, o których nikt Ci nie powiedział
Długość wpisu: 12 min
Każdy chce się w jakiś sposób wykazać i wyróżnić.
Życie uczy nas, że aby się wykazać trzeba być silną i niezależną jednostką, która nie popełnia błędów.
W szkole, jesteśmy najlepiej oceniani za zrobienie zadań bezbłędnie.
Gdy na teście z angielskiego użyjesz słowa “disappear”, a pani chodziło o “vanish” to dostaniesz co najwyżej jedyneczkę w dzienniczku (true story).
Rodzice są z nas dumni, gdy przynosimy do domu piątki, a nie trójki, mimo że trójka mogła nas znacznie więcej nauczyć.
W social media każdy dzień naszego idola na insta story wygląda cudownie, mimo że jego życie może być aktualnie koszmarem. Koszmarów nikt Ci nie pokaże.
Wszelkiego rodzaju porażki są uznawane za przejaw słabości. Więc je ukrywamy, w obawie, że postawią nas w złym świetle.
Ludzie mają swoje problemy, czemu masz jeszcze zamęczać ich swoimi?
Gdy nam w życiu wychodzi i gdy inni widzą jak nam wychodzi (nawet jeśli to tylko iluzja), to automatycznie czujemy się lepiej.
Społeczeństwo i wychowanie programuje nas abyśmy działali w taki sposób. I w taki sposób potem funkcjonujemy także w zespołach programistycznych.
W ogłoszeniach o pracę ciągle widzę wzmianki o “rockstars”, “ninjas”, “champions” i innego tego typu gównach. Jakiś dziwny kult jednostki, który mąci w głowie.
Najlepiej podsumować to słowami wspaniałego Kevina Harta:
Bo praca programisty nie polega na kulcie wybitnych jednostek. To jest tylko romantyczna wizja z filmów o hakerach.
Pozwól, że powiem Ci jak jest naprawdę.
Jak jest naprawdę
👉 Po pierwsze, gdybyś był prawdziwym rockstar ninją to nikt by Cię nigdy nawet nie zobaczył. Tak działają ninje. Nie widać ich, widać tylko efekty ich działań.
👉 Po drugie, Twojego pracodawcę, klienta, lidera, PM-a, delivery managera, you name it, interesuje tylko i wyłącznie sukces projektu.
Jeśli dowozisz projekt i zarabiasz pieniądze, to możesz być dla nich nawet papieżem.
👉 Po trzecie, programowanie to praca zespołowa. Nawet jeśli pracujesz sam, to po drugiej stronie jest ktoś kto wrzuca Ci wymagania do zakodzenia.
Więc tak naprawdę, Twój zespół też gówno obchodzi, czy jesteś championem, rockstarem, papieżem, czy matką Teresą.
Interesujące jest to, jak szybko się wdrożysz, jak szybko będziesz w stanie pomóc dowozić nowe ficzery i jak szybko wszystkich odciążysz.
Więc jeśli chcesz, żeby Cię doceniono, jeśli chcesz się wykazać, to musisz sprawić, że Twój zespół odniesie sukces. Nawet swoim własnym kosztem.
Bo to nie chodzi o Ciebie. Możesz ponieść nawet sto porażek, ale jeśli doprowadzą one do tego, że projekt będzie sukcesem, to i Ty odniesiesz sukces.
A teraz powiem Ci jak to zrobić. Jak zaimponować.
1. Nie próbuj nikomu zaimponować
Coś, co śmieszy mnie za każdym razem, gdy to widzę.
Gdy student trafia do projektu, stara się zaimponować tym, ile nauczył się na studiach, albo samemu, w czasie wolnym.
Gdy medium dev trafia do projektu, stara się zaimponować tym, ile się nauczył w poprzednich projektach.
Gdy senior trafia do projektu, stara się zaimponować doświadczeniem, które zdobył przez lata pracy i próbuje udowodnić, że rozumie cały projekt po kilku godzinach od pierwszego zerknięcia w kod (z chęcią będzie wytykał też wszystkie “złe praktyki” i sugerował seniorskie poprawki).
Wiele osób działa w takim defaultowym trybie “imponowania”.
Z tej okazji, wybierz sobie wyrażenie, które bardziej do Ciebie przemawia:
1:
2:
Jeśli myślisz, że studia, technikum lub Twoje pet projekty na boku nauczyły Cię programować to jesteś w błędzie.
Programowania zespołowego nie nauczysz się samemu.
Najprawdopodobniej nigdy nie miałeś z nim styczności. Bo to czasem przypomina pole bitwy. Nie wystarczy, że kod działa. Nie wystarczy, że nie ma w nim ani jednego buga. Sam kod nie wystarczy. Kod to efekt uboczny pracy zespołowej i komunikacji.
Niespodzianka, programowanie to nie jest twardy, techniczny skill 🤷♂️.
Niekonieczine zaimponujesz tym, czego nauczyłeś się w poprzednim projekcie, bo każdy projekt jest inny.
Jasne, doświadczenie pomaga, ale ważniejsze od niego jest jak szybko jesteś w stanie dostosować się do nowych warunków.
Jeśli myślisz, że komuś zaimponujesz sugerując poprawki w pierwszych dniach pracy (bo “tego się tak nie robi”) to cofnij się kilka akapitów wyżej i ponownie wybierz wyrażenie, które bardziej Ci odpowiada.
Ty jeszcze nie wiesz przez jakie sytuacje musiał przejść zespół kodząc rozwiązanie.
Kodzik niezgodny z dobrymi praktykami mógł być zakodzony w taki sposób świadomie.
Może część kodu to spaghetti, bo miał to być tylko proof of concept, który jednak został w kodzie, bo nie było jeszcze czasu go przepisać, bo klient w tym czasie wrzucił do zrobienia szybkie fixy na ASAPie, bo do projektu doszli nowi stakeholderzy, którzy jak nie dostaną wymaganych ficzerów na czas, to zakręcą kurek z pieniędzmi i nie będzie miało wtedy znaczenia, czy mamy testy i ładny kodzik, bo projektu już nie będzie.
Poznaj historię projektu, dostosuj się do nowych warunków, miej otwarty umysł. Następny punkt Ci z tym pomoże.
Nie próbuj imponować. Ludzie sami zauważą.
2. Pytaj
Żeby poznać historię projektu, kontekst oraz wybory, które zostały dokonane, warto zadawać pytania.
Mega oczywiste nie? Jednak wiele osób woli siedzieć cicho 🤷♂️.
Gdy do projektu trafia nowa osoba i zaczyna zadawać trafne pytania, to dla zespołu oznacza to kilka ważnych rzeczy:
- jesteś samodzielny
- nie trzeba Cię pilnować jak małego dziecka, bo jak czegoś nie będziesz wiedział to zapytasz zamiast ogarniać samemu i tracić czas
- widać w jaki sposób myślisz, wiemy jak Ci pomóc w rozwoju
- jest szansa, że zauważysz ważne rzeczy, które wymagają poprawy
Pracując dłużej w projekcie przestajemy zauważać niektóre rzeczy. Czasem jest to coś oczywistego i wymagającego poprawy.
Nowa osoba może to zauważyć, bo ma jeszcze “świeże” spojrzenie.
Najlepiej zrobić to zadawniem dobrych pytań.
Stosuj “Dlaczego zostało to tak zrobione?”, zamiast “Tego się tak nie robi”.
Bardzo w ten sposób pomożesz. I zaimponujesz.
3. Proś o pomoc
Nie próbuj siedzieć cicho całymi dniami próbując rozgryźć rzeczy samemu.
Jest to często powiązane z pierwszym punktem - próbą zaimponowania i pokazania, że jest się samodzielnym.
Nie tędy droga. Tak samo jak z zadawaniem pytań, samodzielność oznacza, że przyjdziesz poprosić o pomoc, gdy zauważysz, że jakiś task schodzi Ci za długo.
Bardzo często, ale serio, bardzo, bardzo często, zdarza mi się, że ktoś siedzi nad jakimś problemem w pracy, utknął, nie ma pojęcia jak ruszyć od kilkudziesięciu minut, może od kilku godzin, i nie przyjdzie poprosić o pomoc.
A potem, gdy ja w końcu zapytam “z czym mogę pomóc, bo tak cicho siedzisz cały dzień”, to okazuje się, że jestem w stanie rozwiązać jego problem w 3 minuty.
I wiem, że każda osoba w zespole, którą by poprosił o pomoc też rozwiąże ten problem w 3 minuty.
W taki sposób, po raz kolejny dajesz sygnał, że jesteś niesamodzielnym, nieodpowiedzialnym i marnującym czas bobasem, którym cały zespół musi się opiekować.
Don’t be that guy:
4. Powiedz o swoich brakach
Gdy się na czymś nie znasz, to daj znać od razu.
Nikt od Ciebie nie wymaga, żebyś wiedział wszystko.
Daj znać nawet jeśli nie znasz podstaw, których od Ciebie wymagają. Do tego mega trudno się przyznać, bo zatrudnili Cię z nadzieją, że te podstawy znasz.
Ale im szybciej się przyznasz, tym lepiej dla wszystkich. Bo najprawdopodobniej idzie podciągnąć Twoje umiejętności bardzo szybko. Skoro Cię zatrudnili, to znaczy, że widzą w Tobie potencjał.
Pozwól innym ten potencjał wykorzystać, bądź szczery. Nie próbuj nadrabiać braków samemu, bo jest duża szansa, że nie wiesz czego nie wiesz.
Udawaniem daleko nie zajdziesz, trust me. Ja kiedyś często udawałem, że coś umiem lub rozumiem. A potem siedziałem nad taskiem dwa razy dłużej i cały czas się bałem czy robię wszystko dobrze. Stres lvl 100%.
Nikt nie był na tyle odważny, żeby mi powiedzieć, że gdy udajesz, to tak naprawdę widać, że nie rozumiesz.
Ja takich “udawaczy” nazywam iluzjonistami.
Iluzjonista to taka osoba, która potrafi bardzo pięknie udawać. Wszędzie jej pełno, dużo mówi, mało robi, głośno się zachowuje, ciągle prowadzi dyskusje na każdy temat i sprawia tym samym wrażenie eksperta.
Ci głupsi się nabiorą. Ci mądrzejsi też. Ale Ci drudzy w końcu się zorientują i przejrzą Cię na wylot.
Tylko pewny siebie człowiek potrafi przyznać się do fundamentalnych braków. Trzeba sobie wyhodować duże jaja. Niezależnie od płci. Pomożesz w ten sposób zespołowi i zaimponujesz - swoją otwartością.
Będzie Ci się też łatwiej żyło, bez stresu.
5. Popełniaj błędy i wyciągaj z nich wnioski
Gdy wyhodujesz już sobie te duże jaja to łatwiej będzie Ci popełniać błędy.
Coś od czego odzwyczaiła nas formalna edukacja.
Zobacz jak myślą ludzie sukcesu:
I haven’t failed — I’ve just found 10,000 that won’t work.
~Thomas Edison and the Invention of the Light Bulb
I’ve missed more than 9000 shots in my career. I’ve lost almost 300 games. 26 times, I’ve been trusted to take the game winning shot and missed. I’ve failed over and over and over again in my life. And that is why I succeed.
~Michael Jordan
The proactive approach to a mistake is to acknowledge it instantly, correct and learn from it.
~Stephen Covey
Even a mistake may turn out to be the one thing necessary to a worthwhile achievement.
~Henry Ford
W necie jest tego pełno.
Część osób myśli, że “popełniaj błędy” to tylko wyświechtana fraza, którą przechwalają się znani i bogaci.
Ale tak naprawdę, to tylko taka nasza słodka wymówka. Bo w głebi duszy i tak wiemy, że wolimy błędów nie popełniać i będziemy żyć tak żeby ich unikać.
Znani i bogaci są znani i bogaci, bo po prostu poznali wielką tajemnicę:
Popełnianie błędów i wyciąganie z nich wniosków jest najszybszą formą uczenia się. Jest to wspólny mianownik wszystkich tych cytatów.
Nic tak dobitnie nie pokaże Ci co możesz robić lepiej niż solidna porażka.
Gdy raz się porządnie wywalisz na pysk, to drugi raz tego samego błędu nie popełnisz. Wyciągniesz z niego lekcje, które będziesz pamiętał do końca swego życia.
Logicznie na to patrząc, każdy powinien wręcz oczekiwać błędów i ściągać je na siebie, bo zyski z ich popełniania się przeogromne.
Jeśli jednak chcesz zaimponować innym, to nie bój się popełniać błędów. Gdy Ci się noga podwinie, to wyciągnij wnioski, rozwiąż problemy i leć dalej.
6. Zapomnij na chwilę o kodzie
W pracy programisty nie chodzi tylko o kod.
Istnieje mnóstwo innych aktywności, w których uczestniczymy podczas tworzenia oprogramowania.
Większość z nich jest traktowana jako “dodatek”, odskocznia od “prawdziwej” pracy, czyli od kodzenia.
Nikt nie broni Ci zostać małpką od kodzenia. Ale jeśli chcesz być kimś więcej to skup się też na innych rzeczach, które są równie ważne.
Dowiedz się jak w Twoim projekcie wygląda proces. Scrum, Kanban, yolo? Dlaczego akurat to? Jakie modyfikacje wprowadziliśmy?
Kiedy są spotkania? Jak się do nich przygotować? Kto je prowadzi? Czy są jakieś problemy, z którymi możesz pomoć?
Przygotuj się do demo. Pomyśl co powiesz na dzisiejszym daily. Przygotuj się do retro.
Czy masz porządek na Jirze (czy czymkolwiek, czego używasz)? Jeśli nie, to zadbaj o niego. Jest to odpowiedzialność każdej osoby w zespole.
Doprecyzuj taski, popraw descriptiony.
Zrób kolegom CRki.
Zapytaj czy ktoś nie potrzebuje pomocy.
Pomyśl jak usprawnić komunikację z klientem.
Jeśli masz w zespole QA, BA to pogadaj z nimi (pamiętaj, oni też się cykają przyznać, że czegoś nie wiedzą, patrz punkt wyżej).
Poćwicz zadawnie dobrych pytań.
Poćwicz angielski.
Zaproponuj, że poprowadzisz jakieś spotkanie żeby poćwiczyć tę umiejętność.
Mógłbym tak jeszcze wymieniać i wymieniać.
Nie samym kodem człowiek żyje. Niestety część osób marzy tylko o tym, żeby zamieniać kawę w kod. Takich ludzi też czasem potrzeba.
Ale coraz mniej.
Ci, którzy umieją w tzw. skille miękkie są po prostu fajniejsi. Bardziej imponują.
7. Skup się na sukcesie zespołu, a nie na swoim własnym.
Jak już wspominałem we wstępie, nie liczy się sukces pojedynczych osób tylko całego zespłu.
Jeśli zespół odnosi sukces to i Ty odnosisz sukces.
Wyżej wymienione punkty bardzo Ci w tym pomogą.
Na koniec chcę zaadresować coś, o czym muszę cały czas przypominać sobie samemu.
Kojarzysz jak czasem w okolicach godziny 12:00 ktoś głośno oznajmia (albo pisze Ci na privie), że “już dwunasta, a ja jeszcze dzisiaj nic nie zrobiłem”? Często z grymasem na twarzy albo złością w głosie.
Pewnie Tobie też się zdarzyło.
Jeśli nie siedziałeś przez pół dnia na Facebooku, czy YouTubie, to są dwie możliwości:
- Albo masz problem z priorytetami,
- albo faktycznie coś ważnego dzisiaj zrobiłeś.
Z priorytetami pomogę Ci w innym poście. Teraz drugi punkt.
Bardzo często takie słowa można usłyszeć od osób, robią naprawdę ważne rzeczy. Pomagają ustawić komuś środowisko, wdrażają nową osobę do projektu. Uczestniczą w ważnych spotkaniach. Doprecyzowują zadania żebyśmy nie musieli przepisywać połowy systemu. I tak dalej.
W poprzednim punkcie wyjaśniłem, że nie samym kodem człowiek żyje. Więc czy naprawdę “nic jeszcze dzisiaj nie zrobiłeś”? Czy po prostu znowu zapomniałeś, że kod to nie wszystko?
Naucz się doceniać to, że pomagasz innym i że poświęcasz czas na coś innego niż zwykła małpka do kodzenia.
Wiadomo, trzeba znaleźć balans, ale gdy już go znajdziesz i przeznaczysz odpowiednio dużą ilość czasu na pomaganie innym, to przyczynisz się do sukcesu zespołu. Wnikliwe oko Twojego lidera to zauważy i mu zaimponujesz.
Podsumowanie
Wiele osób zaczynając pracę w projekcie chce się wykazać i robi to w nieodpowiedni sposób.
Przejawia nadmierną pewność siebie.
Czyni błędne założenia na temat projektu, bo nie zadaje odpowiednich pytań albo nie pyta w ogóle.
Próbuje rozwiązywać problemy samemu zamiast prosić o pomoc.
Zataja swoje braki, bo nie chce źle wypaść.
Boi się popełniać błędy, więc unika zadań, dzięki którym mógłby się szybko rozwinąć.
Skupia się za bardzo na kodzie, zamiast na tym co od kodu często jest ważniejsze.
Zapomina, że pomaganie innym to nie marnowanie czasu.
Uważam, że jest to spowodowane głównie wychowaniem i otoczeniem, które wpaja w nas takie zachowania.
Jest na to prosty lek. Wystarczy pamiętać, że programowanie to praca zespołowa. To nie indywidualne zwycięstwa są najważniejsze, tylko sukces zespołu oraz projektu.
Kultywowanie jednostek typu “rockstars” i “ninjas” praktykowane jest głównie w toksycznych środowiskach. W tych nietoksycznych mamy “rockstar team”, który skupia się na dowożeniu projektów. A potem świętuje razem sukcesy.
Jeśli schowasz ego do kieszeni, zostaniesz graczem zespołowym, przestaniesz się “wykazywać” i spinać dupę, to znacznie prędzej zaimponujesz swoim kolegom.
Praca w projekcie wygląda momentami jak walka w błocie.
Podczas takiej walki, nie chcesz wyglądać jak ten bobas:
Twoim zadaniem jest aby wyglądać tak:
Musisz sie umarasić. A te 7 punktów, które przedstawiłem, zdecydowanie Ci w tym pomogą.
🖖