Future DevDay – wewnętrzna konferencja programistyczna

5

W miniony piątek miałem okazję uczestniczyć w bardzo ciekawym przedsięwzięciu: konferencji Future DevDay. Jest to coroczna wewnętrzna konferencja dla programistów firmy Future Processing. I wiecie co? Bardzo mi się podobało.

Byłem tam w charakterze “gościa specjalnego”. Obadajcie:

clip_image001

Jak nic mogę rozklejać po słupach i zbierać głosy na radnego jakiegoś czy cuś :).

Po sześcioipółgodzinej podróży samochodem Białystok-Gliwice, meldunku w hotelu i pooglądaniu kilku innych prezentacji po raz ostatni przedstawiłem swoje poglądy na temat Dependency Injection. Organizacja – pełna profeska. Niestety nie poszło mi jakoś super i mam sam do siebie sporo zastrzeżeń, no ale cóż, nie może być zawsze idealnie. Jak można na takim evencie “zgubić” przedstawienie się i zareklamowanie jako szkoleniowiec? :)

Zresztą prezentacja była nagrywana więc jeśli ujrzy światło dzienne w jakimś publicznym miejscu to ją pewnie podlinkuję na Twitterze i na http://www.maciejaniserowicz.com/speaker/. A po występie nawet kawałek wywiadu do kamery dałem, co za czasy!

Ale nieważne.

Udział w FDD dał mi trochę do myślenia. Po co oni właściwie robią taką konferencję? I dlaczego akurat w taki sposób?

Wbrew pozorom – taki event ma sens.

Konferencja jest “zamknięta”, więc nie ma parcia na jakieś specjalnie wielkie show. Prelekcje (poza moją ofc) prowadzone były tylko przez pracowników firmy. Dla prelegentów – na pewno mniejszy stres niż gdyby ktokolwiek chętny mógł się tam zjawić. Każdy programista mógł się zgłosić i w razie akceptacji – pokazać przed całą firmą to czym się zajmuje, czym się interesuje, co sobą reprezentuje. Ma to znaczenie szczególnie w przypadku organizacji tak dużych jak FP, gdzie pracuje kilkuset inżynierów i siłą rzeczy raczej mało prawdopodobne jest, aby przy takiej skali każdy się z każdym znał. Taki występ to chyba najlepszy sposób na “wewnątrz-organizacyjną” promocję osoby swej szanownej.

A dla widzów to świetny sposób aby zobaczyć co dokładnie robią inne zespoły i z kim tak naprawdę pracuje się na wspólny sukces. Nie wiem jak wam, ale mi – gdybym tam pracował – dałoby to wielkiego motywacyjnego kopa.

Mam konferencję, a te lubię. Nie muszę jechać nie wiadomo gdzie, bo mam ją w pracy. Ba, mało tego – po konferencji jest też after-party jak po, chociażby, niedawnym DevDay!

A jeśli mam chęć rozpoczęcia kariery prelegenta to gdzie lepiej to zrobić niż wśród “swoich”, z którymi wspólnie codziennie tworzę tą firmę? Po takim występie spokojnie można próbować się “eksportować” chociażby na lokalną user group. Albo i nielokalną, co może być pośrednim i nieoczekiwanym efektem mojego przyjazdu do Gliwic :). A potem już cały kraj stoi tak zwanym otworem, co i firmie plusów samych przysparza, bo zawsze to i dla niej promocja. No i większa widoczność na rynku pracy, co, jak wiadomo, nie jest bez znaczenia.

Firmo programistyczna duża! Jeśli do tej pory próbujesz motywować i rozwijać programistów tylko przez wysyłanie ich na beznadziejne autoryzowane szkolenia do dużych ośrodków to… nie jest to najlepsza droga. Zresztą o tutaj zerknąć poproszę: “Szkolenia programistyczne, czyli maszyna ssąco-uciszająca“. Zamiast tego w miarę możliwości naprawdę warto spróbować zorganizować coś na kształt Future DevDay. Serio. Deal?

Tak czy siak – dziękuję firmie za zaproszenie. Cały wyjazd bardzo mi się podobał. Niestety z after-party nie skorzystałem w pełni no ale cóż… życie :). Mimo moich ograniczeń i tak fajnie i ciekawie się gadało.

Do zobaczenia gdzieś, kiedyś…

P.S. Znacie “Project Orleans”? Ja nawet o czymś takim nie słyszałem, a przy okazji FDD obejrzałem sobie na żywo bardzo fajne wprowadzenie do tego projektu. A więcej można popatrzeć tutaj: https://channel9.msdn.com/Events/Build/2014/3-641 .

Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET i współorganizator konferencji Programistok. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook, YouTube.

