Sprawny Programista
Shares
Let it go. Odpuść

Let it go. Odpuść

Shares

Dzisiaj o tym dlaczego nie warto za wszelką cenę dążyć do swojej racji.

Przeczytałeś ostatnio dobrą książkę. Albo artykuł. Albo obejrzałeś świetną konferencję. Jesteś nabuzowany wiedzą i ręce palą Ci się do tego by wykorzystać ją w projekcie, nad którym pracujecie.
Poznałeś nową architekturę, albo świetną bibliotekę. Może masz super rygorystyczne podejście do OOP.
Wiesz co? Odpuść sobie.

Co ty gościu gadasz?

Dzisiaj chciałbym powiedzieć Ci o tym, że nie warto za wszelką cenę dążyć do tego, żeby postawić na swoim. Nie warto odrzucać każdego pojedynczego code review kolegi bo zostawił pustą linię w metodzie (a to przecież antywzorzec).

Pamiętaj o tym, że wartością którą dostarczacie jako zespół, jako firma jest na końcu produkt. Klienta nie będzie interesować to, czy zrobiliście to w super najnowszym frameworku, na który jest aktualnie hype. Pamiętaj o tym, że to co się liczy to funkcjonalność waszego software-u.

Prawda jest taka, że

wszyscy czasami piszemy kiepski kod.

Każdemu programiście zdarza się napisać kiepski kod. Każdemu zdarza się być już zmęczonym i po prostu chce kolanem dopchać jakiś fragment kodu tylko po to, żeby mieć już pracę z głowy. Chce sobie odpocząć i spędzić czas z rodziną albo na swoim hobby.

Jeśli jesteś młodym programistą, z gorącą głową, daj innym żyć. Nie przyczepiaj się do każdej najdrobniejszej wpadki kolegi z zespołu. Pamiętaj, to też jest człowiek (szok!). Zobaczysz, że na końcu dużo lepiej wyjdziesz na tym, że zbudujesz dobre relacje z osobami z zespołu, że stworzycie razem jakieś rozwiązanie – nawet jeśli nie będzie ono dopasowywać się w 100 % do najnowszych trendów z konferencji – niż na tym, że będziesz mieć rację.

Na końcu nie liczy się to, kto miał rację, tylko to jakie mamy relacje z osobami, z którymi pracujemy. Nie od dziś wiadomo, że robimy biznesy z ludźmi, których lubimy. I dużo lepiej będzie nam się wracać do pracy wiedząc, że mamy w niej kolegów.

Znaj granice

Ok, tak naprawdę nie chodzi mi o to, żeby nie starać się robić rzeczy jak najlepiej.
Chodzi o to, żeby znać granicę. To super, że nauczyłeś się nowej rzeczy i chcesz ją sprzedać zespołowi – byście mogli dostarczyć lepszy software. Ekstra, tak trzymać. Pamiętaj jedynie o tym, żeby znać granicę.

Jeśli masz jakiś pomysł na architekturę, czy wzorce wykorzystywane w projekcie – a nikt z Twojego zespołu ich nie podziela – nie bądź nazi developerem. Dużo ważniejsze jest byście jako zespół mieli wspólne wzorce pracy i jakości waszego kodu. Koniec końców lepiej utrzymuje się kod/oprogramowanie, które nawet jeśli niezgrabne, to powielające te same wzorce.

Edukuj i daj czas

Jeśli jesteś przekonany, że Twoje rozwiązania są świetne – przekonuj do nich zespół. Ale w luźnych rozmowach, przy tablicy, w trakcie brainstormu. Nie musicie ich zastosować w obecnym projekcie. Ale jeśli zrobicie coś w obecnym nie po Twojej myśli – w następnym możesz zaproponować zespołowi swoje rozwiązanie. Skonfrontować je z tym czego użyliście do tej pory. I wypunktować jego mocne strony. Może teraz łatwiej wam będzie wspólnie podążać nowym rozwiązaniem.

Daj też czas sobie. Jeśli dopiero co poznałeś nową bibliotekę/architekturę daj sobie czas wyrobić o niej zdanie. Przemyśleć, czy faktycznie ma to sens i czy jest najlepsze do rozwiązania waszego problemu. Może się okazać, że parę dni, tygodni Twoja euforia minie i nie będziesz już tak napalony.

Pamiętaj, że nie ma idealnych rozwiązań. Każde ma jakieś granice, przypadki brzegowe, w których korzysta się z niego niewygodnie. Może się okazać, że zmieniając aktualne rozwiązanie wpadniecie z deszczu pod rynnę.

Krótko mówiąc: myśl pragmatycznie. Nie przedkładaj Twojej świetnej zabawy z nowym rozwiązaniem nad dostarczenie projektu. Może się okazać, że robiąc coś po staremu, w znanych technologiach, których nikt nie musi się już douczać, dostarczycie wartość biznesowi szybciej. A pamiętaj, że to jest najważniejsza wartość jaką jako programista dostarczasz. Wprowadzaj zmiany powoli, tak byście jako zespół mogli do nich wspólnie dojrzeć i je zrozumieć.

O autorze Dariusz Mydlarz

Cześć! Jestem programistą odkąd pamiętam, a zawodowo robię to od 2012 roku. Moim głównym językiem jest Java. Chciałbym dzielić się z Tobą moim doświadczeniem w świecie IT. Prywatnie jestem fanem piłki nożnej, mężem i tatą Michałka.

śledź mnie na:

Zanim odejdziesz... ;)

Hej! Zapisałeś się już do listy mailingowej? Dzięki niej dostaniesz krótką informację o nowym wpisie wprost na swoją skrzynkę! ;)

Zostaw komentarz: