Trochę o wynagradzaniu w IT

Home

W Polsce system wynagrodzeń w IT przeważnie wygląda tak. Przychodzi się do firmy i na wejściu dostaje się tyle, ile wynegocjowało się na początku. W niektórych firmach co roku można też liczyć na wyrównanie inflacyjne (z reguły kilka procent), a jeśli się posiedzi w firmie dłużej lub awansuje to jest szansa na większą podwyżkę. Czasami jest też tak, że pensje są zamrożone nawet prze kilka lat. Według mojego i ludzi z jakim rozmawiałem doświadczenia o dużą podwyżkę najłatwiej zmieniając pracę. Dodatkowe benefity to przeważnie opieka medyczna i karta Multisport lub podobna. Bywają też inne, ale, moim zdaniem, jeśli już są, to pełnią rolę wisienki na torcie niż czegoś co mogłoby rzeczywiście kogoś skusić. Oczywiście szczegóły zależą od firmy, ale moim zdaniem ten system jest mocno nieokreślony i bardzo dużo zależy od umiejętności negocjowania i momentu, kiedy przyszło się do firmy.

Mi do gustu przypadł system stosowany w niektórych, bo w cale nie wszystkich, firmach na zachodzie. Zacznę od tego, że opiera się na systemie poziomów, a od zdobytego poziomu bezpośrednio zależy nasza pensja. Nie jest to regułą, ale ja akurat spotkałem się ze skalą zaczynającą się w okolicach 8 oraz kończącą się w okolicach 20 i zawsze się zastanawiam z czego to wynika. Nawet o to pytałem, ale odpowiedzi były, jak dla mnie, mgliste. Na przykład spotkałem się z stwierdzeniem, że z powodów psychologicznych po poziom 1 to brzmi źle.

Ostatnio, całkiem przez przypadek, natknąłem się na kilka artykułów na ten temat napisanych, między innymi, przez Joel'a Spolsky'ego jednego z założycieli portalu stackoverflow.com. W firmie Joel'a algorytm liczenia poziomu jest funkcją 3 zmiennych tj. doświadczenia (liczonego w latach), umiejętności (ocenianych w zakresie 0-6) oraz zakresu obowiązków (również ocenianego w zakresie 0-6). A możliwe kombinacje zostały ujęte w taką tabelkę:



Ważne jest to, że pracowniczy na danym poziomie zarabiają tyle samo względem kwoty bazowej, która aktualizowana jest co jakiś czas. Czyli na przykład na poziomie dziewiątym zarabiasz X, na dziesiątym X+10%, a na jedenastym X+20% itd. Kwota X nie podlega dyskusji. Jeśli chce się zarabiać więcej to najłatwiej osiągnąć to przez zwiększenie swoich umiejętności. Zauważcie, że według powyższej tabelki wraz z kolejnymi latami doświadczenia poziom rośnie powoli w porównaniu do wzrostu umiejętności i zakresu obowiązków.

Istotne jest to, że osiągniecie maksymalnego poziomu nie oznacza, że programista przestaje być programistą i staje się menadżerem. Wprost odwrotnie, to oznacza, że jest wyjebistym programistą i będzie nadal robił to w czym jest najlepszy. Natomiast jak zaczynasz bez żadnego doświadczenia to dostajesz co prawda najniższy poziom, ale po pierwszym roku możesz skoczyć o 5 oczek do przodu, czyli tyle co ma ktoś z 15 latami doświadczenia, ale nie jest tak dobry jak ty.

Jak dla mnie takie postawienie sprawy to super rzecz. Każdy wie, na co może liczyć i mniej więcej przewidzieć, jak będzie wyglądała jego pensja w przyszłości. Można się pewnie czepiać, że ocena umiejętności jest subiektywna, że ktoś może nas nam zaniżyć ocenę... Ja na taki zarzut odpowiem tak: nie ma systemu idealnego i uważam, że ten jest dużo lepszy od tego co opisałem na początki postu. Natomiast jeśli uważasz, że ktoś może Ci celowo zaniżyć ocenę to lepiej bierz nogi za pas i zmień pracę.

Co o tym myślicie? Czy taki system mógłby przyjąć się w Polsce?

Na koniec trochę linków:

• Fog Creek Professional Ladder
• How do You Compensate Programmers?
• Fog Creek Compensation
• Why I Never Let Employees Negotiate a Raise
• Professional Development Ladder
• Transparent Salaries

W kolejnym poście napiszę o systemie bonusów na wejście oraz opcji na akcje, które stanowią ważne uzupełnienie czystego systemu poziomów, a są bardzo mało znane w Polsce.

Jako programista przyzwyczaiłem się do...

Home

Jakiś czas temu rozmawiałem z kolegą z branży i w pewnym momencie powiedział on zdanie, które utkwiło mi w pamięci. Parafrazując stwierdził, że:

"Jako programista przyzwyczaiłem się do tego, że się ze mną rozmawia."

Powiedział to w kontekście pracy w firmie, dla kogoś. Chodziło o to, że nawet jeśli coś mu się nie podobało, ale musiał to zrobić bo ktoś podjął taką decyzję, to nie bolało tak bardzo jeśli ktoś z nim wcześniej o tym porozmawiał. Mam tutaj na myśli zarówno sprawy techniczne co nasuwa się samo, ale również te "miękkie" na przykład związane z organizacją pracy.

