Wszystkie wpisy, których autorem jest ynka

Poznań, 2014: o tym jak napisałam do „Wysokich Obcasów”

W najbliższym czasie na moim blogu, gdzieś pomiędzy Scalą, pojawi się kilka tekstów na temat kobiet i, w szczególności, matek w IT. Znów inspirują mnie do tego okoliczności. Zanim poskładam te teksty, chciałabym podzielić się z Wami listem, który dawno temu (2014) wysłałam do redakcji „Wysokich Obcasów” w odpowiedzi na ich apel o przedstawienie „problemów współczesnych kobiet”. Rozwinęło się to w fajną przygodę: dwie miłe panie reporterki odwiedziły mnie w domu i użyły moich opowieści w jednym z reportaży. Na tyle skutecznie, że mimo że nie podałam nazwiska ani nazwy pracodawcy, kilkoro przyjaciół zorientowało się, że to ja.

Poniżej minimalnie tylko zredagowany list. Plus kilka współczesnych refleksji na końcu.

Poznań, 8 maja 2014

Wiele razy piętnowałam, prywatnie i publicznie, przejawy dyskryminacji zarówno w miejscu pracy [1 – uzupełniające cytaty poniżej], jak i na drodze, która w to miejsce prowadzi [2]. Tyle razy wdałam się w dysputy na firmowych zebraniach [3], tyle razy tłumaczyłam, dlaczego kobiety nie wybierają studiów technicznych [4], tyle razy byłam zapraszana na debaty na ten temat – że ostatnio, przez chwilę, wydawało mi się, że wszystko zostało powiedziane i nie ma już o czym rozmawiać.

Poświęciłam chwilę na refleksję nad apelem o wskazanie bolączek współczesnych kobiet. Bolączka, którą rozstrząsam właściwie codziennie, która w dużej mierze definiuje może życie zawodowe i prywatne.

Poświęciłam chwilę na refleksję nad Waszym apelem o wskazanie bolączek współczesnych kobiet. Bolączka, którą rozstrząsam właściwie codziennie, która w dużej mierze definiuje może życie zawodowe i prywatne.

Jest tak:

Mam trochę ponad 30 lat, męża, doktorat, dobrą pracę w dziale badawczym międzynarodowej firmy. Mnóstwo ofert pracy, w tym od gigantów w mojej dziedzinie. Obserwuję (z sympatią)
kolegów ze studiów, którzy podążają za każdą korzystniejszą lub umożliwiająca lepszy rozwój ofertą. Koleżanki z reguły pracują w jednej firmie znacznie dłużej; spora część z nich prowadzi (dobrze prosperujące) malutkie firmy z własnego domu. Sama, podobnie jak one, czuję, że zawodowe skakanie z kwiatka na kwiatek nie jest dostępną dla mnie opcją.

Dlaczego? Ponieważ jestem kobietą i kiedyś (a teraz już bliżej niż dalej) prawdopodobnie będę chciała mieć dziecko.

Nie, nie boję się, że stracę pracę pierwszego dnia po powrocie i zostanę na lodzie z małym dzieckiem. W moim zawodzie ciągle pracy jest więcej niż przyzwoitych fachowców. Rozmowy kwalifikacyjne to akurat jedna z nielicznych sytuacji, w których nigdy nie odczułam, by moja płeć miała znaczenie. Irytuje mnie to, że kiedy znajomi faceci są u szczytu kariery
zawodowej, przebierają w ofertach i pną się w górę (zgodnie z zasadą, że nigdzie nie awansują cię tak szybko, jak wtedy, gdy jedna firma podkrada cię drugiej) – ja ciągle mam skrupuły. Bo przecież za chwilę mogę chcieć być w ciąży.

Z ciążą problem jest następujący – wymaga zniknięcia z pracy na dobrych kilka miesięcy. Głupio by było po trzech miesiącach w nowym miejscu pójść na zwolnienie z powodu zagrożonej ciąży i pojawić się ponownie po kolejnym roku, gdy nikt nie będzie już pamiętał, skąd się wzięłam. Prawda? Mogłoby to utwierdzić pracodawcę w przekonaniu, że kobietom
tylko to (wynagrodzenie na chorobowym/macierzyńskim) w głowie. Zatem pracuję pilnie kolejny rok, starając się pokazać przełożonemu, że w razie czego warto te kilka miesięcy na mnie poczekać. Wszystko na zapas, gdy nawet nie zaczęliśmy z mężem starań o to dziecko. Gdy wiem, że takie starania mogą trwać latami lub w ogóle zakończyć się niepowodzeniem.

Trudno nazwać to niesprawiedliwością. Brak tu złej woli z czyjejkolwiek strony. To miejsce, w którym pokonuje mnie sama biologia. Zaczynam myśleć, że niedobór kobiet na najwyższych, eksponowanych stanowiskach i w zarządach niekoniecznie wiąże się z seksizmem i dyskryminacją (bo to, że nie wiąże się z mniejszymi zdolnościami kobiet, jest dla mnie oczywiste). Kobiety „same” się eliminują – w najbardziej produktywnym wieku, w momencie najlepszym na nawiązywanie kontaktów, prezentowanie profesjonalizmu, pięcie się w górę – one „produkują” dzieci, lub panikują na ten temat.

No i co z tym zrobić? 🙂

J.

[1] „Wow, jeszcze nigdy nie widziałem, żeby kobieta to potrafiła!”
[2] „Dzisiaj będziemy omawiać geometrię przestrzenną. Z mojego
doświadczenia wynika, że chłopcy radzą sobie z tym lepiej, niż dziewczynki”.
[3] „O co ci chodzi, nie ma nic złego w tym, że kobiety lepiej się znają
na kolorach”.
[4] „Studiuj na politechnice, twój mąż już tu jest”.

 

Od czasu napisania tego listu sporo się u mnie pozmieniało. Mam dwójkę dzieci i nowego pracodawcę (którego bardzo sobie chwalę, ale o tym w następnym tekście). Jeśli chodzi o kwestie poruszone w powyższym tekście, mam dwie gorzkie anegdoty:

  1. Zdecydowałam się na ciążę 2 latach pracy w jednym miejscu. Byłam już w zaawansowanej ciąży, kiedy firma podjęła decyzję o likwidacji (relokacji) poznańskiego biura. Nie miałam dokąd wracać… Chociaż muszę przyznać, że cała historia skończyła się dla mnie bardzo korzystnie.
  2. W nowym miejscu, trochę pamiętna tamtych doświadczeń, trochę wstrząśnięta falą zwolnień, a trochę zgodnie z zasadą „życie>praca” podjęłam decyzje o ciąży po 5 miesiącach. Pracowałam aktywnie do 7 miesiąca ciąży, mimo że czułam się podle – ci, którzy znają mnie osobiście, wiedzą jak bardzo. Dość powiedzieć, że układ kafelków na podłodze w firmowej toalecie dla inwalidów znów mam wyryty w mózgu po wsze czasy (za pierwszym razem było tak samo). No i i tak spotkałam się z komentarzem, z ust kobiety – „a ta tak krótko pracuje i już na zwolnieniu”.

Na koniec jeszcze oświadczenie: zdaję sobie sprawę, że opisuję tzw. problemy pierwszego świata i wiem, na jak uprzywilejowanej pozycji jestem, nie tylko z powodu własnych zasług.

Fajne rzeczy w Scali: klasy przypadków

Skończyłam pierwszy z pięciu kursów programowania w języku Scala w pięciokursowej specjalizacji na Courserze, prowadzonej przez twórcę tego języka.

Kolejna ciekawa cecha języka, jaką poznałam, to klasy przypadków (ang. case classes) i dopasowywanie wzorców (ang. pattern matching).

Instrukcje wielokrotnego wyboru i wzorce w innych językach

W wielu językach programowania istnieje jakaś forma instrukcji switch. W Javie pozwala  ona dokonywać wyboru dla zmiennej typu prostego oraz, nie od początku, zmiennej typu String. Na przykład:

Dopasowywanie wzorców i instrukcja match w Scali

Niektóre języki, w tym Scala, idą o krok dalej. Instrukcji wielokrotnego wyboru można w nich używać nie tylko na danych typów prostych. Co więcej, dopasoowywanie wzorców pozwala nam opisać przypadki w sposób niepełny – np. z zastosowaniem symboli wieloznacznych (ang. wildcards).

Poniżej przykład ze Scali, w którym przetwarzane są wierzchołki drzewa binarnego – osobno wierzchołki wewnętrzne (Fork), osobno liście (Leaf) drzewa.

W zależności od typu wierzchołka (Fork lub Leaf) oraz od wartości jednego z pól w przypadku klasy Leaf, w odmienny sposób zwrócona zostanie waga wierzchołka.

Nieistotne parametry zostały zastąpione symbolem _, który dopasuje się do wszystkiego.  Istotnym parametrom przypisujemy nazwę, dzięki czemu będzie można się do nich odwołać. Można też użyć ukonkretnionych wartości, żeby zdefiniować konkretne przypadki.

Po prawej stronie case nie ma żadnego przypisania ani instrukcji, ponieważ match jest wyrażeniem – zwróci jako wartość prawą stronę operatora =>.

Test  powyższej funkcji (przechodzący, daję słowo):

Klasy przypadków i ich cechy

Brakuje jeszcze definicji klas Leaf oraz Fork. Jak łatwo się domyślić, żeby używać ich w ten sposób, klasy te muszą zostać zdefiniowane jako klasy przypadków.

Ich definicja wygląda tak:

Klasy przypadków:

  • definiuje się z użyciem słowa kluczowego case,
  • powinny być niemodyfikowalne,
  • są porównywane przez podobieństwo strukturalne i wartości, a nie przez referencję,
  • wartości przekazane w konstruktorze są publicznie dostępne.

FAQ

Poniżej kilka szybkich pytań i odpowiedzi:

Q1: Co się stanie, jeśli nie przewidzisz wszystkich wzorców i na etapie wywołania okaże się, że zmienna nie pasuje do żadnego wzorca?
A1:  Otrzymasz scala.MatchError.

Q2: Jak utworzyć odpowiednik javowego default?
A2: Tak:

Q3: Czy to działa także dla typów prostych.
A3: Tak. Co więcej, możliwa jest nawet taka operacja:

PS.

