Relacja z Making Software Developers’ Meetup Summer 2016

Hej, niecałe dwa tygodnie temu miałem okazję uczestniczyć w konferencji Making Software Developers’ Meetup Summer 2016, która odbyła się 14 czerwca w Krakowie. Dziś krótka notka o prezentacjach jakie miały tam miejsce. Nie są to tylko suche skróty z prezentacji ale moje własne wrażenia i przemyślenia.

Mieliśmy okazję wziąć udział w 4 następujących po sobie (z przerwami oczywiście 🙂 ) prelekcjach:

Pierwszą zaczął Matthew Mols. W swoim wystąpieniu „Embracing Failure: Building software from a new perspective” podkreślał wagę bycia przygotowanym na błędy w oprogramowaniu jakie tworzymy. Uczulał też na to, że programiści powinni chcieć i mieć więcej do powiedzenia na temat gotowości oprogramowania do wdrożenia na produkcję.
Generalnie bardzo ciekawe i zgadzam się z nim w tej kwestii. Dla mnie było to mało zaskakujące: nic czego nie wiedziałem czy nie uważałem wcześniej. Jednocześnie chce napisać, że Matt poruszył ważne tematy i uważam, że warto je propagować i nawet powtarzać jeśli trzeba. A co próbował przekazać:

– Oprogramowanie może mieć błędy, lub ogólnie mówiąc źle działać. Mogą to być bugi w kodzie, może to być kiepska wydajność albo np nasza strona może paść ofiarą hackera. Powinniśmy być na to przygotowani w ten czy inny sposób i starać się myśleć o tym wcześniej. Jednocześnie nie zapominajmy, że nie każdy kod jest tak samo ważny. Są części naszej aplikacji, w których błędy nie będą krytyczne. Przykładowo szkoda tracić czasu na przejmowanie się mało ważnym formularzem, gdy nie mamy właściwych zabezpieczeń procesu płatności. Wiele też zależy od tego co dane oprogramowanie robi: wysyła ludzi w kosmos, zajmuje się finansami, czy jest zwykłym blogiem o programowaniu ;-). Trzeba znaleźć właściwy balans. Nie ma jednej recepty.
– Druga część wystąpienia traktowała o tym, o czym kiedyś wujek Bob pisał: programista powinien mieć świadomość o tym, czy jego oprogramowanie może być wdrożone czy nie w danej chwili – czy nie będzie to katastrofa. I jeśli coś stoi na przeszkodzie, np jest źle zabezpieczone, nie będzie działać poprawnie albo będzie niewydajne – informować o tym przełożonych. Ba, wujek Bob często mówi o tym, że powinniśmy mieć decydujący głos w tej sprawie na zasadzie veta. Zgadzam się, że to jest nasza odpowiedzialność. Osobiście żałuję, że niestety często w życiu bywa tak, ze nie mamy w tej sprawie za wiele do powiedzenia. Matt dał przykład podczas prezentacji portalu healthcare.gov, którego z tego co wiem uruchomienie było katastrofą mimo tego, że developerzy głośno informowali swoich przełożonych o problemach z wydajnością które nastąpią po wdrożeniu. Już parę miesięcy wcześniej podnosiły się ich głosy w tej sprawie – ale zostali zignorowani i mieliśmy do czynienia z jedną największych klap w historii tego typu.


Druga prezentacja była najbardziej techniczną i konkretną a zarazem nie pokazała prawie kodu. Ale to dobrze, bo wiele mogłoby to nie dać, a przedstawienie tematu na diagramach dało dużo więcej czytelności. Maciek Grzyb podczas prezentacji „How to mix tracks like a pro?” przedstawiał problemy jakie napotkał jego zespół podczas tworzenia aplikacji do mixowania muzyki na platformę Android. Dużo informacji o problemach buforowania i konwertowania ścieżek muzyki z formatu na format poprzez SDK androida. I to wszystko gdy kilka ścieżek musi być idealnie zsynchronizowanych na raz.
Nie jestem melomanem i na mnie nie zrobiła wrażenia, ale sam zakres działania i możliwości jakie prezentuje wydają się być interesujące.


Największe wrażenie zrobiło na mnie trzecie wystąpienie „Talents in practice” Dominika Juszczyka. Jeśli miałbym wybrać jedną prezencję, żeby na niej być, byłaby to ta. Dominik mówił o systemie rozwoju w oparciu o mocne strony naszej osobowości. W przeciwieństwie do podejścia „to Twoja słaba stronę, popracuj nad nią” zaprezentował koncepcję umacniania stref, w których jesteśmy dobrzy. Ale nie dotyczy to umiejętności jak programowanie, pisanie czystego kodu, lecz cech osobowości które mamy. Na przykład czy naturalne dla nas jest raczej od razu podejmowanie działania, bez myślenia na początku o tym co i jak to zrobić, czy spokojne przemyślenie tego co i jak chcemy zrobić i przeanalizowanie tematu. To są akurat dwa z 34 talentów jakie system Strengths Finder pomaga „wykryć”, tj pokazać które z nich są w naszej osobowości najsilniejsze. Prezentacja też traktowała o tym, jak w codziennej pracy i poza nią, wiedza o naszych mocniejszych stronach może nam pomóc w tym co i jak robimy. Plus jaki ma to wpływ na cały zespół w jakim pracujemy.


Na koniec dowiedzieliśmy się od Konrada Dzwinela „How do we build things at Brainly?”. Była to prezentacja o ich procesie wytwarzania oprogramoania, typu „robimy code review, mamy CI, CD…”. Ot ciekawie posłuchać, że są też inne firmy w których takie podejście działa i fajnie się sprawdza. Do tego była krótka historia o tym jak robić A/B testy i jak ich nie robić 🙂 na przykładzie z ich produktu. Taki lekki talk na zakończenie.


Jeszcze krótko o samej organizacji:  ciekawe miejsce spotkania i dobre jedzenie. Darmowe piwo, to wszystko na plus. Szkoda, że sama sala do prezentacji była duszna i robiła się szybko za ciepła. Dobrze, że nie było takiego upału jak dzisiaj. Klimatyzacja Twoim przyjacielem podczas takich imprez :-). Mimo to polecam i zachęcam do wzięcia udziału w następnej edycji. Jeśli będzie tak jak w tamtym roku – odbędzie się w zimie.

Na koniec linki do strony Dominika, gdzie możecie zapoznać się nie tylko z jego prezentacją, ale innymi wpisami w tej samej tematyce:

Slajdy z prezentacji
npp.run

Jedno przemyślenie nt. „Relacja z Making Software Developers’ Meetup Summer 2016