9 problemów Junior Developera

Po wielu latach wyrzeczeń, nauki, odcięcia się od ludzi, nareszcie jakaś firma postanowiła Cię zatrudnić. Dostałeś swoją szansę na rozwój w branży mlekiem i pieniędzmi płynącej i nie możesz doczekać się tego pierwszego dnia, kiedy wejdziesz cały na biało rozpoczynając misję zbawienia i naprawienia ludzkości. I... 

Zacznijmy od tego, że ten tekst powyżej i poniżej nie jest żadną wyrocznią, ani wynikiem wieloletnich badań. Opieram się na doświadczeniu własnym i wielu osób, z którymi rozmawiałem na temat branży, zarówno ludzi początkujących, jak i tych z wieloletnim stażem. Twoje odczucia mogą być zupełnie różne od moich i nie jest to nic złego. To krótka ściąga tego, z czym prawdopodobnie prędzej czy później się spotkasz. Jeśli nie u siebie, to u osób z którymi będziesz współpracował.

Popełnisz dużo błędów. I dobrze 

Istnieje powiedzenie „nie myli się ten, co nic nie robi”, w różnych jego odmianach. Nie znam żadnego bezbłędnego programisty i nawet uważam, że on po prostu nie istnieje. Pracując i mając przed sobą do wykonania coś bardziej skomplikowanego niż prosty „if”, czy zwyczajną pętlę, prawdopodobnie Twój pierwszy napisany kod nie będzie najlepszy. Umiejętność usuwania własnego kodu, nawet tuż po jego napisaniu, jest bardzo istotna. 

Rozpoczynając karierę, nikt nie powinien oczekiwać od Ciebie tego, że pierwsze napisane rozwiązania będą tymi dobrymi i od razu pójdą na produkcję. To już jest często praktyka wewnętrzna danej firmy, lecz w niektórych przez pierwszy miesiąc lub dłużej, nie będziesz miał w ogóle dostępu do produkcyjnego kodu najważniejszego produktu, a jedynie będziesz pomagał i uczył się na wewnętrznych narzędziach, czy pobocznych projektach. Jest oczywiście też możliwość, że zostaniesz rzucony od razu na głęboką wodę, lecz wtedy sprawdzenie Twojego kodu powinno być dużo bardziej skrupulatnie przeprowadzone przez resztę zespołu. 

Zazwyczaj firmy, jak i osoby z zespołu, wymagają podstawowej rzeczy przy zrobieniu błędu: po prostu go nie ukrywać. Dużo lepiej dla wszystkich będzie, gdy sam podejdziesz i powiesz, że te trzy linijki, które właśnie dopisałeś do projektu mogą spowodować „apokalipsę i załamanie światowej gospodarki”. Dopiero mając więcej doświadczenia, wymagania odnośnie bezbłędności będą wyższe.

Będziesz zadawać za dużo i za mało pytań 

Wbrew pozorom, problem z wyczuciem, kiedy zadać pytanie, nie jest domeną tylko osób startujących w branży, lecz potrafi przewijać się bardzo długo, jeśli ktoś nie ma wyrobionych odpowiednich nawyków. Tutaj najbezpieczniejszą zasadą, będzie dostosować się do reszty zespołu. Każda firma może zupełnie inaczej podchodzić do kwestii czasu i jakości rozwiązania danego problemu. Ciężko znaleźć złoty środek pomiędzy tym, kiedy pytać na tyle często, aby nie wkurzać innych odrywaniem ich od własnych problemów, a nie stać za długo z własną pracą. 

Pomijając to, że czas przeznaczony na przygotowanie się do danego zadania przed jego rozpoczęciem może trwać i 10 minut, i tydzień, bo wszystko zależy od jego złożoności. Sam staram się przyjmować zasadę mniej więcej 30 minut. Jeśli przez ten czas skacząc od dokumentacji, przez StackOverflow i tego typu strony, nie uda mi się przejść o krok do przodu, zazwyczaj decyduję się zapytać osoby lepiej obeznanej w temacie, aby wskazała mi dobry kierunek. Na razie się sprawdza, bo nie widzę żądzy mordu ani u współpracowników, kiedy do nich podchodzę, ani w oczach osoby zarządzającej projektami, kiedy kontroluje czas moich zadań. 

