Showing posts with label praca w zespole. Show all posts
Showing posts with label praca w zespole. Show all posts

11/07/2014

Konferencja wewnątrz-firmowa - edycja 2

Home

Rok temu tutaj oraz tutaj opisałem zorganizowaną przez siebie konferencję wewnątrz-firmową. W tym roku odbyła się jej druga edycja. O szczegółach organizacyjnych nie będę pisał, aby się nie powtarzać. Z drobnymi szczegółami wyglądało to podobnie. Tematy prezentacji były przynajmniej tak ciekawe, jak przed rokiem i można było posłuchać następujących wystąpień:

Janusz Prusaczyk - Introduction to PowerShell scripting

Paweł Kupis - C# 5.0 Async Feature (async/await) and Synchronization Context – the old new friends

Marcin Wierzbicki - Praktyczny pomiar i atrybucja efektywności portfela inwestycji finansowych

Kamil Langowski - Wolfram Alpha: Computational Knowledge Engine

Adam Juszkiewicz - Mobile game development in Unity

Albert Skłodowski - Design Patterns in Functional Programming

Daniel Celeda - Kręgosłup programisty

Jaroslaw Trafidlo - Czy możemy czuć się bezpiecznie podłączając komputer do sieci?

Damian Orzechowski - Silniki gier komputerowych

Paweł Kaczan - Claims based itentity

Mikołaj Barwicki - Science of Motivation

Michał Komorowski - Debuggery historyczne, co to takiego?

Konferencja ponownie udała się i nie jest to tylko moja opinia. Znowu można było posłuchać o najróżniejszych rzeczach, typowo technicznych, wymagających więcej i mniej uwagi, luźnych... i właśnie to mi się w tym wszystkim najbardziej podoba. Być może się powtórzę, ale pozwala to dowiedzieć się o rzeczach, którymi na co dzień zupełnie się nie interesujemy i nawet do głowy nam nie przyjdzie, że jednak warto. Zdecydowanie polecam.

Mam też trochę wniosków na przyszłość. Było bardzo fajnie, ale zawsze może być lepiej. Jednym z pomysłów na poprawę jest wprowadzenie szablonu prezentacji z przykładami oraz ostrego limitu na poziom slajdów. Szablon powinien zapewnić, że wszystkie prezentacje będą równie czytelne oraz, że nikogo nie porwie zbytnia fantazja przy tworzeniu slajdów ;) Limit na liczbę slajdów powinien natomiast ułatwić zmieszczenie się w czasie. Po głowie chodzi mi również zaproszenie na konferencję ludzi z poza firmy. Może to być trudne do zrealizowania, ale może się uda. Co o tym myślicie, bylibyście chętni do wzięcia udziału w takim wydarzeniu?

Z nowości względem poprzedniej edycji, w tym roku wystąpienia były nagrywane. A wszystko dzięki uprzejmości Jarka Trafidło, który udostępnił kamerkę z serii GoPro, był operatorem, a także poddał zgromadzony materiał obróbce. Jeśli ktoś nie był na jakiejś prezentacji, to będzie mógł ją teraz obejrzeć na spokojnie w domu.

Z mojej perspektywy ogromnym dodatkowym plusem tych nagrań jest to, że w końcu mogłem sporzeć na siebie od tej drugiej strony. Przyznam, że to trochę dziwne uczucie, bo głos brzmi jakoś tak inaczej i w ogóle percepcja siebie się zmienia. Na przykład, wiedziałem, że dużo gestykuluję, ale nagranie pokazało, że chyba zbyt dużo. Po drugie, występując wydawało mi się, że ogólnie stoję w miejscu i tylko od czasu do czasu zrobię krok w jedną albo w drugą stronę. Nagranie znowu uświadomiło mi, że poruszam się więcej niż mi się wydaje, a to kroczek w tą, a to kroczek w drugą. Nie mówię, że trzeba stać w miejscu, ale zbytnia ruchliowść również przeszkadza. Bardzo cenne wskazówki na przyszłość.

16/01/2014

Podsumowania roku są bardzo ważne

Home

