Zanotowałem z tego materiału:

• Ludzie odchodzą z firm, zespoły się rozrastają.
• Odchodząca osoba zostawia po sobie dziurę (wiedza, nieskończone zadania, emocje, koleżeństwo, morale).
• Powinniśmy sprawić, aby nowa osoba jak najszybciej stała się efektywna.
• Dobre praktyki:
  • Atmosfera: Zbuduj dobrą atmosferę w zespole, aby wszyscy członkowie zespołu, w tym nowa osoba, byli szczęśliwi w pracy i chętnie razem realizowali cele. Pierwsze wrażenie jest najważniejsze. Zaopiekuj się nową osobą. Wyślij jej wiadomość powitalną oraz pierwsze instrukcje.
  • Wprowadzenie: Daj nowej osobie listę rzeczy do zapoznania się i zrobienia. Jednym z zadań niech będzie przez niego uzupełnienie i doszczegółowienie instrukcji dla nowego członka zespołu.
  • Od pierwszego dnia zaangażuj nową osobą we wszystkie procesy zespołu, włącznie z rzeczami dla “zaawansowanych”:
    • Omawianie architektury.
    • Omawianie nowej funkcjonalności.
    • Code review.
    • Pair programming.
  • Przydziel opiekuna do nowej osoby, aby był osobą, która wspiera wdrożenie nowej osoby (Buddy).
  • Szkolenia:
    • Zrób szkolenie wdrażające o systemie (spróbuj je nagrać), ale też znajdź czas na rozmowę.
    • Daj dostęp do szkoleń.
  • Daj proste zadanie, które dotyka duży obszar systemu.
  • Wykorzystuj model Dreufusa, kroki zdobywania wiedzy.
  • Opis oczekiwań firmy w stosunku do Ciebie:
    • Oczekujemy, że po 3 dniach Twój kod pójdzie na produkcje.
    • Oczekujemy, że po roku będziesz w stanie zarządzać zespołem.

Zanotowałem z tego materiału:

• Piramida testów:
  • Najwięcej testów niskiego poziomu.
  • Najmniej testów wysokiego poziomu.
  • Testy z wyższego poziomu zajmują dużo więcej czasu.
  • Można zrównoleglić wykonywanie testów.
• Należy mierzyć stan Continous Delivery.
• Odpalaj automatycznie testy w każdym pipeline.
• Jak można skrócić czas wykonywania testów:
  • Wprowadzenie testów komponentowych.
  • Usunięcie zbędnych testów (np, Clover).
  • Uruchamianie w pipelinie tylko tych testów, które testują zmieniony ostatnio kod, a nie wszystko (np. JaCoCO).
• Zrób plan wzrostu testów – co, gdy będziecie mieli 100 x więcej testów.
• Traktuj pipeline (i testy automatyczne) jak produkcję.

Zanotowałem z tego materiału:

• Legacy to dziedzictwo.
• Z każdym kolejnym projektem jesteś bliższy idealnego czystego oprogramowania.
• Wybierając jako podstawy architektury popularne buzzwordy dochodzimy szybko do legacy. Powinniśmy wybierać architekturę ze względu na specyfikację naszego projektu, a nie obecną modę.
• Na początku chcemy zrobić czystą architekturę, aż dochodzimy do problemów i ASAPów.
• Największym ograniczeniem w tworzeniu idealnego rozwiązania jest nasza głowa.
• Określ cel swojego projektu:
  • Biznesowe kryteria akceptacyjne.
  • Wymagania biznesowe.
• Nie związuj się  z Frameworkiem – to jest Twój szczegół implementacyjny.

Zanotowałem z tego materiału:

• Co robimy źle? Jak psujemy IT:
  • Estymowanie:
    • Nie dawanie żadnych konkretnych terminów.
    • Denerwowanie się na pytanie, na kiedy coś zostanie zrobione.
    • Traktowanie inaczej siebie, a inaczej inne osoby (ja mogę się mylić, ale reszta nie może).
    • Brak patrzenia na problem z perspektywy drugiej strony.
    • Rozwiązania:
      • Podawać przedziały dat.
      • Podawać ryzyka i szansę na osiągnięcie danej daty.
  • Współpraca z klientem:
    • Brak odpowiedzialności.
    • Niszczenie zaufania.
    • Okradanie klienta.
    • Oszukiwanie klienta.
  • Bierność:
    • Bądź proaktywny.
    • Rozwiązuj problemy, a nie tylko przydzielone Ci zadania w sposób, w jaki Cię nauczyli. Rób więcej, szukaj lepszych sposobów.
    • Rozwijaj firmę.
  • Współpraca zespołu:
    • Zespół złożony z indywidualistów.
    • Każdy walczy z pozostałymi członkami zespołu.
    • Brak szukania wspólnego rozwiązywania problemu.
  • Rekrutowanie:
    • Wysyłanie niepasujących ofert.
    • Wypisywanie w CV wszystkiego, co modne, a nie to, co potrafimy.
    • Okłamywanie, że w firmie jest całkiem inaczej, niż jest rzeczywiście.
    • Przekazywanie niepełnych informacji.
    • Brak szczegółów dotyczących projektu, jedynie bardzo ogólny opis firmy.
    • Brak szacunku do drugiej osoby.