Najlepiej w tym przypadku słuchać współpracowników i przełożonych. To też nie jest na „dzień dobry” wymagane, ale kiedy po zwróceniu uwagi na przesadzanie w którąś stronę wielokrotnie to zignorujesz, raczej nie będziesz cenioną osobą. 

Mając dłuższy staż, trzeba także pamiętać, jak samemu się zaczynało. Inni ludzie zazwyczaj zaczynają zadawać pytania dużo szybciej, niż można się tego na początku spodziewać. Wtedy nie irytuj się, tylko przypomnij sobie, że byłeś w tym miejscu.

Nie docenisz i przecenisz pracowników z większych stażem 

Podstawowym założeniem poziomowania pracowników na juniorów, seniorów i różne tego typu warianty, jest określenia poziomu ich wiedzy. Czy to ogólnoprogramistycznej, czy także tej bardziej szczegółowej w danym projekcie. Według tego podziału, patrząc na kod osoby „starszej” od nas, powinniśmy od razu przyjąć go jako napisanego dobrze, bo przecież z założenia pisze lepiej. To jednak błędne założenie, na bardzo wielu płaszczyznach.

Mimo to, patrząc na kod seniora z wieloletnim doświadczeniem, czasami możemy mieć myśli samobójcze i wątpić w sens dalszego rozwoju w tej branży. No bo jak osoba, która pisze dłużej niż ja żyję, jest w stanie napisać takie barachło, a co gorsza jeszcze podpisać się pod tym nazwiskiem. 

Tragiczny kod powstaje, powstawał i będzie powstawać, także napisany przez nas. Dlaczego? Można np. wymienić ograniczenia czasowe danego projektu (które potem zwracamy, walcząc z tzw. długiem technologicznym). Może się zdarzyć, że senior który stworzył funkcje, o której nie chciałby, aby ktokolwiek się dowiedział, napisał ją mając zły dzień, będąc pod dużą presją czasu lub po prostu nie potrafił jej napisać lepiej. Nikt nie jest specjalistą od wszystkiego i czytając cudzy kod, musimy mieć to na uwadze.

To, że ktoś pracuje w branży 8 lat, a Ty pracujesz 3 dni, nie oznacza, że nie możesz znaleźć błędu w jego kodzie. Oczywiście wtedy nie bierzesz ze sobą zestawu petard i nie rozgłaszasz na prawo i lewo, że taka osoba powinna być odsunięta od projektu i wysłana na przymusowe szkolenie. Może być też tak, że nie rozumiesz tego, na co patrzysz.

W większości przypadków, kiedy skonsultujesz ten fragment z autorem, może Ci przyznać rację, albo wyjaśnić, dlaczego tej racji nie posiadasz. W takiej sytuacji zakładam, że osoba jest otwarta na konstruktywną krytykę i rozwój, co jest raczej częstą sytuacją. Jest też możliwość, że faktycznie ten kod jest tragiczny, ale przecież żaden junior nie będzie mówił, jak należy pisać. Takich seniorów raczej należy jak najbardziej unikać, kod utylizować i robić wszystko, aby nie być zmuszonym do współpracy z nimi. 

Podstawą przyjemnej pracy jest balans pomiędzy respektowaniem wiedzy zdobywanej przez lata, a tą świeżo odkrytą. Czasami z pozoru dziwne rozwiązania mają tak naprawdę konkretny sens. Aczkolwiek, jeśli trzeba się go mocno doszukiwać, to może coś jest jednak nie tak.

Dlatego też, nie ma co się dziwić, że nikt nie chce wprowadzać do projektu jakiegoś cudownego frameworka, który rozwiązałby wszelakie problemy, ale jest wykorzystywany tylko przez trzy osoby na świecie. Pamiętajmy, że rozwiązanie genialnie wyglądające na papierze, nie musi podobnie działać w realnym świecie.

Nie można także pozwolić na sytuacje, kiedy Twoje rozwiązanie jest złe, dlatego że jesteś nowy. To na szczęście rzadka sytuacja, ale jak w każdym zawodzie, osoby postawione wyżej mogą próbować podcinać skrzydła potencjalnym przyszłym konkurentom. Skoro coś zostało przez Ciebie napisane, zrobiłeś to z jakiegoś powodu i warto byłoby zawalczyć o wytłumaczenia osoby odrzucającej to rozwiązanie.

