Na końcu zawsze jest użytkownik

W dziedzinie tworzenia oprogramowania osiągnęliśmy bardzo wysoki poziom. Nowoczesne języki programowania całkowicie zdominowały rynek tworzenia nowych produktów, a problemy takie jak zarządzanie pamięcią w programach czy implementacja prymitywnych algorytmów ustąpiły miejsca myśleniu o osiągnięciu celu biznesowego.

Oczywiście, systemy operacyjne i środowiska, ze względu na swoją naturę, nadal wykorzystują prymitywne technologie. Pojawia się pytanie — czy każdy, kto chce korzystać z tych systemów i środowisk (tj. każdy programista), musi dobrze rozumieć technologie, które je budują? A może jest odwrotnie? Być może powinniśmy skupić się na jak najjaśniejszym przekazywaniu idei do świata komputerów. Dlaczego powinniśmy znać mechanizmy działania środowiska, skoro nie jest to nasza odpowiedzialność ani część naszej pracy?

Dylemat sprowadza się do prostego pytania: czym jest programowanie? Czy jest to lista instrukcji, wyrażenie logicznych idei, czy po prostu tworzenie produktu dla innych? Czy programowanie ma jakiekolwiek znaczenie bez odniesienia do świata zewnętrznego (tj. użytkownika)?

Trzy typy programistów:

Poeta. Program powinien być zwięzły i pięknie napisany.

Haker. Szuka granic, sztuczek w używanych API/SDK. Wykorzystuje nieoczywiste metody w programowaniu, sprawiając, że program robi to, co chcesz i jak chcesz.

Twórca. Tworzy oprogramowanie, aby służyć ludziom.

Programowanie jako poezja

Pierwsze podejście traktuje programowanie zasadniczo jako implementację matematyki. To rodzaj poezji, w której idee w swojej najczystszej formie są przenoszone do środowiska, w którym mają być wykonane. Fakt, że ten program będzie uruchamiany w jakimś środowisku, które może wpływać na jego działanie, jest w rzeczywistości nieistotnym szczegółem implementacyjnym. Najważniejsze jest przekazanie idei w odpowiedniej, wyrafinowanej formie. Kod źródłowy musi być czytelny, zgodny ze standardami architektonicznymi i "gęsty" - powinien dokładnie odzwierciedlać pomysły i intencje programisty oraz zwięźle ujmować to, co zostało określone w specyfikacji.

Programiści, którzy myślą o programowaniu w ten sposób, preferują języki wysokiego poziomu — ułatwiają one określenie intencji.

To, jak napisany program wchodzi w interakcję z ludźmi, jest drugorzędne. Aspekty wizualne są nieistotne; problemy z działaniem, jeśli nie wynikają z błędnego przedstawienia idei, nie są ważnym argumentem przeciwko poprawności implementacji.

Jeśli używałeś Reacta do tworzenia stron internetowych, powinieneś wiedzieć, że model niezmienności i wyrażanie widoku jako czystej funkcji od danych do DOM pochodzi z programowania funkcyjnego. W rzeczywistości większość nowoczesnych pomysłów programistycznych została stworzona przez ludzi, którzy myślą o programowaniu jako o poezji.

Programowanie jako hakowanie

Żaden program nie może istnieć bez środowiska, w którym jest uruchamiany. Jakość programu nie wynika z dobrze napisanego kodu, ale z tego, jak skutecznie program wykorzystuje sprzęt. Kod źródłowy powinien być tak czysty i przejrzysty, jak to konieczne. Najważniejsze jest optymalne wykorzystanie środowiska. Wydajność jest kluczowym czynnikiem decydującym o tym, czy program jest dobrze napisany. Program jest poprawny, jeśli działa zgodnie z naszymi oczekiwaniami — elegancja wykonania jest ważniejsza niż poprawność. Jeśli problem teoretyczny nie może wystąpić ze względu na specyfikę środowiska, nie jest to prawdziwy błąd.

Program powinien działać szybko i wydajnie. Warto jednak pozwolić ograniczeniom sprzętowym kierować doświadczeniami użytkowników. Jeśli mają słaby sprzęt, to program będzie działał odpowiednio — jest to akceptowalne zachowanie.

Holistyczna natura tego podejścia jest interesująca. Dla programistów działających w tym sposobie myślenia, wszystko, co może nieoczekiwanie zmienić zachowanie programu, jest niebezpieczne. Dlatego hakerzy gardzą mechanizmami takimi jak "GarbageCollector" czy językami jak "JavaScript". Preferują języki niskopoziomowe, ponieważ oferują one ogromne możliwości w decydowaniu o zarządzaniu pamięcią i działaniu programu.