• Doceń swoją pracę. Spraw, aby była jeszcze przyjemniejsza dla wszystkich.

Zanotowałem z tych materiałów – 10 pomysłów na biznes:

1. Maszyna nowych treści:
   1. Zrobić z jednego materiału wiele (np. wpis blogowy przerobić w film, podcast, e-booka, serię zdjęć, notatek, wpisów na social media).
   2. Można robić opisy podcastów, transkrypcje, stories na Instagrama.
   3. Znajdź osoby, które produkują jakąś treść i zaproponuj im przerobienie ich treści w inne formy albo tylko w jedną, np. w infografiki.
2. Poszukiwanie informacji dla firm:
   1. Poszukiwanie informacji:
      1. Rzeczy, które przydadzą się w firmie.
      2. Jak wyglądają działania konkurencji, ich ceny i produkty.
      3. Gdzie są potencjalni klienci.
      4. Kim są klienci.
      5. Zbieranie liczb i robienie przejrzystych wykresów.
      6. Zbieranie fajnych nagłówków e-mail, ciekawych reklam.
      7. Poszukiwanie innowacji.
3. Budowa grup membership:
   1. Tworzenie grup, za które trzeba płacić abonament, aby do nich należeć.
   2. Pokazywać i tworzyć wartość za bycie na takiej grupie.
   3. Szukać osób, którym opłaci się mieć takie grupy membership.
   4. Możesz to stworzyć za pomocą np. Circle + Memberful + Stripe.
   5. Nie bierz zapłaty za zrobienie grupy, lecz weź procent za jej stworzenie, rozwijanie i utrzymywanie jej miesięcznych przychodów.
4. Pisanie maili:
   1. Pisanie angażujących i sprzedających maili.
   2. Pomóc innym przedsiębiorcom zarabiać pieniądze za pomocą maili (zwiększać sprzedaż, zaangażowanie).
   3. Możesz zrobić usługę, w ramach której będziesz tworzył system płatnych maili, utrzymywał go, rozwijał i dawał uwagi, jak lepiej pisać maile.
   4. Nie bierz zapłaty za zrobienie systemu płatnych maili, lecz weź procent jego stworzenie, rozwijanie i utrzymywanie jego miesięcznych przychodów.
   5. Możesz brać pieniądze za procent skuteczności maila.
5. Zarządzanie grupami na Facebooku:
   1. Zarządzać komunikatami, angażować, moderować posty, ustawić grafiki, dobre pytania początkowe, promowanie jej, opis grupy.
   2. Szukać sposobów monetyzacji grup.
   3. W grupie powinny być wartościowe rzeczy.
   4. Trzeba moderować grupę, aby nie pojawiły się tam śmieci i spam.
6. Płatne maile:
   1. Pobierać opłaty za wiadomości e-mail.
      1. Takich rozwiązań jest już wiele.
      2. Najlepszy model: zbierać maile i w mailach pisać wartościowe maile:
         1. Jeżeli masz markę, pisz o tym, co robisz, co obserwujesz.
         2. Jeżeli nie masz marki, pisz na ważny temat.
      3. Możesz wysyłać maile z treściami, które już gdzieś przedstawiłeś, np. w video, ale w jakiejś wartościowszej postaci, np. jak wdrożyć wiedzę z tego filmu.
      4. Zaproponuj płatne w swoich mailach maile płatne za 29-49 zł i tam daj więcej wartości.
      5. Promuj swoje bezpłatne maile.
      6. Narzędzia, np. active campaign.
7. Zmiana treści w listy:
   1. Zmieniać wartościową treść w checklisty oraz infografiki.
8. Twórca treści:
   1. Tworzenie angażujących i wartościowych treści.
   2. Kreowanie marek i produktów.
9. Daty i prezenty:
   1. Organizować za kogoś pamiętanie o rocznicach, urodzinach, świętach i przygotowywanie na tę okazję prezentów.
10. Negocjowanie jako usługa:
    1. Negocjowanie za kogoś (szczególnie za firmę).

Zanotowałem z tego materiału:

• Strategie testowania:
  • Testy nigdy nie są robione
  • Testy psują się regularnie i są olewane przez zespół.
  • Testy wstrzymują deploye.