Jak się nad tym chwilę zastanowiłem to stwierdziłem, że z pewnymi wyjątkami mam podobne doświadczenie i w sumie takie podejście wydało mi się oczywiste. Pytanie czy tak jest wszędzie? Może po prostu mieliśmy szczęście. Czy macie podobne wrażenia, a może wprost przeciwnie?

Co wyróżnia bardzo dobrego programistę (2)?

Home

Pewnie słyszeliście o strumieniach (ang. stream) w .NET. O tym, że się je otwiera, a po użyciu zamyka. Zresztą w innych technologiach jest podobnie. Sprawa stara jak świat i wydawałoby się, że każdy o tym wie. Ja w każdym razie z definicji tak robię.

Dziwi mnie więc, że po tylu latach istnienia .NET ciągle pojawiają się pytanie z tym związane, jak na przykład to na stackoverflow.com. Dziwi mnie również, że przy okazji tego rodzaju pytań często pojawiają się najróżniejsze koncepcje / pomysły / odpowiedzi i to od użytkowników, którzy wcale nie są początkujący. Tymczasem wystarczy wrócić do podstaw, aby rozwiązać problem.

A może jest tak, że kiedy na co dzień pracujemy z skomplikowanymi algorytmami / trudnymi problemami biznesowymi / strukturami danych (niepotrzebne skreślić) to w pewnym momencie tracimy perspektywę i każdy napotkany problem od razu wydaje się nam skomplikowany.

Kolejny czynnik powodujący tą utratę perspektywy to chyba również mnogość różnych technologii i bibliotek, jakie są u obecnie używane. Ta biblioteka do tego, tamta ułatwia to, ta automatyzuje tamto itd. W ten sposób przyzwyczajamy się do tego, że wiele rzeczy coś robi za nas i my nie wnikamy w szczegóły i równocześnie zapominamy również o podstawach.

Nie mówię, że nie należy używać bibliotek, framework'ów czyli ułatwiać sobie pracy, ale bardzo dobry programista powinien również wiedzieć co, się za tym wszystkim kryje i nie zapominać o podstawach.

Z rozmów o pracę

Home

Nie wiem dlaczego, ale ostatnio wzięło mnie na refleksje. Siedzę, popijam sobie herbatę i tak ni z gruszki ni z pietruszki przypomniała mi się dawna rozmowa o pracę. Rozmawiałem z dwoma menadżerami, ale takimi z wiedzą techniczną, co to nie zmieniają szybko tematu, jak przechodzisz na tematy techniczne.

Rozmawialiśmy dość długo i w głowie utknęła mi jedna rzecz, jaką powiedzieli. Parafrazując, zgodnie stwierdzili, że ciężko znaleźć programistę, który nie byłby code monkey. Przy czym przez code monkey rozumieli trochę coś innego niż ja w tamtym momencie. Ja pod tym terminem rozumiałem osobę słabo radząca sobie z programowaniem, umiejąca napisać coś pod dyktando, ale nie dużo więcej. Dla nich jednak code monkey mógł być nawet bardzo dobry technicznie programista, doskonale radzący sobie z zadaniami, samodzielny... lecz z jednym bardzo istotnym z ich menadżerskiego punktu widzenia "ale". To jest nie umiejący lub słabo radzący sobie z komunikacją, w szczególności z biznesem, ludźmi nietechnicznymi, taki nieumiejący postawić się w roli użytkownika końcowego.

Z pewnością my programiści nie jesteśmy mistrzami komunikacji i Ci, którzy posiadają obok wiedzy technicznej umiejętności miękkie mogą się łatwo wyróżnić. Zastanawiam się jednak czy rzeczywiście większość z nas to geeki, którzy nie widzą nic poza kodem. Co myślicie?

Co wyróżnia bardzo dobrego programistę?

Home

Sądzę, że dla każdego bycie bardzo dobrym programistą oznacz trochę coś innego, na przykład do wyboru: znajomość nowych technologii, minimalizowanie używania myszki na rzecz posługiwania się głównie klawiaturą, samodzielne doszkalanie się, blogowanie, udział w konferencjach, komunikatywność, umiejętność pracy pod presją czasu... Ja jednak chciałbym zwrócić uwagę na inną rzecz.

Czasami jest tak, że dostajemy do naprawienie jakiś "wredny" błąd. Niekoniecznie wymaga on wielu zmian w kodzie, ale jest trudny do odtworzenia. Być może brakuje nam też danych, aby go powtórzyć lub opis jest niedokładny. A może jest tak, że błąd dotyczy nieznanego nam obszaru, kod jest brzydki albo to kolejny błąd dotyczący podobnej rzeczy i zaczyna nas to irytować.

W każdym razie mamy dosyć i, jak tylko znajdziemy przyczynę i wyk-minimy rozwiązanie (być może nietrywialne i wymagające dużo technicznej wiedzy), to szybko robimy commit i zapominamy o sprawie. To jest moim zdaniem ten moment, kiedy można zobaczyć na czym polega bycie bardzo dobrym programistą. Moim zdaniem w takiej sytuacji bardzo dobry programista, nawet mimo zniechęcenia, zada sobie dodatkowe pytania:

• Czy ten błąd nie występuje jeszcze gdzieś indziej, nawet jeśli zgłoszenie tego nie dotyczy?
• Jak jego poprawka wpłynie na resztę systemu? Powiązania pomiędzy różnymi modułami systemu mogą być nieoczywiste i często uzyskanie odpowiedzi na takie pytanie wymaga dużo wysiłku.
• Jaka jest pra-przyczyna błędu? Na przykład NullReferenceException można "naprawić" bardzo łatwo przy pomocy jednego if'ka. Często będzie to dobre rozwiązanie, ale może być też tak, że null nigdy nie powinien się pojawić w danym miejscu i jest on wynikiem zmiany gdzieś indziej.

To mogą być bardzo niewygodne pytania, szczególnie, jeśli się nam nie chce, ręce bolą i jest coś ciekawszego do zrobienia, ale równocześnie bardzo potrzebne, szczególnie, jeśli pracujemy z starszymi systemami czy nawet tymi młodszymi, ale bez testów automatycznych.

Nie wiem jak Wy, ale ja na początku swojej kariery uważałem, że w zawodzie programisty właściwie liczy się tylko strona techniczna, znajomość nowych technologii, bibliotek itd. W obecnej chwili rzeczy te uważam za niezwykle ważne, ale nie najważniejsze i coraz większą wagę przywiązuje do umiejętności i predyspozycji, nazwijmy je około-technicznych i miękkich. A co wy o tym myślicie? Też tak macie, a może to tylko moje "zboczenie"?

Jak komputer wpływa na na...

Home

W książce Płytki umysł. Jak internet wpływa na nasz mózg Nicholas Carr napisał, że Internet jest wspaniałym narzędzie, ale równocześnie wpływa na nasz sposób myślenia w niekoniecznie pozytywny sposób. Jako przykład podaje obniżoną możliwość skoncentrowania się na lekturze długich tekstów czy to artykułów czy książek.

Uważam, że niestety jest w tym dużo prawdy. Z wnioskami poszedłbym nawet dalej. Tutaj nie chodzi tylko o Internet, ale o używanie komputera w ogóle. Ostatnio zaobserwowałem u siebie skłonność do wykonywania nawet prostych obliczeń przy pomocy systemowego kalkulatora. Robię to wręcz bezrefleksyjnie. Niby nie ma w tym nic złego ponieważ w ten sposób ograniczam możliwość pomyłki. Z drugiej strony pamiętam czasy kiedy dużo bardziej skomplikowane zadania matematyczne rozwiązywałem w pamięci, na przykład zdarzało się, że wracając z uczelni liczyłem w głowie całki ;).

Komputer to pożyteczne narzędzie, ale rozleniwia. Postanowiłem, więc pilnować się i teraz nawet jeśli siedzę przed komputerem to staram się wykonywać obliczenia w głowie i ewentualnie później je sprawdzam. Mała rzecz, ale odzwyczaja od używania komputera do wszystkiego, nawet do rzeczy, które z powodzeniem można zrobić samemu.

Jestem ciekaw czy zauważacie u siebie takie lub podobne nawyki/tendencje spowodowane spędzaniem dużej ilości czasu przed komputerem? Jak sobie z tym radzicie?

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.

Czy zadajesz pytania?

Home

Czy próbowaliście kiedy rozwiązać następujące zadanie?

Napisz program, który wypisze na ekran konsoli swój własny kod. Możesz pominąć białe znaki.

(01-09-2014) Dodatkowe wymaganie:
Kod programu nie powinien być wczytany z pliku, bazy danych lub innego nośnika.

Zachęcam do sprawdzenia swoich sił. Zadanie to wysłałem również swoim kolegom z pracy. Wcześniej rozwiązałem je samemu i w gruncie rzeczy spodziewałem się podobnych do mojego rozwiązań. Zostałem jednak zaskoczony, bo okazało się, że inni podeszli do tego problemu troszkę inaczej, uzyskując ten sam wynik co ja, a nawet lepszy, bo w prostszy sposób. Sytuacja ta przypomniała mi kilka innych, w których zadanie prostego pytania:

Co o tym myślisz? Jak byś zabrał się do tego zadania?

Pomogło mi rozwiązać problem szybciej, lepiej, sprawniej... W pracy programisty niezwykle ważne jest konfrontowanie swoich pomysłów z rozwiązaniami innych. Wydaje Ci się, że wszystko zrobiłeś dobrze? A może ślęczysz nad jakimś problem już bardzo długo i cały czas nie możesz znaleźć zadowalającego rozwiązania?

Zawsze warto zapytać kolegi\koleżanki siedzącej obok o zdanie. To nie kosztuje dużo, a bardzo się opłaca. Nie ma głupich pytań chyba, że jak to powiedział mi kiedyś kumpel chcesz zapytać czy jak staniesz na torach i chwycisz się trakcji to pojedziesz jak tramwaj :)

Moje spojrzenie na DevDay 2013

Home

Przez długi czas stałym punktem w moim kalendarzu była konferencja MTS, ale w pewnym momencie zaczęła mnie nóżyć. Zrobiłem sobie przerwę i rok temu spróbowałem jeszcze raz, ale podobało mi się jeszcze mniej niż wcześniej. Wtedy usłyszałem o organizowanej w Krakowie konferencji DevDay. W sieci zebrała ona doskonałe opinie, więc w tym roku postanowiłem ją odwiedzić i o tym będzie ten post.

Kilka słów wstępu