Bardzo to wszystko wygodne i czytelne.

O, podstawowa dokumentacja Scali została przetłumaczona na język polski!

Fajne rzeczy w Scali: zwracanie funkcji

Kontynuuję kurs programowania w języku Scala, o którym wspominałam w poprzednim wpisie.  Zgodnie z obietnicą, pokazuję kolejną fajną rzecz, której się nauczyłam.

Funkcje, które zwracają funkcje!

W Scali funkcje są tzw. obywatelami pierwszej kategorii (ang. first class citizens).  Inaczej, funkcje są pierwszoklasowe. Oznacza to, że można z nimi robić wszystko to, co można robić z „normalnymi” typami danych, to jest: przekazywać jako argumenty, przypisywać do zmiennych, zwracać z funkcji, tworzyć je na bieżąco.

W szczególności, jedna funkcja może zwrócić inną. Poniżej przykład.

Na początku tworzymy alias o nazwie Set. Reprezentuje on typ funkcyjny: wszystkie funkcje pobierające parametr typu Int i zwracające wartość typu Boolean. W ten sposób chcemy, na potrzeby przykładu, reprezentować zbiory: jako funkcję, która dla każdej podanej liczby całkowitej powie nam, czy liczba ta należy do tego zbioru.

Jeśli nasz zbiór ma być zbiorem jednoelementowym (ang. singleton), to w zależności od tego, jaki to element, musielibyśmy utworzyć (nieskończenie) wiele funkcji sprawdzających, przynależność do zbioru – dla każdego możliwego elementu zbioru jednostkowego. Osobno dla zbioru zawierającego tylko liczbę 1, osobno dla liczby 2 itp. Dzięki możliwości zwracania funkcji, mamy tylko jedną funkcję, która tworzy i zwraca funkcję badającą przynależność do zbioru jednostkowego zawierającego wybrany element – przekazany jako parametr do funkcji singletonSet.

Jak to działa w praktyce?

Na początku testu tworzymy zbiór jednoelementowy zawierający liczbę całkowitą 4. Nasz zbiór – czyli funkcję pobierającą argument Int, zwróconą z funkcji singletonSet – przypisujemy do zmiennej (hm, stałej właściwie) single.

Następnie, wywołując funkcję przypisaną do zmiennej single, sprawdzamy, czy do zbioru {4} należą odpowiednio liczby 4 oraz 1. Zgodnie z oczekiwaniami, dla 4 otrzymujemy wartość true, dla 1 wartość false.

Uczę się Scali!

Zapisałam się na kurs programowania w języku Scala. Prowadzi go na Courserze twórca tego języka, Martin Odersky.

Postanowiłam po każdym tygodniu kursu dzielić się jakimś spostrzeżeniem albo cechą języka.

Co spodobało mi się w pierwszym tygodniu? Możliwość definiowania funkcji zagnieżdżonych, czyli funkcji w funkcjach. Poniżej przedstawiam definicję funkcji rekurencyjnej spradzającej parzystość nawiasów. Pomocnicza funkcja z dodatkowym parametrem jest zdefiniowana wewnątrz niej.

Co to daje? Przede wszystkim, funkcje pomocnicze przeznaczone do jednokrotnego użycia nie zaśmiecają przestrzeni nazw. Oczywiście w Javie zdefiniowałabym taką funkcję jako prywatną, więc do „zaśmiecenia” doszłoby tylko w ramach jednej klasy – ale i to potrafi uprzykrzyć kodowanie, np. kiedy IDE podpowiada mi wersje metody zamiast jednej.

Scala nie jest jedynym językiem pozwalającym na stosowanie zagnieżdżonych funkcji. Pełna lista jest dostępna w Wikipedii, w artykule o funkcjach zagnieżdżonych (opisane są tam też „obejścia” tego problemu w językach bez bezpośredniego wsparcia dla takich funkcji).

Inna rzecz, która przykuła mogą uwagę na kursie, to akcent prowadzącego. Nie mogłam się oprzeć i sprawdziłam, skąd pochodzi. Okazało się, że to Niemiec, ale pracujący we francuskojęzycznej części Szwajcarii.

Swoją droga, bardzo podobają mi się zadania domowe. Wymagają chwili pomyślunku, dobrze ilustrują treść wykładów – a przy tym nie zajmują bardzo dużo czasu.

Zachęcam do przyłączenia się do mnie na kursie!

Nie takie korpo straszne, czyli o wartości feedbacku

Całe dotychczasowe życie zawodowe spędziłam, pracując w dużych firmach.

Anegdotka nr 1, czyli prasówka babci Halinki

Mój poprzedni pracodawca zatrudnia na całym świecie ponad 300.000 osób. Za czasów pracy tam, kiedy tylko odwiedzałam rodzinne miasto (które ma mniej więcej tyle samo mieszkańców, co tamta firma pracowników), babcia zadawała mi zawsze to samo pytanie. Pytała mnie, mianowicie, czy korporacja już wyżęła mnie i wyrzuciła jak zużytą ścierkę.

Na początku próbowałam tłumaczyć, że każda firma, a nawet każde biuro firmy, niezależnie od wielkości, wytwarza własną kulturę pracy. Że w dużych firmach istnieją mechanizmy kontroli, podczas gdy w małych Krzaczeksach niejednokrotnie wszystko rozbija się o widzimisię szefa (z całym szacunkiem dla rodzinnych biznesów i ambitnych startupów). I jeszcze, że rozpasanych programistów z reguły traktuje się po królewsku.

Efekt był żaden, więc w końcu się poddałam i odpowiadałam tylko, że jeszcze nie. Niedługo później firma postanowiła „skonsolidować” pracowników w Warszawie. Nie przeniosłam się, a babcia uznała, że moje przeznaczenie się dopełniło.

Co to znaczy „korporacja”?

Z reguły, kiedy mówię o „korporacji”, mam na myśli firmę, która spełnia większość z wymienionych poniżej warunków:

  • zatrudnia co najmniej 200 pracowników,
  • oferuje benefity takie jak prywatne usługi medyczne czy karta Multisport,
  • organizuje imprezy integracyjne,
  • ma biura w więcej niż jednym mieście,
  • wprowadziła system oceny okresowej.

Anegdotka nr 2, czyli co mnie skłoniło do napisania tego tekstu

Do niedawna nie poświęcałam dużo uwagi temu, w jaki sposób, poza kwestiami czysto merytorycznymi (jak technologie, które poznałam) zmieniła mnie praca dla korporacji. Ale ostatno wydarzyło się coś, co skłoniło mnie do refleksji na ten temat.

Zostałam poproszona przez znajomą panią fotograf o napisanie rekomendacji na jej stronie. Zrobiłam to z przyjemnością, ponieważ lubię ją i podobają mi się wyniki jej pracy. Postanowiłam także wykorzystać okazję, żeby przekazać jej (poza recenzją) jedną uwagę krytyczną. Otóż jedna z koleżanek poskarżyła mi się jakiś czas temu, że podczas sesji niemowlęcej u niej w domu w pani fotograf karcąco odniosła się do karmienia dziecka małego butelką.

Wiedziałam, że to nieporozumienie, ale w jakiś sposób do niego doszło. Przekazałam informację. Spodziewałam się odpowiedzi w stylu „ok, zwrócę uwagę na to, jak rozmawiam z mamami”. Albo, że zignoruje to jako wypadek przy pracy. Nie moja sprawa.

Tymczasem rozpętało się piekło. Fotograf najpierw oskarżyła koleżankę o złośliwość i chęć zaszkodzenia. Potem twierdziła, że to na pewno nie o niej. Później tłumaczyła mi wielokrotnie, że nigdy powiedziałaby nic takiego. Tego dnia poszłam spać z podłym uczuciem, że chciałam pomóc, a jedynie wytrąciłam kogoś z równowagi.

Zrozumiałam wtedy, że mój korporacyjny trening w otrzymywaniu feedbacku i oceny sprawił, że podobnie jak moi współpracownicy i wielu znajomych, reaguję na krytykę inaczej, niż znaczna część naszego społeczeństwa.

Znienawidzona roczna ocena

Wierzę w firmowe systemy oceny. Zdarzyło mi się pracować w dużej (200+) firmie, gdzie takiego systemu brakowało. Prawie nie sposób było dostać podwyżkę, ponieważ szef, do którego trzeba się było udać, nie do końca odróżniał dziesiątki pracowników. Błagaliśmy o wprowadzenie formalnego systemu oceny, który pozwoliłby nam wykazać, że zasługujemy na podwyżkę.

Feedback to nie to samo ocena

Ocena, niezależnie od tego, czy jest ilościowa (np. w skali od 1 do 100) czy jakościowa (dobrze, średnio, źle), podsumowuje nasz wysiłek i informuje o aktualnym położeniu w firmie. Czy w perspektywie mam awans, czy raczej grozi mi zwolnienie?

Feedback, czyli informacja zwrotna, nie powinien być mylony z oceną. Celem wymiany informacji tego typu ma być rozwój. Jeśli kolega z pracy popełnia błąd ciągle w tym samym miejscu, warto wskazać mu odpowiednią lekturę albo kurs. Może utwierdza się w przekonaniu, że tak jest dobrze? Jeśli ktoś opowiada obraźliwe żarty, warto, żeby urażona nimi osoba zwróciła mu uwagę, zamiast znosić je w milczeniu i kisić w sobie złość oraz żal.

Ludzie nie zawsze obiektywnie widzą swoje słabsze strony i nie zawsze rozumieją, jak są odbierani. Życzliwy feedback może mieć ogromną, rewolucyjną wręcz wartość.

Feedback to nie tylko krytyka

Feedback może być też pozytywny. A może żarty jednego z kolegów są zabawne, na temat i rozładowują atmosferę na trudnych spotkaniach? Może ktoś pisze wyjątkowo czytelny kod i warto, żeby podzielił się swoimi zasadami i wiedzą z resztą zespołu? Może ktoś wyjątkowo sprawnie prowadzi spotkania, a przy tym waha się nad zmianą profilu, i warto potwierdzić, że sprawdza się w danej roli?

Wartość feedbacku

Życzliwy i kontrolowany feedback daje szansę na rozwój.