Będziesz forsować genialne i głupie rozwiązania

Tu rozwinę częściowo dwa poprzednie akapity. Rozwiązanie z perfekcyjną dokumentacją, którego używa się w firmie, nie zawsze jest lekiem na całe zło. Należy cieszyć się, że cały czas powstają nowe pomysły i na bieżąco śledzić ich rozwój. Głównym celem firm jest zarabianie, a nie bycie polem minowym dla nieprzetestowanych rozwiązań. Nie jest powiedziane, że nikt nie myślał o użyciu czegoś nowego. Po prostu może się okazać, że zyski płynące z nowej technologii, mogą być niewymierne do poświęconej pracy na jej wprowadzenie. 

Pomysł, który w naszej głowie klaruje się jako coś świetnego, może okazać się dla firmy niewarty uwagi. Prawdopodobnie każdy prędzej czy później natrafi na taką sytuację. Przynajmniej na początku kariery, bardzo często nie posiadamy odpowiedniej wiedzy o całej złożoności projektu, nad którym pracujemy. Przywołując analogię do samochodu, może się okazać, że nasz genialny algorytm poprawiający o 80% wydajność wycieraczek, powoduje problemy z kierunkowskazem. 

Większość dużych firm posiada projekty, nad którymi przez wiele lat pracuje wiele osób. Każda z nich, zazwyczaj z dobrymi intencjami, ma swój plan na rozwój aplikacji i kierunek rozwoju kodu. Łącząc 20 genialnych planów, zazwyczaj dostajemy jeden tragiczny. Wprowadzając nowe rozwiązania do kodu, możemy mieć czasami świetny pomysł, który zadziała w wielu przypadkach i jesteśmy przekonani, że to jest coś, na czym powinny wzorować się przyszłe pokolenia, ale w ostatecznym rozrachunku dla danego projektu może to być po prostu złe. 

Wracając, do przewijającego się „to zależy”, możemy mieć dobry pomysł, lecz jest on blokowany przez różne zębatki, lepiej lub gorzej działającej firmowej maszyny. Ten balans, który musimy zachować, jest bardzo trudny do nauczenia się od razu. Siadając do pisania kodu, powinniśmy zakładać, że stworzymy go jak najlepiej, ale jednocześnie pamiętać też o tym, że może wyjść coś, o czym chcielibyśmy jak najszybciej zapomnieć.

Będziesz pracował za dużo i za mało

Zazwyczaj wchodząc do pracy wiesz, że przez kolejne 8 godzin spędzisz w tym budynku, lub jego bliskich okolicach. Tylko niekoniecznie to oznacza taki sam czas spędzony na dodawaniu kolejnych linijek do projektu. Oczywiście nie mówię tutaj o legendach, które potrafią krążyć o tej branży, czyli: dzień rozpoczęty od kawy, sprawdzenia paru stron w internecie, a przez pozostały czas spędzony na graniu na konsoli czy meczach w piłkarzyki. Nie zapominając oczywiście o owocach zjedzonych w czwartek. 

Nie spotkałem się jeszcze z nikim w tej branży, kto by wymagał 8 godzin tylko i wyłącznie pisania kodu, ani nie spotkałem nikogo z takim wymogiem. Dość powszechną wiedzą jest to, że fizycznie nie da się pracować tyle bez ustanku, dodając linijkę za linijką. Zresztą, tak czy inaczej po intensywnej pracy umysłowej przez parę godzin, po pewnym czasie mózg będzie się po prostu wyłączał. Jeśli taki stan trwałby parę dni, z każdym kolejnym nasza wydajność by spadała coraz szybciej i wcześniej. 

Umiejętność odpoczynku i spojrzenia na problem i swój kod „na świeżo” jest równie ważna, jak jego stworzenie. Nikt nie powinien się Ciebie czepiać, jeśli poświęcisz 5 czy 10 minut na przeczytanie interesującego Cię artykułu czy filmu na YT, bo to nie jest czas stracony dla firmy, a zainwestowany w Twoją wydajność. 

