Luty

29 Feb 2016

W rozwoju osobistym sporo o lęku przed porażką i niepróbowaniu. W praktyce programowania o samym procesie wytwarzania oprogramowania, o programowaniu w stylu lean i BDD. Do tego ciekawostki o czcionkach i jeszcze parę innych drobiazgów w różnych sekcjach. To wszystko w linkach z lutego!

Biznes

Ponoć wychodzi jakoś teraz w Polsce biografia Elona Muska. Dla tych, co tego pana nie znają, a także dla ciekawskich, artykuł z Wyborczej: Elon Musk - geniusz czy szaleniec? Twórca PayPala, Tesli, SpaceX zmusza podwładnych do pracy ponad siły. Sam jestem ciekaw, ile jest prawdy w doniesieniach o pracoholizmie Muska i o tym, jak bardzo jest wymagający i skoncentrowany na swoich przedsięwzięciach. Coś w tym może być, skoro informacje o tym pojawiają się tak często, i skoro sam Musk osiąga tak spektakularne sukcesy. Dla tych, którzy chcą dowiedzieć się więcej, pytanie na Quora: How did Elon Musk work for 100 hours a week for more than 15 years?

Zresztą o tym jak skrajnymi postaciami są niektórzy founders, w mediach aż dudni. Musk, czyli pracoholik, Jobs to neurotyk, a Gates to nerd (choćby ostatnio z InnoPoland: Bill Gates miał obsesję! 2 tygodnie jednocześnie programował i spał nad klawiaturą. Tak powstał Microsoft). I tak dalej, choć nie wiadomo, na ile ci ludzie faktycznie tacy są, na ile to autokreacja, a na ile samonakręcające się media.

Ostatnio czytam książkę Petera Thiela i Blake Mastersa, Zero to one, w której jest rozdział poświęcony temu zjawisku – dlaczego i na ile biznesmeni są tacy wyjątkowi. A ponieważ książka powstała na podstawie bloga Blake Mastersa, który powstał na podstawie wykładów Petera Thiela, odsyłam do bloga, gdzie znajdziecie z grubsza to, co w książce: Founder as Victim, Founder as God.

W styczniu pisałem tzw. stack fallacy, w którym jako jeden z przykładów podałem to, że Apple potrafi robić świetny sprzęt, ale z oprogramowaniem wcale tak dobrze im nie idzie. W lutym natknąłem się na wpis Apple’s declining software quality, w którym możesz znaleść przykłady. Fajna jest też dyskusja o tym wpisie na Hacker News. Pokazuje różne punkty widzenia – że to jest problem związany z zarządzaniem, albo że to kwestia percepcji, bo oprogramowanie Apple od zawsze było buggy, albo że to nie ma znaczenia, bo mimo że jest buggy, daje nam fajne funkcjonalności. W każdym razie jakoś niespecjalnie widać, żeby ktoś zaprzeczał ;-)

W styczniu pisałem też o GitHubie i o liście otwartym twórców oprogramowania Open Source, którego przesłanie brzmiało: ogranijcie się, nie jesteście dość dobrzy. W lutym w związku z tym (albo bez związku, albo w związku jeszcze z czymś innym) pojawiło się kilka artykułów krytycznych. Business Insider pisał o napięciach wewnątrz firmy, niektórzy wychwalali GitLaba (Choose GitLab for your next open source project), pisząc o tym, w czym jest lepszy od GitHuba, a inni jeszcze deklarowali przeniesienie własnych projektów do konkurencji.

Nic jednak wielkiego się nie stało, żaden z wielkich projektów nie zmienił miejsca trzymania źródeł. Szum minął, a GitHub być może lekko się zatrząsł i dalej idzie do przodu. Na początek wprowadzili jedną z funkcjonalności, której się domagano: Issue and Pull Request templates.

Oczywiście nie mogło też zabraknąć historii o startupach. W tym miesiącu o tym, jak się reklamować, nie mając zbytnio na to budżetu: How we got our first 100 paying customers.

