Tag Archives: prelekcje

Różowy Windows Phone i kobiety na wysokościach

Posted in Uncategorized by

28. stycznia we Wrocławiu odbyło się 8. spotkanie Women in Technology. Niecnie wykorzystałam swoją znajomość z szefową i wkręciłam się wtedy na prelekcję ze swoim cyrkiem obwoźnym, czyli wstępem do programowania w Windows Phone. Sam łysogórski zlot odbył się na 25 piętrze SkyTower. Przypomniało mi się dość szybko, że mam lęk wysokości, więc przez całe spotkanie unikałam wielkiego okna z tyłu sali. Mimo wszystko trochę go przełamałam i udało mi się uchwycić widoczny stamtąd uliczny zgiełk.

wit

Gosia rozpoczęła spotkanie od przedstawienia kilku nowości technologiczno-konferencyjno-sponsoringowych (jakkolwiek dziwacznie to brzmi Uśmiech). Następnie po krótkim przedstawieniu się wszystkich, rozpoczęłam prezentację.

Po ostatniej porażce konfiguracyjno-przygotowawczej, mój poziom pewności siebie oscylował w okolicach –10. Dlatego tego dnia pojawiłam się na miejscu dużo wcześniej i sprawdziłam, czy na pewno wszystko dobrze działa.

Działało Uśmiech … do momentu, gdy miałam rozpocząć. Na pierwszy ogień poszedł rzutnik – nie chciał wyświetlić niczego co miałam na ekranie, choć robił to zaledwie 15 min wcześniej. No ale powiedzmy, że się na mnie obraził za to, że udostępniłam go Gosi zamiast tkwić wiernie przyczepiona kabelkiem. Nie obyło się bez jego restartu, co wprowadziło nieco ożywienia, bo pilot również odmówił współpracy. Pozostała więc drabina i ręczne użycie guzika prezentera przyczepionego do sufitu.

Potem oczywiście padła mi sieć i wywalił się emulator, ale… wpadłam na iście genialny pomysł. Zamiast miotać się z szukaniem problemów w konfiguracji, postanowiłam zastosować najstarszą sztuczkę w świecie IT – turn it off and on again… wiedząc, że mój komp wstanie w czasie ok. 5 sekund. Decyzja ta zbawiła moje wystąpienie, a dalsza część przeszła już gładko i bez zbędnych przerywników.

W kilku momentach pojawiły się dyskusje, ponieważ na sali obecne były ekspertki od Windows Phone. Sama też dowiedziałam się kilku rzeczy, dzięki czemu moja prezentacja po raz kolejny została ulepszona. Przekonywałam jak zwykle, by w codziennej pracy używać urządzenia zamiast emulatora. A z racji takiego, a nie innego grona, wzbudzałam mniej kontrowersji, gdy machałam różowym telefonem.

WP_20140128_001-150x150

Po mnie nastąpiła kolej na ćwiczenie networkingowe, za przygotowanie którego należy się wielki szacun dla Kasi. Dowiedziałyśmy się (pewnie po raz kolejny) jak ważna jest komunikacja i jak różne może przybierać formy. Poznałyśmy się trochę lepiej i już w całkiem luźnym, choć nadal licznym gronie wybrałyśmy się na afterowego browara.

Hack.Krk w końcu w .Net

Posted in Uncategorized by

Po frekwencji na poszczególnych eventach, wnioskować można, że wiele osób wie, iż Base organizuje od czasu do czasu hackatony. Jednak zdziwienie przyszło ze środowiska .Net, najpierw z powodu tego, że Base w ogóle .Netem się bawi, potem, że wpadliśmy na pomysł zorganizowania Hack.KRK specjalnie dla programistów tej platformy.

Base kojarzy się raczej z Railsami. Choć wiele osób dopuszcza myśl, że jako firma wyznająca zasadę post PC, zatrudnia programistów systemów Android, czy iOS, to .Net nie jest nasuwającą się na myśl technologią. Wydarzenie było więc dobrą okazją by uświadomić brać programistyczną, że takowych programistów również mamy i potrzebujemy. 24.01.2014 odbył się więc pierwszy Hack.Krk .Net, którego gwiazdą i przyciągaczem tłumów miał być Procent. Informacje o evencie pojawiły się dość późno, ale i tak zebrał się niemały tłumek ludzi chętnych o gry w statki.

Z chłopakami wymyśliliśmy właśnie taką formę challengu. Wymyśliliśmy to raczej nadużycie – byliśmy na piwie w tej sprawie i gdy ja akurat wróciłam z toalety, dowiedziałam się, o pomyśle Kuby. Podobno miał go już dawno, czekał jedynie na nasz odpowiedni stan upojenia by go jednogłośnie przepchnąć.

Zaczęły się więc prace – głównie w trakcie okresu świątecznego. Koncepcyjnie pomysł przeszedł od fazy pojedynku do końcowej wersji – losowej planszy z określonymi wcześniej ilością i rodzajami statków, którą to mieli rozpracowywać gracze. Punktów dostawało się więcej jeśli zatopione zostały wszystkie statki przy jak najmniejszej liczbie ruchów. Dodatkowo brana była statystyka z kolejnych prób, by zminimalizować szczęśliwe trafy algorytmów losowych.

Przyszedł piątek i do Krakowa, w siedzibie Base pojawiło się sporo .Netowców. I nie tylko, bo zadanie zastali w formie API restowego, więc niemal każda technologia się nadawała. Wprowadzeniem była Randka z Nancy Procenta, a po niej nastąpił fight. Wszystko odbywało się w luźnej atmosferze przy towarzystwie browarów i dobrego jedzonka. Większość obecnych pilnie kodowała, ale było jedna grupa… ehm… moja, siadła w kącie i … kłapała zamiast programować.

Ok. 21:30 ruszyły zaplanowane wcześniej lightning talks. Roman mówił o stateless code, ja o tym jak wszyscy powinniśmy być architektami i jak świetnie jest w tej materii w Base, a Natalia i Jan namawiali nas do uczestniczenia w hack4good. Każdemu wyszło nieco dłużej niż błyskawicznie, ale to chyba niczemu nie szkodziło. Zaraz po wystąpieniu dostałam zaproszenie na wygłoszenie wersji rozszerzonej na wroc.net.

Cieszę się, że namówiłam Adriana by przyszedł (choć przyznaję, że bardzo się nie opierał), gdyż inaczej całe podium należałoby do Base’owców. A tak przynajmniej srebro zgarnął ktoś z zewnątrz. Dwa pierwsze miejsca nagrodzone zostały czołgami, które miały wziąć udział w pojedynku, ale… Adrian zepsuł baterie do swojego Uśmiech Pozostało nam więc oficjalnie zakończyć wieczór.

Dla mnie zdarzenie to było okazją by zaprosić kilku znajomych do Krakowa i spędzić wspólnie weekend. Ponieważ uwielbiam mieszkać sama, bo jestem silna niezależną kobietą Uśmiech, na co dzień nie do końca trawię gości. Albo inaczej – śmiało mogę powiedzieć, że za nimi nie przepadam. Coś mnie jednak podkusiło i postanowiłam przełamać to w sobie, przynajmniej na ten jeden weekend. I nie było łatwo.

3 osoby w piątek i 4 w sobotę, to coś co można określić jako zupełne przeciwieństwo mojego dotychczasowego aspargera i aspołeczności. Ale dało się. Pomimo trudności, tego, że po mroźnej nocy nie zapaliło mi auto, że musiałam łózko dzielić z koleżanką i skazać dwóch gości na nocleg na podłodze. Zaliczyliśmy wspólnie Schindlera, hamburgery, wieczorne winko i towarzyszące temu dyskusje.

W niedzielę byłam bardzo zmęczona towarzystwem, ale również zadowolona, że udało mi się spędzić trochę czasu z ludźmi, których lubię. A Maciek suma summarum okazał się gwiazdą TV.

Przystanek KGD.NET, czyli jak przegrać u siebie

Posted in Uncategorized by

W styczniu miałam dość gorący okres, więc moje Windows Phonowe tournee postanowiłam kontynuować w Krakowie, by już daleko nie jeździć. Drugi gig zaplanowałam więc 22 stycznia na 85. spotkaniu KGD.NET. Ogólnie rzecz biorąc… nie poszło mi za dobrze. Dlaczego? To za chwilę, bo najpierw zrelacjonuje wieczór.

Weszłam na styk, powiedziałam co wiedziałam (i parę dodatkowych rzeczy też) i z podkulonym ogonem zebrałam się z miejsca na widoku w bardziej ustronny kąt. Po przerwie publikę na szczęście przejął Paweł, który opowiadał o tym jak budować efektywne zespoły (tak Pawle, wiem, że polskie słowo nie oddaje tego co chciałeś przekazać Uśmiech). Wskazał na znaczenie różnorodności członków zespołu i przedstawił jak w to wpasowują się kobiety i ich naturalne predyspozycje. Nie z wszystkim się zgadzałam, ale w przeciwieństwie do prelegenta nie stały za mną wyniki badań naukowych Uśmiech

600_326350732

Jak to często na spotkaniach KGD.NET bywa, punkt 21. przyszedł personel sprzątający, czego efektem było pospieszne losowanie nagród i zakończenie spotkania. After party odbyło się przy ciekawych smakach piwa i… cydru gruszkowego(?), a pod koniec pojawiły się nawet jakieś shoty. W gronie ograniczonym do 5 osób (organizatorzy, czyli Marta i Jarek, Szymon, Andrzej i ja), posiedzieliśmy do ok. północy poruszając dość szerokie spektrum tematów, choć w większości technologiczno-pracowych.

No a teraz… kilka wskazówek jak położyć wystąpienie publiczne Uśmiech

Zapytać o feedback

… dzień przed wystąpieniem. Tak było – we wtorek poprosiłam o informację zwrotną osoby, które były obecne na mojej prelekcji w Warszawie. Choć ogólna ocena była dobra i niemal każdy powtarzał, że mu się podobało, to… no cóż, mamy skłonność do skupiania się na negatywach. Zresztą na tym właśnie najbardziej mi zależało.

No i mi się dostało Uśmiech Nie, no trochę żartuję, ale spisałam sobie te uwagi i zaczęłam intensywnie myśleć jak tych samych błędów już nie popełnić, zwłaszcza, że miałam okazję sprawdzić to następnego dnia. Dość powiedzieć, że zabrałam się za mission impossible. Może gdybym wzięła na warsztat jedną rzecz, to miałoby to szanse powodzenia w tak krótkim czasie jakim była doba. A w tej sytuacji, zamiast prezentować, co chwilę przypominałam sobie moją listę niedostatków i szarpałam się chcąc wprowadzić implementację rozwiązania ad hoc.

Zaprosić na występ wszystkich znajomych Królika

Pomyślałam, jestem u siebie, więc wiele osób przychodzących na KGD znam. Kilku znajomych uprzedziło mnie o swojej obecności tego dnia (innych zobaczyłam na liście zapisanych osób). Wiedziałam, że pojawi się jeden kolega z pracy i jeden z moich studentów. Nie spodziewałam się jednak, że ok połowa audytorium, to będą znane twarze – z dawnych prac, z obecnej, ze studiów, z twittera, a także moi studenci. Można byłoby się spodziewać, że znajomi to dobre wsparcie, w końcu nie życzą źle i wybaczą potknięcia. A jednak – mój stres wzrósł niebotycznie. Tak jakby zwiększyło się we mnie poczucie odpowiedzialności – trochę mniej wstyd wyłożyć się przy obcych Uśmiech

Spóźnić się

Nie żeby to była jakaś wyjątkowa sytuacja w moim wydaniu. Ja się wszędzie spóźniam, chyba, że planuję, że będę godzinę wcześniej – wtedy istnieje pewna szansa na punktualność. No ale nie stało się tak tego dnia, kiedy to byłam starą dobrą spóźnialską Basią. Dodałam przez to stresu również organizatorom, bo wg planu występowałam pierwsza, Paweł pojawić się miał później. Publika, chyba nie do końca to zauważyła, ale mi przybyła cegiełka stresu i kilka siwych włosów.

Próbować odpowiadać na pytania, na które nie zna się odpowiedzi

To już była zupełna porażka… Wstyd mi do tej pory. Zamiast zwyczajnie, gdy do takiej sytuacji doszło stwierdzić: “Nie wiem, nie znam się, zarobiona jestem”, zaczynałam po prostu mleć ozorem. Tylko, że na moje nieszczęście, na sali było kilku ekspertów od WP, no i moje “mądrości” były szybko weryfikowane.

Dlaczego tak robiłam? Do dzisiaj nie wiem do końca. Chyba przejęłam się wnioskiem, który padł na początku autoprezentacji. Pracuję z WP już ok pól roku, więc powinnam występować z pozycji osoby bardziej doświadczonej niż początkujący programista tej platformy. A ponieważ zazwyczaj nie mam w naturze przyznawania się do poziomu advanced w jakiekolwiek dziedzinie (chyba, że mówimy o spaniu, oglądaniu seriali czy innych technikach marnowania czasu), więc… naprawdę nie wiem.

Nie przetestować połączenia internetowego

Czy też, jeśli już o tym mówimy, nie przetestować uruchomienia VS, emulatora, programu. Ale od początku. Aplikacja, która pokazuję łączy się z Twitterem, więc potrzebuje internetu. W siedzibie ABB (bo tam się spotkania odbywają) nie udostępniają wifi dla gości, umówiłam się więc z kolegą, że mi jej trochę pożyczy. Ponieważ byłam spóźniona, przetestowaliśmy to łebkach, no i oczywiście efekt tego był taki, że gdy chciałam wyświetlić listę tweetów, internet przestał działać. Potem do buntu maszyn dołączył emulator, uruchamiając się we wszystkich rozdzielczościach. W pewnym momencie rozłożyłam ręce, bo już nic się nie dało zrobić. Byłam wdzięczna losowi, że pozostało mi VS i miałam jak pozywać kod.

Pech, wiem, ale też rzecz, która tak naprawdę najmocniej z przedstawionych tutaj zadziałała na negatywny odbiór. Jak coś nie działa, cała prezentacja spada w głęboką przepaść laaaaame i jest jej bardzo ciężko się z niej wykaraskać.

Tak naprawdę nie wiem, czy było tak źle jak opisuję, bo większość feedbacku z tego wystąpienia brzmi: “Miałaś wyjątkowego pecha”. Czy to oznacza, że miała pecha, była klapa, więc trudno, let’s move on, czy miałam pecha, ale mimo to pokazałam coś wartościowego? Nie wiem. Osobiście mam nadzieję, że szala przechyla się w tę drugą opcję. A ja mam materiał do pracy na kolejne razy, z których pierwszy odbył się tydzień później we Wrocławiu. Ale to już w kolejnym odcinku…

Windows Phone w stolicy

Posted in Uncategorized by

Pewnie nie wszyscy wiedzą, ale od kilku miesięcy zajmuję się programowaniem w Windows Phone. A ponieważ najlepsze tematy na sesje powstają w pracy, postanowiłam co nieco o tym opowiedzieć, gdy umawiałam się na swoją pierwszą poważną sesję na grupie .net. Temat jednak wtedy nie siadł, architektura była bardziej pociągająca, postanowiłam więc ruszyć z nim w tournee w inne rejony.

I tak 16. stycznia tego roku pojawiłam się w końcu jako prelegent na 71. spotkaniu WG.NET. W końcu, bo Michał, szef grupy, namawiał mnie na wystąpienie już… 6 lat temu. Ale, jak to mówią, co się odwlecze, to nie uciecze, zawitałam więc w końcu do stolicy.

Osobiście bardzo podobał mi się support, zrobiony przez Sebastian Solnicę, który opisywał różne czary, jakie można zrobić przy debuggowaniu z pomocą Visual Studio. O większości nie miałam bladego pojęcia, a ponieważ lubię się uczyć nowych rzeczy, jestem Sebastianowi bardzo wdzięczna. Dodatkowo niezmiernie przypadły mi do gustu jego dowcipy. Nie miałam więc nic przeciwko temu by snack rozciągnąć do… 40 minut, bo świetnie bawiłam się przy tej prezentacji. Oczywiście cały ten czas zjadał mnie stres, a dzięki temu chwilę mojego wystąpienia mogłam nieco odwlec. Wreszcie jednak nadeszła godzina zero… wyszłam i  zaczęłam mówić.

Prezentacja

Moja prelekcja nie miało być monologiem eksperta, lecz garścią informacji o tym jak zacząć budować aplikacje na WP i na co zwrócić uwagę. Nie chciałam nawet nikogo przekonywać do programowania mobilnego ani pracy na tej platformie. Miałam natomiast meta cel – by zachęcić innych do występowania, nawet jeśli w danym temacie nie są alfą i omegą.  Dużo może dać samo przygotowanie prezentacji. Dla mnie największym wyzwaniem było zrobienie aplikacji od zera, gdyż w pracy zastałam ją w pewnym sensie gotową. Siedziałam nad tym cały (piękny Uśmiech) weekend.

Plan początkowo miałam taki, by taką prostą appkę zbudować na oczach widowni. To by dopiero mi dodało parę punktów do zaje…fajności. Wiadomo jednak jak to jest z planami – aplikacja się rozrosła i tworzenie jej w real time byłoby niczym innym, jak strzałem w kolano. Zdecydowałam się więc na pokazywanie kodu i jego różnych aspektów.

Agenda wyglądała mniej więcej tak:

  • Konfiguracja środowiska deweloperskiego
  • Uruchamianie i debuggowanie
  • Jak budować GUI
  • Zastosowanie MVVM
  • Testowanie
  • Praca z bazą danych
  • Kilka niespodzianek programistycznych

Gdy już zaczęłam, czułam się bardzo dobrze i swobodnie. Pewnie dlatego, że audytorium było bardzo przyjazne, choć niestety dla mnie już nieco zaznajomione z WP. Poczułam lekki pomruk zdziwienia i rozczarowania, gdy przyznałam, że nie jestem ekspertem i pokażę podstawy. Mimo to dostałam wiele pytań w trakcie, a także po i nawet umiałam na niektóre opowiedzieć (o czym później). Przede wszystkim zdałam sobie sprawę jak jeszcze niewiele wiem i jak dużo pracy przede mną.

Po wszystkim, jak to jest w zwyczaju, postanowiliśmy się wybrać na piffko. Szkoda, że jedynie w znanym mi gronie Kuby, Marcina, Karola i Sebastiana (chłopaki załóżcie blogi, będziecie się świecić na niebiesko Uśmiech). Liczyłam po cichu, że poznam kogoś nowego, ale mimo to świetnie się bawiłam, a stres prezentacyjny powoli, za to skutecznie ze mnie zszedł.

Feedback

Po pewnym czasie poprosiłam osoby obecne wtedy na sali o feedback, a o tym co m.in. było tego konsekwencją jeszcze kiedyś napiszę. Teraz przedstawię czego się dowiedziałam, a być może to spowoduje, że wezmę sobie te informacje do serca. Ponieważ ja zawsze wszystko wiem, najbardziej druzgocący był dla mnie fakt, iż można było mnie czymś zaskoczyć, że ludzie mają uwagi, o których nie miałam pojęcia.

Plusy

Nie będę robić kanapki z g…, w końcu to mój blog i moja informacja zwrotna. Powiem więc najpierw o tym co było fajne, a potem przedstawię obszary do poprawy. Po pierwsze miło było się dowiedzieć, że byłam pierwszą dziewczyną-prelegentką występująca na wg.net. Inną sprawą na plus było to, że odbiór prezentacji był dość pozytywny. To było zresztą widać, gdy po prelekcji ludzie podchodzili do mnie i pytali o rady. Dostałam też kilka maili w związku z tematyką.

What’s the point?

Jak to często u mnie bywa, dużo mówiłam, ale brakowało jasnego celu, zdania czy tezy, wokół których obracałaby się prezentacja. Męłłam ozorem, ale nie wynikał z tego żaden wniosek. Choćby taki czy fajnie czy niefajnie programuje się w WP. W pewnym sensie miałam nadzieję, że moim clu będzie to, że na platformie programuje się… śmiesznie i dość niedeterministycznie. Nawet udało mi się to pokazać – publicznie wywaliło mi się debuggowanie, internet, a nawet Visual Studio, a chciałam pokazać jedynie jak wolno uruchamia się emulator. Ale i tu pojawiły się wątpliwości u odbiorców – wyszło trochę nieprofesjonalnie.

Q&A

Inne informacje dotyczyły tego, że pozwalałam na pytania w trakcie prezentacji, a nie czekam z tym na koniec. To podobno dość rozpraszało odbiór. Trochę mnie ta uwaga zasmuciła, bo kontakt z widownią jest dla mnie kwestią priorytetową, a bez pytań się tego nie osiągnie. Najgorsze, że momentami wydawało się, iż nie znam odpowiedzi, a próbuję jednak ją wyprodukować zamiast przyznać, że czegoś nie wiem. Z drugiej strony sama zadawałam chyba za mało pytań, co tylko smutek mój spotęgowało.

Inne dobra…

Z innych spraw – widać było, że się stresuję, siedziałam, co minimalizowało dynamikę (choć to trudno będzie przeskoczyć, gdy pokazuje się kod) i za dużo robiłam osobistych odniesień do znajomych z sali. Dodatkowo dostałam dwie skrajnie różne uwagi – pokazywałam za mało i za dużo kodu, więc w tej kwestii muszę zdać się na własny judgement call.

Podsumowując, wystąpienie na wg.net było dla mnie bardzo przyjemne i wygląda na to, iż również dla słuchających mnie osób. Mam więc nadzieję, że jeszcze dostanę zaproszenie do Warszawy Uśmiech

Does great power… vol.2

Posted in Uncategorized by

Kontynuując i uogólniając nieco motyw architektury, a wchodząc głębiej w temat władzy, chciałam podzielić się przemyśleniami dotyczącymi szeroko pojmowanego zagadnienia podejmowania decyzji. Wątpliwości, również te dotyczące architektury, rozstrzygane są zazwyczaj przez osobę uznawaną za najbardziej kompetentną, eksperta w danej dziedzinie, lub wspólnie na drodze dyskusji w zespole. Architekt będzie więc taką właśnie postacią, wydającą postanowienia na konkretnym polu – architektury Uśmiech

W zależności od tego w jakim trybie się to dzieje, rozróżniane są pewne style podejmowania decyzji obowiązujące w danej firmie, zespole, czy branży. W dalszej części przedstawię jedną z takich klasyfikacji, a następnie spróbuję przyporządkować je do konkretnych rodzajów firm – od korporacji, po startup.

Style podejmowania decyzji

Jeśli pogooglujemy tytuł tego akapitu, ukaże się nam cała lista sposobów dojścia do kompromisów. Istnieje oczywiście wiele podziałów, czy systemów klasyfikacji, ja natomiast chciałam zwrócić uwagę na następujące cztery style:

  • Autorytatywny
  • Autorytatywny z konsultacją
  • Demokratyczny
  • Wspólne podejmowanie decyzji

Wbrew pozorom nie jest to lista od opcji najgorszej po najlepszą, gdyż wszystkie mają rację bytu w konkretnych sytuacjach. Zanim jednak zaczniemy oceniać, dodam parę wyjaśniających słów o każdej.

Autorytatywny

Autorytatywny styl to taki, w którym jedna osoba, która (przynajmniej w teorii) wie wszystko najlepiej, podejmuje ostateczne decyzje. Może to być ktoś najbardziej doświadczony, naturalnie wyłoniony lider, lub po prostu szef zespołu, firmy, czy projektu.

Niekoniecznie jest nim jakiś trzęsący wszystkim Krzysztof Jarzyna ze Szczecina, ale zwyczajnie ktoś wyznaczony do nadawania sprawom kierunku, od kogo oczekuje się wiedzy, odpowiedzialności, i kto dostaje za efekty swoich wyborów odpowiednią gratyfikację finansową lub ochrzanową. Sytuacja taka jest częsta, gdy na zespól składają się niedoświadczone młokosy, które albo zostały postawione w roli słuchaczy spijających mądrości z ust guru, albo nawet same oczekują, że ktoś nimi pokieruje i powie jak sprawy mają być robione właściwie.

Autorytatywny z konsultacją

Sposób podobny do poprzedniego  – nadal mamy tu jedną osobę, ale za to na tyle dojrzałą, by uznawała również zdanie innych. Konsultacje konsultacjami, ale wciąż jest pewnego rodzaju szef, który automatycznie staje się autorem i bierze odpowiedzialność za to co wyprodukował zespół.

Wszyscy wiemy, że sytuacja taka przyjmuje różne formy – od tego, że zasięganie rad jest udawane, po jedynie podpis pod wysiłkami teamu. Opcja najlepsza to oczywiście coś pośrodku. Choć wątpliwości budzi sprawa, gdy za zasługi nagrodę dostaje decydent, to jednak wiele zespołów taki system akceptuje ze względu na kary w razie braku sukcesów.

Wydaje mi się, że jest to najczęściej funkcjonujący model w firmach. W końcu to właśnie kierownikowi czy ekspertowi płaci się za podejmowanie decyzji i to on powinien ponosić ich konsekwencje. Styl ten to parafraza zdania, które często słyszę gdy rozmawiam o kierowaniu zespołem: “Jasne, że trzeba dyskutować, ale w końcu ktoś MUSI podjąć decyzję!”. Członkowie zespołu często zresztą godzą się na taki układ, lub jeśli nie – startują w szranki o odpowiedni stołek. Po co? Otóż po to, by samemu stanąć w roli autorytetu. Styl ten występuje więc, gdy zespól jest dojrzalszy, składa się z osób o pewnym już doświadczeniu i wiedzy, ale z funkcjonującym szefem-decydentem.

Demokracja

Demokracja jak to demokracja – polega na tym, że wygrywa decyzja większości, i niestety, gdyż to ma do siebie ten system, powoduje niejednokrotnie niezadowolenie tej części, która ma inne zdanie. Osobiście nie spotkałam się z czystą implementacją takiego typu dyskusji – zazwyczaj oczywiście brane jest pod uwagę to co mówi głos ludu, ale decyzja podejmowana jest znów przez konkretną, specjalnie do tego wyznaczoną osobę. Nie widziałam i nie brałam udziału w wymianie zdań, która miała w swoich zasadach zapis: “teraz robimy głosowanie, potem zliczamy karteczki, a gdy się rozejdziemy, to robimy tak jak zagłosowała większość, tzn. przynajmniej 50% + jeden głos”.

W mojej skromnej opinii ta opcja jest najgorsza ze wszystkich czterech. Zazwyczaj jeśli decyzję podejmuje jakiś, nawet nielubiany, szef, to ludzie to łatwiej ją przyjmują niż wynik głosowania. Mówiąc ludzie mam tu na myśli członków opozycji. Pewnie dzieje się tak z tego względu na fakt, iż glosowanie wprowadza na pewnym poziomie tajność. Decyzja traci jedną twarz, pojawia się za to interfejs grupy. Trudniej jest kogoś winić i z kimś się spierać.

Wspólne podejmowanie decyzji

Brzmi jak utopia, co? No cóż… pewnie dla niektórych nią jest. Ja miałam niewątpliwą przyjemność uczestniczyć w takich właśnie polemikach. Model w skrócie polega na tym, że zespół dyskutuje, przekonuje, dyskutuje, przekonuje, a na końcu wspólnie się na coś zgadza.

Wygląda pięknie, ale jest dość trudne we wdrożeniu, i to z kilku względów. Po pierwsze, gdy wchodzimy na tematy “wiary”, których w świecie IT jest całe mnóstwo, może być ciężko zatrzymać rozhulane w kłótni towarzystwo. No i kto niby ma to zrobić? Uśmiech. Po drugie, jeśli mamy bandę indywidualistów, o których również u nas nietrudno, to każdy będzie miał tendencję do ciągnięcia w swoją stronę. Po trzecie jeśli członkowie grupy nie do końca czują, że to na co się zdecydują, ma być dobre nie dla nich z osobna lecz dla projektu, jego celu lub zespołu jako całości, rozmowa może dotyczyć prywatnych interesów.

Jednak gra jest warta świeczki – produkt w postaci decyzji zespołu, gdzie każdy z osobna rozumie ją w pełni i wie dlaczego jest taka a nie inna, to filar, na którym można zbudować dosłownie wszystko. Zabrzmi jak banał, ale nie ma lepszego sposobu na zbudowanie motywacji w człowieku niż zaangażowanie go w realizację, zaczynając oczywiście od jego wpływu na decyzje. Do tego jednak potrzebny jest wysoki poziom świadomości i rozwoju członków zespołu. Każdy powinien zdawać sobie sprawę z tego, że jego zdanie nie tylko jest ważne, ale wręcz niezbędne. W takiej ekipie potakiwacze i bierni słuchacze funkcjonować mogą, ale marnują daną im okazję na dołożenie swojego klocuszka w procesie.

Decyzje w firmach

Można pomyśleć, że jedynym słusznym modelem jest wspólne podejmowanie decyzji, autorytaryzm nie ma w ogóle racji bytu, a demokracja jest ewentualnie dopuszczalna. Otóż… (tu użyję mojego najmniej ulubionego sformułowania) TO ZALEŻY Uśmiech Na przykład zestawiając różne firmy pod względem wielkości czy struktury, można zaobserwować zależności dotyczące styli podejmowania decyzji.

Korporacja

Jeśli miałabym opowiedzieć się za jednym stylem, to stwierdziłabym, że w korporacjach dominują decyzje autorytatywne. Choć firmy te same często twierdzą, że w proces wplatana jest konsultacja, czy to z członkami zespołu, czy z ekspertami dziedzinowymi, to jednak śmiem twierdzić, że udaje się to jedynie czasami. A dokładnie wtedy, gdy sprawa nie dotyczy kwestii na tyle ważnych, by góra musiała się nimi trudzić. W takim wypadku pozwala się je rozstrzygać na niższych poziomach.

Mała rodzinna firma

Wydawałoby się, że nie ma nic bardziej różnego od korporacji, niż mała rodzinna firma. A jednak … jeśli jest w niej jeden Wielki Informatyk (jak Wielki Elektronik z Pana Kleksa) pod postacią CTO, nadwornego architekta, czy nawet CEO, to decyzje podejmuje właśnie on. Jeśli firmę tworzą specjaliści o porównywalnych umiejętnościach i doświadczeniu to jest szansa na większy głos tych ludzi.

Średnia firma

Jeśli mała firma się rozwinie, to staje się czasami średnią. Wraz ze wzrostem liczby osób, pojawia się jakaś struktura, czasami nawet kilkupoziomowa. Decyzje podejmowane są przez szefa konkretnej jednostki. Firmowe – przez prezesa, czy zarząd, przez co są zazwyczaj autorytatywne, natomiast działowe/zespołowe – przez kierownika/dyrektora. To, czy te ostatnie włączają konsultacje, w dużej mierze zależy od tych konkretnych managerów. Pojawia się teraz moment na wrzucenie do zarządzania opcji demokracji lub nawet wspólnego podejmowania decyzji.

Startup

Startup w pewnym sensie przypomina małą firmę, lecz rozdzieliłam je z premedytacją. Chciałam podkreślić, że tutaj nacisk położony jest na innowację i rozwój, a co za tym idzie istnieje większe przyzwolenie na swobodę. Dzięki temu powstaje sporo miejsca na demokrację, czy nawet na autonomiczne wypracowanie rozwiązań w zespole. Choć początkowo przypomina to chaos, i można mieć wrażenie, że żadne decyzje nie są podejmowane, to w skutecznych startupach jest to jedynie faza wypracowująca zespoły wysokiej skuteczności.

Powyższe prawdy to oczywiście uogólnienia (których z reguły nie cierpię), sformułowane jedynie na podstawie mojego doświadczenia (i doświadczeń innych ludzi, których znam). Z pewnością są korporacje, gdzie zdarza się fajna polityka lub szef, który bierze zdanie zespołu pod uwagę, a nawet pozwala na ich własne decyzje. Pewnie są mniejsze firmy, które gdy dochodzi do rozstrzygania sporów, zachowują się bardziej formalnie niż niejedna korporacja.

Temat będę kontynuować… W kolejnym odcinku opowiem historię życia w ujęciu architektoniczno-decyzyjnym.

Does great power come with great responsibility? vol. 1

Posted in Uncategorized by

… parafrazując słowa Bena Parkera, wujka Spidermana (wiem, że dla niektórych to żenada tego nie wiedzieć, lecz mimo to wyjaśniam)…

Temat wyszedł z moich refleksji o architekturze oprogramowania, więc postanowiłam zrobić z niego prezentację, którą przedstawiłam po raz pierwszy w Białymstoku na grupie .Net. Wiele wątków, które tu umieszczę pochodzi od słuchaczy, post będzie więc kumulacją naszych wspólnych przemyśleń.

O co więc chodzi z tą władzą i odpowiedzialnością? Zacznę od tego, że każdy z nasz developerów chce lub kiedyś chciał zostać architektem (ew. managerem, ale nie o tym odłamie programistów chcę teraz pisać). Jeśli nigdy nie chciałeś i nie chcesz, to podejrzewam, że jesteś na początku swej drogi i wizja ciebie jako architekta jawi ci się jako cos jeszcze zbyt nieosiągalnego.

Otóż jest taki moment w życiu programisty, w którym ktoś obdarza nas i nasze kompetencje zaufaniem. Powierza nam odpowiedzialność w postaci decyzji architektonicznej. Możemy mieć wpływ na kształt projektu, być może tylko na wybór frameworka, a jednak w efekcie uderza nad woda sodowa do głowy. Teraz, myślimy, pokażemy wszystkim jak to się robi dobrze…

Architektura?

Ale zanim o rządach, to może słów kilka o tym, czym właściwie jest architektura. Jak się pogógla, to znajdziemy tysiąc definicji i perspektyw na zjawisko. Dla jednych to fizyczne komponenty systemu – serwery, szyny, chmury, dla innych podział systemu na warstwy, dla jeszcze innych pewne niefunkcjonalne wymagania, jak bezpieczeństwo czy niezawodność.

Z jedną rzeczą wszystkie te strony zazwyczaj się zgadzają – architektura, niezależnie od obecności pilnującej jej osoby – zawsze jest. Na domiar złego, to że nie jest nadzorowana, może doprowadzić do kłopotów. Makaronowy kod to najmniejsza z konsekwencji. Architektura dotyczy takich zagadnień jak niezawodność, bezpieczeństwo czy skalowalność. Polega na nadaniu kierunku implementacji systemu i komunikowaniu tego kierunku wszystkim osobom zaangażowanym w realizację. Architektura to fundamenty, wysokopoziomowe, trudne do zmiany w późniejszych etapach decyzje. Albo … jak podsunął mi jeden ze słuchaczy z Białegostoku: decyzje, które pozwolą reszcie zespołu na łatwiejsze rozwiązywanie problemów w przyszłości.

Po co?

Po co w ogóle zajmować się architekturą? Ano po to, by popatrzeć się na system pod kilkoma kątami. A w każdym z nich chodzi o jakość. Tylko cóż to jest ta jakość? Pominę tym razem internety i powiem nieco asekurancko – to zależy. Zależy m. in. od tego, kto tej jakości wymaga. Jeśli pod uwagę weźmiemy projekt systemu, ważne okażą się takie cechy jak integralność, reużywalność i utrzymywalność. Rozważając działanie trzeba pomyśleć o dostępności, wydajności, niezawodności, skalowalności czy bezpieczeństwie. Wdrożeniowców z pewnością zaciekawi łatwość serwisowania, czy testowalność. Dla użytkowników jakość to przede wszystkim użyteczność systemu, szeroko rozumiane UX.

O czym należy pamiętać budując architekturę? Przede wszystkim o tym, że nie jest ona tworzona raz, tak jak i całe oprogramowanie. Musi być zmieniana i musi być tak budowana by zmiany w łatwy sposób umożliwiać. Po drugie należy się skupić zarówno na modelach (które są uproszczeniem rzeczywistości) jak i kodzie (by w tych chmurach nie pozostać). Po trzecie należy wszystkie te decyzje komunikować, bo model, nawet najlepszy, jeśli nie zostanie przekazany, to nie zostanie użyty. Po czwarte i ostatnie, projekt powinien koncentrować się na kluczowych decyzjach, nie da się zamodelować wszystkiego, bo wtedy model przestaje być modelem, a staje się implementacją.

Jak się ocenia architekturę?

Jest kilka metod tzw. formalnych, które pozwalają na ocenę tego, czy nasz architekt dobrze wykonał swoją robotę. Takie metody jak ATAM, SAAM czy ARID polegają z grubsza na analizie scenariuszy. Pierwszą rzeczą jaką należy zrobić jest stworzenie tych scenariuszy i nadanie im wag/punktów/priorytetów. Ten etap sam w sobie jest wartościowy dla projektu, gdyż efektem są wymagania systemu.

W SAAM oceniane jest to, czy scenariusz jest możliwy do zaimplementowania w danej architekturze systemu bez wysiłku. Jeśli tak nie jest, to pytanie brzmi ile komponentów należy zmienić by to osiągnąć i jak trudne to będzie. ATAM bazuje na atrybutach powiązanych z danym scenariuszem. Rozważa się takie aspekty jak wydajność, czy bezpieczeństwo i określa się tzw. sensibility points, czyli punkty istotne z punktu widzenia tych aspektów. ARID z grubsza polega na zabawie jak za pomocą danej architektury zrealizować dany scenariusz i czy jest on w ogóle wykonalny.

Z mojego doświadczenia wynika jednak, iż architektura oceniana jest głównie “na oko” i na dodatek subiektywnie. Istnieje zbiór dobrych praktyk, które gdy się je stosuje, pozwalają nam, z w miarę wysokim prawdopodobieństwem, założyć, że architektura powstałej aplikacji jest dobra. Niekoniecznie trzeba podążać sformalizowanym procesem, żeby to zauważyć. Najważniejsze zwykle jest zdanie interesariuszy projektu, którym jest każdy kto ma jakikolwiek związek z budowaną aplikacją – klient, PM, developer, architekt, tester, gość od platformy systemowej czy deploymentu, oficer bezpieczeństwa. Każdy z nich ma swoją perspektywę i swoje priorytety. Architektura jest dobra jeśli żadnego z nich nie uwiera.

Rola architekta

Małymi kroczkami doszliśmy do naszego architekta. Osoby, która analizuje, projektuje i decyduje. Od której oczekuje się, że pokaże kierunek implementacji i przypilnuje, by był on utrzymywany. Aby jego działania były skuteczne, architekt powinien być elastyczny i komunikatywny. Do jego obowiązków należy weryfikowanie i ocenianie implementacji pod kątem realizacji architektury, a także rozwiązywanie pojawiających się w związku z nią problemów. Dodatkowo dochodzi tu kwestia planowania przyszłych kroków implementacji i zarządzania ryzykiem.

Aby wszystkie te działania miały miejsce, a przede wszystkim by zostały zaakceptowane przez zespół, na architekta wybiera się zazwyczaj osobę z dużym doświadczeniem i wiedzą. No i stąd ta kwestia władzy – jeśli mianujemy kogoś architektem, od razu stawiamy go na piedestale. Dając mu w ręce tyle odpowiedzialności, naturalnym odruchem jest myślenie, że wiąże się z tym decyzyjność.

Z premedytacją użyłam słowa rola, a nie stanowisko. Myśl/i rozwinę w przyszłych postach, w różnych ujęciach takich jak style podejmowania decyzji, dojrzałość zespołu, czy moje własne doświadczenia związane z architektami.

Białystok .Net i Basia

Posted in Uncategorized by

Kolejny tydzień, więc czas na opis kolejnego zeszłorocznego wystąpienia. Również wschód, ale bardziej na północy. No i tym razem bardziej technicznie, bo w tematyce około .Netowej.

4 grudnia, notabene, w dniu moich imienin, wystąpiłam w Białymstoku na spotkaniu tamtejszej Grupy .Net. Ponieważ z Krakowa daleka jest droga do stolicy Podlasia, podróż zajęła mi jakieś 2 dni. Nie narzekam jednak, bo ostatnio okazało się, że bardzo lubię podróżować, zwłaszcza pociągami, gdzie mam czas spokojnie pomyśleć i popracować, tylko internetu czasem brak (tak, wiem wiem, muszę zmienić operatora Uśmiech). Obecny post także w tym środku transportu powstaje.

Oprócz mnie prezentację miał mieć także Leszek Kwaśniewski, lider warszawskiej grupy SQL Server, do niedawna trener i specjalista od baz danych. Spotkaliśmy się wtedy w pociągu w Warszawie, gdzie dość gładko wprowadził mnie w tajniki SQL Server 2014, a jednocześnie części treści swojego wystąpienia. I dobrze, bo jestem tuman jeśli chodzi o bazy danych i być może właśnie dzięki tym korkom zrozumiałam, o czym później mówił.

Dojechaliśmy na miejsce, z dworca odebrał nas Marcin Iwanowski, szef Białostockiej grupy .Net. Gdy już znaleźliśmy się w sali, gdzie miało odbyć się spotkanie, byłam pełna obaw, czy te kilka osób, które tam zastaliśmy, to całe audytorium. Na szczęście okazało się, że jestem jak zwykle panikarą. Punktualnie o godzinie zero, sala była pełna ludzi, a kolejni napływali.

Nie do końca rozumiałam dobór tematyki około sqlowej, jeśli chodzi o grupę developerów, ale powstrzymałam się od uwag. Stwierdziłam, że przecież to może być jedynie moje zdanie. No i oczywiście potem okazało się, że na widowni oprócz programistów byli także administratorzy. Leszek zrobił, nazwane przez niego twardym, wprowadzenie, abym ja mogła wejść później, znów jego nomenklatura, bardziej na miękko. Opowiadał o ficzerach nowego (lub o ile dobrze pamiętam jeszcze wtedy przyszłościowego) Sql Server 2014. Było coś o indeksach kolumnowych, cenach i…? Hmm… Najważniejsze, że wtedy rozumiałam Uśmiech

Potem przyszła kolej na mnie. Temat by mniej techniczny, gdyż opowiadałam o architekturze. O moim jej rozumieniu kiedyś i obecnie. O swoich doświadczeniach i marzeniach by architektem zostać. Ponieważ przez 10 lat pracowałam w kilku firmach i wieeeeelu zespołach, miałam okazję spojrzeć na te kwestie z różnych punktów widzenia. Po pierwsze, chciałam je więc przedstawić, ale po drugie i najważniejsze, dowiedzieć się, co na ten temat myślą inni.

Grupa, choć na początku obawiałam się, że nierozruszana, okazała się bardzo responsywna. Albo temat, albo moje kontrowersyjne tezy, wywołały bardzo ciekawą dyskusję, która ciągnęła się nawet po zakończeniu prezentacji, już przy piwie i kanapkach. Dostałam nawet feedback, że dawno tak nikt ich nie zaktywizował. No i najlepsze – pamiętali o moich imieninach <3. Dostałam nawet prezent Uśmiech.

Afterparty  było dość grzeczne i skutecznie trzymało się tematów branżowych. Nie żebym była zaskoczona, skoro odbywało się w pokoju obok Uśmiech. Omawialiśmy oprócz architektury, o kwestiach związanych z zawodem programisty, edukacją w IT oraz kolejnymi wystąpieniami. Nadszedł jednak czas, kiedy ja i moi gospodarze zdecydowaliśmy się wyjść, głównie po to, by zdążyć posilić się czymś smaczniejszym niż kanapki i mocniejszym niż piwo.

Joanna i Procent zabrali mnie do jakiejś knajpy (było ciemno i daleko od domu, więc nawet po groźbą rozstrzelania, nie trafiłabym tam po raz drugi), w której zjedliśmy pyszne podpłomyki, wypiliśmy śliwkowe piwo przerywane wściekłymi psami i porozmawialiśmy na wiele interesujących tematów. Wieczór był długi i ciągnął się jeszcze w zaciszu domowym, a rano uwieńczony został dodatkowo leniwym śniadaniem “na mieście” Uśmiech, po którym szczęśliwie wróciłam do domu. Procentom dziękuję za super gościnę!

Rzeszów, Karotki i aplikacje mobilne

Posted in Uncategorized by

Jak już wcześniej wspomniałam 18. października odbyło się 3. spotkanie rzeszowskich Karotek. Tematem wiodącym miały być aplikacje mobilne i kwestie z tym związane, co w tym konkretnym przypadku sprowadziło się do dwóch aspektów: marketingu mobilnego i architektury. Ale to za chwilę…

Tamten piątek był dla mnie bardzo trudny. Za sobą miałam intensywny dzień, w nocy prawie nie spałam, a w perspektywie pozostawała podróż do Rzeszowa, stres prezentacji i kolejny długi wieczór. Każdy kto mnie zna, wie, że byłam o krok od znalezienia mniej lub bardziej wiarygodnej wymówki i pozostania cały dzień w łóżku by odespać wszystko co mnie już spotkało i co jeszcze miało mnie czekać. A jednak, zebrałam się i po południu zawitałam do stolicy województwa podkarpackiego.

Na szczęście spotkałam tam Olgę, organizatorkę GGC w Rzeszowie, która swoim entuzjazmem potrafi zarazić nawet taką marudę jak ja. Zorganizowała wszystko tak, iż mimo zmęczenia wykrzesałam nie tylko trochę, ale nawet całkiem sporo energii.

Pierwsze prezentację przeprowadziła Monika Mikowska – oczywiście w szpilkach z gigantycznym obcasem Uśmiech Monika ma niesamowitą wiedzę na temat marketingu mobilnego. Dowiedziałam się o wielu, mniej lub bardziej spełniających swoją funkcję, aplikacjach dostępnych w na różnych platformach. Jedna z nich (wg prelegentki jedna z tych mniej sensownych) mi osobiście bardzo się spodobała. Po raz kolejny przekonałam się jak seks dobrze się sprzedaje. Niestety nie ma jej na WP…

