Chłodny umysł

Mój znajomy znalazł sobie pracę za granicą w renomowanej firmie, bo w kraju nie bardzo mógł się dogadać z potencjalnymi pracodawcami reprezentującymi drugi garnitur deweloperów oprogramowania. Myślę, że dobrze zrobił. Wielu z nas, będąc na jego miejscu, postąpiłoby prawdopodobnie tak samo. Nie dość, że zatrudnienie w znanej firmie podnosi prestiż zawodowy, to dodatkowo można nieco łyknąć światowego życia.

Mój znajomy znalazł sobie pracę za granicą w renomowanej firmie, bo w kraju nie bardzo mógł się dogadać z potencjalnymi pracodawcami reprezentującymi drugi garnitur deweloperów oprogramowania. Myślę, że dobrze zrobił. Wielu z nas, będąc na jego miejscu, postąpiłoby prawdopodobnie tak samo. Nie dość, że zatrudnienie w znanej firmie podnosi prestiż zawodowy, to dodatkowo można nieco łyknąć światowego życia.

Praca u dużych producentów oprogramowania dostarcza czasami niezapomnianych wrażeń. Wiem coś o tym, bo sam wiele lat służyłem w takiej jednostce, co prawda krajowej, ale zawsze. Było przynajmniej z kim porozmawiać na tematy fachowe. W dobie globalizacji nieco zmieniły się zasady i procedury wytwarzania oprogramowania. Jeden zespół zajmuje się kontaktami z klientami, inny zgłaszaniem i testowaniem rozszerzeń funkcjonalnych, a już zupełnie inny samym projektowaniem i programowaniem. Mogą one być wielonarodowe i rozsiane w różnych częściach naszego globu. Tak więc programiści związani z jednym rodzajem oprogramowania mogą być ulokowani, dajmy na to, w Indiach, a ci, którzy zajmują się innymi modułami, np. w Izraelu.

Zastanawiam się przy okazji, czy można spokojnie pracować w Izraelu. Ogólnie znana sytuacja nie sprzyja skupieniu, które przynależne jest projektantom i programistom. Chyba właśnie to powoduje, że czasami oprogramowanie tworzone w nerwowej atmosferze nie działa do końca poprawnie.

Zostałem przy pewnej okazji zapytany, dlaczego tak się dzieje, że program od czasu do czasu nie zapamiętuje zmienionych danych. Jak na moje doświadczenie z bazami danych, wniosek mógł być tylko jeden. Przypadkowość ta nie wynika bynajmniej z nieokiełznanego temperamentu komputerów, tylko z powodu niewłaściwego podejścia do transakcji w bazach danych. Otóż, gdy jedna transakcja blokuje dostęp do zasobów, inna transakcja, która akurat próbuje coś zapisać, nie ma szans, aby to uczynić. Akurat w przypadku omawianego serwera czas oczekiwania na zwolnienie zasobów może być nieskończony, czego raczej w programistycznej praktyce się nie stosuje w obawie przed trwałymi zakleszczeniami, które jeśli wystąpią, trzeba "ubijać" ręcznie. Można też ustawić programowo dowolnie krótki czas oczekiwania. Gdy w tym okresie zasoby się nie zwolnią, transakcja jest odrzucana. Jeśli teraz programista nie zadba o analizę kodu zakończenia transakcji i spowoduje, że jej niepowodzenie nie będzie sygnalizowane użytkownikowi, otrzymamy taki właśnie rezultat hazardowych zachowań systemu. Ja np. mam nawyk takiego , że wznawiam nieudaną transakcję kilkakrotnie, w regulowanych odstępach czasu, a gdy to nie poskutkuje, dopiero wówczas alarmuję użytkownika. No, ale nie pracuję na zagrożonym atakami bombowymi terytorium, mogę więc spokojnie sobie programować i ręce mi się nie trzęsą, a głowa jest spokojna.

Gdybym musiał robić to samo nawet nie w warunkach zagrożenia, ale pracując chociażby na dużej sali, gdzie wszyscy zajmują się wszystkim i panuje ogólny rozgardiasz, co i nieraz zdarza się w większych firmach software'owych, efekt końcowy też nie byłby najlepszy. Tak więc nie wypada się naśmiewać z programistów tworzących swe produkty w ciężkich warunkach. Łatwo się wymądrzać, żyjąc w komforcie. Z relacji mego znajomego wynika, że podróże na tereny niespokojne nie cieszą się powodzeniem. Ostatnio np. trzeba było zgrupować w jednym samolocie pasażerów z dwóch zaplanowanych lotów, aby w "imponującej" liczbie sześciu mogli odlecieć do miejsca przeznaczenia. Cóż, spokojnie jak na wojnie, jak zwykło się mawiać.


TOP 200