Rozwój osobisty

Skoro była już mowa już o Musku, to w lutym czytałem też artykuł na LinkedIn, do którego przyciągnęło mnie między innymi jego nazwisko: I asked Larry Page, Elon Musk and Jack Dorsey how they felt starting their companies. Their answers caught me off guard. Adam Grant, autor artykułu, opisuje to, czego dowiedział się od wspomnianych Przedsiębiorców, kiedy robił z nimi wywiady do swojej książki. Twierdzi, że:

They all felt the same fear of failure that the rest of us do. They just responded to it differently.

Wyszło na to, że i tutaj pojawia się znany motyw związany z tym, że ludzie chcą poczuć się bezpiecznie, dlatego nie próbują czegoś nowego. Tymczasem okazuje się, że najczęściej żałuje się nie tego, że się coś zrobiło, ale tego, że się czegoś nie zrobiło. Musk, Page i Brin, Dorsey (ten od Twittera), Jobs, Cuban (ten od Ubera) ponosili porażki i próbowali dalej. Jobs przecież został wyrzucony ze swojej firmy, Page i Brin z niepowodzeniem próbowali kiedyś sprzedać Googla, a Cuban ma za sobą startup, który nie wypalił. Grant twierdzi, że wszyscy ci Przedsiębiorcy bardziej bali się nie spróbować, niż spróbować i ponieść porażkę.

Oczywiście jeśli nie będziesz ciągle próbować, to ci się nie uda to truizm i potworne uproszczenie, jednak warto się zastanowić trochę głębiej nad tym, że obawa przed porażką jest niewspółmiernie duża w porównaniu do potencjalnych konsekwencji faktycznej porażki.

Można na przykład twierdzić, że jest to niejako uwarunkowane ewolucyjnie, kiedy porażki miały dramatyczne konsekwencje (np. zjadł cię tygrys szablozębny), albo że chodzi tutal o jakiegoś rodzaju błąd poznawczy w stylu niechęci do straty (a zresztą pewnie jedno i drugie i tak są ze sobą powiązane). Albo że chodzi o skłonność do ryzyka wbudowaną w geny – Amerykanie mogą uchodzić za naród najbardziej przedsiębiorczy dlatego, że większość z nich ma przodka, który podjął ryzyko emigracji na drugą stronę Atlantyku.

Moim zdaniem jednym z ważnych czynników przesadnego lęku przed porażką jest konstrukcja systemu edukacji, który mniejszy nacisk kładzie się na wspieranie eksploracji, a większy na zwalczenie potknięć. Mamy przecież od pierwszej klasy do końca studiów taki system, w którym wykładowca/nauczyciel podaje jedynie słuszną wiedzę, a następnie sprawdza, na ile wiedza została zapamiętana i karze za popełnione błędy, wystawiając niższą ocenę.

Maciej Bennewicz, znany polski coach, pisze w swojej książce (Coaching, czyli restauracja osobowości):

Niestety już od pierwszej klasy wbija się nam negatywne przekonania. Nauczyciel podkreśla czerwonym długopisem błędy. W ten sposób je w nas “wdrukowuje” łącznie z przekonaniem, że “jestem słabym uczniem”. Słabymi uczniami byli Einstein, Edison, Churchil i setki innych! Podobne nawyki mają nasi szefowie i my wobec siebie samych, członków rodzin właśnych dzieci!

Albo Michał Pasterski pisał na swoim blogu o schemacie popełnianie błędów jest złe (13 błędów polskiego systemu edukacji):

Już od pierwszej klasy szkoły podstawowej dzieci są ofiarami polityki strachu, według której nauczyciele traktują popełnianie błędów jako oznakę bycia “gorszym uczniem”.