DevDay organizowane są przez firmę ABB, ale poza logiem na identyfikatorach oraz niewielkich plakatów rozstawionych tu i tam firma w ogóle nie narzuca się uczestnikom. Generalnie charakter konferencji jest mało komercyjny i to wielki plus. Mnie co prawda odrobinę drażniło, że co chwilę ktoś robił zdjęcia np.: podczas rozmowy z prelegentami ale coś za coś, ABB też coś chciało mieć za wyłożenie pieniędzy :)

Organizacyjnie nie mam żadnych zarzutów, poza kolejką do obiadu, ale to drobnostka. Zresztą nie byłem jeszcze na konferencji, na której udało się to naprawdę dobrze zorganizować. Ekipa organizacyjna spisała się w 100%.

Z organizacyjnych rzeczy bardzo spodobało mi się kontrolowanie czasu, czyli pokazywanie prelegentom kartki z informacją ile jeszcze mogą mówić. Fajny był też system oceny sesji. Przy wychodzeniu z sali do dyspozycji miało się karteczkę czerwoną - nie podobało mi się, żółtą - było średnio i zieloną - podobało mi się. System może mało precyzyjny ale prosty, szybki i nie wymagający wypełniania żadnych ankiet.

Mój przewodnik po sesjach

Sesja początkowo

Pierwsza sesja miała być podobno krótka, ciekawa i motywująca. Prelegent porównał programowanie do biegania. Moim zdaniem wyszło niestety średnio (szczególnie na tle innych prezentacji) było krótko, ale niezbyt ciekawie i niezbyt motywująco.

Ocena: Na pograniczu żółtej i czerwonej karteczki.

"Back to basics: the mess we've made of our fundamental data types"
Jon Skeet

Przed prezentacją nie wiedziałem czego się po niej spodziewać. O prelegencie wiedziałem, że to łebski koleś, legenda StackOverflow, ale nie kojarzyłem go jako prelegenta. Temat też trochę budził moje podejrzenia, bo co można powiedzieć o podstawowych typach danych.

Jak się okazuje można i to jeszcze w jaki sposób. Prezentacja była poprowadzona we wspaniały sposób, z humorem, do tego była ciekawa i można było z niej dużo wynieść. Spróbujcie na przykład odwrócić ciąg znaków zapisany w zmiennej s na poniższym przykładzie:

var s = "Les Misérables".Normalize(NormalizationForm.FormD);

Ocena: Bardzo zielona karteczka.

"Scaling agile"
Dariusz Dziuk

Jedyny Polak w gronie prelegentów. Mówił o organizacji pracy w szwedzkiej firmie Spofity, która udostępnia utwory muzyczne prawie za darmo. W tej chwili zatrudnia kilkuset pracowników technicznych. Podzieleni są na kilkuosobowe zespoły, które są trochę takimi małymi firma tj.: same wybierają sobie narzędzia, sposób pracy, są wielo-platformowe, czyli jeśli pracują nad jakąś nową funkcjonalnością to mają ją dostarczyć na wszystkie platformy np.: Android'a i iOS. A drugim nadrzędnym celem Spotify oprócz zarabiania pieniędzy jest uszczęśliwiania pracowników :)

Prezentacja została poprowadzona bardzo sprawnie, ale bez porywów, momentami mi się dłużyła. Nietypowe (dla mnie na plus) było wprowadzenie podczas, którego Dariusz opowiedział kilka słów o historii Jazz'u.

Ocena: Żółta karteczka.

"SPA Made Breezy"
Tiberiu Covaci

Najbardziej techniczna sesja na jakiej byłem dotyczą tworzenia aplikacja SPA (ang. Single Page Application) przy pomocy Breeze.js oraz MVC. Trochę nie wyszedł pokaz możliwości biblioteki na żywo, co jednak nie zraziło prelegenta (tutaj widać obycie i doświadczenie).

Mi sesja nie przypadła do gustu, może dlatego, że na co dzień nie programuję aplikacji WWW, a może dlatego, że ostatnimi czasy prezentację, w których przewija się dużo kodu pisanego na żywo do mnie nie trafiają.

Ocena: Na pograniczu żółtej i czerwonej karteczki.

"Building Startups and Minimum Viable Products"
Ben Hall

Lekka, bardzo fajnie poprowadzona sesja dotycząca startup'ów, a prelegent wiedział o czym mówił, bo ma dwa na swoim koncie, a teraz pracuje dla firmy, która wyszykuje obiecujące firmy i w nie inwestuje. Ben zwrócił uwagę, że startując ze swoim pomysłem przede wszystkim trzeba mieć pasję, a najlepiej bardzo dużo pasji. Jego zdaniem na początek  należy unikać pisania kodu, jak najwięcej wykorzystywać istniejące rozwiązania, skupić się na dostarczeniu wartości, a nie na jakości kodu czy pisaniu testów jednostkowych. Dobry wynik dla firmy inwestującej w startup'y to podobno 30%, czyli jeśli 3 inwestycje na 10 zaczną na siebie zarabiać to jest dobrze.

Ocena: Zielona karteczka.

"Full-text search with Lucene and neat things you can do with it"
Itamar Syn-Hershko

Prezentacja była nie tyle o Lucene, co o rozproszonym serwerze przeszukiwania pełnotekstowego opartym o Lucene. Lekka techniczna sesja, z wprowadzeniem dla początkujących. Słyszałem głosy, że temat prezentacji sugerował co innego i było za dużo o rzeczach podstawowych, ale mi sesja się podobała, bo odświeżyłem sobie wiedzę.

Ocena: Zielona karteczka.

"The Architecture of StackOverflow"
Marco Cecconi