Refleksja jak powyżej naszła mnie właśnie podczas takiego spotkania podsumowującego. Niby wiedziałem, jakie projekty były realizowane w czasie zeszłego roku, niby wiedziałem o wszystkich przedsięwzięciach podejmowanych w poszczególnych obszarach (innowacja, zarządzanie wiedzą itd.), zdawałem sobie również ze zmian w zespole... Pomimo tego, kiedy zebraliśmy wszystko do kupy byłem zaskoczony, ale w bardzo przyjemny sposób, i podbudowany jak dużo rzeczy udało się zrealizować.

Niektóre ze zmian były całkiem duże i ewidentnie będą miały pozytywny, długofalowy wpływ. W szczególności mam tutaj na myśli wdrożenie automatycznych testów jednostkowych oraz integracyjnych, wypracowanie zasad ich tworzenia i włączenie ich w oficjalny proces wytwórczy, w czym maczałem swoje palce.

Mniejszych i większych wydarzeń było sporo więcej i ważne, że wszyscy dowiedzieli się lub przypomnieli sobie, co się działo przez ostatni rok, a przecież nie każdy ma ekspozycję na wszystko co się dzieje. Dlatego uważam, że takie spotkania, o ile zrealizowane dobrze, najlepiej wewnątrz zespołu, tak aby skupić się na konkretach bez corporate bullshit, są bardzo potrzebne.

Jeśli w Twojej firmie nie ma zwyczaju organizowania takich spotkań, to wyjdź z taką propozycją albo jeśli masz taką możliwość zorganizuj je samemu.

10/08/2013

Konferencja wewnątrz-firmowa 2

Home

Ostatnio napisałem o zorganizowanej przez siebie konferencji wewnątrz-firmowej. Teraz należy napisać o czym można było posłuchać. Oto lista 12 przygotowanych prezentacji, wszystkie moim zdaniem stały na wysokim poziomie. O jakości prezentacji niech świadczą bardzo dobre wyniki ankiet. Średnia ocena to 8.3 w skali od 1 do 10!

Albert Skłodowski - F# as a functional language for the .NET platform

An introduction to functional programming in .NET using F# language. Write simple code to solve complex problems!

Damiarz Orzechowski - Is C++ dead? What was added into C++ x11 standard in comparison to C# and .NET features

Summary of history behind latest C++ standard. Presentation of highlights of latest standard and comparison of features between C++ and C#/.NET.

Daniel Celeda - Software Project Survival Guide

Quick induction to the main factors of a successful software project.“Software projects succeed or fail based on how carefully they are planned and how deliberately they are executed. The vast majority of software projects can be run in a deterministic way that virtually assures success. If a project’s stakeholders understand the major issues that determine project success, they can ensure that their project reaches a successful conclusion.”

Kamil Langowski - Paradoxes and idiosyncrasies of probability

Simple math problems that are outstandingly controversial, but are nonetheless facts.

Marcin Wierzbicki - Financial instruments for dummies

The talk covers basic subjects from financial engineering field, starting with present value, fixed income securities, bond pricing, immunization and arbitrage, and finishing... after 1 hour :)

Marek Ryński - An introduction to the basics of Web Application Security - theoretical lecture

A review of available mechanisms used to ensure confidentiality, integrity and availability of information in Web Applications. The talk will cover different approaches to authentication, highlighting strong and weak solutions. A few words will be said about smart cards and biometrics. Hacking, injection attacks and social engineering are only buzz words to attract your attention on this abstract, but none of these things will be discussed.

Michał Komorowski - RavenDB as an example of document oriented databases. A history of application in my pet project.

NoSQL databases are a relatively new idea which is becoming more and more popular. In this presentation, I’ll focus on document oriented databases. I’ll discuss the topic on the example of RavenDB and my pet project LanguageTrainer which supports learning foreign languages.

Michał Rzeszutko - Dependency Injection patterns and best practices

An introduction to the subject of DI. The talk covers basic subjects - what it is DI and what are the benefits of using it, as well as the more advanced ones – how to use it properly (patterns) and what to avoid (anti-patterns).

Mikołaj Barwicki - Do IT the Toyota Way?

Toyota is an enterprise built on unique philosophy focused on manufacturing and process quality that is summarized in a set of statements referred to as “Toyota Way”. Is this what made Toyota the world’s largest car manufacturer? Are these statements applicable to software development organizations?

Paweł Kupis - Aspect-oriented programming on the example of PostSharp.

