Dzięki Bogu nie mam w sobie tego demona, ale się z nim spotkałem wielokrotnie w swoich miejscach pracy oraz na studiach.
Programowanie to sztuka.
A każda sztuka potrzebuje artysty.
Kod jest jak obraz, który musi zostać namalowany. Aplikacja jest jak rzeźba, którą trzeba dokładnie kuć dłutem.
Artysta chce wyrazić siebie. Chce wyrazić swój geniusz. Chce być podziwiany. A programista może tworzyć dzieło sztuki tylko w jeden sposób, pisząc kod.
Piękność umysłu Artysty
Artysta ma jednak swoje problemy i demony, które przeszkadzają w pracy oraz w komunikacji nawet na poziomie kodu.
Artysta zapomina w trakcie tworzenia swojego dzieła, że INNI ludzie też będą z tego korzystać.
Zapomina o celu, jaki ma osiągnąć tworząc aplikację. Koncentruje się na wewnętrznym pięknie kodu, który nie zawszę będzie rozumiany.
Koncentruje się na sobie i swojej wierze, co jest słuszne. Przeczytał w końcu tyle poradników “jak” powinno się programować, że w końcu ma dylemat jak to zrobić.
Tracąc czas na takie dylematy jak:
- Czy mój kod JavaScript będzie piękniejszy bez myślników, czy z?
- Czy ta pętla foreach wygląda lepiej, czy te krótsze, ale mniej czytelne polecenie LINQ?
- Czy umieszczenie tego kodu w taki sposób nie sprawi, że będzie on bardziej elegancki?
- Czy wywołanie metody powinno być oddzielone jednym znakiem nowej linii, czy dwiema, czy wcale?
Artysta kocha to, co stworzył. Widzi w tym wewnętrzne piękno.
Problem jednak się pojawia, gdy to wewnętrzne piękno sprawia, że kod jest coraz to bardziej nieczytelny.
Artysta chce by inny programista dostrzegł piękno, więc wkłada dodatkowy wysiłek by ten następny programista dostał całkowitego olśnienia, gdy zobaczy jego Monę Lisę.
Problem jednak nie polega tylko na stracie czasu artysty, ale także na zakłopotaniu swoich innych kolegów dziwnymi stworzeniami.
Oto historie, które znam.
- Artystą zapewne był kolega, który w procedurach SQL pozostawił po sobie komentarze o smerfach. Potem dostałem zdanie by wszystkie je skasować.
- Artysta był na pewno kolega, który pomyślał, że dla rozrywki nazwie zmienne bohaterami ulicy sezamkowej.
Artysta chce bym się dobrze bawił czytając taki kod. Bym się odstresował i zapomniał, dlaczego tutaj właściwie pracuję.
Zobaczył ten piękny pejzaż.
Niestety nie zmienia to faktu, że takie upiększania jak np. głupie komentarze i głupie zmienne WYCIEMNIAJĄ KOD.
Z Artystą też czasem ciężko się dogadać. Mam takiego kolegę, który każdą pogawędkę programistyczną kończy od „a mógłbym to napisać w Asabamblerze”. Tylko pytanie, co z tego. To napisz to w Asamblerze.
Pamiętaj kod ma być czytelny więc nawet jeśli skrócisz 5 linijek do jednej, to zastanów się czy inny człowiek zrozumie co tutaj się dzieje.
To nie konkurs na bycie największym geniuszem, tutaj tylko chodzi o wzajemną pomoc.
Artysta konfrontacja z demonem
Artysta będzie bronił swojego kodu, co tworzy poważne problemy dla prawdziwego świata.
Będzie się bronił przed zmianami twierdząc, że “nikt go nie rozumie” albo, że “koledzy zazdroszczą mu, że nie są aż tacy mądrzy jak on”.
Jeśli artysta nie skonfrontuje się ze swoim problem, to wcześniej czy później zmieni pracę. Nie będzie chciał pracować z ludzi, którzy go nie rozumieją.
A co, jeśli ty jesteś artystą.
W wersji łagodnej tracisz czas na upiększanie kodu dla swoich egoistycznych celów nie myśląc o innych kolegach z zespołu. To się zdarza każdemu. Po prostu bądź bardziej świadomy.
W wersji ekstremalnej jako artysta uspokój się i nie dodawaj głupich komentarzy, ani zmiennych i przypomnij sobie, dlaczego ciebie tutaj zatrudnili.
Jeśli czujesz, że musisz wyrazić swoją mądrość w postaci kodu, to po pracy znajdź sobie jakąś formę rozrywki, która wypełni to uczucie potrzeby akceptacji i zrozumienia twojej osoby.
Miejsce pracy i kod nie jest do tego najlepszym miejscem.
Nawet jeśli się czujesz jak artysta, to też jesteś człowiekiem i popełniasz błędy.
Jeśli masz wątpliwości co, do swojego kodu i chcesz rzeczywiście stworzyć dzieło sztuki. W porządnej firmie nie powinno być problemu z zapytaniem kolegi o feedback.
Cokolwiek usłyszysz przegryź to i zrób to lepiej.