Sama tego doświadczyłam. Kiedyś panicznie bałam się wystąpień publicznych i unikałam ich jak ognia. Za którymś razem, kiedy nie miałam wyboru i musiałam coś przygotować, obca dla mnie osoba podeszła powiedzieć, że jej zdaniem mam do tego talent, tylko powinnam czasem patrzeć na publiczność. Dodało mi to pewności siebie, a dzisiaj występowanie nie jest dla mnie najmniejszym problemem.

Nie znaczy to, oczywiście, że musimy bez cienia wątpliwości przyjmować wszystko, co nam mówią. Być może ktoś się nie zna, nie rozumie, albo wręcz nie życzy nam najlepiej. Mimo wszystko warto powstrzymać się od odruchowego uznawania,  że „krytykuje żeby zaszkodzić” czy „krytykuje z zadrości”.

Warto także nauczyć się dawać życzliwy, wyważony feedback.

Kiedy się odzywać?

Jak uczy przedstawiona powyżej historia, nie zawsze! Nie za często. Bezpieczniej w sformalizowanych sytuacjach – to kolejny powód, dla którego jestem fanką firmowych systemów oceny. Wtedy „trzeba” coś powiedzieć, więc nikt nie powinien brać takich informacji do siebie.

Feedback, jak każde przydatne narzędzie, bywa nadużywany. Mam kolegę w pracy, który, gdy tylko coś mu się nie spodoba, bierze mnie na stronę i wypowiada kwestię „mam dla ciebie feedback”.

Znoszę z podniesionym czołem. I tego samego Wam życzę 🙂

„Stałe” w Javie:
final, static, i niemodyfikowalność

Wpis z dedykacją dla D, który postanowił nauczyć się nowego języka programowania i, chcąc utworzyć stałą (constant – słowo kluczowe niedostępne w Javie),  zapytał mnie o relację pomiędzy terminami: final, static i obiekt niemodyfikowalny (immutable).

final

Słowo final zmienia znaczenie w zależności od kontekstu, ale zawsze oznacza, że coś jest „ostateczne” i po utworzeniu nie da się już tego zmienić.

Klasa final

Jeśli klasę oznaczymy słowem final, nie będzie można jej rozszerzać, czyli tworzyć jej podklas. Zatem będzie to „ostateczna” wersja danej klasy.

Metoda final

Z metodami jest podobnie jak z klasami. Jeśli słowem final oznaczymy metodę, nie będzie można jej przesłaniać w klasach pochodnych – czyli mamy do czynienia z „ostateczną” wersją danej metody.

Pole klasy final

Jeśli słowem final oznaczymy pole klasy, będzie to oznaczało, że wartość można mu nadać tylko raz – będzie ona ostateczna. Wartość tę można przypisać na dwa sposoby – albo „w miejscu”, przy definiowaniu klasy, albo w konstruktorze. Nie da się tego zrobić później. Jeśli pole final nie otrzyma wartości w żadnym z tych dwóch miejsc, kompilator zaprostesuje.

Za przykład niech posłuży fragment definicji klasy String z Javy 8:

Zmienna final

Jeśli jako final opiszemy zwykłą zmienną w środku kodu, wartość (a dokładniej: wartość w przypadku typów prostych lub referencję w przypadku obiektów) będzie można jej przypisać maksymalnie raz. Na przykład:

Parametr final

Jeśli jako final oznaczymy parametr metody,  zablokujemy możliwość zmiany jego wartości. I tak nie powinniśmy tego robić – to jedna z dobrych praktyk. Użycie słowa final oficjalnie nas do niej zobowiązuje.

static

Słowo kluczowe static nie musi być łączone ze stałymi. Chcę jednak rozebrać je na czynniki pierwsze, ponieważ często spotyka się je razem z final w następujących konstrukcjach (ta akurat znów klasy String):

Słowo „statyczny”, jako przeciwieństwo „dynamiczny” można w uproszczeniu rozumieć w ten sposób, że opisany nim byt do życia nie potrzebuje obiektów (tworzonych dynamicznie).

Pole klasy static

Jeśli pole klasy zostanie oznaczone jako static (jak w przykładzie bezpośrednio powyżej), oznacza to, że jest współdzielone przez wszystkie obiekty danej klasy. Można uzyskać do niego dostęp odwołując się do nazwy obiektu lub do nazwy klasy – efekt będzie ten sam. Pamięć jest przydzielana tylko raz, podczas ładowania klasy.

W ten sposób można definiować ważne stałe albo różnego rodzaju liczniki (np. liczba egzemplarzy danej klasy – wówczas w konstruktorze zwiększamy wartość tego pola o 1).

Metoda static

Metoda static jest współdzielona przez wszystkie obiekty, można ją także wywołać odnosząc się bezpośrednio do nazwy klasy, bez potrzeby tworzenia obiektu.

Metoda ta ma dostęp jedynie do statycznych atrybutów (pól i metod) danej klasy. Co za tym idzie, nie może też używać słów this ani super.

W ten sposób często definiuje się różne metody pomocnicze – na przykład większość metod w klasy Math.

Najbardziej znana metoda statyczna to oczywiście main.

Blok kodu static

Wewnątrz definicji klasy można umieścić statyczny blok kodu, w którym, na przykład, zainicjalizujemy jakieś statyczne pola. Zostanie on wywołany w trakcie ładowania klasy.

Mimo że bloki statyczne rzadko pojawiają się w kodzie, kolejność ich wykonywania to konik wielu profesorów informatyki na egzaminach z programowania obiektowego.

Zagnieżdżona klasa static

Jeśli klasę zagnieżdżoną opiszemy słowem static, będzie ona mogła odwoływać się jedynie do statycznych atrybutów swojej klasy zewnętrznej.

Obiekty niemodyfikowalne

Obiekt niemodyfikowalny (immutable) to taki obiekt, w którym po użyciu konstruktora nie można już dokonywać żadnych zmian.

Przekazując taki obiekt, mamy pewność, że nie zostanie on zmieniony przez żaden kod – ani nasz, ani znajdujący się pod kontrolą kogoś innego. Obiekty niemodyfikowalne są wybawieniem podczas pracy z wątkami, ponieważ nie trzeba synchronizować ich stanu.

Niemutowalne są na przykład obiekty klasy Integer.

Oto fragment definicji tej klasy:

Wartość value (czyli liczbę typu prostego int opakowywaną przez klasę Integer) można ustawić jedynie przy użyciu któregoś z konstruktorów. Nie da się jej zmienić później. Klasa Integer ma szereg metod pozwalających uzyskać dostęp do tej wartości, ale sama wartość wewnątrz obiektu tej klasy nigdy  nie zostanie zmieniona. Nie jest do tego potrzebne słowo final (które zostało tu użyte) – wystarczyłaby sama enkapsulacja. final daje nam jednak niezbitą pewność, że po inicjalizacji nikt już tej wartości nie zmieni.

Co ma zrobić osoba, która potrzebuje innej liczby Integer? Będzie musiała po prostu utworzyć nowy obiekt.

Nie istnieje słowo kluczowe immutable. Obiekty niemodyfikowalne tworzy programista, korzystając z mechanizmu enkapsulacji oraz słowafinal.

Wszystko razem, czyli static final String

Rozważmy definicję poniższych pól:

Wszystkie trzy pola są opisane jako static final, czyli są to stałe współdzielone przez wszystkie obiekty danej klasy.

W pierwszym przypadku mamy stałą typu prostego. Sprawa jest oczywista – nie wolno nam zmienić jej wartości. Nie możemy przypisać pod ERROR_CODE żadnej innej wartości.

W drugim przypadku mamy obiekt. Jest to, dodatkowo, obiekt niemodyfikowalny (immutable). Uczący się Javy kolega zapytał ostatnio, po co dodawać final, skoro obiekt jest niemodyfikowalny. Po co? – żeby nie można było zmienić referencji. Gdyby nie słowo final, możliwa byłaby następująca operacja:

Obiekt String z wartością „Ouch” jest co prawda niemodyfikowalny (nie można zmienić przechowywanej w nim wartości), ale nic nie stałoby na przeszkodzie, żeby podmienić obiekty przypisane do zmiennej RESPONSE. Użycie final nas przed tym chroni.

W ostatnim przypadku mamy zwykły (modyfikowalny) obiekt ze zmiennym stanem, przypisany do pola oznaczonego jako final. Co to oznacza? Że co prawda, dzięki final, nie możemy zmienić referencji (to będzie nadal tem sam obiekt) ale ciągle możemy nieźle namieszać w jego wnętrzu przy użyciu API:

Jasne?

Odpowiedne korzystanie z javowych „stałych”, wartości statycznych i obiektów niemodyfikowalnych pozwala na oszczędzenie miejsca w pamięci i stworzenie czytelnego, łatwego w utrzymaniu kodu.

Inauguracja serii „Mama w IT”, czyli wpis o porodach: porównanie warunków w polskim szpitalu publicznym i prywatnym

Serio, to jest wpis o porodach. Z programowaniem ma tyle wspólnego, że dzięki pracy w dobrze opłacanym zawodzie za drugim razem nie musiałam godzić się na warunki NFZ i wybrałam prywatny szpital. Do tematu rodziców w IT zamierzam jeszcze kilka razy wrócić, bardziej od strony wykonywania zawodu i pracy w biurze.

Tym razem koncentruję się na osobistym doświadczeniu i odpowiadam na kilka pytań związanych z porównaniem warunków w państwowym i prywatnym szpitalu, które regularnie ktoś mi zadaje. Mogę, to w końcu mój prywatny blog! A temat uważam za bardzo ważny.

W pierwszej wersji wpis był ścianą tekstu o długości czterech stron A4. Ostatecznie postanowiłam sprowadzić go do postaci rozbudowanej tabeli. Może na co dzień jestem dość wylewna, ale zależało mi, żeby nie przekroczyć granicy ekshibicjonizmu.

Ponieważ nie chcę stracić jednej trzeciej czytelników, postanowiłam wprowadzić specjalny znacznik: <uwaga: anatomia!>…</>. Tekst poza tym oznaczeniem nie powinien wyzwolić u nikogo przerażenia ani mdłości.