Short introduction to aspect-oriented programming concept, fast review of .NET aspect frameworks and PostSharp in action.

Przemek Wasylko - Command-query responsibility segregation: can we successfully separate read from write parts of the system?

Exploration of design pattern where different (often in a radical way) model and approach is used to update information than model used to read information. I will try to show how this affects system architecture and user interface experience. But does it really make engineer’s life easier? And software less prone to errors?

Tomasz Moska - Configuring SQL Server Instance for optimal performance

The talk will cover some good practices regarding configuration of SQL Server instance.

04/08/2013

Konferencja wewnątrz-firmowa

Home

W jednym z ostatnich postów pisałem o zorganizowanym przez siebie Quiz'ie. Dzisiaj napiszę o innym pomyśle na powiew świeżości w pracy, czyli o konferencji wewnątrz-firmowej. Konferencję taką zorganizowałem pod koniec czerwca (jej pierwotnym pomysłodawcą był mój przełożony Mikołaj).

Trochę uprzedzając, był to strzał w dziesiątkę pod każdym względem, a więc czym prędzej biegnijcie do swoich przełożonych z propozycją zorganizowania takiego wydarzenia ;) Zacznijmy od spraw organziacyjnych, czyli jak się do tego zabrałem.
  • Na początek ustaliłem szczegóły z przełożonymi, czyli kiedy taka konferencja może się odbyć i ile czasu można na nią poświęcić. My wybraliśmy ostatni tydzień czerwca i na każdą prezentację przeznaczyliśmy godzinę. W konferencji mógł wsiąść udział każdy i mógł zobaczyć dowolną ilość prezentacji, przy czym było jasno powiedziane, że praca ma priorytet, czyli jeśli jest pilne zgłoszenie to trzeba je obsłużyć.
  • 4 miesiące przed konferencją rozesłałem prośbę o zgłaszanie tematów wraz z krótkim opisem. Na zastanowienie się dałem 1 miesiąc.
  • Co bardzo ważne, tematyka prezentacji mogła być dowolna, również nietechniczna. Jedynym warunkiem było, że prelegent:
    • Ma interesować się tematem.
    • Musi mieć przynajmniej trochę przekonania :), że dla innych temat również będzie interesujący.
  • W regularnych odstępach (to bardzo ważne) rozsyłałem przypomnienie, że zostało tyle, a tyle czasu na  zgłoszenia.
  • Po zebraniu propozycji (około 30 prezentacji, ale każdy mógł zgłosić więcej niż 1) zorganizowałem głosowanie. Na oddanie głosu były 2 tygodnie i znowu należy o tym przypominać.
  • Na konferencję wybrałem 12 najlepszych prezentacji, ale każdy prelegent miał przygotować tylko 1.
  • Poinformowałem kolegów o wyniku głosowania.
  • Aby prelegenci nie czekali do ostatniej chwili z przygotowaniami poprosiłem ich aby przesłali mi agendę miesiąc przed konferencją.
  • Zarezerwowałem salę, rzutnik, laptop itp.
  • Poprosiłem prelegentów o preferencje kiedy chcą wygłosić swoje prezentacje i przygotowałem harmonogram.
  • Dwa tygodnie przed konferencją rozesłałem do wszystkich w firmie zaproszenie na poszczególne prezentacje.
  • Tuż przed samą konferencją przygotowałem ankiety, wydrukowałem je i pociąłem.
  • Sprawdziłem również czy laptop działa, czy współpracuje z rzutnikiem i co jest na nim zainstalowane. Oczywiście poinformowałem również prelegentów czego mogą się spodziewać po sprzęcie. Pomimo to, zgodnie z prawem Murphy'ego, nie obyło się bez niewielkich problemów technicznych.
  • Na każdej prezentacji na stołach czekały długopisy i anonimowe ankiety. Ich wypełnienie było obowiązkowe.
  • Po konferencji zebrałem od prelegentów materiały i umieściłem je na Wiki.
  • Podliczyłem ankiety i rozesłałem je do prelegentów. Przy okazji zapytałem czy zgadzają się na publikację wyników. Wszyscy się zgodzili więc udostępniłem również wyniki ankiet.
