Biznes

Może zacznę od historii wielkich korporacji. Wszyscy wiedzą, jak powstawały Apple, Facebook i Google, ale nikt nie wie, jak powstał Amazon. Tak sobie pomyślałem gdzieś na początku grudnia i postanowiłem poszukać jak Jeff Bezos stworzył swoje imperium. Znalazłem kilka ciekawych artykułów na ten temat, pierwszy nawet po polsku, o kreatywnym tytule Historia sukcesu sklepu Amazon.com. Warto też zajrzeć na Birth of a Salesman oraz na stronę fundable.com, gdzie oprócz historii Amazona możesz znaleźć artykuły o tym, jako powstało kilka innych znanych firm z naszej branży (Startup Stories).

Marketing. W poprzednim miesiącu rozpisywałem się o Startup Playbook Sama Altmana, w grudniu portal Priceonomics zaprezentował The Content Marketing Handbook. Nie czytałem jej jeszcze, ale po pobieżnym przejrzeniu wydaje mi się, że znajdę w niej wiele materiałów, które pozwolą kiedyś jednemu z moich małych projekcików zmienić świat ;-)

Rozwój osobisty

Na blogu Startups and Shit od grudnia można poczytać o tym, jaki jest gwarantowany, zdaniem autora, sposób, żeby wzbogacić się w branży technologicznej (How to get rich in tech, guaranteed). W skrócie:

If you want to get rich, your best bet on a risk-adjusted basis is to join a profitable and growing public company. Google for short. Make $200-500k all-in a year, work hard and move up a level every 3-5 years, sell options as they vest (in case you joined Enron), and retire at 60, rich. This plan works every time.