5 Comments

  1. Cześć.
    Fajnie, że Ci się u nas podobało. Co do projektu Orleans to ja również dopiero na FDD się o tym dowiedziałem.

    Mam generalnie dwa pytania – jako, że na AfterParty nie mogłem zostać i osobiście Cię zagadać.
    Dlaczego Twoim Zdaniem XUnit jest najlepszy? Wiem, że jak ktoś mówi, że coś jest fajne albo nie, to najczęściej jego subiektywne odczucie. Chciałbym poznać Twoje argumenty, bo nie powiedziałeś dlaczego tak sądzisz :)
    Druga kwestia to tool do testów, którego używałeś aby w locie sprawdzać czy testy przechodzą albo czy w ogóle istnieją. Możesz podać jego nazwę?

    • Marcin,
      Co do xunit to jesteście bardzo dociekliwi, na after party dwa razy na ten temat gadaliśmy, fajnie :). Odpowiedź najprostsza : bo w xunit daję jeden atrybut i już, rolę setup /teardown pełni konstruktor i dispose.
      Narzędzie do testów to ncrunch (do wygrania już wkrótce podczas dotnetconf.pl :)).
      A jak wrażenia z mojej prezentacji? jakiekolwiek uwagi?

      • Dzięki. Przyjrzę się jednemu i drugiemu uważniej :)

        Co do prezentacji to po pierwsze pokazała potęgę świadomego refaktoringu, co mnie utrwaliło w przekonaniu, że na ten proces – jak i CodeReview – zawsze warto poświęcić czas.
        Co do tematu samej prezentacji, to mnie akurat niczym nie zaskoczyłeś, bo czytam Twojego – i nie tylko – bloga regulranie i wszystkie zagadnienia poruszane przezCiebie i Basię odnośnie SOLIDa, DI, IoC itp. są mi znane. Ale fajnie było posłuchać tego, zwłaszcza gdy co chwilkę wszystko było potwierdzane przykładami na żywo ewoluującego kodu i okraszone dawką dobrego humoru.
        Generalnie jestem na TAK.

  2. Słyszałem to wystąpienie już drugi raz, więc pomyślałem głębiej jaki feedback mogę Ci dać. Oto i on:
    Bardzo jedziesz po static’ach na wystąpieniu. Trudno się nie zgodzić, że ich nadużycie prowadzi do strasznego zabetonowania kodu. W twoim jednak przykładzie ja bym się dopatrzył kandydata na „dobrego” statica. Moim zdaniem są one uzasadnione, jeśli są to tzw.: „pure functions” (ale też nie wszystkie).
    W przykładzie z prelekcji, pokusiłbym się o zrobienie w ten sposób walidacji e-maila.(Zresztą zrobiłem przykład: https://github.com/szabl/di-talk/compare/refactoring_to_static_by_szabl)
    Co na tym zyskam: uproszenie kodu
    Co zachowuje: testowalność
    Co tracę: elastyczność -na stałe uzależniam się od jednego sposobu walidacji emaila, od którego nie mogę się odciąć w testach.
    Jeżeli, co bardzo prawdopodobne, na tak daleko posuniętej elastyczności mi nie zależy (nie oczekuje więcej niż jednego sposobu walidacji maila), a stubować tej zależności w testach nie muszę, bo nic mi to nie daje, to zalety statica zaczynają przeważać.

    Rozumiem, ze prezentacja, którą robisz omawia DI i pokazaniu tej techniki ma służyć, ale nie demonizowałbym tak bardzo static’ów ;]

  3. Szabl,
    Czasami robię “wrzutki” niezwiązane bezpośrednio z tematem (jak właśnie static czy dygresja o xunit). Nie mam czasu mocno wnikać w daną kwestię, ale lubię wtedy zdecydowanie podkreślić swoje stanowisko nawet, jeśli jest w danym momencie przekoloryzowane. Gdyby takie zdecydowane nie było to nikt by uwagi nie zwrócił :). A tak – pojawia się temat do ewentualnych dyskusji trochę szerszych niż tylko ścisły temat prezentacji.
    Ale thx za uwagę i za kod… chociaż sam bym takiego kodu nie zatwierdził ;). Preferuję jednak interfejs i nie-static dlatego, że w podesłanym przykładzie jest ukryta zależność. A jak zrobimy taką jedną to zaraz gdzieś pojawi się druga, i trzecia, gdzie indziej – czwarta i wkrótce wylądujemy w wiadrze ze spaghetti.