Taki sposób myślenia niszczy kreatywność dzieci i buduje u nich stałe poczucie strachu przed podejmowaniem działań i eksperymentowaniem. To w większości przypadków na zawsze kształtuje psychikę człowieka i jest jednym z najważniejszych powodów, dla których tak wielu z nas żyje przeciętnym życiem.

Bo to już nie jest tylko kwestia tego, czy stworzysz startup, który osiągnie sukcesy, tylko coś znacznie większego.

No dobra, ale ciągnąc dalej wątek chcenia i robienia. Jessica Abel (amerykańska artystka i twórczyni komiksów) opisuje na swoim blogu pojęcie Idea Debt. Pojęcie jest zapożyczone od Kazu Kibushi (japońskiego twórcy komiksów) który powiedział:

I try not to to look at what I’m going to do as this amazing great grand thing. (…) Now I’m actually solving problems in the moment, and that’s so much more exciting than than trying to fill years of what I like to call my “idea debt.” That’s when you have this dream of this awesome thing for years. You think, “Oh, I’m going to do this epic adventure. It’s going to be so great.” The truth is, no matter what you do, it will never be as great as it is in your mind, and so you’re really setting yourself up for failure.

Idea Debt jest wtedy, kiedy myślisz dużo o czymś wspaniałym, co zrobisz, opowiadasz o tym znajomym, ale tak właściwie niewiele robisz. Masz jakiś swój projekt, na który wpadłeś kilka lat temu, zbierasz pomysły, zastanawiasz się, jak do niego podejść i jaki wspaniały będzie rezultat. Wtedy, tłumacząc prawie dosłownie, zaciągasz dług wobec swojego pomysłu. Ten dług rośnie z czasem, kiedy pomysł wydaje ci się coraz lepszy i pewnie warto zacząć realizację, zanim będzie nie do spłacenia. Mark Zuckenberg nie czekał, aż w jego głowie Facebook stanie się czymś globalnym, tylko zaczął robić coś dla swojego uniwersytetu ;-)

Warto spróbować, zanim pomysł zdąży urosnąć, ale oczywiście tylko, jeśli chcesz go zrealizować. Nie jest nic złego w pielęgnowaniu swoich pomysłów i zadłużaniu się w ten sposób. Bo może nie chcesz, może nie warto, a nikt ci nie karze i nikt nie ma prawa od ciebie oczekiwać, żeby twoja wspaniała idea się zmaterializowała.

I to też taką przestrzeń (w angielskim słowo space ładnie pasuje), bo nikt nie będzie do ciebie miał pretensji, jak ci się nie uda.

Teraz krótko o pracy zdalnej. Jedną z firm, która pracuje w znacznej mierze zdalnie jest Basecamp (swoją drogą Basecamp wydało nawet książkę o pracy zdalnej). Jason Zimdars, jeden z tamtejszych designerów we wpisie Why I work remotely (hint: it has nothing to do with productivity) podaje kilka zalet z obszaru życia osobistego. Można podczas pracy opiekować się chorym dzieckiem, można na tydzień pracować u przyjaciela, w ciągu dnia wyprowadzić psa itd.

(Na marginesie: od marca zaczynam pracować w pełni zdalnie!)

Praktyka programowania

TL:DR You can not observe a developer without altering their behavior.

Tak na samym początku artykułu Heisenberg Developers pisze Mike Hadlow. Jest to artykuł jeszcze z czerwca 2014, jednak natknąłem się na niego na HackerNews w lutym tego roku.

Mike Hadlow zaczyna od historii. Kilka lat temu pracował w firmie, gdzie wszystko szło gładko, jednak z czasem pojawiło się wymaganie klienta, które na początku wydawało się nieskomplikowane, jednak z czasem okazało się straszną kobyłą. Developerzy chcieli odłożyć implementację na później, na którąć z kolejnych wersji systemu, ale biznes nalegał.

