Ola Kunysz

Zdarzają nam się w pracy hackathony, podczas których testujemy jakieś narzędzia, frameworki, albo zwyczajnie zapuszczamy się tam, gdzie zazwyczaj nie ma czasu. Czasem pracujemy w grupach, czasem w pojedynkę. Zawsze jest w tym dużo zabawy i taka dziecięca radość z odkrywania nowych rzeczy. Polecam każdemu! (jeśli Twoje pytanie brzmi: "ale jak przekonać do tego przełożonych?", to dodam, że wiele z konceptów testowanych podczas hackathonu ląduje na produkcji. Ba! Ląduje tam szybciej, niż gdyby miały początek w Jirze) Do rzeczy. Na ostatnim hackathonie postanowiłam przetestować Visii , czyli serwis do wyszukiwania wizualnego. Współpraca polega na tym, że karmi się ich zbiór swoimi danymi, a o ni zajmują się przeszukiwaniem tego zbioru na podstawie obrazów.  Było to o tyle ciekawe, że moja koleżanka pracowała na tym samy zbiorze danych, ale z pomocą AWS  SageMaker'a, więc  na trochę niższym poziomie. Mogłyśmy na końcu porównać wyniki: czas + koszty vs jakoś ć zwracanych prod

To był jeden z najdziwniejszych miesięcy w moim życiu zawodowym. Zaczęłam dostawać propozycje wystąpień na spotkaniach na drugim końcu Polski, moja prezentacja została zaakceptowana przez dwie duże konferencje, prawie codziennie ktoś mnie namawia do prezentowania, albo ja namawiam innych. Dzieje się dużo i szybko. Tak wygląda rzeczywistość większości moich koleżanek w IT. Ciekawe, że lata działalności organizacji typy Carrots i WiT nie zrobiły tak spektakularnego zamieszania, jak kilka twittów. Gdyby nie majówka w Bieszczadach, mogłabym nie złapać do tego dystansu i znów się rzucić na zbyt dużo na raz. Mam nadzieję, że to nie chwilowy ruch spowodowany paniką przed spaleniem na stosie i ta rzeczywistość stanie się normą, nie powodując uszczerbków na niczyim zdrowiu psychicznym.  Czuję ekscytację i presję równocześnie. Jeszcze mocniej czuję, że te prezentacje muszą być dobre, bo oto grupa sceptyków różnorodności szykuje swe oręże :) A tak poważnie, to wspaniale, że będę się spotykać z

Nie wiem, co mam myśleć o uwadze, która spadła ostatnio na Code Europe. Niby dobrze, że ktoś podnosi takie tematy, ale czy to właściwy ton i czy to jedyna taka konferencja? Niestety większość konferencji tak wygląda w polskim IT. Kiedy patrzysz na listę prelegentów, to masz wrażenie, że to impreza dla białych chłopców (tak, chłopców, bo rzadko wiek prelegentów przekracza czterdziestkę), a przecież branża wygląda inaczej. Jest mało kobiet w działach technicznych, to fakt, ale przecież są i robią rzeczy, i robią je dobrze, chodzę na ich prelekcje regularnie. Więc dlaczego świetne prelegentki występują głównie na imprezach dla kobiet?  Zrobiło się nam towarzystwo wzajemnej adoracji w polskim IT. Jeśli popatrzysz na 10 największych konferencji z polskimi prelegentami, to wszędzie pojawiają się te same twarze, z nierzadko tymi samymi tematami. Te tematy często są po prostu słabe, ale nikt nie rozdziera szat, ot rachunek prawdopodobieństwa. Ale kiedy prelekcja jednej (1/1) prelegentki jest

Miałam ostatnio okazję być na wrocławskim JUGu, na którym Paweł Zajączkowski opowiadał o projektowaniu Web API. Poza tym, że zostałam wzięta za rekruterkę ( wow wow, community takie otwarte ), to otworzyły mi się oczy na kilka nowych tematów. Na codzień pracuję z Web API i staram się projektować je w sposób przyjazny jego użytkownikom (najczęściej developerom na froncie). Okazuje się, że to nazywa się APIX - API Experience. To taki piękny punkt, w którym biznesowy świat UX wkracza w czeluści kodu backendowego. Bo jako programiści nawzajem też jesteśmy swoimi klientami i też powinniśmy dbać o komunikację między naszymi serwisami, albo komponentami. Doświadczony developer wie, że częściej czyta się kod, niż się go pisze. No może greenfieldowe projekty mają na początku odwrotne statystyki, ale z biegiem czasu zrównują się z innymi. Cały kod, który jest w projekcie, api, komendy devopsowe, wszystko jest danym nam dziedzictwem, zwanym legacy  / ˈlɛɡəsi / . Żeby efektywnie dbać o to dziedz