Programowanie jako tworzenie użytecznych rzeczy

Programiści tworzą oprogramowanie, ponieważ inni ludzie go potrzebują. Programowanie samo w sobie jest środkiem do celu.

Dla programistów z tego obozu kod źródłowy musi być przede wszystkim jasny i prosty, aby zapewnić łatwe i szybkie zmiany w kolejnych iteracjach. Najważniejszym aspektem jest dodawanie funkcji i sposób, w jaki użytkownik wchodzi w interakcję z oprogramowaniem. Szybkość jest ważna, ale nie ważniejsza niż funkcja, którą oprogramowanie ma spełniać. Wszystkie błędy mają znaczenie tylko o tyle, o ile wpływają na użytkownika. Oprogramowanie powinno działać zgodnie z oczekiwaniami użytkownika. Aspekt wizualny jest zatem bardzo ważny.

Twórcy preferują języki wysokiego poziomu i środowiska z szerokim dostępem do bibliotek, aby dostarczać funkcjonalność tak szybko, jak to możliwe.

Istnieją napięcia między Poetami, Hakerami i Twórcami. Główna krytyka dotyczy braku wiedzy na temat m.in. działania sprzętu lub nieznajomości idei z programowania funkcyjnego. Z drugiej strony, Twórcy są najbardziej „produktywnym” typem programistów — oprogramowanie, które tworzą, jest zawsze użyteczne, ma doskonały interfejs użytkownika (UI) i doświadczenie użytkownika (UX), a błędy nie szokują użytkowników.

Jak to wygląda w praktyce?

Kiedy myślę o tworzeniu oprogramowania, zawsze dochodzę do wniosku, że warto stworzyć zespół składający się z programistów reprezentujących wszystkie typy myślenia. Jednak priorytetem jest dostarczanie wartości biznesowej i komunikacja z użytkownikiem. Wysoka jakość w tej dziedzinie tworzy użyteczny program, sprzyja dobrej współpracy z zespołem UX/UI oraz z osobami odpowiedzialnymi za dostarczanie wymagań biznesowych. Warto praktykować zapewnianie przestrzeni na tematy „poetyckie” i „hakerskie”. Doskonała czytelność „poetyckiego” kodu i zastosowanie innowacyjnego podejścia architektonicznego mogą wspierać zespół w szybszym dostarczaniu kolejnych funkcji. Z drugiej strony, optymalizacje „hakerskie” zapewnią poprawne działanie programu na sprzęcie użytkownika.

Musimy być ostrożni z hakerami i poetami. Odnoszę się tutaj do popularnego memu - Midwit, który pokazuje poprzez rozkład normalny, że czasami podejście, które wydaje się bardzo prymitywne, jest tym właściwym, preferowanym przez najlepszych w danej dziedzinie. Początkujący i eksperci często podzielają opinie i skłonność do prostoty w sposób, który irytuje "przeciętnych".

Doświadczamy tego, gdy w mediach widzimy zwykłego pracownika fizycznego zarabiającego fortunę na kryptowalutach, a jednocześnie obserwujemy Elona Muska (osobę o ogromnym IQ i wiedzy) przejawiającego zamiłowanie do Dogecoina. Podobnie w świecie tworzenia oprogramowania, gdy doświadczeni programiści w intelektualnych debatach zbywają wszystko słowami "to zależy" i poklepują się po plecach za mądre i dojrzałe słowa. Jeszcze kilka lat wcześniej można było spotkać ich gorliwie cytujących "Wujka Boba" i reagujących furią na każde odstępstwo od "Czystego Kodu". Teraz programiści ze środka krzywej toczą wojny o to, który framework jest lepszy, podczas gdy Pieter Levels zarabia ponad 1 milion dolarów rocznie na jednym prostym pliku PHP.

Książka "Getting Real" przedstawia sposób tworzenia oprogramowania. Aby naprawić problemy związane z wydajnością i dostarczyć "hakerskie" optymalizacje, warto znać sposób działania środowiska. Istotne jest przestrzeganie zasady "Najpierw spraw, żeby działało, potem spraw, żeby działało dobrze, a na końcu spraw, żeby działało szybko."ShareRewrite

Podsumowując, użytkownik powinien zawsze być najważniejszym elementem w tworzeniu oprogramowania. Szukajmy programistów, którzy mają ten sam cel co my - dostarczanie wartości biznesowej, a wtedy wszystko będzie dobrze. Ostatecznie środowisko się zmienia, sprzęt się zużywa, a użytkownik pozostaje ze swoimi potrzebami. Kluczem jest więc odpowiadanie na nie.

Race to Running Software | Getting Real

Getting RealBasecamp

Scale Later | Getting Real

Getting RealBasecamp