Po kilku miesiącach, kiedy ciągle nie było widać końca implementacji, biznes zdecydował się na zatrudnienie menadżera ze świetnym CV. Zacieśniono kontrolę – wprowadzono Jirę. Każda funkcjonalność była rozbijana na mniejsze zadania wpisywane do Jiry. Każda próba refaktoringu musiała być udokumentowana.

Wszystko zwolniło. Programiści zamiast rozwijać aplikację, zaczęli realizować taski. Dla własnego bezpieczeństwa zawyżali estymaty. Motywacja spadła. W końcu najlepsi ludzie, także autor, odeszli z firmy.

No więc co poszło nie tak? Mike Hadlow podaje kilka przykładów:

Proces wytwarzania oprogramowania nie jest do końca rozumiany przez menadżerów. Często traktowany jest jako zestaw mechanicznych czynności, a nie proces twórczy.
Próbowano wymusić estymację, co w przypadku wytwarzania oprogramowania jest możliwe tylko w bardzo ograniczonym zakresie.
Bardzo szczegółowe zarządzanie (mikrozarządzanie) prowadzi do tego, że najbardziej utalentowane osoby odchodzą (piękne zdanie: Finely grained management is a recipe for “talent evaporation”).

A receptą na to wszystko jest autonomia.

(Koniecznie poczytajcie też komentarze do tamtego wpisu).

Na blogu o znamiennej nazwie programming is terrible w lutym pojawił się wpis Write code that is easy to delete, not easy to extend. Jest to świetny wpis o tym, jak należy programować – krok po kroku. A całość zaczyna się cytatem Jeana Paula Sartre’a z czasów przed jego karierą filozoficzną, kiedy jeszcze programował w ANSI C (link dla niedowiarków):

Every line of code is written without reason, maintained out of weakness, and deleted by chance.

Każda istniejąca linijka kodu wiąże się z kosztem utrzymania. Im więcej masz linijek, tym więcej będziesz musiał włożyć wysiłku, jeśli coś się zmieni. Dlatego warto pisać taki kod, który łatwo jest usunąć.

(Poniżej synteza listy kroków, ale jeśli tylko potrafisz czytasz po angielsku, zajrzyj na oryginalny wpis, bo tutaj będzie mało przykładów i sporo uproszczeń).

Nie pisz kodu. Trudniej utrzymać monolit z milionem linijek niż mikroserwis, gdzie linijek jest kilkadziesiąt. Usunięcie jednej linijki w monolicie da mniejszy efekt, niż usunięcie linijki w mikroserwisie.
Kopiuj kod, bo wykorzystanie kilka razy kawałka kodu, daje sporo korzyści – możesz na przykład zobaczyć, jak ten kawałek jest dostosowywany do konkretnych rzeczy w twoim kodzie. Jeśli jednak zrobisz z tego kawałka np. osobną, współdzieloną funkcję, trudniej będzie utrzymać twój kod. Łatwiej zmienić skopiowany kod wewnątrz funkcji, niż zmienić współdzieloną funkcję. (Zajrzyj też tutaj).
Nie kopiuj kodu, czyli innymi słowy: twórz utils. Jeśli coś zaczynasz kopiować często, albo coś korzysta z informacji ze świata zewnętrznego (plików konfiguracyjnych, zmiennych środowiskowych, systemu plików), stwórz folder util i wrzucaj tam pliki implementujące te często powtarzające się rzeczy. W tym wypadku jednak, zamiast robić coś easy-to-delete, dążymy do tego, żeby te rzeczy, które trudno usunąć, trzymać w jednym miejscu.
Pisz więcej boilerplate, czyli takiego copy-paste kodu, w którym za każdym razem trochę się zmienia. Przykład: skorzystanie z biblioteki do zapytania HTTP, gdzie tworzy się zapytanie, wykonuje je, a potem czeka na odpowiedź. Tutaj podobnie jak w kopiowaniu kodu chodzi o to, żeby minimalizować zależności do czegoś, co jest poza danym scope (funkcją, metodą, klasą itp.).
Nie pisz boilerplate, jeśli zduplikowanego kodu jest zbyt dużo. Często powstają biblioteki, które są nakładką, fasadą na bardziej skomplikowaną bibliotekę, a dzięki którym sam nie musisz pisać tyle boilerplate. Korzystaj z nich, jeśli trzeba, albo stwórz swoje (choćby w formie utils).
Stwórz wielki kawał kodu, czasami trzeba. Dzień się kończy, a ty masz za mało czasu, żeby skończyć funkcjonalność zgodnie z dobrymi praktykami. Albo tworzysz startup i nie masz czasu napisać czegoś zgodnie ze sztuką (tzw. founders code). Dobrze, napisz wielką metodę, pełną zagmatwanego kodu, ale niech wszystko będzie w jednym miejscu. Łatwiej będzie taki kod usunąć w przyszłości. Łatwiej usunąć jeden wielki problem, niż 18 malutkich, współzależnych, które powstały, kiedy pochopnie dzieliłeś swój kod.
Podziel swój kod na mniejsze kawałki, bo duże fragmenty kodu łatwo usunąć w całości, ale trudno usunąć tylko część z nich. Kod powinien być podzielony nie przez wzgląd na funkcjonalności, ale przez to, na ile jest niezależny. Utrzymywanie dwóch różnych funkcjonalności w jednym komponencie może być OK, jeśli ich podzielenie może spowodować konieczność nietrywialnej koordynacji powstałych po podzieleniu. No i oczywiście używaj loose coupling. Klocki, z których budujesz swój system powinno się dać łatwo podmienić.
Dalej pisz kod, ale taki, który łatwo jest usunąć. Jeśli piszesz kod, który jest rozszerzalny, zakładasz, że za trzy miesiące wszystko się ładnie zgra. Jeśli piszesz kod, który łatwo jest usunąć, na bieżąco możesz eksperymentować, zostawiać to, co działa i pozbywać się nietrafionych eksperymentów.

Można powiedzieć, że w Write code that is easy to delete, not easy to extend zostało opisane takie lean-podejście do pisania kodu – eksperymentuj i wycofuj się w razie potrzeby, i nie zaczynaj od robienia czegoś wielkiego. Podobne podejście można znaleźć we wpisie Strategic Scala Style: Principle of Least Power. Wszystko po to, żeby uniknąć nadmiernego skomplikowania kodu. Ogólna zasada brzmi:

Given a choice of solutions, pick the least powerful solution capable of solving your problem.

A filozofia, która sie za tym kryje jest prosta. Złożoność to twój wróg, nie bój się refaktorować i uważaj, żeby nie przekombinować (don’t over engineer).

Mając to wszystko na uwadze, autor przeprowadza nas po kolei przez takie zagadnienia, jak immutability, interfejsy, typy danych, obsługa błędów, asynchroniczne typy danych i wstrzykiwanie zależności. Wszystko pięknie, na przykładach i krok po kroku.

Na koniec tej sekcji jeszcze o testowaniu i BDD.

Ostatnio (dokładnie nie pamiętam, ale chyba jeszcze w styczniu) byłem w Krakowie na Meetupie poświęconym BDD i Spock. Jedna z myśli, która tam padła, dotyczyła tego, że BDD często jest przeformalizowane i wymaga mnóstwo nadmiarowego kodu. Pisząc np. w JBehave, mnóstwo rzeczy trzeba skonfigurować, zaprogramować parsowanie i wykonanie (po wyrażeniach regularnych) każdego wyrażenia z Gherkina; innymi słowy, mnóstwo dodadkowego kodu do utrzymania. A w dodatku okazuje się, że składnia Gherkina miała być czytelna dla klientów, ale kiedy takich opisów testów jest sporo, klient nie chce tego czytać. Czyli mamy narzędzie, albo sposób testowania, który powstał dla biznesu, ale okazuje się, że biznes tego nie potrzebuje, a programiści muszą utrzymywać więcej kodu.