Podsumowanie całej przygody jest następujące: mimo że mieszkam w dużym ośrodku miejskim, gdzie i tak mam dostęp do bardziej nowoczesnego szpitala spełniającego większość z wyznaczonych standardów opieki okołoporowej, pieniądze wydane na prywatny szpital to najlepiej wydane pieniądze na świecie. Mniej z powodu „luksusowych” warunków (jak jednoosobowy pokój), bardziej z powodu podejścia personelu do pacjenta, które charakteryzowało się empatią i partnerskim traktowaniem – wartościami niemalże niedostępnymi w państwowej opiece zdrowotnej. A przecież finalnie płacimy tak samo, tylko droga pomiędzy klientem (pacjentem) a wykonawcą usług (personel szpitala) jest dłuższa i nieporównywalnie bardziej kręta.

  Publiczny Prywatny
koszt Ok. 700 zł. za własną położną wybraną spośród pracownic szpitala (od tego czasu szpital zakazał tego procederu). Ok. 9000 zł za poród z wybranym lekarzem (ceny w polskich szpitalach prywatnych wahają się pomiędzy ok. 3000-15000 zł).

Musiałam doliczyć do tego ceny noclegu w Warszawie na krótko przed wyznaczonym terminem.

liczba dni w szpitalu 5 (standard to 2) 2
liczba osób (matek) w sali 3 1
warunki w sali porodowej Poród rodzinny.

Prysznic, trochę sprzętów pomocniczych jak wielkie nadmuchiwane piłki.

Poród rodzinny.

Prysznic, wanna. Trochę sprzętów pomocniczych.

warunki w pokoju na oddziale Własna łazienka, stanowisko do kąpieli i przewijania dzieci, łóżka i szafki dla mam. Własna łazienka, stanowisko do kąpieli i przewijania dzieci, stanowisko do ogrzewania, łóżko i szafka, fotel, stół, rozkładana kanapa, telewizor, Internet (kiepski), telefon z numerami na wszystkie potrzebne mi oddziały (np. neonatologia).
możliwość odwiedzin Zakaz wstępu na oddział.

Mama może wyjść do „przedpokoju” (i bardzo dobrze – odwiedziny rodziny w wieloosobowym pokoju na oddziale porodowym to bardzo zły i naruszający intymność pomysł).

Jak najbardziej, przez cały dzień.

W niektórych typach pokoju jest nawet możliwe przenocowanie jednej osoby (razem z wyżywieniem).

Zakaz wstępu dzieciom (zarazki).

podejście do pacjentki Istniejąca tylko w służbie zdrowia paskudna forma „mama, podaj”.

Mieszanka pobłażania i zniecierpliwienia.

Większość położnych była zasadniczo miła i życzliwa, ale trafiło się parę jędz. Odpyskować czy wykazać się asertywnością nie jest łatwo, gdy nie wiadomo, czy za chwilę baba nie uszczypnie mojego dziecka w drodze na szczepienie albo poda mi tylko połowę z przepisanych środków przeciwbólowych.

Normalne podejście do dorosłego, samostanowiącego człowieka – „proszę podać”, ewentualnie „pani Justyno”. Jedna osoba, która mówiła mi na „ty” („Justynko”), zaproponowała tę samą formę zwracania się do siebie.
przepływ informacji Żaden.

Można było nękać zniecierpliwione położne lub czekać na jedyny w trakcie dnia obchód. O tym, że danego dnia jednak nie wychodzę do domu, dowiadywałam się codziennie, kiedy byłam już spakowana, a mąż wyruszał po nas z pracy.

Dobry:

  • ulotka z podstawowymi informacjami (np. godziny posiłków)
  • pod ręką telefon z numerami na najważniejsze oddziały
  • pełna informacja przy każdym wykonywanym zabiegu
  • uprzejme, choć również trochę zabiegane położne na oddziale
wyżywienie Jak na stronie „posiłki w szpitalach: grube parówki i dwa plastry sera na trzy kromki chleba. Przynajmniej bez pleśni. Urozmaicone jedzenie ze szpitalnej kafeterii, możliwość wyboru obiadu spośród kilku opcji.
konsultacje z personelem i przepływ informacji
  • Obchód raz dziennie (ginekolog, pediatra).
  • Położne na oddziale.
  • Obchód dwa razy dziennie (ginekolog, neonatolog).
  • Konsultacja neonatologiczna przed każdym zabiegiem u dziecka.
  • Ginekolog i neonatolog stale pod telefonem.
  • Fizjoterapeuta.
uśmierzanie bólu porodowego
  • Dolargan
  • Znieczulenie zewnątrzoponowe (które zupełnie nie zadziałało na połowę mojego ciała, ale anastezjolog nie miał czasu na poprawienie wkłucia); w obecnej chwili, o ile mi wiadomo, żaden szpital w Poznaniu nie zagwarantuje dostępności tej metody
  • Znieczulenie zewnątrzoponowe podane starannie, spokojnie i regularnie sprawdzane, z opcją samodzielnej (pod kontrolą lekarza) zmiany mocy
  • Opcjonalnie także gaz rozweselający
<uwaga: anatomia!> nacięcie </> Tak. Z pospiesznym, spapranym szyciem, które stało się przyczyną największych cierpień po. Okazało się, że lekarz właśnie kończył zmianę i spieszył się do domu. Nie. Kilka szwów.
ustąpienie poważniejszych dolegliwości bólowych Dwa tygodnie po Od razu
opieka nad noworodkiem Oprócz paru godzin po porodzie, cały czas z mamą, niezależnie od jej samopoczucia. Z mamą, ale z możliwością wysłania na parę godzin na oddział noworodkowy w dowolnym momencie.
doradztwo laktacyjne Brak.

Brak chociażby jednego laktatora na oddziale położniczym!

Umiarkowana pomoc.

Bez problemu można wypożyczyć laktator (czasami potrzebny podczas pierwszych dni).

ogólna ocena doświadczenia Ekstremalnie nieprzyjemne, chociaż nie traumatyczne. Całkiem komfortowe.

Porównywane szpitale: Szpital św. Rodziny w Poznaniu, Szpital Medicover w Warszawie. Wpis nie jest reklamą i przedstawia tylko moje osobiste, subiektywne doświadczenia. 

Recenzja książki „Zawód: Programista” Macieja Aniserowicza

W tym wpisie będę zachęcać Was do przeczytania dzieła blogera, który ma zasięg o dwa rzędy wielkości większy od mojego. W pierwszej chwili pomyślałam, że nie ma to sensu, bo kto miał wiedzieć o jego książce ten wie z samego źródła.  Po namyśle uznałam jednak, że wśród mojej publiczności chyba więcej jest osób, które nie są programistami i tylko nieśmiało zaczynają interesować się tym tematem – a ta wyjątkowa pozycja jest przeznaczona także dla nich.

No to piszę.

Na moim blogu znajdziesz sporo tekstów opisujących zawód programisty i starających się odpowiedzieć na pytanie, kto może go wykonywać i czy warto (linki poniżej) – ale Maciej podszedł do tematu w sposób o wiele bardziej metodyczny.

Moje teksty na podobne tematy:

Maciej, czyli kto?

Maciej Aniserowicz jest autorem popularnego bloga https://devstyle.pl/, na którym pisze o technologiach związanych z .NET, ale także zamieszcza sporo ciekawych, ogólniejszych felietonów. Oprócz tego jest konsultantem, nagrywa podcast, występuje na konferencjach, prowadzi szkolenia. Jest organizatorem konkursu https://devstyle.pl/daj-sie-poznac/, który dał mi sporo inspiracji i motywacji podczas mojego pierwszego urlopu macierzyńskiego (dał mi także, w ramach nagrody za 3 miejsce, moją własną licencję na IntelliJ).