Przed godziną zero wszystko było więc zapięte na ostatni guzik. Konferencja spodobała się chyba wszystkim. Ja jestem z niej bardzo zadowolony, zarówno jako organizator jak i prelegent. To wspaniała okazja do integracji zespołu, nauki nowych rzeczy i potrenowania swoich umiejętności prelegenta w sprzyjającym środowisku.

Za jakiś czas napiszę o czym można było posłuchać na konferencji.

06/07/2013

Quiz - rozruszaj towarzystwo

Home

Czy Wasza praca jest zawsze ciekawa i pełna wyznań, a może czasami Was nuży i zastanawiacie się jak ją urozmaicić?

Byłoby super gdyby każdy z nas mógł odpowiedzieć na to pytanie "Tak moja praca jest bardzo ciekawa i nigdy mnie nie nuży", ale w rzeczywistości bywa różnie. Zawsze można zmienić pracę, ale można również próbować zmienić coś w obecnej. Sceptycy pewnie powiedzą, a co ja mały trybik w wielkiej machinie mogę zrobić. Dużo zależy od firmy i bywają przypadki beznadziejne. Ja na rozruszanie zespołu proponuję zorganizować Quiz.

Ja postanowiłem coś takiego zrobić już po raz drugi w swojej karierze i jestem bardzo zadowolony z efektów. Odgórnym celem Quiz'u była zabawa i nauka. Zasady były proste:
  • 10 tur po 3 pytania (łatwe, średnie i trudne) dotyczące szeroko pojętego programowania.
  • Pytania przygotowałem za wczasu, tak aby nie musieć ich wymyślać co tydzień.
  • Starałem się, aby odpowiedzi można było udzielić w jednym zdaniu, czasem wręcz jednym słowem, ewentualnie napisać kilka linijek kodu.
  • Pytania rozsyłałem w poniedziałek rano i czekałem na odpowiedzi do końca dnia. Następnego dnia oceniałem wyniki, rozsyłałem odpowiedzi z komentarzami i aktualną statystykę (anonimowa lista).
  • Udział był dobrowolny.
  • Udział był anonimowy, każdy uczestnik miał przypisany identyfikator i tylko ja znałem mapowanie.
  • Zwycięzca mógł wybrać sobie nagrodę ufundowaną przez firmę (wybrał przenośny dysk).
Do Quiz'u zgłosiło się 20 osób. Łącznie zadałem 9 łatwych pytań, 12 średnich oraz 9 trudnych za łącznie 60 punktów. Zwycięzca zdobył 52.5 punkty i walka trwała do ostatniej tury ponieważ druga osoba w rankingu miała 52 punkty, a trzecia i czwarta 51. Zebrane w całości pytania i odpowiedzi utworzyły 22 stronicowy dokument!

Quiz spodobał się i spotkał się z bardzo dobrym odbiorem również ze strony przełożonego, który dał pieniądze na nagrodę. Najbardziej cieszy mnie jednak to, że już kilkukrotnie słyszałem od kolegów, że w trakcie Quiz'u nauczyli się czegoś nowego.

Organizacja Quiz'u to również nauka dla mnie. Aby przygotować pytania i nie zaliczyć wpadki wiele zagadnień musiałem przestudiować dużo dokładniej. Nauczyłem się również jak, wbrew pozorom, trudne jest układanie pytań w taki sposób, aby były zrozumiałe dla wszystkich. Pomimo, że każde zadanie czytałem wielokrotnie zdarzało się, że musiałem odpowiadać na pytania i rozsyłać dodatkowe informacje.

Na koniec kilka przykładów pytań:

Łatwe

We have to measure an execution time with the maximum possible resolution/precision. It was implemented in the following way. Does this code meet this requirement? If yes, why? If not, propose a better solution.
var start = DateTime.Now;
//...
var end = DateTime.Now;
Średnie

.NET 4.5 introduces a new, easy and elegant way to retrieve a name of a method (caller) which executed/called a given method (calle).
public void Fun()
{
//Here, I want to get a name of a method that executed/called Fun method
}
Trudne

We want to use a class called  Fun, that  is defined in an external library. Unfortunately, a constructor of this class contains a bug which causes an exception. In other words, we can't create a new instance of Fun class, but we have to. You have to find a workaround. You mustn't modify Fun class.

16/12/2012

Code Retreat

Home

