boiling-frog-492x472

Boiling Frogs 2017 – relacja

Tym razem konferencja odbyła się w Hali Stulecia, ponieważ organizatorzy zdecydowali się podwoić liczbę uczestników. Przyznam, że osobiście wolę trochę bardziej kameralne konferencje – dlatego też rok temu podobało mi się bardziej. Ale tylko jeśli chodzi o organizację. Merytorycznie było tak samo dobrze jak poprzednio. Żałuję, iż Boiling Frogs ma miejsce w zimie, ponieważ lokalizacja latem pozwalałaby na oglądanie pokazów multimedialnej fontanny, która znajduje się właśnie na pergoli przy Hali Stulecia. Zimą jest troszkę mniej atrakcyjnie.

Sale w których odbywały się prelekcje były na dwóch różnych piętrach, więc troszkę było biegania, ponieważ przerwy nadal były 15 minutowe. Organizatorzy przyznali, iż zaprosili za dużo prelegentów przez co przerw nie dało się wydłużyć. W jednej z sal zdecydowanie problemem był brak klimatyzacji, ponieważ z godziny na godzinę było trudniej w niej wysiedzieć a brak tlenu = drzemka:) Nie wiem czy to problem całego obiektu czy tylko tej sali. Była największa z tych w których odbywała się konferencja, w innych tego problemu nie zauważyłam, ale pojawiał się problem z dużo za małą ilością krzeseł. Tak więc troszkę problemów organizacyjnych się pojawiło. Jednak nie odstraszy mnie to od odwiedzenia konferencji za rok:)

A teraz troszkę o prelekcjach:

Pierwsza na którą się wybrałam to Clean architecture: co z tego możesz wziąć dla siebie? Mariusza Sieraczkiewicza.  Opowiedział nam trochę o różnych typach architektur oraz o tytułowej Clean architecture podając przy okazji trochę jej wad i zalet.

Kolejna to  Pair programming — sposób na lepszy kod i mocniejszy zespół Krzyśka Jończyka. Mnie osobiście do pair programmingu namawiać nie trzeba. Bardzo lubię to robić i staram się nawet zdalnie praktykować tą metodę. Większość ludzi bywa niestety niechętna – tym wszystkim polecam tą prezentację. Krzysiek opowiada na przykładach z życia o tym jak dużo pair programming wnosi dobrego dla programistów a także dla biznesu. Mianowicie – programistom pozwala lepiej i szybciej uczyć się od siebie nawzajem a kod zyskuje na jakości, ponieważ błędy wychwytywane są częściej już w trakcie tworzenia oprogramowania. Pair programming przyspiesza też wdrażanie nowych osób w firmie czy też w projekcie – chyba każdy z nas wie, iż najszybciej uczymy się od siebie nawzajem. No i w końcu siedzenie razem nad jakimś zadaniem powoduje, iż nawiązują się w zespole silniejsze więzi, ludzie poznają się nawzajem i tym samym zyskuje na tym cały zespół.

Krzysiek podzielił się również ciekawym podejściem do pair programmingu, którego przyznam, że nigdy wcześniej nie stosowałam w PP, ale na pewno zacznę – mianowicie technika pomodoro. Dla tych, którzy nie wiedzą o co chodzi – jest to technika, której główną zasadą jest by pracować w 25 minutowych interwałach i po każdym z nich robić 5 minut przerwy. Z kolei po 4 interwałach zrobić dłuższą np. 20 minutową przerwę. Do tej pory zdarzało mi się  to stosować to w pracy samodzielnej. Ważne jest jednak to, że nie każde zadanie nadaje się do realizacji w technice PP i tutaj zawsze musimy się wykazać pewną dozą doświadczenia i zdrowego rozsądku.

Następna prezentacja to Developer na detoksie Michała Płachty. Tutaj przyznam, że z opisu spodziewałam się czegoś bardziej o asertywności w podbramkowych sytuacjach, gdy tuż przed wyjściem z pracy nagle zdarza się pożar a my musimy zdecydować czy ratujemy pracę kosztem życia prywatnego czy też delegujemy nasze zadania by jednak życie prywatne nie ucierpiało.