Taki był punkt wyjścia tego spotkania, ale oczywiście wskazana została jedna wielka zaleta Gherkina – wykorzystanie jego składni (dla przypomnienia: given/when/then) i samo zastosowanie BDD bardzo dobrze strukturyzuje testy. Tutaj wkroczył na scenę Spock, czyli framework do testowania w Groovym (działa na JVM), w którym można robić BDD, bez konieczności utrzymywania plików w składni Gherkina. Wszystko wraca na swoje miejsce, robimy BDD w sposób mniej obciążający programistów i równie czytelny, a biznesowi możemy pokazać kilka testów akceptacyjnych.

DevOps

Obecnie w adresach stron internetowych przedrostek www często jest pomijany. Dlaczego nie jest to najlepsza praktyka, przeczytacie na stronce www. is not deprecated.

CloudFlare to ciekawe narzędzie służące do poprawy wydajności aplikacji i portali internetowych. Z jednej strony to taki CDN, ale z drugiej ma sporo zaawansowanych opcji, zabezpieczających nawet przed DDOS. Konfiguracja jest banalnie prosta – żeby zacząć wystarczy zmienić swoje DNSy i… to wszystko. CloudFlare, będzie teraz cache’ować twoje skrypty i CSSy.

Jeśli chcesz dowiedzieć się, jak to działa, zajrzyj tutaj. I wspomnij mój wpis, jeśli natkniesz się na taką stronkę:

Nieciekawa historia z wpisu Today DigitalOcean lost our entire server przypomina, że nie warto do końca ufać nawet wyspecjalizowanym firmom i najlepiej samemu sobie robić dodatkowe backupy.

I jeszcze na koniec dobre praktyki SSH: SSH: Best practices.

Architektura i narzędzia

W tej sekcji niewiele, tylko jedno narzędzie. Ponieważ mam już trochę dość cukierkowego Bootstrapa i błyskawicznie zmieniającego się Google Web Starter Kit, więc podaję lżejszą alternatywę, której pewnie spróbuję w najbliższym czasie: Basscss.

Ciekawostki

Pierwszy artykuł z ciekawostek jest o kerningu czcionek (A Beginner’s Guide to Kerning Like a Designer), czyli regulowaniu odległości w czcionkach pomiędzy poszczególnymi znakami. Szczerze mówiąc, to dopiero teraz się dowiedziałem, czym kerning jest i że w ogóle jest potrzebny.

Drugi artykuł też o czcionkach! The New Web Typography to dosyć długi wpis o tym, jak współcześnie powinny wyglądać czcionki na stronach internetowych, jakie są z tym problemy itp. Choć są tam fragmenty techczniczne i wskazówki, znacznie bardziej jest to esej niż tutorial.

We wpisie Graphing when your Facebook friends are awake pewien developer opisał, jak na podstawie informacji o statusach znajomych w czacie Facebookowym, wywnioskował, kiedy znajomi śpią, a kiedy nie. Wnioskowanie okazało się całkiem trafne i daje do myślenia o tym, jak wiele można się o nas dowiedzieć z Facebooka.

Jeśli korzystaliście z Maca, to pewnie wiecie, że instalacja aplikacji polega tam na tym, że pobiera się jakiś plik, rozpakowuje go, a następnie przenosi go do folderu Aplikacje. Zwykle pliki te są dość duże – 100 MB to takie minimum. Dzieje się tak dlatego, że aplikacja na maca zawiera wszystkie zależności, jakich potrzebuje i uruchamiana jest w środowisku izolowanym od reszty zależności. Np. nie wysypie się, bo zainstalowana w systemie bilioteka X jest w nieodpowiedniej wersji.

Ostatnio pojawiło się narzędzie, które umożliwia instalowanie aplikacji w taki sposób na linuksach: AppImage.

OK, każdy to gdzieś już widział, ale ja też zamieszczę: w lutym Typesafe zmieniło nazwę!