Oczywiście dochodzimy teraz do drugiej ściany. Nie raz można się spotkać z tym, że po pewnym czasie, osoba która rozpoczęła pracę, poczuła ten luz, wie i widzi na monitorach innych coś innego niż IDE czy dokumentacja i będzie przeginała w drugą stronę. Zdarza się to w różnym czasie, a u niektórych nigdy nie występuje, lecz nie można o tym zapominać. Kiedy przestaniesz dostarczać swoje zadania na czas lub zawsze na styk, pomimo wielokilometrowych wycieczek po firmie, czy nieskończonych plotkach przy ekspresie do kawy, może to zostać dość mało subtelnie zauważone. 

To że Twój team leader, product owner czy prezes firmy nie zwraca Ci uwagi na oglądanie kolejnego odcinka serialu na Twoim monitorze, nie oznacza że coś takiego jest niewidoczne. Zazwyczaj jest bardziej widoczne niż ściągnie za czasów szkolnych. Lecz niewątpliwą zaletą tej branży, w większości przypadków oczywiście, jest to, że będąc uczciwym wobec innych, inni będą uczciwi wobec Ciebie. Nie jesteśmy robotami i nikt nie lubi być kontrolowany przez cały czas pracy i szczególnie w pracy umysłowej być karcony za każdym razem, kiedy spojrzy gdzieś poza powstający kod. W zamian za to, powinniśmy być także fair wobec osób, które nam taki luz dały. 

Chcąc czy nie chcą, praca programistów jest dużo bardziej zespołowa, niż jest to przekazywane w serialach. Nie siedzimy samotnie w pokoju bez okien, a jedynym naszym gościem jest zabłąkany szczur. I każde zadanie, które miało być przypisane do nas, ale z jakiegoś powodu nie wyrobimy się z nim, będzie musiał poprawiać ktoś po nas. A raczej nikt, kto będzie musiał sprzątać bałagan narobiony przez nasze lenistwo, nie będzie zbyt skory, aby w przyszłości robić to z własnej woli.

Będziesz pisał świetny kod dla siebie i tragicznych dla innych

Jedną z podstawowych książek, którą powinna znać każda osoba aspirująca na programistę, jest „Czysty Kod” Roberta C. Martina. W jednym z pierwszych rozdziałów swojej książki mówi o tym, że po pierwsze, nie piszemy kodu dla siebie, a większość pracy spędzimy na czytaniu cudzego, a nie pisaniu własnego. To dość ważna zależność, o której czasami zapominają nawet osoby z wieloletnim doświadczeniem. 

Niektórzy są w stanie pokusić się o stwierdzenie, że aktualnie czytelność kodu jest ważniejsza, niż jego wydajność, szczególnie przy mocy obliczeniowej urządzeń, na których zazwyczaj jest odpalany program, nad którym pracujemy. Na nic nam super wydajny kod, który będzie zrozumiany tylko przez jego autora i to przez pierwszy tydzień po napisaniu. 

Aktualnie coraz trudniej znaleźć projekt, nad którym będziemy pracować tylko i wyłącznie sami, bez wkładu innych osób. A podstawą dobrej współpracy jest zrozumienie się nawzajem. Będąc kierowcą rajdowym, na nic by nam był najlepszy pilot, jeśli mówiłby do nas w starożytnym dialekcie z rodziny języków indyjskich, mimo że sam byłby najlepszym profesjonalistą w fachu. 

Bardzo wiele osób, rozpoczynając swoja karierę, doznaje czegoś, co w teorii zwie się „Efektem Krugera-Dunninga”. W skrócie, nasza pewność siebie jest zupełnie nieadekwatna do posiadanych przez nas umiejętności. Kod, który nam będzie wydawał się genialny, ponieważ przecież skorzystaliśmy naraz z siedmiu wzorców projektowych i zaoszczędziliśmy 37kb ramu, może być uznany za tragiczny. Nie ze względu na jakość, a czytelność. Poświęcając dodatkowe 10 minut na dane zadanie pod koniec, jesteśmy w stanie bardzo ułatwić życie innym i sobie w przyszłości, chociażby przez rozbicie funkcji na mniejsze i zmianę nazw zmiennych. 

Praktycznie każdy zespół ma swoje wewnętrzne zasady, mniej lub bardziej sensowne i zrozumiałe na początku. Nawet jeśli jakaś zasada wydaje się bezsensowna, a na jej miejsce mamy coś lepszego, nie warto forsować takiego rozwiązania przez kod. Jest to dobry przekaźnik informacji, które chcemy zademonstrować, dlaczego pisanie w taki sposób jest lepsze, lecz musi być to skorelowane z rozmową z zresztą zespołu.