Jednak Michał opowiada o czymś również ciekawym – mianowicie o naszych sposobach postrzegania świata i sposobach podejmowania decyzji. I tak mogliśmy się dowiedzieć, że jeśli przyjdziemy do lekarza a on zamiast przepisać nam lekarstwa bez namysłu, najpierw sięgnie do książki, to my stracimy do niego zaufanie. Z kolei większe zaufanie wzbudza w nas lekarz ubrany w fartuch lekarski niż taki bez – mimo, że nie mamy pojęcia o wiedzy jaką posiada jeden albo drugi. Mamy również tendencję do zakładania, że wiemy jak coś działa tylko dlatego, że używamy tego na co dzień. Tymczasem większość ludzi nie jest w stanie opisać poprawnie niektórzych codziennie używanych mechanizmów. W ten sposób posługując się jak to nazwał Michał „iluzją wiedzy” oraz „iluzją zaufania” tworzymy nasze opinie. Problem w tym, że często przyjmujemy różne opinie za pewnik i nie próbujemy ich kwestionować ani nawet się nad nimi zastanawiać. Dlatego potrzebny nam detoks – abyśmy ponownie zaczęli sobie zadawać pytania. Michał przywołuje w swojej prezentacji całą masę ciekawych badań, dlatego też zachęcam do obejrzenia jej jeśli tylko będziecie mieli okazję. Zapewne już niedługo pojawi się w internecie – informacji szukajcie na stronie Boiling Frogs.

A później były mikroserwisy w wydaniu Jakuba Kubryńskiego (SLA i utrzymanie mikroserwisów)  – tutaj muszę przyznać, że byłam na kilku prezentacjach z tego tematu i bardzo często jest nudno. Tym razem jednak było bardzo życiowo. Kuba radził, przestrzegał, dzielił się naprawdę fajnymi doświadczeniami i przede wszystkim podkreślał, iż mikroserwisy nie są dla każdego. W sumie osobiście mocno się z tym zgadzam, zwłaszcza że nie tylko z mikroserwisami jest tak, że gdy coś nowego się pojawia wszyscy się nagle na to rzucają i chcą stosować gdzie popadnie. Jednak kiedy opada pierwszy entuzjazm a jednocześnie pojawiają się pierwsze problemy, widzimy że nie wszystko powinniśmy na siłę próbować stosować wszędzie. Kuba zaleca rozsądek i radzi jak zdecydować czy mikroserwisy są dla nas czy nie.

Po przerwie obiadowej udałam się na lightning talk do Ani Konopki – Jak nie zmarnować 8h a biurkiem. Ania przedstawiła nam sposoby na rozwinięcie swoich „umiejętności miękkich” w trakcie całego dnia pracy.

Bardzo dobrze bawiłam się na prezentacji Borysa Łąckiego ptBezpieczne programowanie — świat pełen błędów. Można było się dowiedzieć o różnych niebezpieczeństwach jakie czyhają na nas w świecie opanowanym przez inteligentne urządzenia, które tak chętnie instalujemy w naszych inteligentnych domach czy samochodach. Wśród opowiedzianych historii znalazły się m.in. historia o tym jak z inteligentnej opaski da się odczytać ruchy naszej ręki a tym samym piny jakie wpisujemy, o tym że można wyłączyć zdalnie zabezpieczenia na myjni i nasz samochod zostanie zniszczony, o przejmowaniu kontroli nad samochodowym radiem lub przeciążeniu rozruszników serca powodując nagłe osłabienie baterii. Prezentacja bardzo ciekawa i dobrze sobie coś takiego od czasu do czasu obejrzeć, by pamiętać o tym by rozsądnie podchodzić do wszystkich innowacji. Ją również polecam na przyszłość, gdy tylko się pojawi w sieci.

Ostatnia prelekcja o które chciałabym wspomnieć, to „Kariera developera. Zostałem seniorem i co dalej?” Michała Grucy. Jest to temat, który żywo mnie nie interesuje, ponieważ podobnie jak Michał mam wrażenie, że kolejnym krokiem po byciu senior developem od człowieka oczekuje się, że zostanie leadem, managerem itp. Większość firm niestety w tym kierunku pcha developerów co jednak nie zawsze jest dobre. Stanowiska te wymagają specyficznej wiedzy, często powodują ograniczenie obowiązków programistycznych co może prowadzić do tego, że nie każdy developer się tym odnajdzie. Michał przypomina o tym, że są jeszcze inne drogi i że przede wszystkim dużo zależy od firmy w której się znajdujemy. Jeśli jest ona prawdziwie otwarta na nasz rozwój w pożądanym przez nas kierunku jest duża szansa, że uda nam się zamiast rosnąć w górę na leada, na przykład urosnąć „w bok” zdobywając wiedzę w nowej technologii.

Na afterze było jak zawsze troszkę za głośno, ale bardzo miło. Bardzo się cieszę, że udało mi się być na konferencji w tym roku. Dziękuję organizatorom za świetną pracę i do zobaczenia za rok!

Jedna myśl na temat “Boiling Frogs 2017 – relacja”

  1. Wow, poza jedna prezentacją („Developer na detoksie”) udało mi się wybrać wszystkie inne całkiem inaczej niż Ty 😛
    To chyba pokazuje, że fajnie mieć kilka ścieżek do wyboru i konferencja może podejść osobom o bardzo różnych zainteresowaniach w ramach IT. Było faktycznie całkiem fajnie 😉

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *