Tym razem nie będzie pełnej relacji z konferencji. Będzie kilka nieuczesanych oraz zapożyczonych myśli z prezentacji, które podobały mi się najbardziej.
Patrick Copeland opowiadał o pretotypowaniu (pretotyping). Nie wiecie co to jest? Ja też nie wiedziałem. Pretotypowanie to jak najszybsze sprawdzenie, czy jakiś pomysł jest wart realizacji. Zamiast tworzyć prototypy (które kosztują) warto spróbować coś jeszcze prostego – po to, żeby jak najmniejszym wysiłkiem zrobić już jakąś ewaluację naszej idei.
Dawno, dawno temu, za czasów maszyn do pisania, pojawiła się koncepcja napisania oprogramowania typu Speech-To-Text. Potencjalni klienci byli tą ideą zachwyceni – ale kiedy zaczęli pracować z prototypem rozwiązania, szybko się zniechęcili do tego pomysłu ze względu na brak możliwości sensownej edycji tekstu. A cały dowcip polega na tym, że IBM nie wydał wielu setek dolarów na prototyp rozwiązania – tak naprawdę nie było żadnego programu! była osoba, która siedziała za ścianą i wpisywała do komputera tekst, który słyszała w słuchawkach. Tak niewiele posłużyło do ewaluacji idei.
Myśli zapożyczone od Patricka: wypróbowuj jak najwięcej idei i staraj się zbadać jak najmniejszym kosztem ich sensowność. I jeszcze jedno – nie szukaj setek pomysłów. Zamiast tego poszukaj innowatorów.
Wojtek Seliga podczas prezentacji „Software Developer Career Unplugged” opowiadał o własnych i o zapożyczonych doświadczeniach dotyczących rozwoju zawodowego. Wiele osób nie planuje swojej kariery, a na pytanie, dlaczego zmienili stanowisko lub firmę na inną, odpowiadają „tak się złożyło” albo „to był przypadek”. Na każdym stanowisku mamy jakąś krzywą rozwoju – najpierw mocno się rozwijamy, potem nasz rozwój zwalnia, aż w końcu następuje pewna stagnacja w osiągniętych umiejętnościach. Wówczas do pracy wykorzystujemy własne doświadczenie i nie jest nam potrzebna żadna nowa wiedza. Największy problem tkwi w tym, że zmiana pracy jest wyjściem ze strefy komfortu – możemy dostać gorszą pensję, część naszych doświadczeń z poprzedniej pracy jest bezwartościowa, musimy od nowa budować naszą pozycję zawodową. Czy warto to robić? Wojtek przekonuje, że jeżeli tylko zmieniamy pracę na taką, którą lubimy – to warto.
Myśli zapożyczone od Wojtka: zwracaj baczną uwagę na to, czy w swojej pracy się rozwijasz i na to, czy ją lubisz. Jeżeli nie rozwijasz się w pracy lub nie lubisz jej (a jeden z tych warunków jest wystarczający) – czas na zmianę! A zmieniając warto planować własny rozwój, a nie wykorzystywać najbliższą nadarzającą się okazję.
Myśl zapożyczona od Łukasza Lenarta: niezależnie od tego, jakiego frameworka używasz – nie ufaj mu. W każdym frameworku istnieją błędy. Śledź informacje o swoim frameworku i upgrade’uj go do najnowszej wersji tak szybko, jak to możliwe.
Sandro Mancuso pokazywał w jaki sposób z pracować z „legacy code”, czyli jak zmieniać stary i brzydki kod w ładny. Myśli zapożyczone od Sandro: nie możesz zmieniać starego kodu dopóki nie pokryjesz go testami. Zacznij pisanie testów od najkrótszych i najprostszych gałęzi kodu. Zacznij refaktoryzację od najgłębszych gałęzi. Ciekawa była również metoda pracy Sandro polegająca na tworzeniu kodu w dwóch niezależnych pionowych oknach edytora – w jednym z nich mamy kod, nad którym pracujemy, a w drugim mamy testy jednostkowe, które pokrywają ten kod.
Joel Spolsky opowiadał na przykładzie serwisów Stack Overflow i Stack Exchange o tym, że sposób tworzenia serwisu internetowego czy też aplikacji ma zasadniczy wpływ na to, jak ludzie z niego korzystają.
W wielu historiach Joela najbardziej uderzyło mnie wyjaśnienie, skąd wzięło się cytowanie poprzedniego maila za pomocą znaku „>” i odpisywanie bezpośrednio pod cytowanym akapitem. Otóż jest to relikt z czasów Usenetu, w którym wiadomości były rozsyłane mailami, ale nie było centralnego serwera wiadomości, a z powodu małej ilości miejsca na komputerach nie było można przechowywać lokalnie historii konwersacji. Żeby więc adresat zrozumiał, do czego się odnosimy, musieliśmy w mailu zacytować jego wypowiedź – wtedy sposób ograniczenie techniczne wpłynęło na działanie i przyzwyczajenie milionów ludzi. Joel mówił, w jaki sposób wykorzystywane są sposoby wyświetlania pytań, edycji pytań, mechanizm rankingu użytkowników w celu stworzenia jak najbardziej użytecznego serwisu Stackexchange.
Myśl zapożyczona o Joela – budując serwis poprzez swoje decyzje projektowe promujesz pewne zachowania jego użytkowników.
Sam Newman mówił o rozbijaniu wielkich systemów na mniejsze fragmenty. Zdecydowanie warto to robić – rozbijając wielkie, monolityczne systemy na mniejsze komponenty możemy uzyskać szybsze przenoszenie zmian, możemy różnicować je technologiczne, możemy umieszczać je na różnych platformach czy serwerach, możemy przypisywać ich rozwój do mniejszych zespołów… Dobry serwis musi być spójny wewnętrznie i luźno powiązany z elementami zewnętrznymi (loose coupling).
Powszechnym problemem jest rozdzielanie komponentów w aplikacji i odwoływanie się przez wszystkie komponenty do wspólnych danych – w tym przypadku odwoływanie się do wspólnych struktur danych sprawia że serwisy nie są w pełni niezależne. Prawdziwą niezależność uzyskujemy poprzez rozdzielenie również struktur danych i połączeniu poszczególnych serwisów do fragmentów bazy danych oddanych im na wyłączność – ale to z kolei rodzi konieczność wymiany danych między komponentami (czyli tak naprawdę tworzenia dodatkowych usług, które wymieniają te dane).
Myśl zapożyczona od Sama – najlepszym miejscem do projektowania połączeń między naszymi komponentami jest tablica, na której je rysujemy. Twórzmy małe serwisy, które robią tylko jedną rzecz i robią ją dobrze. I jeszcze jedna myśl: „tak naprawdę mógłbym przepisać polecenie ‘ls’ w dowolnym języku, na przykład w Javie – gdybym tylko chciał czekać zawsze 2 minuty na wykonanie tego polecenia”.
Paweł Brodziński prezentował swoje przemyślenia odnośnie budowania efektywnych zespołów. Myśli zapożyczone od Pawła: zbiorowa inteligencja zespołu (czyli tak naprawdę zdolność do rozwiązywania problemów przez zespół) nie zależy od sumy ani od średniej inteligencji jego członków, a zależy od empatii członków zespołu, od jakości komunikacji (w tym też od możliwości zabierania głosu przez wszystkich członków zespołu) oraz od odpowiedniej różnorodności stylów poznawczych. Wg badań Anity Woolley im więcej mamy kobiet w zespole, tym większa jest zbiorowa inteligencja (cudowna wiadomość dla zespołów IT, nieprawdaż?). Im bardziej elastyczni są członkowie zespołu, im chętniej pomagają innym w ich pracy – tym mniejsze jest prawdopodobieństwo tworzenia się kolejek zadań na pojedynczych członkach zespołu. Efektywna praca często oznacza wykonywania pracy, której normalnie byśmy nie wykonywali. Im chętniej członkowie zespołu poprawiają istniejące rozwiązania, bez oglądania się na ich autorów – tym większa jest jakość naszego systemu.
I na koniec myśl zapożyczona z finałowej prezentacji Svena Kick-Ass Petersa. Jedna, ale za to jak ważna:
