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

Posted in Uncategorized by basiafusinska

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.

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.

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.

16Apr2014

IoC, DI i akademicka dyskusja

Posted in Uncategorized by basiafusinska

W sobotę odbyła się łódzka konferencja GET.NET (o czym jeszcze napiszę), w trakcie której tuż przed moją, odbyła się prezentacja Procenta o Dependency Injection. Samo wystąpienie było świetne, a moją ciekawość podsyciła dodatkowo obietnica (powtórzona dwukrotnie) wyjaśnienia całego zamieszania wokół pojęć DI (Dependency Injecton i Inversion) oraz IoC. Jakie było moje rozczarowanie, gdy upragniony moment nadszedł, a Maciek skwitował wszystko zdaniem, że definicje nie są ważne.

Oj wkurzyłam się… Pomyślałam – naprawdę? Czy to, że ludzie mylą te pojęcia oznacza, że powinniśmy to olać i pozwolić, by żółć sączyła się z rany? Oczywiście zgadzam się z ogólnym stwierdzeniem, że w sumie nie ważna jest nomenklatura, byle dobre praktyki stosować, ale… czy na pewno tak jest do końca? Czy SRP pod inna nazwą równie by pachniała? Czy od teraz powinniśmy się komunikować opisując co dana zasada czy wzorzec robi, zamiast operować ich nazwami? Jakoś tego nie widzę, zajmowałoby to stanowczo za dużo czasu.

No to jak to jest z tym IoC i DI? Ano bardzo prosto, aż szkoda, że tyle przekłamań w internetach. Zacznijmy od ogółu.

Inversion of Control

IoC jest zasadą, która przeciwstawia się tradycyjnemu proceduralnemu podejściu do programowania. Polega na odwróceniu kontroli (tak, wiem, że rozumiecie Uśmiech ), w taki sposób, by miał ją zewnętrzny kod zamiast głównego flowu.

A oto obrazek przedstawiający ideę, zapożyczony z ok kolegi z fb, gdyż stwierdził (a ja się zgodziłam), że go tu brakuje.

W tradycyjnym podejściu nasz program wykonuje kroki, wywołując metody bibliotek, do których posiada on referencje. W podejściu IoC natomiast, to zewnętrzny software wywołuje nasz kod by wykonać pewne akcje. Relacje wtedy układają się zupełnie na odwrót. Dlatego zasada ta jest często żartobliwie nazywana regułą Hollywood: Don’t call us, we’ll call you.

Jest to więc bardzo szerokie pojęcie, dużo szersze niż wstrzykiwanie zależności, czy Service Locator. Przykładami z innej bajki są eventy, callbacki, czy zwykłe programowanie bazujące na interfejsach (np. wzorzec strategii).

Dependency Injection

Czyli wiemy już, że DI jest po prostu jedną z implementacji IoC. Wzorcem projektowym polegającym na tym, że przekazujemy (injection) zależność (dependency) do obiektu. Zależność staje się częścią stanu klienta (np. polem klasy lub jego property). Kluczową sprawą jest fakt jej przekazania, by nie pozwalać na tworzenie lub pozyskiwanie jej po stronie używającego obiektu.

Dependency Inversion

A jak się ma do tego Dependency Inversion? Jest to jedna z zasad SOLID faworyzująca taką budowę modułów, by odwrócić zależności i wprowadzić jak najbardziej luźne powiązania między nimi. DI oraz Service Locator się do niej stosują. A brzmi ona następująco:

Moduły wyższego poziomu nie powinny polegać na modułach niższego poziomu, lecz na abstrakcjach
Abstrakcje nie powinny polegać na konkretnych implementacjach, to konkretne implementacje powinny polegać na abstrakcjach

(Błędnie stosowana często prowadzi do tego, że po prostu wrzucamy na każdym poziomie interfejs, który jest implementowany przez dokładnie jeden moduł, ale to temat na zupełnie inny post.)

Mylić więc Dependency Injection i Dependency Inversion to całkiem normalna sprawa. Natomiast wrzucanie tego do jednego wora z IoC, to już lekkie nadużycie, bo wór ten jest o wiele obszerniejszy.

9Apr2014

Fody Weaver i PropertyChanged

Posted in Uncategorized by basiafusinska

Jeśli zdarza się nam pracować z plikami .xaml i korzystamy z dobrobytu jakim jest bindowanie kod-widok (niezależnie od tego czy będzie to MVVM czy code behind), po pewnym czasie nadchodzi moment, gdy szlag nas trafia i musimy napisać po raz kolejny zamiast prostego ładnego property:

public class MyClass
{
    public string MyProperty { get; set; }
}

jakiegoś takiego potworka:

public class MyClass
{
    public event PropertyChangedEventHandler PropertyChanged;

    string _myProperty;
    public string MyProperty
    {
        get { return _myProperty; }
        set 
        {
            if (value != _myProperty)
            {
                _myProperty = value;
                OnPropertyChanged("MyProperty");
            }
        }
    }

    public virtual void OnPropertyChanged(string propertyName)
    {
        var propertyChanged = PropertyChanged;
        if(propertyChanged != null)
        {
            propertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }
}

Pojawiają się w naszej klasie: event, implementacja metody OnPropertyChanged, oraz jej wykorzystanie w setterach. Pomijam tu “smaczek” podawania nazwy w stringu. To i tak nie jest najgorsze co się nam może przydarzyć. Moglibyśmy mieć property, które odwołuje się do kilku innych. Wtedy musimy dodatkowo pamiętać, by OnPropertyChanged dla niego wykonać w setterach składowych.

Bleh…

Z pomocą przychodzi np. Fody. Jest to prosty pakiet, który należy ściągnąć (np. stąd, lub nugetem), zainstalować i nakazać projektowi, by go używał (Project > Fody > Enable). Dodatkowo, przyda się konfiguracja weavera. Jest na to kilka opcji, a tu już odsyłam do dokumentacji.

Ja akurat używam pliku .xml:

<?xml version="1.0" encoding="utf-8" ?>
<Weavers>
  <PropertyChanged EventInvokerNames="raisePropertyChanged"/>
</Weavers>

Dzięki temu nie muszę w swojej klasie ani w moim property robić nic poza czystym get i set. Moje ViewModele stają się zwykłymi klasami, bo chyba do tego zostały wymyślone.

Fody oczywiście sporo od siebie dodaje i kod przybiera inną formę. Nasza klasa zaczyna implementować interfejs, dostaje event, ma zaimplementowaną metodę OnPropertyChanged, a wszystkie property są poorane w przedstawiony wcześniej sposób, nawet te złożone z kilku innych. Ale czego oczy nie widzą, tego sercu nie żal Uśmiech

1Apr2014

Hack.Krk w końcu w .Net

Posted in Uncategorized by basiafusinska

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.

30Mar2014

Żółtodziób w świecie Windows Phone – pierwsze kroki

Posted in Uncategorized by basiafusinska

Gdy zaczynałam swoją przygodę z programowaniem w Windows Phone (jakoś w maju zeszłego roku) okazało się, że to nie jest po prostu kolejny rodzaj projektu w Visual Studio. A szkoda, bo samo rozpoczęcie pracy, czy przeglądnięcie kodu, który zastałam w nowej pracy, wymagało wielu instalacji. Jasne, że wiele z nich dotyczyło konkretnych bibliotek użytych w projekcie, jednak kilka ruchów było niezbędnych, by w ogóle zacząć pracę z platformą. Postanowiłam opisać dla potomności te moje pierwsze kroki, a nuż ktoś skorzysta z opcji #lazyweb.

Konfiguracja środowiska developerskiego

By zacząć programować na WP8 (dla WP7 wymagania są mniejsze) potrzebne nam są przynajmniej :

Windows 8 64-bit (MSDN sugeruje, że musi to być Pro, ale to nieprawda),
Visual Studio 2012 (wystarczy Express),
Windows Phone SDK 8.0.

Tak jest na początek – samo SDK instaluje nam:

VS 2012 Express (jeśli nie mamy),
szablony projektów (które są już w VS jeśli mamy już choć wersję Professional),
Emulator WP

Tuta mała notka – emulator wymaga Hyper-V, więc jeśli chcemy go używać, wersja Windows powinna być przynajmniej przynajmniej Pro. Ale o samym Hyper-V za chwilę.

No i teoretycznie można zaczynać programowanie.

Tworzenie projektu

Tutoriali do WP jest całe mnóstwo. Nie ma sensu bym się powtarzała. Powiem tylko, że po instalacji SDK w VS pojawia się cała sekcja Windows Phone, można wybrać jeden z kilku rodzajów projektów i zacząć programować. Fazy budowy aplikacji przedstawię w kilku kolejnych wpisach.

Uruchamianie i debuggowanie

Gdy już stworzymy jakąś funkcjonalność lub jeśli chcemy sprawdzić jak działa szablonowy projekt, to trzeba go jakoś uruchomić. Tutaj mamy dwa wyjścia – emulator lub telefon.

Aby użyć emulatora potrzebujemy Hyper-V, które wymaga pewnych ustawień w BIOSie, DHCP, 4GB RAM i tego, by użytkownik należał do grupy Hyper-V Administrators. Tak naprawdę tych wymagań jest trochę więcej (odsyłam tutaj), ale widocznie miałam (tym razem) ogromne szczęście i mój lapek je wszystkie spełniał, nie musiałam więc nic dodatkowo konfigurować.

A jednak nie polecam zbytnio pracy na emulatorze. Jest wolny w działaniu (maaasaaaaakryyyycznieeee, chociaż, to się poprawiać pewnie będzie), bardzo wolno się uruchamia i nie zawsze zgodny z tym jak aplikacja zachowuje się na telefonie (chociaż tych różnic jest naprawdę niewiele). Dodatkowo, jeśli sobie go wyłączymy (np. przez przypadek, jak mi się często zdarzało), a nasza appka ma bazę danych, byliśmy do niej zalogowani, czy jej start trochę zajmuje, to przy kolejnym uruchomieniu emulatora musimy poczekać na to, aż on sam się rozkręci, aż nasza aplikacja wystartuje, trzeba się będzie zalogować oraz stracimy wszystkie zcachowane dane (również te z bazy danych).

Jakie w takim razie mamy wyjście? Słuchawkę 🙂 Podpinamy ją kabelkiem i uruchamiamy aplikacje na telefonie. Działa to trochę wolniej w trybie debuggowania (jednak to normalne), natomiast aplikacja zachowywać się będzie tak jak w rzeczywistości. Hola, hola, czy to takie proste? Tak, ale… Trzeba wykupić sobie konto developerskie i zarejestrować w nim telefon. Teraz to koszt ok 20$ rocznie i zapewniam, że jest warte nerwów, które można stracić przy walce z emulatorem.

Co z debuggowaniem? Tutaj nie ma nic szczególnego w stosunku do innych platform – możemy to robić zarówno na emulatorze jak i telefonie.

Miłego zaczynania! Uśmiech

14Mar2014

Przystanek KGD.NET, czyli jak przegrać u siebie

Posted in Uncategorized by basiafusinska

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

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…

10Mar2014

Does great power… vol.3 – Story of my life

Posted in Uncategorized by basiafusinska

O architekturze było już trochę, a potem jeszcze trochę, ale więcej teorii górnolotnych niż życiowych przykładów. Czas więc i na to. Przedstawiam dziś, przefiltrowaną przez architekturę właśnie, historię mojego życia.

Przygodę ze światem IT zaczęłam jakaś chwilę temu i przez to miałam okazję znaleźć się w różnych firmach, zespołach i rolach. Pracowałam zarówno w małej firmie, która dopiero od kilku lat istniała na rynku, jak i w międzynarodowej korporacji. Jak wiadomo, wiąże się to z doświadczeniem różnych środowisk, sposobów na organizację pracy, a co za tym idzie – podejść do architektury.

Mała firma – młodszy programista

Zacząć pracować postanowiłam jeszcze w trakcie studiów. Dziś nie jest to nic nadzwyczajnego, ale taki sposób na życie dopiero się wtedy rodził. Zatrudniłam się w małej firmie i byłam tam może 30. osobą. Na tym etapie rozwoju, tworzyło ją kilka zespołów, z których każdy miał swojego kierownika-guru. Ja byłam Johnem Snow, nie wiedziałam więc nic. Bardzo chciałam uczestniczyć w budowie czegoś, co zobaczy rzeczywisty, płacący klient, ale przede wszystkim moim celem było nauczyć się jak najwięcej.

Decyzje architektoniczne podejmował oczywiście kierownik, co mi małemu żuczkowi bardzo odpowiadało. Byłam pełna zachwytu dla wiedzy starszych stażem kolegów i do głowy mi nie przyszło, że mogę choćby zaproponować jakieś rozwiązanie. Kończyło się więc na tym, że ktoś coś wymyślał, a ja to wykonywałam. Pełniłam więc rolę nieco bardziej zaawansowanej maszyny do pisania… w Visual Studio.

Off topic: Nie wiem jak dawałam sobie radę z pracą, domem, studiami (tak, tak, był jeszcze drugi kierunek). Chyba bezpiecznie jest powiedzieć, że sobie jej nie dawałam. O ile nabieranie doświadczenia to super motywator, by zacząć jak najwcześniej, to jednak dzisiaj stwierdzam, że nie do końca skóra warta była wyprawki.

Średnia firma – starszy programista

Firma się rozrosła, moje kwalifikacje wzrosły i tak zaczęła się rodzić współpraca między członkami zespołu, wspólne szukanie rozwiązań, proponowanie zmian. Wciąż mieliśmy kierownika, który w wskazywał stronę w którą finalnie szliśmy, ale pojawiły się mniej lub bardziej indywidualne projekty. Było więc miejsce na pewną autonomię.

Zespoły były wzbogacane ludźmi o różnym doświadczeniu, powodowało to trochę tarć, ale najczęściej stanowiło pozytywne zjawisko. Poza jednym czynnikiem – odpowiedzialnością. Niewielu programistów miało podejście, w którym celem był projekt. Każdy raczej pilnował jedynie, czy na jego podwórku wszystko gra.

Architekturą zajmował się nasz kierownik, jako osoba o największym doświadczeniu. Jednak dochodziło mu wiele obowiązków administracyjno-zarządczych. Do mnie i kolegów dość szybko doszła świadomość tego, że architekt to nie stanowisko, lecz rola. Rola, z którą z jednej strony wiąże się duża odpowiedzialność, a z drugiej gruntowna wiedza. Zapragnęłam wtedy zostać architektem (jak już będę duża i mądra) i to właśnie wpisałam w swoim planie 3-letnim.

Średnia firma – architekt

I… udało się. Urosłam, zmądrzałam i marzenia się ziściły. W efekcie razem z kolegą, poprowadziliśmy kilka projektów w roli architektów. Było po prostu cudownie, żyć nie umierać. Codzienny standup, pilnowanie czy wszyscy rozumieją DDD (nie rozumieli), czy szablon projektu się nie rozjeżdża (rozjeżdżał się), czy claimy działają tak jak powinny (nie działały).

Jak coś było nie po naszej myśli robiliśmy minę doświadczonych mędrców i dobrodusznie karciliśmy młody narybek programistów. I jeszcze raz … rysowaliśmy diagramy, przekazywaliśmy linki do przydatnych stron. Wszystko po to by projekt był robiony tak jak my chcemy… eeee tzn. tak jak powinien być robiony.

Dla mnie skończyło się na kompletnym oderwaniu od rzeczywistości. Wydawało mi się, że bardzo dobrze rozumiem projekt, ale straciłam kontakt z kodem i po pewnym czasie techniczne detale były dla mnie zwykłym bełkotem. Wtedy zrozumiałam, że stałam się modelowym architektem z ivory tower.

Korporacja – senior software …. coś tam

Nadszedł czas pokory, nabrałam dystansu do całej sprawy. Przeszłam też do innej firmy, gdzie miałam zamiar budować system i jego architekturę (tym razem) razem z innymi. A przede wszystkim chciałam znów programować, bo zrozumiałam, że bez tego modele są jedynie obrazkami.

Tyle, że… na miejscu już był architekt. I to taki pełną gębą – nie programujący i na dodatek daleko, w kontakcie głównie telefonicznym. Ogólnie bardzo fajny facet, ale niewiele już dla projektu robiący, gdyż to ja docelowo miałam przejąć system. Czułam jakbym zrobiła krok w tył, co samo w sobie nie było jakieś mega straszne. Ot jestem znów doświadczonym programistą, któremu mówi się co ma robić. Jak się postarałam, to miałam nawet własne poletko do zabawy, trochę odpowiedzialności… nie za dużo Uśmiech

Tak się więc trochę kisiłam. Kroplą goryczy przelewającą czarę okazała się dość niskopoziomowa decyzja architektoniczna – wybór ORMa i brak możliwości zakwestionowania tej decyzji. Well… wiem, że tak w korporacjach jest, nie powinnam się była dziwić. Dobrze, że mogłam to zmienić.

Średnia firma – kierownik

I tak… znów zmieniłam pracę. Tym razem zostałam kierownikiem działu. Brzmi dumnie, ale dział był niewielki – 10-osobowy. Teraz, postanowiłam, o architekturze decydować będą ludzie, nie nadworny decydent. Sama zajmę się uprawianiem servant leadership, a w wolnych chwilach, pomogę w programowaniu.

Tylko, że… mój zespół nie za bardzo chciał o czymkolwiek postanawiać. Może chodziło o to, że byli to ludzie niedoświadczeni i taka odpowiedzialność to było dla nich za dużo. A może przyzwyczajeni byli do modelu słuchania i nie spodziewali się, że może istnieć inny. Suma summarum, stwierdzili, że finalne decyzje należą do mnie, bo w końcu jestem szefem i za to mi płacą. Chcąc nie chcąc zostałam Wielkim Architektem.

Startup – developer

Trochę miałam już tego dość, a przede wszystkim szukałam miejsca, gdzie pracuje się inaczej. Nie zrozumcie mnie źle, wiem każda firma ma swoją kulturę organizacyjną. Zdaję sobie sprawę z roli odgórnych decyzji. Wiem też, że nie każdy gotowy jest na przyjęcie odpowiedzialności z całym dobrodziejstwem inwentarza. Mi jednak to co miałam nie do końca wystarczało.

Teraz pracuję w startupie, gdzie widzę diametralną różnicę. Przede wszystkim – nie ma czegoś takiego jak odgórne decyzje dotyczące architektury, a jeśli już o tym mowa, to nie istnieją odgórne decyzje dotyczące kwestii technicznych. Każdą z nich poprzedza dyskusja i to nie tylko w gronie osób to w końcu implementujących, ale również całego zespołu, a nawet osób spoza.

Model jest prosty – jesteś częścią teamu, więc funkcjonujesz na takich samych prawach jak inni. A to wiąże się również z pewnymi obowiązkami. Udział i wkład każdego z nas staje się wymaganiem, a nie jedynie możliwością.

Nie mamy więc architektów, a raczej każdy z nas nim jest. I każdy powinien, bo nie zrezygnowanie z tej roli oznacza często zrzucenie z siebie odpowiedzialności. W zespole każdy z nas architekturę zna, rozumie, buduje wg niej i jest za nią odpowiedzialny.

KONIEC!

22Feb2014

Windows Phone w stolicy

Posted in Uncategorized by basiafusinska

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

21Feb2014

Does great power… vol.2

Posted in Uncategorized by basiafusinska

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.

12Feb2014

Święta, Święta i Wrocław

Posted in Uncategorized by basiafusinska

Oczywiście trochę (alb już nawet bardzo) późno, ale nie wcale…, piszę o Świątecznym spotkaniu 3 wrocławskich grup: Women in Technology, Wrocławska Grupa.Net, Polish SQL Server User Group. Świątecznym, bo bożonarodzeniowym, choć wiem, że za pasem wiosna i Wielkanoc Uśmiech

Aby uczestniczyć w imprezie, porzuciłam na 2 dni Kraków i podobno imprezę wszech czasów, co wywołało w moim wnętrzu istną falę wyrzutów sumienia. Jednak ostatecznie, głównie z uwagi na to, iż postanowiłam częściej wychodzić ze strefy komfortu, a dodatkowo wolę bardziej kameralne imprezy (hmm… chyba sprzeczność mała właśnie mi wyszła), 17 grudnia 2013 zawitałam we Wrocławiu.

Z dworca odebrała mnie Gosia, która zasłynęła już jako osoba mająca niebagatelny wpływ na moje życie. Komisyjnie postanowiłyśmy odpuścić sobie spotkanie Wroc.Net, które to mimo (albo z powodu) późniejszej imprezy, postanowiło się tego dnia organizować, i wybrałyśmy się na “papierocha, pogaduchy i strojenie głupich min” przy pysznych hamburgerach. Mniam Szeroki uśmiech Chwilę przed czasem, dotarłyśmy do Bohemy, gdzie miało się odbyć spotkanie. Na miejscu było już kilka osób, których w miarę upływu czasu, sukcesywnie przybywało.

Ogrom kameralności mnie nieco przeraził, bo choć mieściliśmy się przy dwóch stolikach, to nie wiem naprawdę w jaki sposób. Poznałam wiele nowych osób, ale nie jestem pewna czy ktokolwiek z tego tłumu pamięta mnie. Chociaż, z pewnością są takie osoby. W końcu efektem mojej bytności była iście wampirza sweet focia Uśmiech oraz kolejna okazja dla mojego wymądrzania się – tym razem na Wroc.Net w marcu. Poruszyliśmy wiele tematów, od C#, przez pracę w IT, rodzinne sprawy, przeczytane książki, po alkohol, którym się raczyliśmy.

Gościła mnie oczywiście Gosia, do której dotarłyśmy szczęśliwie i nie tak późno, gdyż następnego dnia czekał mnie powrót do Krakowa. Znów się nie wyspałam w nocy, dopiero następnego dnia, niedługo się przyzwyczaję. Bo podobno, co nas nie zabije, to nas wzmocni… chyba, że nas zabije Uśmiech

Dlaczego w ogóle wspominam o tym evencie? W sumie poza tym, że spotkanie skupiło ludzi z IT, impreza sama w sobie była mało techniczna. Piszę, bo uważam, że to fajna inicjatywa, okazja do poznania, co prawda ludzi z branży, za to od innej strony, tej bardziej ludzkiej. Choć jak wiadomo (i jak mówi mi kilkuletnie doświadczenie) ciężko wykrzewić z bandy informatyków tematy pracowe.

Nie wrzucam oczywiście żadnego innowacyjnego tematu, w Krakowie również mamy spotkania technologiczne, i imprezy. Jednak często robione są w formie ‘piwo po’ na zakończenie spotkań grupowych i jeśli nie ochrzczone zostaną mianem biby wszech czasów, niewiele osób rezerwuje sobie ten dodatkowy czas. A nawet jeśli, to chce go spędzić na omawianiu właśnie poruszanych tematów.

Piszę po to by namówić nas, programistów, administratorów, testerów i reszty, na wyjście na piwo i rozmowy u dupie Maryni. Na spotkania z ludźmi, a nie z ich pracowo/hobbistyczno/ITowymi wyzwaniami Uśmiech Nasz zawód jest super i wiem, że reszta świata powinna nam jedynie zazdrościć, jak fajnie jest móc robić to co się kocha tak mocno, że nawet przy piwie chce się ciągnąć temat, ale believe me reszta naszego życia może być równie ciekawa.