Ostatnio wydał książkę „Zawód: Programista” (https://zawodprogramista.pl/), której recenzję zamieszczam poniżej w postaci subiektywnej listy plusów i minusów tego dzieła.

Plus: świetnie ustrukturyzowana – spis treści daje dobre pojęcie, o czym jest ta książka

Mogę powiedzieć krótko, o czym jest ta książka: o tym, jak wygląda praca programisty, jakich potrzeba predyspozycji, jakie są możliwe poddziedziny, czy da się przekwalifikować, na jakie można liczyć zarobki… Ale zamiast wierzyć mi na słowo, możesz po prostu zerknąć na dostępny w Internecie spis treści i od razu będziesz wiedzieć, o czym i dla kogo jest ta książka.

Treść jest świetnie przemyślana i ustrukturyzowana. Jak maile pisane przez programistów 😊

W każdym razie, nie kupujesz kota w worku.

Plus: naprawdę jest takie zapotrzebowanie na rynku

Być może przytaczałam już tę historię w którymś z moich wcześniejszych wpisów. Mam dobrego znajomego, który na żale znajomych „humanistów” na temat wysokości zarobków i traktowania pracowników w zawodach związanych ze sztuką, kulturą lub urzędami reagował irytacją i za każdym razem ucinał dyskusję twierdząc, że powinni przekwalifikować się na inny, potrzebny zawód (czyli, w skrócie, nasz zawód). Wydawał się bardzo pewny swego, aż któregoś dnia jeden z wspomnianych humanistów stanął wycieńczony na jego progu i poprosił o wskazówki, jak dokładnie się przekwalifikować. Nagle, gdy wygadany znajomy miał stać się odpowiedzialny za poprowadzenie osoby, która chce przeprowadzić taką zmianę w swoim życiu – nie był już tak pewny swego. Ostrożnie wykręcił się od udzielenia konkretnych porad.

Maciej, oczywiście, nie bierze odpowiedzialności za czyjąś reorganizację życia zawodowego, ale opisuje kroki i warunki pozwalające się na coś takiego odważyć. Wiem, że istnieje duża grupa osób, które na taki właśnie poradnik czekają.

Sama podjęłam kiedyś próbę nauczenia grupy lingwistów podstaw programowania (począwszy od pisania gramatyk formalnych dla znanych im języków naturalnych). Okazało się, że około jedna trzecia zespołu lingwistów i filologów doskonale sprawdziła się w tej roli. Część z nich pracuje dzisiaj jako programiści lub testerzy.

Plus: to jest po polsku.

W czasach self-publishingu niestety nie można tego brać za pewnik, ale ta książka rzeczywiście jest napisana po polsku. Przecinki są we właściwych miejscach (mam wątpliwości co do jednego, ale to podobno cytat), słowa są użyte zgodnie z ich znaczeniem (choć nie rozumiem kawałka o paraboli), imiesłowy działają jak trzeba. Dla mnie to istotne.

Plus: trzeźwe spojrzenie na finanse

W porównaniu do większości moich przyjaciół pracujących na etat, w IT zarabiam naprawdę dużo. W porównaniu do osób, które prowadzą własne, dobrze prosperujące firmy – niekoniecznie. To kompromis, na który w tej chwili chętnie się godzę. Nie siedzę po godzinach, a w nocy śpię. Jestem odpowiedzialna za wyznaczony dla mnie wycinek, a nie za cały dobrostan firmy. Mi pasuje.

Istnieje wiele mitów na temat nieprzyzwoicie wysokich zarobków w IT. Najwięcej szumu wywołał chyba ten artykuł: IT-arystokracja. Najbardziej zepsuta pensjami i przywilejami grupa zawodowa. W książce Maciej rzeczowo rozprawia się z zawartymi w nim (i podobnych publikacjach) tezami. Tłumaczy, jakiego wynagrodzenia można oczekiwać w jakich okolicznościach, przekonuje również, że kasa to nie wszystko. Podaje wskazówki, jak najlepiej zarządzać programistycznymi finansami – a zwłaszcza ich nadwyżką!

Mój ulubiony cytat: „Arystokracja IT”? Co to za arystokracja, która nie przeżyje miesiąca bez wypłaty?

Plus: miło obcować ze spełnionym człowiekiem

Książkę świetnie się czyta również dlatego, że napisał ją człowiek spełniony. Widać, że autor robi to, co lubi i jest w miejscu, w którym chciał być. Uwielbiam obcować z takimi ludźmi, nawet tylko przez kartki książki 😊

Domyślam się, że znajdą się osoby, które niektóre fragmenty zaklasyfikują jako przechwałki. Nawet jeśli nie wszystkie historie z życia i wyliczanki są niezbędne – mnie takie podejście napawa optymizmem.

Plus: … na dodatek człowiekiem, który nie żyje tylko pracą

Jeden z najbardziej przerażających mnie aspektów naszej pracy to programiści-maniacy, w których życiu nie ma nic poza IT, którzy czytają tylko branżową prasę i specyfikacje frameworków. O dziwo, niektórzy z nich mają nawet żony (mężów?) i dzieci. Zdaję sobie sprawę z tego, że ja sama, z moimi dziesiątkami hobby i bandą ludzi, których uważam za niezbędnych w moim życiu, nigdy nie dorównam tym ludziom techniczną biegłością. Tym bardziej raduje się moje serce, kiedy Maciej pisze o znajdowaniu czasu dla rodziny, o nieprzekraczalnym warunku braku nadgodzin. Ogólnie o równowadze w życiu.

Plus: sporo rad uniwersalnych, np. związanych z produktywnością

Temat zachowania równowagi pomiędzy życiem prywatnym a zawodowym jest ważnym motywem tej książki. Jednocześnie od początku jest oczywiste, że jeśli chcemy coś osiągnąć, musimy wykonać dodatkową pracę i znaleźć na tę pracę czas. Poczytać coś po powrocie do domu, napisać trochę kodu albo tekstu na blogu, przygotować wystąpienie. Kiedy to wszystko robić? Jak to robić dobrze? Publikacja zawiera podrozdział „Jak zmotywować się do pracy po pracy?”, ale także poza nim przemycone jest trochę wskazówek na temat efektywnego zarządzania czasem (np. o metodzie pomodoro). To bardzo ważne.

Swoją drogą, mogę dorzucić kilka swoich wskazówek. Moje koleżanki często wyrażają podziw wobec tego, ile rzeczy mi udaje się zrobić po pracy. Oto jedna z moich najważniejszych zasad: bez żenady płacę innym za wykonywanie powtarzalnych czynności, które niczego mnie nie uczą. Raz w tygodniu przychodzi do mnie pani sprzątająca i wymiata miejsca, do których ja nigdy nie docieram (ani mąż, ani dziecko, które za to uwielbia ładować zmywarkę). Nie gotuję codziennie. Niektóre, w tym wykształcone i pracujące zawodowo, kobiety z jakiegoś powodu czują się zobligowane do regularnego wykonywania tych czynności, niekoniecznie ze względów finansowych. Później trudno im znaleźć czas na cokolwiek innego. A dzieci rysują w przedszkolu mamę z odkurzaczem.

Plus: odnośniki pozwalające dokładniej zgłębić temat

Książka ma bardzo strawną objętość – czytałam ją tylko przy karmieniu noworodka, skończyłam w trzy dni. Bardzo podoba mi się, że w wielu miejscach wskazuje źródła i autorów, z których publikacjami warto się zapoznać. Zawiera także linki do stron Macieja, gdzie znajdziemy listy blogów, inspiracji i inne obszerne zasoby, które niepotrzebnie nie zajmują miejscach na kartkach i które Autor może na bieżąco aktualizować. Zamierzam za kilkoma z takich linków podążyć.

Plus (i trochę minus): osobiste spojrzenie

Maciej pisze o swoim osobistym (przebogatym) doświadczeniu, starając się wyciągnąć z niego wnioski dla wszystkich. Przez większość czasu to się udaje. Na dodatek jest to dobre dla narracji – całą historię czyta się jak dobrą powieść 😊. Mimo wszystko, oczywiście, nie każdemu uda się powtórzyć tę sztukę. Ludzie mają różne zdolności i różne granice. Sukces to ciężka praca, ale także odrobina szczęścia. To, że Maciejowi coś się udało, nie musi znaczyć, że uda się nam po odtworzeniu jego kroków. Z drugiej strony, coś, co jego zatrzymało, dla kogoś innego może okazać się jedynie drobnym potknięciem.

Minus: za mało dystansu do coachingu

Może jestem cyniczna i zblazowana, ale w dzisiejszych czasach – coachów sprzedających masom truizmy i cudze cytaty jako własne przemyślenia – jestem bardzo sceptycznie nastawiona do sformalizowanych form samorozwoju. Kiedy Maciej zupełnie bez ironii pisze o „wychodzeniu ze strefy komfortu”, włączają mi się wszystkie dzwonki alarmowe. Choć to oczywiste, że to akurat niezbędny krok, żeby do czegokolwiek dojść.

Minus: trochę sucharów, trochę powtórzeń

Książkę pisał informatyk. Nie wiem, czy trzeba dodawać więcej 😉 Parę tez i anegdotek powtarza się w kilku miejscach (choć w większości przypadków Autor sam to zauważa). Parę zdań mnie zażenowało. Najbardziej chyba to: „Wyobraź sobie, że młoda mama na macierzyńskim może zobaczyć światełko w tunelu, błyskające znad garów i mopa.” Wyobraź sobie, Macieju, że dla żadnej z moich rozlicznych koleżanek w rozlicznych zawodach urlop macierzyński nie sprowadził się do „garów i mopa”.

Minus: za mało o dyskryminacji w naszym zawodzie

Problem dyskryminacji w naszym zawodzie jest prawdziwy. Dostaje się kobietom, mniejszościom narodowym, osobom starszym. Sama miała szczęście pracować w firmach, które zapewniały przyzwoity poziom kultury w pracy – a i tak przynajmniej raz zdarzyło mi się płakać w toalecie po kolejnym komentarzu na temat umiejętności kobiet (chociaż pan „nie mówił o mnie”). Natomiast słyszę co nieco od koleżanek z innych firm. Mam nadzieję, że kiedyś dostanę pozwolenie, żeby ze szczegółami opisać tu historię człowieka, który naskarżył na koleżankę do działu HR za „psucie atmosfery w pracy”, kiedy protestowała przeciwko kolejnym rasistowskim żartom na open space.

Sama zaczynam zwracać uwagę na to, że zaczynam zawyżać średnią wieku w firmie. Irytują mnie zaproszenia do „młodych, dynamicznych zespołów” – nie tylko dlatego, że są nic nie znaczącą kalką. A przecież Maciej jest chyba mniej więcej w moim wieku?

Polecam ten ciekawy artykuł na temat ageismu i pracy w Google po pięćdziesiątce (nie, nie, my aż tak nie zawyżamy 😀 ): Surviving as an Old in the Tech World.

Podsumowanie

Zdecydowanie polecam książkę zarówno aktywnym programistom, jak i osobom rozważającym wybór tej ścieżki kariery, na różnych etapach życia. To bardzo trzeźwe i uczciwe spojrzenie na nasz zawód. Nawet jeśli nie wszystkie porady są uniwersalne i nawet jeśli kilka istotnych kwestii pominięto, jest tam sporo przydatnych informacji i wskazówek, a także materiału do refleksji nad przebiegiem własnej kariery.

Bonus personalny: moja walka o papierowy egzemplarz

Książkę można było zamówić z wyprzedzeniem, ale ja czekałam na moment, kiedy naprawdę będzie gotowa. Jak tylko zorientowałam się, że to już, weszłam na stronę https://zawodprogramista.pl/ w celu jej zamówienia. Ręka zadrżała mi nad formularzem adresowym. Chciałam i wersję elektroniczną, i papierową, ale data uniemożliwiła mi zamówienie książki do domu. Otóż akurat wybierałam się do innego miasta, żeby skorzystać z usług prywatnego szpitala położniczego (ciągle się zastanawiam, czy ten blog jest dobrym miejscem na szczere porównanie warunków i przestrzegania standardów w placówkach NFZ i prywatnych; naprawdę jest o czym pisać). Zarezerwowałam tam mieszkanie na okres dwóch tygodni (żeby być w odległości 15 minut, a nie 3 godzin od szpitala), ale nie wiedziałam dokładnie ile dni zostanę i nie znałam z góry dokładnego adresu z numerem mieszkania. W końcu zamówiłam książkę pierwszego dnia pobytu tam, a drugiego byłam już w szpitalu! Na szczęście właścicielka mieszkania okazała się na tyle miła, żeby odebrać przesyłkę i wysłać mi ją do Poznania. Jeszcze nie doszła, dlatego nie widać jej na półce.

Liliana ma dzisiaj 13 dni i jest uwielbiana przez wszystkich domowników na czele ze swoją starszą siostrą.

Literatura informatyczna: wspominki o tłumaczeniach i korektach

Dawno, dawno temu zajmowałam się tłumaczeniem książek (informatycznych). Początkowo dorabiałam w ten sposób do stypendium doktoranckiego, ale nie bez znaczenia była dla mnie przyjemność płynąca z pracy z językiem oraz możliwość poznania nowych technologii. Żeby coś dobrze przetłumaczyć, należy to najpierw dogłębnie zrozumieć. Drogi na skróty nie ma.

Stan circa 2010, przed nocą oczyszczenia na moich półkach z książkami IT

Dlaczego akurat teraz piszę o tym na blogu?

Po pierwsze, z racji zalania mózgu prolaktyną (jeszcze chwilka!) nie jestem w stanie generować nowych, ciekawych tematów i chciałam odgrzać tekst ze starego bloga. Ostatecznie napisałam artykuł zupełnie od nowa.

Po drugie, odezwał się do mnie mój ulubiony redaktor z propozycją przetłumaczenia nowego wydania książki, nad którą pracowałam dobrych parę lat temu. Nie zgodziłam się (patrz punkt 1), ale zaproponowałam wykonanie korekty merytorycznej tekstu przełożonego przez nowego tłumacza. To było dla mnie zupełnie nowe doświadczenie i chcę podzielić się przemyśleniami.

Po trzecie, znajoma rozważająca wejście w obszar tłumaczeń IT zadała mi kilka pytań o tę pracę, w związku z czym musiałam przypomnieć sobie, jak to było.

Po czwarte, wreszcie, to kolejna ścieżka rozwoju w szeroko rozumianym świecie IT, a przecież o tym jest ten blog.

Jak się dostaje taką pracę?

Wydawnictwa techniczne, inaczej niż czysto  literackie, miewają na stronach zaproszenie do współpracy dla tłumaczy. Szukają raczej znających język praktyków niż osób z papierami tłumacza czy filologa.

Rekrutacja polega najczęściej na przetłumaczeniu próbki (za darmo), a następnie już rozdziału książki (za pieniądze). Jeśli po tym doświadczeniu obie strony będą zadowolone, przyszły tłumacz otrzyma propozycję przekładu, kiedy pojawi się coś ze zgłoszonej przez niego dziedziny.

Cały proces może trochę potrwać, nawet kilka miesięcy.

Co jest łatwe, a co jest trudne w przekładach IT?

Kilka uwag poniżej.

1. Amerykańscy autorzy zawsze zwracają się czytelnika bezpośrednio

W pierwszych tłumaczonych przez siebie książkach stosowałam wymyślną ekwilibrystykę form bezosobowych i tradycyjnych zwrotów do „Czytelnika”, ale po jakimś czasie uznałam, że w literaturze IT i poradnikach przyjęła się już przecież forma bezpośrednia. Problem krążenia wokół bezpośrednich zwrotów wydawał się rozwiązany.

Niestety, w tej sytuacji ujawnił się nowy problem w postaci form czasowników w czasie przeszłym oraz w trybie przypuszczającym. W języku polskim ujawniają one rodzaj gramatyczny podmiotu. Kłopotliwe stały się wszystkie sformułowania typu “if you removed line 3″ („gdybyś usunął/usunęła linię 3”). Jeśli posiłkuję się słowem “czytelnik”, słowo to wymusza rodzaj i wszystko jest w porządku. Zwracając się do odbiorcy bezpośrednio, mam problem. Jasne, można kombinować, ale gdy autor w co drugim zdaniu używa takich zwrotów, po chwili staje się to męczące dla obu stron (dla tłumacza i czytelnika, autora zostawmy w tym wypadku w spokoju).

W niektórych angielskojęzycznych książkach programista jest kobietą – autorzy stosują zaimek “she” (istnieje jeszcze bezpieczna forma „they”, jeśli z premedytacją odmawiamy podania płci). Po polsku to by nie przeszło. W naszym języku żeńskie formy są bardzo silnie nacechowane. Gdybym zaczęła zwracać się do czytającego książkę programisty lub studenta “jeśli miałaś kiedyś do czynienia z usługami sieciowymi”, to wprawiłabym w konsternację przedstawicieli obu płci. Techniczna książka ma się czytać płynnie i bezproblemowo.

Finalnie bez poczucia większej żenady stosuję rodzaj męski, zakładając, że piszę do domyślnego „czytelnika”.

2. Choćby nie wiem jak dziękowali korektorom, książki i tak często są napisane niechlujnie

Klasyczny przykład to zdanie „Możesz wybierać pomiędzy poniższymi trzema dostawcami”, po którym następuja lista złożona z czterech pozycji. Tego typu błędy dość łatwo wychwycić, choć człowiek zachodzi w głowę, czym dokładnie zajmował się wymieniony z nazwiska korektor.

Niestety, problemów często jest więcej:

  • zaimki („to”) pasujące do trzech różnych wspomnianych wcześniej bytów lub nie pasujące do żadnego,
  • niedziałający kod,
  • twierdzenia, które na pewno nie są prawdziwe,
  • fragmenty kodu niemające nic wspólnego z akapitem, który ma je opisywać,
  • w połowie urwane zdania.

Jako tłumacz zawsze starałam się zrozumieć intencje autora i poprawiałam tego typu rzeczy, jednak ostatnio (o czym niżej) przekonałam się, że wcale nie jest to uniwersalne podejście.

3. Tłumaczenie książek napisanych po angielsku przez autorów, dla których angielski nie jest językiem ojczystym, to temat na co najmniej rozprawę doktorską

Programowanie jest dziedziną egalitarną. Nie trzeba być rdzennym Brytyjczykiem po Oxfordzie, żeby mieć wartościowy materiał na książkę informatyczną. Książki o popularnych frameworkach piszą więc Polacy i Bułgarzy, zarówno ci pracujący w swoich ojczystych krajach jak i ci na emigracji. Jednym i drugim wydaje się, że skoro w pracy skutecznie posługują się angielskim, ich znajomość języka wystarczy do napisania książki. No cóż, nie zawsze jest to prawda.

Najgorzej jest, oczywiście, w przypadku książek wydanych własnym sumptem, których autor oszczędzał na korekcie, ale na szczęście takie dzieła rzadko kiedy się tłumaczy. W każdym razie trudno podążyć logicznie za wywodem autora, który nie widzi różnicy pomiędzy rodzajnikiem określonym a nieokreślonym, bo w jego języku nie występują ani jedne, ani drugie.

4. Rdzenni Amerykanie potrafią przyłożyć popkulturą.

Największy koszmar i blokada tłumaczeniowa spotkały mnie przy mojej pierwszej książce, ponad dziesięć lat temu. Autor określił wówczas jakąś aplikację terminem „Borg-like”. Dzisiaj Internet podpowiada nieco więcej. Wtedy tego sformułowania po prostu nie można było znaleźć w Google.

Czego się dowiedziałam po dwóch dniach kminienia? Że Borg to rasa ze Star Treka (jestem geekiem, ale w Star Trek nigdy się nie wciągnęłam, za dużo materiału do nadrobienia), która przemocą asymiluje czy wręcz „wchłania” inne rasy. O to samo można oskarżyć niektóre aplikacje.

Jest nawet taki żarcik o SP2 do Windows XP:

„Windows XP SP2 is often called Windows XP Borg Edition, as it tries to assimilate all other software (or destroys it) as is the custom with the Borg. Also common with the borg, once you install ‚Borg’ edition, resistance is futile”

5. Listingi potrafią ciągnąć się przez cztery strony…

Tłumaczowi, jak wiadomo, płaci się od „strony tłumaczeniowej”, czyli de facto od liczby znaków w wynikowym tekście. Przy listingach jest wyjątkowo mało roboty, tym bardziej, że obecnie większość wydawnictw nie próbuje polonizować np. nazw zmiennych. Szybki zarobek.

6. … ale czasem trzeba z nich wygenerować spolonizowany zrzut ekranu.

Co robi się kłopotliwe, jeśli listing zawiera błędy i kod zwyczajnie nie chce działać. Wtedy nagle jedna strona może kosztować kilka godzin.

7. Informatyczna nowomowa.

Jakiś czas temu znajomy szykował się do napisania reklamacji do wydawnictwa odpowiedzialnego za polską wersję Millenium Larssona. Otóż na tylnej okładce podobno wydanej po polsku książki pojawiają się słowa “outsiderka” i “researcherka”.  Część rozmówców stanęła w obronie tłumacza, pisząc, że “zasysanie” słów z obcych języków jest procesem naturalnym. Moim zdaniem, tendencja do zasysania obcych słów jest usprawiedliwiona, o ile słowo o danym znaczeniu nie istnieje już w języku polskim. W przeciwnym razie to zwykłe pójście na łatwiznę, niedopuszczalne zwłaszcza w wykonaniu tłumacza, czyli osoby profesjonalnie zajmującej się językiem.

W informatyce angielskie słownictwo jest wszechobecne i obezwładniające. Zgadzam się, że wymyślanie na siłę narodowych odpowiedników jest kompletnie bez sensu. Zdarza mi się, choć nie jestem z tego dumna, używać (W MOWIE) słów takich jak “zakomitować”, “dump” albo “timeout”. Poddałam się też w końcu na słowie “framework”, z którym kiedyś próbowałam się szarpać. A jednak wiele wprowadzanych w ten sposób słów ma poprawne i zrozumiałe wersje polskie. Con za tym idzie: ie toleruję pluginów (wolę wtyczki), use case’ów (przypadki użycia), forków (rozwidlenia)… Załamuje mnie “diagram kolaboracji” (współpracy, u licha! okupacja za nami). Dla tych, którzy w tej chwili przyrzekają, że nigdy nie tkną moich tłumaczeń: zawsze podaję wersję oryginalną, która ma ułatwić odnalezienie się osobie, która wcześniej czytała oryginalną dokumentację.

8. Miło jest trzymać w ręku przetłumaczoną przez siebie książkę…

Tłumacz dostaje do ręki egzemplarz autorski! O ile książka jest wydawana na papierze, o co coraz trudniej.

9. … mniej miło, po jej otwarciu na losowej stronie, trafić na przeoczoną wcześniej literówkę.

Co rzeczywiście zdarzyło mi się w przypadku pierwszej książki, mimo że przeszła przez wszystkie tury korekty (techniczna, merytoryczna, językowa).

Tłumaczenia a sprawa kobieca

Wspomnę poniżej o dwóch aspektach.

1. Żeńskie końcówki

Wracając do wspomnianej powyżej „researcherki”, mam dość silną opinię na temat żeńskich końcówek w nazwach zawodów. Z całego serca ich nienawidzę! Nie rozumiem, dlaczego spory odłam feministek tak bardzo walczy o ich stosowanie. 

Dla mnie lekarz to lekarz, nie ma znaczenia jego płeć, tylko kompetencje i, na bliskim drugim miejscu, styl bycia i szacunek do pacjenta. Czym się różni “pisarka” od “pisarza” – pisarz tworzy literaturę, a pisarka powieści dla pensjonarek? Jakie znaczenie ma tutaj płeć?! Sprawę w moim odczuciu dodatkowo pogarsza to, że żeńskie końcówki często brzmią jak zdrobnienia, mniej poważne wersje pracy, którą wykonują mężczyźni. Nie chcę, nie potrzebuję.

2. Doskonałe żarciki

A skoro o żarcikach mowa, oto przykład, na który natknęłam się kiedyś w przekładanej przez siebie pozycji z branży:

Jak wiadomo, i jak wynika z powyższego, mężczyźni zajmują się czytaniem, kobiety zajmują się plotkami. Wszyscy o tym wiedzą.  I tu muszę oddać hołd mojemu redaktorowi. Zapytany, czy mogę sprowadzić te dwie osoby do jednej płci (wydawnictwo woli spolszczać imiona w przykładach, więc fragment i tak był do zmiany) odparł, że jeśli mi zależy, to mogę nawet je odwrócić 🙂 

Sumienność, czyli dlaczego już nie polecam tłumaczy

Dwa razy poleciłam swojemu redaktorowi kolegów-informatyków, o których wiedziałam, że znają się na rzeczy i bardzo dobrze posługują się angielskim. Dwa razy prawie się spaliłam ze wstydu, kiedy okazywało się, że panowie poprzekraczali wyznaczone terminy w taki sposób, że zgodnie z umową obcięto im część wynagrodzenia za przekład.

Nie wzięłam pod uwagę tego, że jedną z najistotniejszych cech tłumacza jest sumienność, pojęcie niezbyt dobrze znane wśród programistów. Programowanie to w dużej mierze szukanie dróg na skróty, sprytnych sposobów, żeby zrobić coś szybciej, łatwiej, mniejszym nakładem sił. Usunięcie 200 linii kodu i zastąpienie ich jedną, która robi to samo (chociaż czasami załącza 3 gigantyczne biblioteki) jest powodem do dumy. Tymczasem przy tłumaczeniach po prostu się tak nie da! Trzeba przetłumaczyć wszystko, każde zdanie (no, prawie), nawet jeśli autor przez trzy strony po prostu leje wodę, żeby nadmuchać objętość książki.

Inteligencja i rzutki umysł nie pozwolą nam usiąść do tłumaczenia po dwóch miesiącach prokrastynacji i załatwić sprawy w ciągu tygodnia. Z programowaniem czasami tak się udaje.

Czego dowiaduje się korektor

Jak już wspominałam, miałam ostatnio okazję sprawdzić się w roli korektora merytorycznego książki informatycznej. Było to dla mnie przeżycie wstrząsające, ponieważ zrozumiałam, jak różne podejście do przekładu mogą mieć różni tłumacze i jak odmiennie rozumieją swoją odpowiedzialność za tekst.

Opisywałam już powyżej swoje przygody z poszukiwaniem znaczenia terminu „Borg-like”. Utknąć nad stroną książki zdarzało mi się częściej: kiedy autor załączył niedziałający kod, a ja musiałam wygenerować screenshot, więc debugowałam i pisałam kawałki od nowa; kiedy napisał „to” i w ogóle nie było wiadomo, o co mu chodzi, więc musiałam wertować dokumentację na stronie twórcy biblioteki; kiedy podane przez niego przykłady w ogóle nie przystawały do opisywanego zagadnienia i pisałam je od nowa lub sprawdzałam, skąd je ściągnął i co dokładnie mu się pomyliło. Czułam się odpowiedzialna za jakoś tekstu, który ostatecznie podpiszę także moim nazwiskiem.

Ostatnio zasiadłam do korekty merytorycznej i zrozumiałam swoją wielką naiwność…

Co może zrobić tłumacz, kiedy oryginalne zdanie nie ma sensu? Przetłumaczyć je na polski w wersji, która również nie znaczyła zupełnie nic.

Co robi, kiedy nie działa listing i nie dało się łatwo wygenerować screenshotu? Dodaje komentarz „kod nie działa” i na tym kończy swoją pracę.

Połowa czasu spędzonego przeze mnie na „korekcie” była w rzeczywistości wprowadzaniem poprawek w dziurawym kodzie, żeby polska wersja książki, w przeciwieństwie do oryginalnej, pokazywała działające przykłady. Żebym wiedziała, że tak można, w czasach tłumaczeniowych zarobiłam tę samą kasę w o połowę krótszym czasie.

Okazało się też, że tłumacze techniczni potrafią mieć ego porównywalne do programistów na backendzie. Pokłóciłam się z tłumaczem o przekład słowa „immutable”, które zamienił na „niemutowalny” (patrz sekcja o nowomowie powyżej). Takiego słowa w języku polskim nie ma, natomiast moim zdaniem spokojnie działają tu „niemodyfikowalny” lub „niezmienny”. W większości tego typu dyskusji zaznaczałam swoje zalecenia i odpuszczałam, ale tutaj nie chciałam się pod czymś takim podpisać. Wtedy tłumacz poinformował mnie, że „tak się mówi w branży”… Co rozłożyło mnie na łopatki, bo parę stron dalej nie potrafił wygenerować screenshotu z kodu, w którym jedynym problemem był brak wywołania funkcji na koniec.

Chyba napiszę w końcu osobny tekst o ego programistów.

Czy tłumaczenia informatyczne są w ogóle potrzebne?

Z jednej strony, wydaje się, że coraz mniej. Po pierwsze, naprawdę nie sposób dziś być dobrym, oblatanym programistą bez znajomości angielskiego, a to oznacza, że coraz więcej informatyków jest w stanie czytać książki w oryginale (chociaż przeszkodą bywa cena!). Po drugie, wiadomo, rozwój sztucznej inteligencji i tłumaczenia maszynowego sprawia, że niektóre teksty można wrzucić do translatora i mniej więcej zrozumieć, o co chodziło autorowi.

Z drugiej strony, dzisiaj coraz więcej osób interesuje się informatyką i programowaniem. Te tematy stają się coraz bardziej powszechne i coraz silniej wchodzą w nasze życie. O chmurze, bitcoinach i Pythonie czytają nie tylko programiści, ale także starsze dzieci, księgowe i seniorzy. Dla nich obcy język, nawet angielski, jeszcze długo może być zaporą.

Co do automatycznie tłumaczonych tekstów… Translatory są dobre, jeśli chcemy zrozumieć komunikat systemowy lub odpowiedź na forum. Książki pełne są niuansów i wstecznych odwołań… A także błędów, które tłumacz i korektor mogą skorygować, w przeciwieństwie do automatycznego translatora 🙂 Wydaje mi się, że jeszcze przez sporo lat translatory (i pamięci tłumaczeniowe CAT) będą raczej pomocą dla tłumaczy niż konkurencją dla nich.

Choć mimo wszystko odradzałabym swojemu dziecku wybór kariery tłumacza w dzisiejszych czasach.

Quiz

W ramach pół-inteligentnej rozrywki, polecam sprawdzenie, jak w różnych krajach potocznie nazywa się znak @ („małpa”).

Przy czerwonym winie, o kobietach w informatyce, z kobietami w informatyce

Poznań tej jesieni to obszar objęty epidemią: od jelitówki, przez zwykłą grypę i przedszkolne żółte katary aż po powrót odry. Chorowanie nie sprzyja kreatywności, dlatego dzisiaj odgrzewam starszy tekst, z poprzedniego bloga. Pięć lat temu (!) postanowiłam przepytać kilka koleżanek o ich przygodę z programowaniem.

Czy dużo się od tego czasu zmieniło? Nie wprowadziłam prawie żadnych modyfikacji w treści tego wpisu. Nowe akapity oraz wtrącenia zaznaczam na ciemnozielono.

Zaczęłam rozmowę pytaniem o to, dlaczego dziewczyny wybrały informatykę jako kierunek do studiowania, a także o reakcje otoczenia na ten wybór. Oto, co odpowiedziały:

  • Eliza (programuje w Delphi, C# i JS – dzisiaj w PHP): Tak naprawdę to początkowo chciałam studiować psychologię, ale w trzeciej klasie okazało się, że nie daję sobie rady z biologią. Zawsze lubiłam matematykę, dlatego w końcu wybrałam informatykę. Rodzina nie zareagowała w żaden charakterystyczny sposób. Zawsze lubiłam też grać na komputerze – uwielbiałam Boulder Dash.
  • Ewa (obecnie używa Rails i JS  i Pythona, ale jako właścicielka małej firmy ma osobiste doświadczenia z ASP, C#, PHP i Javą): Komputery pociągały mnie od dziecka. Dużą przyjemność sprawiało mi siedzenie przy komputerze mamy, kopiowanie folderów, tworzenie prostych plików wsadowych… no i gra w Prince of Persia. Oboje rodzice pracują w dziedzinach technicznych (telekomunikacja i programowanie), dlatego cieszyli się z tych zainteresowań, chociaż każde próbowało namówić mnie do wyboru swojej dyscypliny. Jednak przed rozpoczęciem studiów w ogóle nie programowałam, jeśli nie liczyć AC Logo.
  • Magda (Java serwerowa, aplikacje na Androida, aplikacje internetowe w Javie): Mam w rodzinie tradycje matematyczne. Moi rodzice są nauczycielami matematyki, więc mój wybór nie wydawał się dziwny. Miałam zdolności w tym kierunku. Poza tym lubię rozwiązywać abstrakcyjne zagadki, a programowanie dla mnie to jak układanie z klocków!

Pytałam również o rozważane inne kierunki studiów. Eliza wspominała o psychologii. Ewa przez chwilę myślała o polonistyce, jednak ponieważ za naszych czasów można było złożyć papiery tylko w 3 różne miejsca, zarzuciła ten pomysł. Magda ukończyła dwa kierunki: matematykę i informatykę. Początkowo interesowała się matematyką stosowaną, jednak teraz jest zadowolona z tego, że wybrała programowanie.

Eliza mówi, że nie chciałaby, żeby jej dziecko było programistą – „bo to nudne”. Absolutnie się z nią nie zgadzamy, jednak trzeba przyznać, że jest to praca, o której trudno rozmawia się z ludźmi robiącymi coś innego.

W następnej kolejności zadałam pytanie, jaki był stosunek dziewczyn do chłopaków w ich szkole, na studiach i w pracy. Zapłaciłam karę za ten skrót myślowy – Ewa podała mi konkretne liczby, natomiast pierwszą odpowiedzią Elizy było „lubiłyśmy ich”

Liczby:

  • Eliza: 20-10 w liceum (rozszerzony angielski), 14-48 na uczelni, 4-22 w pracy.
  • Ewa: 11-20 w szkole (mat-fiz), 14-48, 3-3 w obecnej pracy (kierownikiem projektu jest kobieta, której zależy na zatrudnianiu kobiet, po części dlatego, że produkt jest związany z modą i faceci mają problemy z identyfikacją z nim; przez wiele dni wyśmiewali się ze słodkiego wielkanocnego zajączka, którego dziewczyny wstawiły na stronę).
  • Magda: 1/3 dziewczyn w liceum („ale to dziewczyny były lepsze”), nie pamięta dokładnych liczb z uczelni, ponieważ każde zajęcia odbywały się w innym składzie. Na pewno chłopaków było więcej. W pracy 3-10.

Kolejne pytanie: Czy Twoim zdaniem kobiety i mężczyzni na kierunku technicznym na studiach są traktowani tak samo? Jeśli nie, czy możesz podać przykłady nierówności (w obie strony)?

Spodziewałam się powodzi żalu,  jednak okazało się, że wcale nie jest tak źle. Oto, co wymieniły dziewczyny:

  • Magda: Panie w dziekanacie zawsze były milsze dla mężczyzn, zwłaszcza tych przystojniejszych Poza tym nie przypominam sobie, więc chyba grubszych spraw nie było.
  • Ewa: Jeden z prowadzących rozmawiał tylko z chłopakami, nawet jeśli mieli bardzo blade pojęcie o wspólnym projekcie, a przy tym ciągle mówił do nas „panowie”.
  • Część naszych kolegów z premedytacją zapisywała się na zajęcia prowadzone przez atrakcyjne dziewczyny, traktując je bardziej jako przyjemność estetyczną niż kompetentnego nauczyciela w istotnej dla nas dziedzinie.

Powtórzyłam to pytanie jeszcze raz, ale w kontekście pracy zawodowej:

  • Ewa opowiedziała nam o paru spotkaniach biznesowych, na których potencjalni klienci rozmawiali tylko z jej wspólnikiem, mimo że w wielku kwestiach to ona ma większą wiedzę. Twierdzi jednak, że mogło tam chodzić o kwestie autoprezentacji i smiałości w kontaktach.
  • Eliza wspomniała historię, w której rozwiązała koledze problem, z którym zmagał się od dłuższego czasu. Kolega pochwalił ją przy szefie. Szef spytał, jak Elizie udało się znaleźć rozwiązanie, a ona odpowiedziała, że wyszukała je w Google. „Aha, czyli miałaś szczęście” nie było raczej adekwatną reakcją.
  • Magda czasami w obecnej pracy spotyka się ze stwierdzeniem ze strony kolegów, że robi coś w inny sposób, bo jest kobietą. „Strasznie mnie to wkurza, bo co ma do rzeczy moja płeć.” We wcześniejszych miejscach pracy nie spotykała się z takimi komentarzami.

Chciałam również poznać opinię dziewczyn na temat liczby kobiet w informatyce. Czy jest naturalna? Czy kobiety nie chcą tego robić, nie potrafią, a może chodzi o coś jeszcze innego? Ostatecznie doszłyśmy do następującego wniosku: zmuszanie kobiet do pracy w tym zawodzie nie ma sensu, jednak zdecydowanie należy je zachęcać. Sam fakt, że programowaniem zajmuje się więcej mężczyzn niż kobiet nie musi być niczym złym ani nienaturalnym, ale aktualne proporcje nie odwzorowują realnego rozkładu umiejętności. Są warunkowane kulturowo: od małego słyszymy, że „chłopcy są lepsi w naukach ścisłych a dziewczynki w humanistycznych” a nawet że „chłopcy są zdolni, ale leniwi, a dziewczynki pracowite, ale przeciętne”.

Stereotypy działają w obie strony. Słyszymy że „tylko brzydkie dziewczyny idą na politechnikę”, „na informatykę laski idą po to, żeby łatwo znaleźć męża”, ale także „jeśli pójdziesz na techniczne studia, faceci będą cię szczypać w tyłek”.

Ewa opowiedziała nam o świeżej frustrującej sytuacji powiązanej z protestowani w sprawie ACTA. Została zaproszona na oficjalną imprezę, na której przedstawiono ją – i jej szwagra –  jednemu z polskich ministrów. Oboje zostali zaprezentowani jako informatycy, z naciskiem na to, że Ewa zajmuje się programowaniem. Minister spytał szwagra, co sądzi o ACTA a gdy ten odparł „nie wiem, nie czytałem” – kompletnie zarzucił temat, nie dając Ewie okazji do wyrażenia swojej rozbudowanej opinii.

Wracając do stosunku liczby kobiet do liczby mężczyzn. Zgodziłyśmy się, że parytety nie mają sensu, jednak więcej dobrych dziewczyn w informatyce to rzecz naprawdę pożądana. Popieramy wszelkie inicjatywy mające na celu zwiększenie udziału kobiet w tym zawodzie, pod warunkiem, że nie prowadzą one do wykluczenia facetów (spójrzmy jednak prawdzie w oczy, od tego jesteśmy jeszcze bardzo daleko).

Pod koniec rozmowy próbowałyśmy odpowiedzieć na pytanie, czy istnieją obszary informatyki, w których my (lub „większość kobiet”) sprawdzamy się lepiej niż mężczyźni (lub „większość mężczyzn”).

Wygląda na to, że większość kobiet ma jednak lepsze umiejętności komunikacyjne niż większość mężczyzn. Obecność paru kobiet w zespole ma bardzo dobry wpływ na atmosferę pracy. Często mamy więcej cierpliwości podczas objaśniania różnych spraw, także osobom spoza naszej dziedziny. Nie nosimy w sobie głębokiej nienawiści do pisania dokumentacji! Chociaż czasami praca ta nie jest odpowiednio doceniana. Być może łatwiej jest nam przyznać, że (jeszcze) czegoś nie wiemy. Obawiam się trochę, że ta cecha wcale nie wychodzi nam na korzyść: inaczej odbierane są osoby, które zaczynają zdania od „uważam, że”, a inaczej te, które mówią „jestem pewien”. Nie potrafimy wskazać żadnych poważniejszych różnic, jeśli chodzi o poziom, sposób czy styl kodowania.

Przy okazji wspomniałyśmy pewnego znanego nammężczyznę, który deklaruje, że nigdy nie zatrudni kobiet, ponieważ nie wie, jak z nimi rozmawiać. Twierdzi, że jeśli skarci pracownika-mężczyznę i powie mu, że powinien robić coś inaczej, ten powie „OK” i weźmie się do pracy. Kobieta, według, niego ”zamknie się na pół dnia w łazience i będzie płakać”. Pomijając już to, że żeby zgłaszać takie obserwacje, trzeba by jednak zatrudnić kobietę – po pierwsze, żadna z nas nie płacze z takiego powodu (dwa razy w życiu płakałam w łazience w pracy, oba razy po konkretnych seksistowskich uwagach kompletnie niezwiązanych z moją pracą). Po drugie, moje doświadczenie uczy, że co prawda wiele osób powie „OK”, co nie zmieni jednak faktu, że spróbują się za to odegrać, gdy nadarzy się okazja.

Zakończę ten radosny wpis cytatem z Magdy:

Wybrałam taki zawód, bo lubię. Chociaż czasami poziom frustracji sięga zenitu! Nie rozumiem natomiast dziewczyn, które w swojej pracy chcą udowodnić, że są lepsze od mężczyzn. Nie o to chyba w życiu chodzi żeby komuś coś udowadniać.

Sama po kilku latach przeczytałam ten tekst z zainteresowaniem. Czy coś zmieniło się w środowisku? Czy zmieniły się moje poglądy? Wypunktuję poniżej kilka luźnych uwag. 

  • Dzisiaj jeszcze bardziej niż wtedy jest dla mnie oczywiste, że za „zachęcanie” kobiet do IT (a jeszcze bardziej za ich niezniechęcanie) trzeba się zabrać bardzo wcześnie. Począwszy od sklepów z zabawkami i zawartości działów „dla chłopców” i „dla dziewczynek” oraz wyboru komplementów, jakimi obdarzamy małe dzieci. 
  • Dziś jeszcze mniej chętnie używam sformułowań „większość kobiet” i „większość mężczyzn”. 
  • Uważam,  że krótkoterminowo i w niektórych sytuacajch parytety mogą mieć sens. 
  • W sektorze IT potrzeba coraz więcej pracowników. Również z tego powodu, kobiet jest więcej niż jeszcze parę lat temu. Pewną nowością są osoby, które nie studiowały informatyki, ale udało im się przekwalifikować.
  • W backendowych zespołach, z którymi obecnie pracuję, nadal nie ma jednak ani jednej programistki (są za to dwie techniczne managerki: ludzi i produktu).
  • Głupie żarciki w pracy jak były, tak są. Wbrew obiegowej opinii, korporacje z reguły radzą sobie z tym tematem lepiej niż „przyjazne” niewielkie firmy. 
  • Wśród kobiet, które twierdzą, że jakakolwiek dyskryminacja w naszej branży jest wyssana z palca, wiele jest informatyczkami w drugim pokoleniu. Moim zdaniem potwierdza to tezę o znaczeniu warunkowania w domu, na najwcześniejszym etapie rozwoju. Jeśli dziewczynka wychodzi z domu rodzinnego przekonana, że może wszystko, jest znacznie mniej podatna na drobne przejawy seksizmu i dyskryminacji.