Będziesz przeklinać i doceniać code review

Glen Lipka na swoim blogu commadot.com opublikował bardzo popularną grafikę obrazującą znacznik jakości kodu jako „WTFs/second” (która w oryginale została stworzona przez Thoma Holwerda). Jest to chyba najlepsze przedstawienie tego, jak faktycznie można sprawdzić, czy to, co napisaliśmy, jest dobre, czy złe. Kiedy będziemy mieli okazję przeprowadzić code review po raz pierwszy, zobaczymy jak często rozwiązania stworzone przez kogoś innego potrafią nas zaskakiwać pozytywnie i negatywnie oraz ile razy w głowie pojawi się „WTF”. 

Dając nasz kod do pierwszego sprawdzenia, prawdopodobnie zostanie on odrzucony. I tutaj nie chodzi o to, że dodane linijki, czy rozwiązanie proponowane przez Ciebie jest złe. Biorąc pod uwagę "raczkowanie", takie aspekty są jak najbardziej możliwe. Kluczową kwestią jest dopasowanie się do zespołu. Nazywanie zmiennych, kolejność dodawania stałych elementów w klasie (przykładowo zmienne prywatne, publiczne, delegaty itp.), a także wiele innych - na pewno istnieją takie zasady. Jest to rzecz która wchodzi do krwi po czasie, jeśli code review jest dobrze przeprowadzane. 

Jeśli trafisz do firmy, gdzie nie ma praktyki sprawdzania sobie nawzajem kodu, warto porozmawiać o możliwości wprowadzenia tego. Dużo lepiej coś wyjaśnić, lub poprawić przed dodaniem kolejnego elementu na produkcje, niż przeszukiwać system kontroli wersji w poszukiwaniu „winnego” i dopytywanie się, co autor miał na myśli. Szczególnie, że taka osoba może już dawno nie pracować, a Ty przed sobą będziesz mieć rozwiązanie, bardziej na poziomie filozoficznym, niż programistycznym. 

Kiedy już nastanie ten czas, że usiądziesz do pierwszego sprawdzenia z Twojej strony, musisz pamiętać o tym, że nie zawsze rozwiązanie którego nie rozumiesz, jest złe. Powinniśmy pamiętać, że tworzymy kod dla innych, nie dla siebie i jego prostota w odbiorze jest bardzo ważna. Mimo to, pewne bardziej zaawansowane rozwiązania, mogą być dla Ciebie kompletnie nieczytelne. Nie oznacza to od razu, że przykładowa funkcja jest dobra. W takiej sytuacji najlepiej skonsultować z autorem rozwiązania, czy nie lepiej byłoby przygotować coś równie efektywnego, lecz prostszego w odbiorze. Czasami jest to tylko edycja nazw zmiennych, czasami konstrukcja funkcji albo rozbicie na podfunkcje. 

Dostając też do ręki kod osoby, która programuje bardzo długo i jest szanowana w firmie, nie możemy zakładać, że jest nieomylna. Literówkę, nadmiarowe entery, czy głupi błąd, może zrobić każdy, niezależenie od doświadczenia.

A kto to panu tak...

Prawdopodobnie rzadko nasza praca będzie polegała tylko na dodawaniu nowych funkcjonalności. Wchodząc do zespołu, który rozwija już istniejącą aplikację, część czasu przeznaczysz na łatanie błędów i zmienianie istniejących już rozwiązań. 

Pewnie większość z osób, która zawołała kiedyś jakiegoś fachowca do remontu, lub oddała samochód do mechanika, słyszała tę znaną frazę „a kto to panu tak...”. Przy czym ta osoba niejednokrotnie narzekała na samego siebie. W zawodzie programisty też nie raz usłyszymy podobne wypowiedzi, kiedy mamy działać na cudzym kodzie. Otwieramy daną klasę, rzucamy okiem, co tam się dzieje i nasz pierwszy wniosek jest taki, że w najlepszym przypadku, do tego arcydzieła rękę przyłożyła pijana małpa, która na chwilę miała możliwość siedzenia przy komputerze. Aby iść napiętnować osobę, która to napisała, sprawdzamy w systemie kontroli wersji, kto to napisał i widzimy tam nasze nazwisko. 