O Code Retreat, czyli swego rodzaju warsztatach programistycznych, usłyszałem po raz pierwszy całkiem niedawno, kiedy dyrektor działu, w którym pracuję, rzucił pomysł zorganizowania czegoś takiego w firmie. Od pomysłu do realizacji nie minęło dużo czasu i w ostatnią sobotę wraz z kolegami i koleżankami z pracy (około 20 osób) wzięliśmy udział w takich warsztatach prowadzonych przez Michała Taszyckiego.

Z czym to się je? Celem Code Retreat jest wymiana wiedzy pomiędzy uczestnikami warsztatów oraz nauka nowych rzeczy, których na co dzień nie używa się w pracy. Warsztaty takie składają się z kilku krótkich sesji, w moim przypadku było to 6 sesji po 45 minut, podczas których rozwiązuje się jakieś problemy programistyczne. Pracowaliśmy w parach i co jakiś czas wymienialiśmy się klawiaturą. W czasie każdej z sesji pary były różne, a ponieważ w wydarzeniu brali udział programiści C# i Java, czasami trzeba było programować w języku, którego nie używa się na co dzień.

Tematem przewodnim tego Code Retreat była gra w życie. W czasie każdej z sesji mieliśmy za zadanie zaprogramować taką grę, ale za każdym razem wymagania na metodykę pracy i użyte techniki programistyczne były inne. Co istotne, każda sesja kończy się usunięciem całego kody. Pogrubienie oznacza fizyczne, trwałe usunięcie kodu, a więc za każdym razem pracę rozpoczynaliśmy się od początku.

Należy podkreślić, że celem nie jest tak naprawdę napisanie działającej gry. Temat nie jest trudny, ale 45 minut to nie jest dużo czasu zważywszy na to, że przy okazji uczymy się nowych rzeczy. Główny cel to nauka, nauka i jeszcze raz nauka, w sprzyjających warunkach i bez stresu, a gra w życie czy inne zadanie to tylko pretekst.

Czego się nauczyłem? W czasie jednej z sesji mieliśmy na przykład zastosować czysto purystyczne podeście to Test Driven Development, czyli nie mogliśmy napisać linijki kodu bez testów. W innej sesji programując nie mogliśmy w ogóle używać myszki, no ewentualnie po to aby raz sprawdzić skrót i potem już go używać. W jeszcze innej sesji pisany kod powinien zawierać minimalną liczbę klauzul sterujących if, a najlepiej w ogóle itd. Zadania mogą być najróżniejsze.

Czy purystyczne trzymanie się TDD jest dobre? Uważam, że nie. Czy używanie tylko i wyłącznie klawiatury nie jest przesadę? Uważam, że dobrze znać skróty klawiaturowe i starać się minimalizować używanie myszki ale ona się też się przydaje. Czy programowanie bez if'ów ma sens, czy tak w ogóle się da? Ano da się, nie jest to może proste, ani oczywiste ale da się.

Zadania z takimi skrajnymi wymaganiami wyrywają jednak z rutyny, pokazują, że coś można zrobić inaczej, pobudzają do myślenia, rozszerzają horyzonty i to jest moim zdaniem SUPER. Niewątpliwą zaletą jest również integracja zespołu. Co by nie mówić, Code Retreat to po prostu świetna zabawa.

Podsumowując jestem bardzo zadowolony z udziału w Code Retreat. Przyznam, że początkowo byłem trochę sceptyczny, nie wiedziałem czego tak naprawdę się spodziewać, ale nie żałuję ani minuty spędzonej w sobotę w biurze :), w czym niewątpliwą zasługę ma również prowadzący Michał Taszycki.

Polecam Code Retreat!!!

08/01/2011

Co to jest?!?!?!

Home

Co to jest?!?!?!. Kiedyś otrzymałem mail o takim właśnie tytule, a zawierający fragment mojego kodu. Kod ten, przyznam szczerze, zbyt elegancki nie był, ale napisałem go w sytuacji rodzaju "Masz to napisać na wczoraj". Ważne, że działał i robił to co miał robić. Nie jestem człowiekiem, który uważa swój kod za święty i sądzę, że umiem przyjąć krytykę, ale ten mail nie spodobał mi się z kilku powodów.