Pierwszy raz ze specjalizacją w programowaniu logiki biznesowej spotkałam się w książce Soft Skills  John'a Z. Sonmez'a. Zapaliła mi się żaróweczka i otworzył przede mną nowy świat, bo oto okazało się, że oprócz standardowego podziału na frontend i backend, jest taka działka jak pisanie głównej treści aplikacji. Stało się dla mnie jasne, dlaczego zawsze bardziej jarały mnie prezentacje o DDD i dyskusje o zbieraniu wymagań, niż gadanie o bebechach JVMa i decydowanie o wyborze frameworków. Piękny moment olśnienia, życzę każdemu! Dlaczego odnoszę to do książki Async Remote ? Poza tym, że Robert Pankowecki i Andrzej Krzywda są ewangelizatorami DDD, Event Souring'u, CQRS'a i innych buzzwordów "dla biznesu", poruszają w książce bardzo ciekawe i trudne zagadnienie, jakim jest zbieranie wymagań i tworzenie prototypu funkcjonalności biznesowej. Dzielą się tym, w jaki sposób tworzą działający szkielet aplikacji, zanim wybiorą bazę, system autoryzacji, a nawet framewor

Zacznę od wątpliwości. Wątpliwości, które wzbudził we mnie rozdział o podziale zadań. Taski jednopunktowe to całkiem sensowna propozycja. Po moich ostatnich doświadczeniach z ugrzęźnięciem na nieznanym terytorium doceniam pomysł. Ale możliwość wzięcia pierwszego taska z listy to już trochę abstrakcja. Większość zespołów nie jest jednorodna. Ja przynajmniej nigdy w takim nie pracowałam. Nawet jeśli jesteśmy fullstackami to zawsze mamy jakieś specjalizacje. Może to jest szufladkowanie, może lęk, albo zwyczajne lenistwo, ale nie zawsze da się wziąć cokolwiek. Będąc rycerzem backendu, biorę czasem taski frontendowe, ale raczej dotyczące kodu, niż dizajnu. Średnio czuję tę część tworzenia oprogramowania i nie potrafię dać jej tyle miłości, co choćby logice biznesowej. Więc o ile wezmę task pod tytułem Dodaj walidację pola X , o tyle zadanie Stwórz widok Y raczej ominę. Z drugiej strony wprowadzanie kategorii Frontend i Backend trochę sztucznie dzieli zespół i sprawia, że nigdy nie zagląd

Kiedy zaczęłam czytać Async Remote, już na początku uderzyło mnie coś, na co wcześniej nie zwracałam uwagi. Mimo kilkuletnich doświadczeń ze SCRUM'em, nigdy nie zauważyłam niszczącej mocy słowa  sprint . Faktycznie jest tak, że kiedy scrumowy sprint się kończy, to od razu zaczynamy następny. Niektóre zespoły mają nawet demo, retrospektywę i planowanie tego samego dnia. Wrażenie ciągłego pośpiechu może i powoduje ekscytację i poczucie produktywności, ale na dłuższą metę bardzo męczy. Bo, jak po każdym sprincie, należy się długi odpoczynek, czas na regenerację mięśni i przewietrzenie głowy. Inaczej możemy doprowadzić do wypalenia. Jest jeszcze jedna nienaturalna rzecz w sprintach, czyli podział pracy. Zazwyczaj nie zaczynami, ani nie kończymy zadań w tym samym momencie, a do tego jesteśmy zmuszeni. Może to powodować frustracje, a nawet wzajemne obwinianie w przypadku "niedowiezionego" sprintu. Ciekawe jest też podejście autorów książki do składu i obowiązków zespołu. Dopi

Kiedy pracujesz w zespole, w którym pięć osób przebywa w trzech strefach czasowych, mówi natywnie trzema językami i pisze kod w trzech innych, uświadamiasz sobie co tak naprawdę jest ważne w pracy. No bo nie osiem godzin spędzonych biurko w biurko, na piciu kawy i wspólnych posiłkach w firmowej kantynie. Ważne jest zaufanie. Zaufanie zdobyte pracą, uczciwą komunikacją i przezwyciężonymi problemami. Trochę nam się rozrósł zespół i postanowiliśmy się podzielić po 4-5 osób. Ja trafiłam do grupy, w której tylko jeden kolega, tak jak ja, pracuje we Wrocławiu, ale akurat postanowił wyjechać na workation do Tajlandii. Stało się bez znaczenia, czy pracuję z biura, z domu, czy z kawiarni. Ważne, żeby dostarczać dobry kod i żeby mój element układanki pasował do innych. Nie jest to takie oczywiste, bo komunikacja przy pracy całkowicie zdalnej ma inny wymiar. Dojście do konsensusu, kiedy wszyscy mówimy drugim dla siebie językiem jest co najmniej utrudnione. Mimo, że każdy z nas ma biegły angiels