Portalu StackOverflow chyba nikomu nie należy przedstawiać. Na tym samym silniku stoi ponad 100 innych serwisów typu Q&A, a sam portal StackOverflow jest w czołówce najczęściej odwiedzanych stron na świecie. Wbrew pozorom do obsługi tego wszystkiego wystarczy 11 serwerów WWW, 4 serwery bazodanowe i dwa serwery cache'ujące używające technologii Redist. Każdy serwer bazodanowy ma ponad 300GB pamięci, tak aby pomieściła się cała baza danych.

Kod aplikacji podzielony jest raptem na kilka projektów (całość to ok. 100 tyś linii kodu). Testów jednostkowych jest bardzo mało, bo użytkowników jest tak dużo, że wszelkie błędy wykrywane są bardzo szybko. Ewentualne poprawki można dostarczyć w kilka minut. Co z tym związane, w wielu miejscach użyto klas statycznych, bo i tak nie będą mock'owane, a przede wszystkim ma być prosto. Zespół StackOverflow nie zastanawia się też na przejściem do chmury, czy użyciem bazy NoSQL, ponieważ wszystko działa dobrze tak jak jest. Lubię takie zdrowie podejście do tematu.

Prezenter skończył mówić z 15-20 minut przed czasem, ale pozostałą część sesji zajęły pytania z publiczności.

Ocena: Na pograniczu żółtej i zielonej karteczki ale bliżej zielonej.

"The software journeyman's guide to being homeless and jobless."
Rob Ashton

Kolejna genialna sesja. Rob pokazał niesamowity warsztat, a mówił o tym jak rok temu zrezygnował z pracy w korporacji bo miał dosyć, a pieniędzy i tak nie miał na co wydawać. Od tego czasu podróżuje po świecie z jedną walizką i pracuje tam gdzie dostanie lokum oraz bilet lotniczy. Teraz jest w Belgii i, jak sam mówi, to strasznie nudne miejsce, w Izraelu pracował nad RavenDB, w międzyczasie zaliczył wypadek samochodowy, kodował w Closure w czasie koncertu Eurowizji itd. A tak w ogóle trochę mu się śpieszyło bo chciał napić się piwa :)

Mi bardzo spodobało się też podsumowanie, w którym Rob powiedział coś w stylu (bardzo luźną parafraza) "No tak, ale ja nie mam żony, dzieci czy innych zobowiązań, a więc mi jest łatwiej. Wy też jednak możecie coś zrobić, zmienić pracę na ciekawszą, blogować, występować na konferencjach, uczyć się nowych rzeczy, dzielić się wiedzą..."

Ocena: Bardzo zielona karteczka.

Sesja końcowa

Sesja końcowa to dużo powiedziane, bo trwała małe kilkanaście minut. Nie zabrakło zasłużonych podziękowań dla prelegentów oraz dla ekipy obsługującej konferencję. Była też fala, poważnie, taka jaką widuje się na meczach piłkarskich oraz pamiątkowe zdjęcie :)

Ocena: Bardzo zielona karteczka

Podsumowanie

W dwóch słowach Było super! i już szykuję się na przyszły rok. Przyznam, że od strony technicznej dużo się nie nauczyłem, ale zdobyłem dużo miękkiej wiedzy i zastrzyk pozytywnej energii.

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!!!

Informatyka w służbie medycyny ;)

Home

Nie wiem jak większość z Was, ale ja na co dzień, jako programista agenta transferowego dla dużych instytucji finansowych, nie mam okazji obserwować jak wynik moich wysiłków przekłada się na pracę klienta. Sądzę, że nie jestem odosobniony i w mniejszym lub większym stopniu doświadcza tego każdy kto pracuje nad projektami przeznaczonymi dla dużych firm i korporacji. Z tego powodu lubię wykorzystywać swoje umiejętności i pomagać przyjaciołom i rodzinie.

Ostatnio moja szwagierka, która jest na specjalizacji z anestezjologii, spytała czy pomógłbym jej zautomatyzować papierkową robotę związaną ze specjalizacją. Papierologia ta przejawia się tym, że dla każdego zabiegu w jakim uczestniczy musi wypełnić odpowiedni formularz. Zabiegów takich w ciągu całego stażu musi wykonać, o ile mnie pamięć nie myli, około 2 tyś. Oznacza to konieczność wypełnienia i wydrukowania takiej samej liczby formularzy i dodatkowego zestawienia podsumowującego.

Wzór formularz przygotowała sobie sama w Excelu. Początkowe kilkadziesiąt kart wypełniła ręcznie. Robota łatwa ale żmudna i zawsze łatwo o pomyłkę. Dodatkowo ciężko potem przeglądać dużą liczbę takich kart i wyszukać tą, która nas w danej chwili interesuje. Formularz wygląda w następujący sposób:



Do tego informację o każdej takiej karcie zapisuje się w zestawieniu podsumowującym. Pomysł na automatyzację był następujący: "Chciałabym mieć arkusz w programie Excel z kolumnami, w które wpisywałabym informacje potrzebne do wypełnienia kart i zestawienia podsumowującego. Na tych kolumnach założę sobie filtry itp. Z arkusza tego generowane będę karty oraz zestawienie podsumowujące."

Zrobienie czegoś takiego nie jest trudne ale wymaga umiejętności pisania makr. Z chęcią przystąpiłem więc do pracy. Jedno popołudnie i nowe rozwiązanie było gotowe. Składa się na nie:

• Arkusz z wzorem formularza. Z tego arkusza wzór jest kopiowany i wypełniany.
• Arkusz z danymi. Każdy wiersz odpowiada jednemu formularzowi. Aby za każdym razem nie generować wszystkich kart zawiera dodatkową kolumnę ze znacznikiem czy już generowano daną kartę.
• Arkusz z podsumowaniem.
• Arkusz z wygenerowanymi kartami.
• Skrypt (140 linii) generujący podsumowanie i karty, uruchamiany kombinacją klawiszy Ctrl+G.

Coś bardzo prostego, chwila wysiłku, ale sporo satysfakcji.

Moda na chmurę

Home

To, że konferencja MTS 2010 odbyła się w dużym stopniu pod znakiem chmury obliczeniowej nie dziwi mnie. Nie dziwi mnie również, że prasa branżowa, portale społecznościowe, blogi i fora są pełne artykułów i postów na ten temat. Cloud computing to przecież relatywnie nowe i bardzo ciekawe ze względów technologicznych zagadnienie, również dla mnie.

Jestem natomiast zaskoczony, że tematyka chmury obliczeniowej zaczęła bardzo szybko wpływać szerokim nurtem do prasy nie branżowej. W czasie ostatniej wizyty w salonie prasowym w jednym z magazynów przeznaczonych dla menadżerów, którego tytułu niestety nie pamiętam, zobaczyłem artykuł zachwalający zalety chmury. Zaś w magazynie Forbes znalazłem cały, obszerny dodatek poświęcony tylko chmurze! Z ciekawości sprawdziłem czy tematyka chmury była poruszana na portalach takich jak onet.pl czy rp.pl i znalazłem kilka artykułów. Z innych przykładów, koleżanka, która pracuje w instytucji finansowej, powiedziała mi, że dyrektor działu IT zapowiada wykorzystanie tej technologii. Od kolegi z pracy dowiedziałem się natomiast, że jego promotor, który do tej pory nie przywiązywał uwagi do nowinek, stwierdził, że chmura to coś ciekawego.

Chmura bardzo szybko staje się albo już stała się modna, słyszy się o niej prawie wszędzie, a przede wszystkim budzi zainteresowanie biznesu. Z jednej strony niesie to z sobą szanse rozwoju firm, które zainwestują w chmurę oraz kontraktów dla firm IT. Z drugiej strony stare przysłowie mówi, że co nagle to po diable. Nie budzi natomiast wątpliwości fakt, że działy marketingowe dostawców rozwiązań typu cloud wykonały kawał dobrej roboty.

100 postów

Home

Niby 100 to liczba jak każda inna ale jednak ponad 100 opublikowanych postów skłoniło mnie do spojrzenia wstecz i napisania krótkiego podsumowania. Należy zacząć od tego, że napisanie takiej liczby postów zajęło mi 2 lata co daje średnio 4 posty w miesiącu. Mało to czy dużo? Dla mnie w sam raz. Były okresy, w których publikowałem więcej i takie, w których pojawiał się jeden post w miesiącu. Poruszałem różne tematy, głównie związane z platformą .NET i nowoczesnymi technologiami ale pojawiły się również posty związane z grami komputerowymi, mini recenzje sztuk teatralnych czy na temat inicjatywy Powrót do Ojczyzny. Zawsze starałem się aby to co piszę było dla innych w jakiś sposób wartościowe. Nie mi to oceniać ale wierzę, że mi się udało.

Co zrobiłem w ciągu 2 lat?

W tym czasie blog ewaluował i zmieniał się, domyślny szablon dostosowałem do swoich potrzeb i gustu, dodałem podświetlanie składni przy pomocy syntaxhighlighter'a, chmurę etykiet, QR kod z zakodowanym moim adresem e-mail, sekcję Aktualnie czytam, stopkę z informacją o prawach autorskich, licznik subskrypcji ... by w końcu osiągnąć obecną, odpowiadającą mi w prawie 100% formę. Nauczyłem się jak pisać i redagować posty oraz, że każdy post przed opublikowaniem należy odłożyć i wrócić do niego za kilka godzin lub najlepiej następnego dnia w celu ponownego sprawdzenia. Nieoceniony jest, że kiedy wpiszę w Google swoje imię i nazwisko to mój blog pokazywany jest na jednym z pierwszych miejsc. Moje wpisy pojawiają się wśród pierwszej 10 wyników po wpisaniu takich haseł jak: IntelliTrace, blog programowanie czy visual studio blog (stan na moment pisania tego postu). Linki to mojego bloga można również znaleźć w serwisach dotnetmaniak, dotnetblogs czy dotnetnews. Nie jestem już, więc anonimowy w sieci, a co najważniejsze pokazałem się z dobrej strony, a to było jednym z moich celów kiedy zaczynałem blogowanie.

Co dalej?

Co tu ukrywać blogowanie spodobało mi się. W przyszłości chciałbym przynajmniej utrzymać, a najlepiej zwiększyć średnią 4 postów w miesiącu, oczywiście bez obniżenia poziomu. Będę również starał się zdobyć więcej czytelników i pobudzić ich do komentowania. Po głowie chodzą mi również takie pomysły jak przejście z bloggera na platformę WordPress czy artykuły dwujęzyczne (Pl/En).

