Filozofia pragmatyczna

To jest twoje życie

Jako człowiek masz w sobie możliwości sprawcze.

Można zmienić firmę lub zmienić swoją firmę.

Branża daje wiele możliwości, więc bądź proaktywny i z nich korzystaj.

Kot zjadł mój kod źródłowy.

Ponoś odpowiedzialność za własne czyny oraz swojego zespołu. Jeżeli coś zepsułeś, to zamiast szukać wymówek, zaproponuj potencjalne rozwiązania. Czasami, gdy zamykają się jedne drzwi, to inne się otwierają. Być może w ostatecznym rozrachunku, nawet skorzystasz na jakiejś "porażce".

Entropia oprogramowania / Dług technologiczny

Kod jest jak dom z wybitą szybą. Jeżeli dom ma wybitą szybę, to za jakiś czas ludzie wybiją kolejne, namalują grafitti i zamienią ten dom w ruinę.

Nie można pozwolić, aby w kodzie była taka wybita szyba. Trzeba ją załatać jak najszybciej przynajmniej tymczasowo. Słaba czystość lub niebezpieczne luki w kodzie, o których każdy wie, są conajmniej niepożądane i osoby pracujące z takim kodem mogą go traktować tak jak ten dom.

Zupa z kamieni i gotowane żaby

Bądź katalizatorem zmian. Jeżeli masz jakiś pomysł to go przedstaw w skuteczny sposób, aby inni okazali zainteresowanie.

Odpowiednio dobre oprogramowanie

Jakość powinna być ustalona w wymaganiach i być dostosowana do projektu.

Biorąc pod uwagę projekt w zależności czy to gra komputerowa, czy system bankowy możemy pozwolić sobie na odmienne wymagania dotyczące jakości pisanego kodu / wytwarzanego oprogramowania. Nie ma sensu robić czegoś perfekcyjnie, jeśli za dwa dni tego kodu może nie być lub jeśli zrobienie czegoś perfekcyjnie zajmie nam dużo czasu.

Użytkownicy wolą mieć dostęp do niedopracowanej funkcji niż czekać miesiące, aż dostaną całość.

Zasada YAGNI (You ain't gonna need it)

Osobiście lubię tworzyć oprogramowanie wystarczająco dobre i łatwe do refaktoryzacji. Wtedy nie muszę się przejmować, że moje "przemyślane" klasy AbstractBuilderFactory będą musiały być wywalone do kosza z powodu, że trzeba dodać jedną funkcję, której się wcześniej nie przewidziało.

Najważniejsze to tworzyć kod łatwy do refaktoryzacji i do testowania. Jeżeli da się go łatwo przetestować, to raczej jest dobry. (choć w rzeczywistości nie jest to takie proste).

Portfolio wiedzy

Inwestycja w wiedzę zawsze przynosi największe zyski — Benjamin Franklin.

Budowa własnego portfolio wiedzy

Regularne inwestowanie
Różnorodność (jeśli chodzi o zakresy zdobywanej wiedzy)
Zarządzanie ryzykiem (trochę popularnych narzędzi/języków trochę egzotyki)
Kupuj tanio, sprzedawaj drogo (świeże obiecujące technologię, mogą być dobrze opłacane w przyszłości)
Przeglądy i korekty (branża jest dynamiczna, więc jak coś się kończy, to trzeba to rzucić w kąt i tego nie tykać, np. jQuery)

Cele

Jeden język rocznie najlepiej spoza zakresu wiedzy np. Haskell dla Javowca
Jedna książka techniczna na miesiąc
Sięganie po książki inne niż techniczne
Branie udziału w szkoleniach
Zangażowanie w lokalne grupy użytkowników technologii
Eksperymentowanie z różnymi środowiskami
Być na bieżąco (czytać blogi, oglądać filmiki)

Okazje do nauki

Są rzeczy, które umiem i których jeszcze nie robiłem.

Przy każdej okazji, gdy czegoś nie wiemy, powinniśmy powiększyć własną wiedzę. Jeżeli nie znajdziemy odpowiedzi na nasze pytanie w internecie, to być może powinniśmy się spytać kogoś kto zna odpowiedź.

Krytyczne myślenie

Patrz krytycznym okiem na to, co czytasz i słyszysz.

Zadawaj pytania "5 razy dlaczego", aby poznać istotę problemu
Kto na tym skorzysta? (warto zadać, zwłaszcza gdy technologia/podejście jest świeże)
Jaki jest kontekst? Jeżeli tytuł to najlepsze praktyki, to warto się spytać dla kogo.
Kiedy i w jakich warunkach rozwiązanie się sprawdza? Czy krótkoterminowo, czy również długoterminowo
Dlaczego to jest problem?

Komunikuj się

Traktuj język angielski i język ojczysty jako języki programowania. Nie powtarzaj się (DRY) i stosuj pozostałe metody znane z programowania, aby ułatwić sobie komunikację i pracę z językiem ojczystym.

Poznaj swoich odbiorców

Każda twoja wypowiedź powinna być przystosowana do odbiorcy. Nie można mówić osobie nietechnicznej o swojej ulubionej technologii, gdy ona nie wie, co się do niej mówi.

Należy wiedzieć, co powiedzieć

Przed naszą wypowiedzią należy przygotować plan/szkic, który umożliwi nam poruszenie każdego z tematów w określony sposób. Dzięki temu będziemy wiedzieć, co powiedzieć.

Należy wybrać właściwy moment

Ważne prośby/pytania warto zadawać w odpowiednim momencie. Jeżeli dziecko szefa jest w szpitalu, na zewnątrz pada deszcz i jest piątkowy wieczór, to nie jest to dobra sytuacja na dyskusję o podwyżce lub modernizacji komputera.

Natomiast jeżeli właśnie straciliśmy dużo kodu źródłowego, to można obmówić inne podejście do systemu kontroli wersji.

Należy wybrać odpowiedni styl

Jedni wolą luźną pogawędkę, inni długi formalny i obszerny raport. Należy dobrać odpowiedni styl do naszego odbiorcy.

Należy zadbać o warstwę estetyczną

Należy upewnić się, że wszystko będzie wyglądać schludnie. Sprawdzić pisownie. W obecnych czasach można zastanowić się nad nadaniem tonu naszej wypowiedzi za pomocą narzędzi sztucznej inteligencji.

Dokumentacja

Dokumentacja powinna opisywać to, czego nie opisuje kod i testy. Wszystkie decyzje technologiczne i architektoniczne warto opisywać równolegle z kodem w dokumentacji.

Komunikacja online

Należy przeczytać tekst przed kliknięciem przycisku Wyślij
Należy sprawdzić pisownię.
Należy sprawdzić listę adresatów.
Należy zachować prosty format.
Tekst nie może cytować/naśladować otrzymanego maila.
Jeśli dajemy cytat, to musi być to odpowiednio zaznaczone.