Moje wystąpienie miało dotyczyć budowy aplikacji mobilnych. Miałam pewien kłopot związany ze stopniem techniczności. Nie znałam backgroundu audytorium i nie wiedziałam na ile mogę poszaleć i jak nisko zejść. Przedyskutowałam to wcześniej z Olgą i postanowiłyśmy, że przedstawię słuchaczom szersze kulisy pracy programistycznej.

W efekcie zdecydowałam się na opis architektury aplikacji mobilnych. Skupiłam się na tych działających w trybie offline, bo responsive design z tej perspektywy sprowadza się do aplikacji webowej tyle, że na telefonie/tablecie. Aplikacje, które mogą działać gdy nie ma internetu, wprowadzają za to pewien ciekawy aspekt – synchronizację danych.

I o tym właśnie opowiadałam. Wciąż nie byłam pewna jaki poziom szczegółowości zapewni zrozumienie zarówno tego co ja mowie jak i złożoności samego tematu. Postanowiłam skupić się na nakreśleniu kilku kwestii, jakie należy rozważyć przy projektowaniu synchronizacji danych, w tym na obsłudze konfliktów. Opisałam jak się przechowuje dane w relacyjnej bazie danych i okrzyknięta zostałam ID girl. Podobno mówiłam zrozumiale, więc uważam to za swój wielki sukces Uśmiech Więcej o samej zawartości merytorycznej opiszę (jak obiecałam) w osobnym poście.

Sama organizacja wydarzenia miała dość kameralną atmosferę. Pochodzę z okolic Rzeszowa i miło było poczuć podkarpacką atmosferę. Żeby tego było mało, uraczeni zostaliśmy pysznym ciastem marchewkowym.

Po naszych prelekcjach nadszedł czas na postintelektualne pifffko. Miałam okazję zobaczyć piękny rzeszowski rynek i zjeść pyszny vyprazany syr (wybaczcie mnie puryści językowo ortograficzni). Monika co prawda miała lekki kłopot przy chodzeniu po kocich łbach, ale dała radę.

Wspomniałam, że dzień był ciężki dla mnie z powodu niewyspania. A ponieważ sen (a zwłaszcza jego brak) to dla mnie kwestia może nie życiowa, ale wpływająca na samopoczucie, poważnie obawiałam się o swój stan dnia następnego. Szczególnie, że znów położyłam się późno. Na szczęście Olga i jej współlokatorka okazały się na tyle gościnne i wyrozumiałe, by nie budzić mnie do 11. Naładowałam akumulatory i następnego dnia z humorem wróciłam do domu. Dzięki dziewczyny!

Żółta kaczka i efekt terapeutyczny

Posted in Uncategorized by

Zbierałam się z założeniem tego bloga już … pewien czas.  Tak długi, że wstyd się przyznać. Właściwie miałam innego wcześniej, ale częstotliwość pojawiania się na nim wpisów była tak mała, że szkoda w ogóle o moim wkładzie wspominać. Tym razem, postanowiłam, będzie inaczej.

Punktem zwrotnym w tej kwestii był moment, gdy zmieniłam pracę, by zostać kierownikiem działu oprogramowania. Teraz, pomyślałam sobie, będę mieć tysiące tematów do opisywania: budowanie zespołu, decyzje architektoniczne, konkretne techniczne rozwiązania, radzenie sobie z konfliktami, które się najpewniej pojawią, rozwój kompetencji programistów… a to tylko kilka, które mi się pojawiły w tamtym momencie.

No ale ideały ideałami, a życie życiem 🙂 Tematy oczywiście się pojawiały i to wszelakiej maści, ale zawsze znajdzie się jakaś wymówka, by się za robotę nie zabrać. W tym roku miałam przecież jeszcze zacząć biegać, zdać kilka egzaminów M$, wystąpić na kilku konferencjach, czy przeczytać stos mądrych książek. Tym którzy mnie znają wiadomo co z tego wyszło, a tym którzy tej wiedzy nie mają łatwo się pewnie domyślić.

Temat na poważnie poruszyłam przy okazji rozmowy z Gosią. Opowiedziałam jej o moim głodzie pisania, a także o innych niespełnionych postanowieniach noworocznych :). Pożaliłam się, iż mimo moich doświadczeń, nie mam pomysłów na posty. Ku mojemu zdziwieniu, dostałam prostą radę, by napisać o tym co się u mnie aktualnie dzieje. Na przykład o moich wystąpieniach prelegenckich. Wtedy przyszło mi do głowy, że dobrym tematem będą nie tylko same eventy, ale także ich treść merytoryczna. Na koniec doszłyśmy do wniosku, że mogę nawet opisać obecnie trwającą rozmowę, co tez niniejszym czynię.

Gosia miała problem jakby z drugiej strony. Wpisy na blogu pojawiają się u niej dość regularnie, zastanawiała się jednak nad tematami wystąpień. Tutaj ja wkroczyłam do akcji, stwierdzając, że temat można zrobić z czegokolwiek (bo przecież wpisu na bloga to nie :)), ale najlepiej z tego, nad czym się aktualnie pracuje, zarówno technicznie jak i procesowo.

W efekcie obydwie spełniłyśmy dla siebie rolę żółtej kaczki, bo zwyczajnie potrzebowałyśmy się wygadać. No i dodatkowo ruszyć choć trochę z tematami, zmotywować się. Jak na kozetce u terapeuty :). Na dodatek każda z nas miała świetne rady dla drugiej, przy kompletnej blokadzie ze swojej strony. Mimo, iż problemy bardzo od siebie nie odbiegały.

Gosia szybko ogarnęła temat, mi natomiast zajęło to trochę czasu i striggerowane zostało groźbą publicznego linczu z jej strony w razie gdyby mój pierwszy post się nie pojawił… do końca tygodnia. Pozostała więc do spełnienia moja część umowy. Założenie bloga okazało się dziecinnie proste i niezbyt czasochłonne, mimo to chwilę leżał odłogiem. Aż do teraz…

No więc, jak commitment, to commitment. Idąc za radą, zobowiązuję się publicznie do opisu następujących wydarzeń (i zawartości merytorycznych):

Na następny rok mam póki co zaplanowane 4 wystąpienia:

  • Spotkanie Warszawskiej Grupy .Net (16.01.2014)
  • Women in Technology we Wrocławiu (28.01.2014)
  • Spotkanie Wrocławskiej Grupy .Net (18.03.2014)
  • ??? konferencja w Łodzi (12.04.2014)

Lista się, mam nadzieję, powiększy, więc we właściwym czasie pojawią się odpowiednie wpisy.

Jeśli drogi czytelniku dotarłeś aż tutaj, to dziękuję za poświęcony czas – na przyszłość postaram się o krótsze teksty.