• Jak testować:
  • Wypisz wszystkie możliwe scenariusze dla danego komponentu.
  • Przetestuj szczegóły implementacji, jeżeli są istotne.
  • Problem: Mała zmiana w kodzie może zepsuć wiele testów. Test sprawdzał za dużo.
    • Rozwiązanie: Robić testy sprawdzające decyzję i sprawdzające zachowania. I zrobić dwie klasy – jedna generuje zachowanie, a druga decyzję. Łatwiej będzie to testować.
  • Problem: Do kodu dodana została kolejna zależność. W testach brakuje nowej zależności.
    • Rozwiązanie: Tworzyć zależności w Setup.
  • Problem: Tworząc mocki zależności, trzeba znać szczegóły implementacji.
    • Rozwiązanie: Rozdzielić kod na: klasę:
      • mającą wiele zależności, ale nie podejmującą decyzji,
      • mającą mało zależności i podejmującą decyzję.
  • Problem: Jeżeli jest wiele czerwonych testów po zmianie w danej klasie, to nikt nie chce jej zmieniać.
    • Rozwiązanie: Bardzo możliwe, że ta klasa ma zbyt wiele odpowiedzialności (patrz Single Responsibility Principle).
  • Wyjątki:
    • Problem: Część programistów chce używać mocków w testach, a inni nie chcę.
    • Rozwiązanie: Klasy są różnego rodzaju. Dla jednych należy mockować, a dla drugich nie należy.
  • Jak testować, to z TDD:
    • TDD prowadzi do dobrego designu:
      • Dobre nazewnictwo.
      • Istnieje kontrakt.
      • Jest przetestowane.
      • Łatwo refaktoryzować.
    • Ale:
      • Pod spodem coraz bardziej możemy odbiegać od rzeczywistości.
    • Więc:
      • Musimy cały czas uważać na design i pogłębiać wiedzę na temat domeny. Ponieważ nie znając domeny TDD nie uchroni nas przed napisaniem złego oprogramowania.
  • Testy i TDD to (i programiści muszą to zrozumieć, zobaczyć i poczuć!):
    • Mniej bugów.
    • Lepszy kod.
    • Więcej zabawy.

Zanotowałem z tego materiału:

• Na początku projektu jest radośnie, a potem jest tak, jak zawsze: ludzie odchodzą, klient zmienia wymagania, napisany kod nie jest idealny, jest dużo błędów.
• Każda nowa architektura lub podejścia wprowadzały usprawnienia, ale żadne nie było idealnym rozwiązaniem.
• DDD, CQRS i Event Sourcing jest świetnym narzędziem do tworzenia oprogramowania.
• Poznaj przede wszystkim:
  • Dobre projekty DDD: https://twitter.com/andrzejkrzywda/status/688121714207666176.
  • Publikuj wydarzenia – Event Sourcing – możesz zacząć tylko od zapisywania wydarzeń, bez reagowania na nie. Dzięki wydarzeniom możemy zrozumieć jak podzielić domenę na bounded contexty.
  • Mikroserwisy nie są idealnym rozwiązaniem. Zazwyczaj na początku nie warto ich robić, bo to jest bardzo skomplikowana architektura.
  • Oddziel się od frameworków – zrób swój kod przenośny i niezależny od zewnętrznych bibliotek.
  • Zrozum bounded contexty (podsystemy aplikacji).
• Bardzo ważną umiejętnością pracowania z legacy jest umiejętność usuwania kodu przy zachowaniu funkcjonowania aplikacji.

Zanotowałem z tego materiału:

• Kod może być czysty, a i tak mamy dług technologiczny.
• Trzeba budować architekturę tak, aby czas wprowadzanie nowego feature’a był taki sam wraz z rozwojem aplikacji. Czas poświęcany na naprawę bugów również powinien być stały w czasie dla całego projektu, aby po jakimś czasie nie naprawiać wyłącznie bugów.
• Dług technologiczny może powstać, ponieważ:
  • Programiści  nie mają odpowiedniej wiedzy.
  • Programiści działają zbyt szybko, bo chcą jak najszybciej zakończyć pracę.
  • Programiści  wypuszczają zły kod, aby w przyszłości zebrać więcej informacji o przypadkach granicznych.
  • Programiści wiedzą, jak coś zrobić, ale nie mają czasu na to.