Dołączenie do startupu tego nie gwarantuje, jak wspomniane jest na blogu i w podlinkowanym poście z blogu Hunter Walk (Sorry Startup Employee #100, Your Equity Probably Won’t Make You Rich). Ale, jak twierdzą na Startups and Shit, startup to jedyne miejsce, gdzie można zdobyć 20 lat doświadczenia w 5 lat. I dalej podane są wskazówki, jak wybrać startup, do którego najlepiej dołączyć.

Swoją drogą czytałem znów jeden ze starszych wpisów ba blogu Paula Grahama (jednak już w styczniu, a nie w grudniu). Wpis był pogadanką dla amerykańskich licealistów o tym, jak wybierać karierę zawodową (What You’ll Wish You’d Known). Tam Paul Graham zaleca podejście, które w pewien sposób koresponduje z tym opisanym na Startups and Shit. Powinieneś się skupiać na tym, co spowoduje, że w przyszłości będziesz mieć większe możliwości wyboru. Możesz pracować dla Enronu i klepać Javę 1.6, za co dostaniesz sporo pieniędzy i być może w perspektywie lat staniesz się bogaty. Jednak, zdaniem Grahama, takie podejście cię zamyka, blokuje ci drogę do dalszego rozwoju.

Może tamta droga kariery wcale nie jest taka pewna i po jakimś czasie okaże się, że zatrzymałeś się na technologiach sprzed dwudziestu lat, a twój pracodawca wreszcie się zorientuje jak bardzo cię to czyni nieproduktywnym. Co wtedy? W naszej branży niestety nie można się zatrzymać. Może nawet zbytnia specjalizacja to nie jest najlepszy pomysł?

Ciągnąc dalej ten temat, podrzucam kolejny link, The 100-Hour Rule, który może cię zainspirować, jak sobie radzić w tak dynamicznie zmieniającym się otoczeniu. Bo, jak wiadomo, żeby zostać ekspertem w jakiejś dziedzinie, trzeba na to poświęcić 10 tysięcy godzin, prawda? No to załóżmy, że pracujesz 8 godzin dziennie, masz 26 dni urlopu, nie pracujesz też w soboty, niedziele i święta. Wychodzi mniej więcej 226 dni pracujących rocznie, czyli wspomniane 10 tysięcy godzin, to, bagatela, 5 i pół roku. Wtedy zostaniesz ekspertem w danej dziedzinie.

Tak jak startupy pozwalają w pewien sposób zhakowac czas potrzebny na nabycie doświadczenia, tak na blogu Coding VC proponują regułę hakującą czas potrzebny na zostanie ekspertem. Dlaczego kursywą? Bo reguła 100 godzin pozwala nie na zostanie ekspertem, ale na poznanie jakiegoś zagadnienia znacznie lepiej niż większość ludzi.

For most disciplines, it only takes one hundred hours of active learning to become much more competent than an absolute beginner.

Potrzeba lat, żeby zostać szefem kuchni, ale tylko stu godzin lekcji gotowania, żebyś gotował lepiej, niż większość twoich znajomych. Potrzeba lat programowania, żeby stać się dobrym programistą, ale tylko kilku kursów online, żeby zająć się profesjonalnie programowaniem. I tak dalej.

Ale pójdźmy jeszcze dalej. W komentarzach do tego wpisu pojawił się filmik z TEDa, mówiący o zasadzie 20 godzin. Licytacja, kto da mniej? Przecież powszechne jest przekonanie, że trzeba się napracować, żeby coś osiągnąć. Zobaczmy.

Na filmiku najpierw demaskowana jest zasada 10 tysięcy godzin. Okazuje się, że dotyczy ona w zasadzie tego, jak wspiąć się na szczyt w wąskiej, konkurencyjnej dziedzinie, a wcale nie tego, jak dojść do poziomu eksperta, czy nawet, żeby stać się w czymś dobrym. Badania, na podstawie których sformułowano zasadę 10 tysięcy godzin dotyczyły na przykład szachistów i sportowców.

Prezentujący, Josh Kaufman, pokazuje, że na początku uczysz się naprawdę szybko, a dopiero wspinanie się na kolejne poziomy wymaga coraz większego wysiłku. Potem jest kilka wskazówek, jak należy się uczyć, żeby zmieścić się w tych 20 godzinach.

Te wszystkie materiały ładnie się spinają w całość. Paul Graham twierdzi, że powinieneś podejmować takie decyzje, żeby mieć jak najwięcej możliwości w przyszłości. Startups and Shit, pokazuje, że praca w startupach jest wartościowa, bo przyspiesza proces zdobywania doświadczenia (czyli w pewnym sensie: szybciej masz więcej możliwości). I wreszcie reguły 20 i 100 godzin pokazują, że szybciej można się czegoś nauczyć, że szybciej, niż się wydaje, można zacząć robić coś nowego, nawet profesjonalnie. Bariera jest głównie psychologiczna, odpychająca od nowości i nabycia nowych umiejętności. Zamiast zachęcania do eksperymentów, stawiająca mur, że, żeby tylko zacząć, musisz zrobić tak wiele. Albo poświęcić 5 i pół roku, żeby być w czymś dobrym.

A jako wisienka na koniec tej sekcji i z okazji zbliżającego się nowego roku 12 resolutions for programmers. Matt Migh daje inspiracje, czego nowego mógłbyś nauczyć się w nowym roku, czego nowego możesz spróbować. To od czego zaczynamy?

Praktyka programowania

Zmiana tematu – od tego, co należy chwalić, do tego, co należy potępiać. Dość długi wpis o patologiach organizacyjnych w tworzeniu oprogamowania (Normalization of deviance in software: how broken practices become standard).

Jeśli chcecie poczytać o tym, że w pewnej firmie zamiast zgłaszać błędy sprzętu producentowi, naprawiano je samodzielnie, żeby konkurencja nie miała tych poprawek, albo o tym, że w pewnej firmie nigdy nie przesyłano dalej maili z uwagi na bardzo restrykcyjne przepisy dotyczące bezpieczeństwa, to ten artykuł jest dla was. Ale to nie wszystko. Znajdziecie tam też sporo sensownej analizy, dlaczego tak się dzieje i jaki to ma związek z lekarzami, którzy nie myją rąk.

Powyższy wpis jest generalnie o patologiach w praktyce programowania na poziomie organizacyjnym, a nie na poziomie technicznym. Ale teraz już zaczynamy o poziomie technicznym. Scala Best Practices to… zestawienie dobrych praktyk w programowaniu w Scali :-) Można się dowiedzieć sporo fajnych rzeczy, od oczywistości po rzeczy bardziej subtelne. Każda chyba wskazówka zilustrowana przykładem kodu.

Przy okazji ostatniej rekrutacji poczytałem też sporo innych fajnych rzeczy o Scali. Jednym z ciekawszych odkryć był wzorzec projektowy cake pattern. Służy on do tego, żeby bez konieczności używania żadnej biblioteki skorzystać z wstrzykiwania zależności, nie korzystając przy tym z implicits w konstruktorach, które mogą czasami zaciemniać kod.