Z jednej strony to dobrze, ponieważ mamy naoczny przykład naszego rozwoju. Z drugiej strony, nawet jeśli napisał to ktoś inny, możemy optymistycznie założyć, że miał ku temu jakiś konkretny powód. Terminy zadań „na wczoraj”, chwilowe wypalenie zawodowe, po prostu gorszy dzień itp. każdemu może się zdarzyć. Jeśli przy podobnych bohomazach widujemy często powtarzające się nazwisko, ta osoba cały czas pracuje, a najlepiej wszem wobec opowiada o sobie jako o bożyszczu programowania, warto spróbować coś z tym zrobić. 

Rozwiązań na taką sytuacje jest parę i wiele zależy od kultury danej firmy. Najlepiej zacząć od rozmowy z taką osobą, ponieważ może my się tutaj mylimy. Dalej dobrze porozmawiać ze swoim team leaderem, jak widzisz daną sprawę i omówić sposoby rozwiązania „problemu”. Jeśli taka sytuacja dotyczy team leadera, idziemy po drabince wyżej. Najgorsza sytuacja ma miejsce, kiedy tą osobą jest „szef wszystkich szefów” w projekcie. Wtedy najlepiej pomyśleć o zmianie pracodawcy. 

Pamiętajmy też o tym, że dług technologiczny pojawi się zawsze, niezależnie od tego, jak bardzo będziemy starali się perfekcyjnie napisać swój program. Nowe wersje języków, dostosowanie do nowych standardów w branży, rozwój programu, tak to po prostu działa. 

Im bardziej zrozumiały program napiszemy, tym konsekwencje długu będą mniejsze, a jego regularne eliminowanie będzie łatwiejsze. Ważne, aby podobnie jak my, system, w którym pracujemy, rozwijał się w dobrym kierunku. Wtedy i nam i z nami będzie się przyjemniej pracowało.

Przecenisz swoje możliwości

Czytając ten artykuł, prawdopodobnie jesteś dopiero na początku swojej ścieżki, tak samo jest to mój pierwszy „większy” tekst dla szerokiej publiki. Podobnie jak ja teraz, tak i Ty prawdopodobnie przecenisz swoje możliwości ze względu na swoje ambicje. 

Przed rozpoczęciem kariery jako programista, przez 4 lata pracowałem jako grafik. Najtrudniejszym wyzwaniem nie było zrozumienie intencji klienta, czy wyjaśnienie mu, że dana koncepcja mija się z wszelakimi znanymi nurtami estetycznymi. Najtrudniej było, patrząc na zlecenie, wycenić czas potrzebny na jego wykonanie. Teraz patrząc na nowe zadanie, nadal jestem świadomy, że podczas estymacji po prostu się pomylę. Z czasem oczywiście niedoszacowanie, czy przeszacowanie czasu pracy jest coraz mniejsze, lecz do perfekcji jeszcze daleko.

Prawdopodobnie na początku swojej drogi to Twój team leader będzie wyliczał Ci dni potrzebne na rozwiązanie danego problemu. Możliwe że przy większej, lub mniejszej konsultacji z Tobą. 

Musimy wziąć pod uwagę to, że większość osób w tej branży ma raczej większe, niż mniejsze ambicje (nie wspominając o ego ;)) i otrzymując pytanie „jak długo Ci to zajmie”, pewnie damy relatywnie krótki termin, bo przecież taka pierdoła nie może mi zająć więcej niż dwa dni. Później rozpoczynając pracę nad tą pierdołą, okazuje się, że jednak tych małych klocków, które musimy wziąć pod uwagę, jest dużo więcej. Zauważyłem taką zależność, być może błędnie, że im krótszy staż pracy ktoś posiada, tym jest większym optymistą, jeśli chodzi o estymację czasy wykonania zadania. 

Podsumowanie 

Cały tekst powstały wyżej, można streścić do dwóch wniosków: 

• pisz taki kod, jaki sam byś chciał czytać 
• pracuj tak, jakbyś chciał z kimś pracować 

Biorąc pod uwagę te dwie zasady, mamy duże szanse w przyszłości być dobrymi programistami. Pamiętajmy także, że każdy senior, także kiedyś był juniorem i prawdopodobnie popełniał te same błędy, które teraz Ty popełniasz i popełnisz.