Jeśli ktoś z Was ma dla mnie jakieś rady lub uwagi, coś mu się w tym blogu nie podoba albo odwrotnie coś mu przypadło do gustu, a może chciałby więcej lub mniej wpisów na jakiś temat i powinny być dłuższe lub krótsze... to z przyjemnością wysłucham wszystkich głosów.

Jeden duży projekt, czy może wiele małych

Home

Kilka dni temu dyskutowałem z kolegą na temat tego czy całość/większość kodu powinna być umieszczona w jednym dużym projekcie (jak On uważa) czy rozłożona pomiędzy mniejsze projekty (jak uważam Ja). Przez projekt rozumiem tutaj jednostkę organizacji kodu np.: csproj w Visual Studio. Duży projekt to dla mnie taki, który zawiera wszystko czyli: implementację GUI, logikę biznesową, interfejsy, struktury danych, klasy dostępu do danych itd. Może się to przekładać na liczbę linii kodu ale nie musi. Dalej, aby odróżnić projekt jako jednostkę organizacji kodu od projektu jako przedsięwzięcia biznesowego będę używał sformułowania projekt biznesowy dla tego drugiego.

Wracając do wspomnianej dyskusji to zakończyła się impasem ponieważ żaden z nas nie zmienił swojego zdania. Spowodowała jednak, że postanowiłem jeszcze raz gruntownie przemyśleć sprawę. W ten sposób powstała poniższa lista zalet i potencjalnych wad małych projektów. Listy te są skonstruowałem w ten sposób, że na początki znajdują się najważniejsze/najpoważniejsze zalety i wady.

Zalety

• Łatwiejsze użycie tego samego kodu w innym projekcie biznesowym. Przy dużych projekcie również jest to możliwe ale oznacza dodanie referencji do wielu innych niepotrzebnych w danym kontekście rzeczy czyl bałagan.
• Wymusza poprawną architekturę. Na przykład jeśli GUI, logika biznesowa i dostęp do bazy danych znajdują się w innych projektach to projekt z GUI będzie miał referencję na projekt z logiką biznesową ale nie na odwrót ponieważ referencje cykliczne nie są dozwolone.
• Ułatwia dalszy rozwój. Wyobraźmy sobie sytuację, w której projekt biznesowy jest na etapie stabilizacji i zbliża się termin oddania. Z drugiej strony istnieje konieczność dalszego rozwijania jakiejś jego części. Po wdrożeniu klient zapewne będzie zgłaszał błędy. Po jakimś czasie może pojawić się potrzeba złączenia (merge) dwóch (lub więcej) ścieżek rozwoju czyli przeniesienia poprawek błędów z wersji produkcyjnej na rozwojową i dodanie nowych funkcji z wersji rozwojowej do wersji produkcyjnej. W przypadku małych projektów łatwiej zorientować się co się zmieniło, co trzeba przenieść, a co nie, czy merge spowoduje jakieś błędy itd.
• Aspekty psychologiczne. Nie przytłacza liczbą plików i folderów. Łatwiej zorientować się "o co biega" - łatwiej jest pracować z małym projektem odpowiedzialnym za jedną konkretna rzecz niż z dużym odpowiedzialnym za dziesiątki różnych rzeczy.
• Łatwiejsze utrzymanie testów jednostkowych. W przypadku podejścia, w którym testy jednostkowe są umieszczane w innym projekcie niż testowany kod będzie mieli kilka małych projektów z testami jednostkowymi. W podejściu przeciwstawnym w danym projekcie będziemy mieli ograniczoną liczbę testów dotyczących tego jednego projektu. Należy to przeciwstawić dużym projektom gdzie powstanie nam albo kolejny duży projekt na testy jednostkowe albo bardzo duży projekt zawierający wszystko plus jeszcze testy jednostkowe tego wszystkiego.
• Prostsze i łatwiejsze w utrzymaniu pliki konfiguracyjne. Ma to znaczenie jeśli używamy technologii wymagających wielu plików konfiguracyjnych, najczęsciej dokumentów XML np.: Spring.
• Krótsza kompilacja. Jeśli nie zmieniły się interfejsy to można skompilować pojedynczy, mały projekt.
• Wykonywanie brancha małego projektu trwa szybciej

Wady

• Defragmentacja pamięci. Pisałem o tym już wcześniej. Problem polega na tym, że przy ładowaniu do pamięci moduły nie są ustawiane jeden po drugim ale są umieszczane w "losowo" wybranych miejscach co powoduje poszatkowanie pamięci. W większości wypadków nie jest to problemem ale na przykład przy alokacji dużej bitmapy potrzebny jest ciągły obszar pamięci. W wyniku defragmentacji system będzie dysponował dostatecznie dużą ilością pamięci ale nie w jednym kawałku. Problem nie występuje na systemach 64-bitowych, które są coraz powszechniejsze.
• Dłuższe uruchamianie VS. Jeśli utworzymy Solution i dodamy do niego kilkadziesiąt projektów to jego otwieranie będzie trwać długo. Z drugiej strony czy aby na pewno praca z kilkudziesięcioma projektami ma sens?
• Konieczność zarządzania dużą liczbą referencji. Każdy lub prawie każdy projekt będzie miał kilka lub więcej referencji do innych projektów. Zgadzam się, że może to być problem. Z drugiej strony pracowałem przy rozwijaniu naprawdę dużego systemu składającego się z kilkunastu podsystemów, każdy z kilkunastoma małymi projektami z czego część była współdzielona i radziliśmy sobie.
• Trudniejsza instalacja. Wynika to z dużej ilości bibliotek dll, które powstają w wyniku kompilacji wielu małych projektów. Mogą również wystąpić konflikty wersji. Podobnie jak wyżej zgadzam się, że jest to możliwe ale podobnie jak wyżej przeciwstawiam tej wadzie swoje doświadczenie, które mówi co innego.
• Dłuższa kompilacja całego systemu. Zgadzam się, przy wielu małych projektach kompilacja wydłuży się i to znacznie. Jednak i tutaj dołożę swoje trzy grosze. Jak często istnieje potrzeba przekompilowania całego systemu? Jeśli w danym momencie pracujemy z kilkoma konkretnymi projektami to po co wykonywać build wszystkich pozostałych? Ma to sens, jeśli zostały zmienione klasa, struktury lub interfejsy używane w wielu innych projektach.
• Problemy z konfiguracją tych samych rzeczy w różnych projektach. Przy odpowiedniej architekturze systemu i zastosowaniu odpowiednich wzorców projektowych (singleton, fabryka) nie jest to dla mnie żaden problem.
• Zwiększony czas uruchamiania aplikacji. Tak ale o ułamki sekund.