Miałem na początku trochę problemów ze zrozumieniem, o co chodzi w tym wzorcu i dopiero po chwili implementacji doznałem objawienia. Dla zainteresowanych polecam artykuł Jonasa Bonéra, Real-World Scala: Dependency Injection (DI), gdzie oprócz tego podejścia jest pokazane jeszcze kilka innych. I koniecznie spróbujcie to zaimplementować, to przekonacie się, jak świetnie organizuje kod.

Na koniec tej sekcji jeszcze o czym, co się nazywa object-relational impedance mismatch. Nie wiem, czy o tym słyszeliście, ale generalnie problem występuje na styku modelu obiektowego i relacyjnego. Chodzi o to, że te modele nie są zgodne, występują pomiędzy nimi rozbieżności. To głównie dlatego, jeśli programujecie w zestawieniu np. Java + SQL, tyle czasu poświęcacie na przemapowanie modelu obiektowego na relacyjny i z powrotem. Albo też dlatego model może być niepoprawny – bo np. koncepcyjnie dużo zaczerpnięte jest z modelu relacyjnego (pola typu id, gettery i settery, brak enkapsulacji, kompozycji, czy interfejsów). Przyznaję, że to właśnie impedance mismatch jest tym, co mnie najbardziej odstrasza od relacyjnych baz danych, bo to jest coś, co powoduje, że programujesz mniej efektywnie i produkujesz kod niższej jakości.

W każdym razie, w grudniu odkryłem, że ponoć w programowaniu funkcyjnym ten problem jest mniejszy, bo model funkcyjny programowania lepiej współgra z modelem relacyjnym. Najpierw wyczytałem to w tutorialu do Slick, biblioteki dostępu do relacyjnych baz danych dla Scali. Impedance mismatch wspomniane było tylko w jednym miejscu, i to dość enigmatyczne:

Knowing this, you might not be surprised that a functional language, such as Scala, can provide some benefit in lessening the problem known as object-relational impedance mismatch.

Postanowiłem więc pogrzebać dalej i dotarłem do wątku na Stack Overflow, który może wyjaśnia trochę więcej, ale ciągle niewiele. Temat jest tak ciekawy, że mam nadzieję, że kiedyś pogrzebię jeszcze głębiej i zrobi się z tego osobny wpis.

DevOps

W tej sekcji piękna historia o refaktoringu GitHuba: Move Fast and Fix Things. Wydaje mi się, że już w sumie widziałem podobny wpis na ich blogu, bo równie dużo skupiali się na ich sposobie testowania na produkcji – na tym, że podczas testów, część zapytań działa zarówno ze starą, jak i nową wersją kodu, a potem porównywane są rezultaty. Ta historia prawie na pewno jest o czymś innym, a przy okazji jest całkiem zajmująca. Vicent Martí opowiada, w jaki sposób, niezauważalnie dla użytkowników, podmienili na portalu jedną z kluczowych finkcjonalności Gita – mergowanie.

Jako uzupełnienie – wizualizacja, jak działają poszczególne polecenia w Gicie: Visualizing Git Concepts with D3.

Architektura i narzędzia

Architektura w aplikacjach mobilnych (i nie tylko) korzystających z mikroserwisów: jak backendy powinnny być przygotowane dla frontendów. Pattern: Backends For Frontends Sama Newmana to dość długi wpis specjalisty od mikroserwisów, który warto przynajmniej przejrzeć.

Wrzucam tu jeszcze dwa ultimate guides, pierwszy jest zbiorem referencji dotyczących wszystkich najważniejszych aspektów pracy z Play Framework, drugi od podstaw opisuje SBT.

Ciekawostki

The 10 Most Entertaining StackOverflow Questions Of All Time, a w nich między innymi o tym, dlaczego chucknorris jest interpretowany jako kolor w HTML, jakie są najlepsze obrazki i żarty programistyczne, albo o tym, jaka jest różnica pomiędzy Java i JavaScript (Java and Javascript are similar like Car and Carpet are similar).

Oprócz tego warto zajrzeć, jakie książki w 2015 roku Bill Gates uznał za najciekawsze (The Best Books I Read in 2015) i przeczytać artykuł o tym, jak różne kultury postrzegają czas (How Different Cultures Understand Time).