Po pierwsze oprócz mnie został wysłany do dwóch innych osób. Po drugie w kodzie zamieściłem komentarz wyjaśniający co ten krótki fragment kodu robi. Po trzecie treść wiadomości nie zawierała żadnych wyjaśnień jak to zrobić lepiej. Innymi słowy celem tego maila było nie tyle zwrócenie mi uwagi, że coś zrobiłem nie tak, ale bardziej pokazanie innym, że coś robię nie tak.

Całą sytuację nie przejąłem no bo i po co. Na "zaczepki" tego rodzaju mam w zwyczaju nie odpowiadać chyba, że się powtarzają. Kilka godzin później otrzymałem jednak wiadomość od jednej z dwóch osób, do której skierowany był mail Co to jest?!?!?!. Wiadomość ta była skierowana bezpośrednio do autora wiadomości Co to jest?!?!?! i wyglądała mniej więcej tak:

A to CO TO JEST?!?!?!:
  1. Opis błędu numer 1.
  2. Opis błędu numer 2.
  3. ....
Opis błędów wskazywał, że autor kodu poprzestał tylko na jego skompilowaniu i nawet jeden raz go nie uruchomił. Jak mówi stare przysłowie kto mieczem wojuje ten od miecza ginie. Krytyka jest potrzebna i często wskazana, ale krytykować trzeba umieć. Ja kiedy napotkam jakiś błąd w cudzym kodzie to trzymam się kilku zasad:
  1. Nie krytykuję publicznie czyli wysyłam mail tylko do jednej osoby. Jeśli rozmawiam z osobą, w której kodzie znalazłem błąd to mówię jej o tym w dyskretny sposób.
  2. Jeśli widzę, że błąd jest powszechnie popełniany to wysyłam maila to potencjalnie zainteresowanych osób i pokazuję przykład błędnego kodu ale nie wskazuję kto go napisał.
  3. Krytykując staram się zawsze wyjaśnić czemu uważam, że coś jest zrobione źle i jak to zrobić lepiej.
  4. Staram się aby moja wiadomość/wypowiedź nie była odebrana jako atak. Na przykład zamiast sformułowania Co to jest?!?!?! mail zatytułowałbym Błąd w metodzie SomeMethod. Taki tytuł wiadomość niesie z sobą jakąś informację i sądzę, że jest neutralny w odbiorze.
  5. Zanim wyślę maila lub pójdę porozmawiać upewniam się jeszcze raz, że błąd to rzeczywiście błąd.
Publiczna krytyka niestety jest czasem potrzebna, ale tylko w "beznadziejnych" przypadkach czyli wtedy kiedy ktoś zupełnie ignoruje nasze uwagi.

02/12/2010

Dlaczego należy być upierdliwym...

Home

... kiedy dostaje się jakieś zadanie do wykonania. Albo wręcz bardzo upierdliwym i dopytywać się o wszystkie szczegóły, a przede wszystkim o te, które wydają się nam oczywiste. Odpowiedź brzmi, aby nie tracić czasu. Zasada jest prosta ale pomimo to ciągle o niej zapominam kiedy sądzę, że już wszystko rozumiem i zadanie nie jest skomplikowane. Przykład z życia.

Otrzymałem do wykonania łatwe zadanie, które upraszczając polegało na tym aby, użytkownicy domenowi nie musieli logować się ponownie do aplikacji WWW używanej wewnątrz sieci klienta. Zdecydowałem, że zastosuję Windows Authentication. Testy w środowisku lokalnym przebiegły gładko, a więc pozostało zainstalowanie aplikacji na serwerze testowym. Myślałem, że to już koniec roboty podczas gdy w rzeczywistości zajęło mi to jeszcze dużo, dużo czasu. Z jakichś powodów automatyczne logowanie nie chciało działać na docelowej maszynie. Czemu? Bo nie byłem upierdliwy i nie zadałem jednego pytania:

Czy serwer testowy został dodany do domeny?

Niestety ale przyjąłem, że znajduje się w domenie, do której należą użytkownicy (warunek konieczny automatycznego logowania) i przyczyny kłopotów szukałem wszędzie tylko nie tam gdzie potrzeba. Bądźmy, więc upierdliwi i kiedy dostajemy zadanie pytajmy, pytajmy i jeszcze raz pytajmy.