Ponieważ w powyższych wyliczeniach powoływałem się na to, że coś trwa tyle, a tyle przytoczę bardzo fajne zestawienie porównujące czasy kompilacji, ładowawania solution'a przez Visual Studio itd. dla różnej liczby projektów, które pojawiło sie w dyskusji na portalu stackoverflow - odpowiedź autorstwa jerryjvl'a.

Reasumując jestem przekonany, że zalety dzielenia kodu na małe projekty przeważają potencjalne wady. Co więcej uważam, że problemy z małymi projektami wynikają głównie ze złego podejścia i przyjęcia nieodpowiednich rozwiązań takich jak: budowanie wszystkich projektów zamiast kilku wybranych lub z dogmatycznego trzymania się małych projektów czyli bezrefleksyjnego tworzenia małego projektu na wszystko co się da. Co za dużo to jednak nie zdrowo :)

Na koniec jedna uwaga. Na początku projektu biznesowego może się wydawać, że lepiej trzymać wszystko w dużym projekcie bo tak prościej, bo kodu mało. Ale o ile nie jest to rzeczywiście malutki projekt biznesowy to szybko okaże się, że podzielenie kodu na mniejsze projekty będzie wymagać tyle pracy, że nikomu nie będzie się tego chciało zrobić.

Jak rozpoczęła się moja przygoda z Delphi

Home

Los chciał, że od jakiegoś czasu do moich obowiązków dołączyła potrzeba utrzymywania i pielęgnacji komponentu drzewo-listowego (kontrolka pozwalająca na wyświetlanie danych hierarchicznych i listowych z wieloma kolumnami) napisanego w Delphi. Długi broniłem i zapierałem się nogami ale w końcu musiałem się poddać. Dodam, że moja wiedza na temat Delphi była mniej niż skromna. Była bo teraz jest po prostu skromna :).

Plusem całej sytuacji jest to, że kod, który otrzymałem do pielęgnacji został dobrze wytestowany, komponent zachowuje się bardzo stabilnie, jednym słowem zgłoszeń błędów jest mało.

Można zapytań po co utrzymywać stary komponent skoro można napisać nowy albo jeszcze lepiej wybrać i zakupić jeden z istniejących na rynku. Z przepisaniem problem jest taki, że potrzeba by pewnie jednego osobo-roku zdolnego programisty aby to przepisać na .NET (tyle mniej więcej zajęło napisanie starego komponentu) plus dużo czasu na wytestowanie i stabilizację. Ameryki nie odkryję jeśli powiem, że znalezienie takiej ilości zasobów na w gruncie rzeczy niekomercyjny projekt to trudna sprawa.

Jeśli chodzi o zakupienie komercyjnego rozwiązania to pomysł dobry ale zawsze jest jakieś ale. Osobiście zapoznałem się i przebadałem pod względem wydajności, funkcjonalności itd. około dziesięciu rozwiązań dostępnych na rynku. Niektóre komponenty mają naprawdę duże możliwości. Problem polega na tym, że pomimo wszystko nie pokrywają wszystkich cech komponentu stworzonego na wewnętrzne potrzeby firmy, w której pracuję. Nie wchodząc w szczegóły firmowy produkt potrafi naprawdę dużo. Sytuacja bez wyjścia? Tak i nie. Tak, ponieważ z pewnością nie uda się znaleźć rozwiązania w 100% pokrywającego wymagania. Nie, ponieważ w obecnej chwili firma rozwija swoje produkty w .NET, a używanie starego komponentu wymaga użycia ActiveX z czego raz po raz wynikają jakieś problemy. Nie wspominając już o konieczności utrzymywania starego kodu.

Reasumując moja przygoda z Delphi jeszcze potrwa i mam nadzieję, że się czegoś nauczę. Na razie dzięki porównaniu IDE dla Delphi z Visual Studio zdałem sobie sprawę jak duży postęp dokonał się jeśli chodzi o zintegrowane środowiska programistyczne. Z drugiej strony porównanie czasu kompilacji dużego projektu napisanego w Delphi do projektu napisanego w .NET wypada bardzo znacząco na korzyść tej pierwszej technologii. Niestety podobnie jest z szybkością uruchamiania się aplikacji.