• Dług technologiczny jest jak finansowy. Jeżeli zaciągasz kredyt, to powinieneś być coraz ostrożniejszy i zacząć spłacać dług.
• Spłacalny dług technologiczny:
  • Czysty kod.
  • Pamiętać o celu oprogramowania: ma spełniać swoje zadanie – dawać wartość klientowi.
  • Pamiętać o oprogramowaniu wysokiej jakości: szybko rozwijane, przyjazne, rozwiązujące problemy, bez dużej liczby błędów.
  • Wzorce projektowe (w miejscach, gdzie ułatwia, a nie, ponieważ znamy dany wzorzec).
  • SOLID.
  • Prosty kod.
  • YAGNI – YOU AIN’T GONNA NEED.
  • Zasada Pareto (np. najwięcej zmian kodu – jądro systemu) – od tych klas należy rozpocząć refaktoryzację.
  • Usuwaj nieużywane funkcjonalności z kodu.
    • Trzeba szybko dostarczać nowe  funkcjonalności. Masa pojazdu na wpływ na szybkość poruszania się. Możesz poruszać się szybciej, jeżeli zmniejszysz masę (usuniesz nieużywane funkcje).
    • Możesz wykryć nieużywane funkcje za pomocą łatwego logowania.
    • Więcej featere’ów -> więcej kodu -> większa złożoność -> większy dług technologiczny -> więcej problemów (obejścia, bugi) -> więcej featere’ów….
  • Największym problemem programistów są: wymagania biznesowe. Rozwiązanie: przyrostowe rozwijanie (o największej wartości biznesowej) oraz priorytety zadań = AGILE.
• Trzeba robić Agile, a nie o nim mówić. Wszyscy pracownicy muszą wziąć odpowiedzialność za produkty i usługi. Programiści muszą wziąć odpowiedzialność za swój kod i aplikację.

Zanotowałem z tego materiału:

• Zespół rozproszony mierzy się z problemami w obszarach:
  • Duży dystans.
  • Różnice czasowe.
  • Różny język.
  • Różna kultura.
• Buduj zespół, rozmawiaj z nim, integruj się, włączaj kamerki, rozmawiaj nie tylko o pracy, bądź otwarty na budowanie relacji również po pracy.
• Z tego powodu:
  • Ciężko jest umówić spotkanie.
  • Małe problemy rosną w ogromne.
  • Wiadomości są opóźnione lub się gubią.
  • Pojawiają się niespodziewane blokady, których nie da się szybko rozwiązać, bo część zespołu nie jest w pracy.
  • Psują się relacje między członkami zespołu lub w ogóle nie są budowane.
• Najważniejsze jest zaufanie (wiara, że inni mają jak najlepsze intencje) i komunikacja.
• Kanały komunikacji:
  • Twarzą w twarz.
  • E-mail – wiadomości powinny być:
    • Ważne.
    • Konkretne.
    • Krótkie.
    • Precyzyjne.
  • Komunikatory – wiadomości:
    • Wiadomości powinny być tylko ważne.
  • Wideokonferencje – spotkania:
    • Wideo.
    • Tylko głosowe.
    • Jeżeli nie jesteś potrzebny na jakimś spotkaniu, to nie idź na nie.
    • Wysyłaj podsumowanie spotkania.
• Redukuj szum informacyjny!
• Upraszczaj język i komunikację!

Zanotowałem z tego materiału:

• Język oprogramowania wpływa na niezawodność oprogramowania.
• Branży telekomunikacyjnej bardzo zależy i zależało na dużej niezawodności, więc od lat szukają oraz tworzą rozwiązania, które są wysoce niezawodne.
• Elixir to połączenie Erlanga (niezawodność) i Ruby (przyjemne programowanie).
• Erlang i Elixir daje możliwość wykorzystywania w pełni mocy procesora oraz skalowania aplikacji na sieć.
  • Programowanie funkcyjne pozwala osiągać większą niezawodność.
  • Nie trzeba zatrzymywać oprogramowania, aby wprowadzić aktualizację.
  • Wielowątkowość oparta jest na modelu aktorów (przypomina miniserwisy).

Zanotowałem z tego materiału:

• W małej firmie:
  • Czujesz duży związek z produktem.
  • Masz większą decyzyjność i wpływ na system.
  • Robisz długo w tej samej technologii.
  • Nie możesz zmienić zespołu, bo nie ma innego zespołu.
  • Musisz pracować po godzinach (jeżeli jest to start-up).
• Rodzaje firm:
  • Startup:
    • Misja jest dobrze znana i jest super!
  • Firma produktowa:
    • Jest stabilne: spoko misja, dobra jakość,  jest bardzo dobrze oddzielony czas na życie prywatne i pracę.
  • Software house
    • Jest wysoki poziom mistrzostwa. Jet dużo przygód i dużo problemów.
• Zwiększ zadowolenie pracowników:
  • Bądź dobrym szefem, chwal, dawaj zadania, które rozwijają i cieszą danego pracownika.
  • Pozwalaj pracownikom rozwijać swoją pasję.
  • Pozwalaj pracownikom i motywuj ich w osiąganiu mistrzostwa.
  • Szanuj ludzi.