Święta pełną parą i wierzę (bo co innego można robić w święto kościelne?!), że większość z nas nawet nie rozważa sesji przed kompem jako właściwe zajęcie i korzysta z dobrodziejstw wolnego czasu na wspólne biesiadowanie z rodziną, a więc wyciszenia pełną parą. Lepiej korzystajmy z tej chwili, bo nie prędko może się pojawić następna.
Po ostatnim "wyskoku" 1-kwietniowym "Fsharp, dotNet i okolice...dojrzałem - zarzucam JEE na rzecz ciekawiej zapowiadającej się platformy .Net", gdzie zadeklarowałem odejście w stronę .Net dostałem kilka ciekawych komentarzy, z których jeden szczególnie mnie zaintrygował autorstwa Macieja Moczkowskiego:
Hej, oczywiscie ze dalem sie nabrac... Chyba dlatego, iz sam zaczynam dochodzic do podobnej konkluzji. Nie chodzi mi zupelnie o mowienie co jest lepsze i nie zamierzam Javy porzucac. Ale po wielu latch pracy z Java EE czuje sie troche wypalony - juz nie pociaga mnie tak jak kiedys to ze ukazal sie 123ci framework web'owy dla Java EE;) Za to coraz bardziej ciagnie mnie by zobaczyc druga strone medalu - jak radzi sobie platforma .NET.
Tak wiec wkrecony, ale troche zawiedzony...
Jemu zawdzięczam przedświąteczne olśnienie i skierowanie na właściwe tory - użycie technologii do rozwiązywania problemów, dla których ona została stworzona.
Brzmi znajomo, ale mam wrażenie, że wielu z nas zatopiło się w niekończącej się gonitwie za nowinkami technologicznymi...nie mając czasu na ich wykorzystanie w produkcji. Czyż to nie paradoks naszej profesji, gdzie zamiast stawać w szranki z problemami stworzenia aplikacji realizującej pewne potrzeby...ekhm...biznesowe (ale bez tego nadymania korporacyjnego, tylko faktyczne potrzeby człowieka i zaprzęgnięcia do tego komputera) zmagamy się z bezkresem problemów technologicznych?!
Ten komentarz uzmysłowił mi, że rozwiązywanie problemów technologicznych tworząc aplikację jest zdecydowanie ciekawszym zajęciem niż nauka kolejnych technologii bez ich produkcyjnego wykorzystania. To jest właśnie sens naszej nauki kolejnych technologicznych bajerów, skrótów klawiszowych, kolejnych środowisk i języków. Cóż nam po kolejnej znajomości (nie tylko technologicznej), jeśli sprowadza się do kolejnej pozycji w naszym technologicznym serwisie społecznościowym? Cóż nam po znajomości Java EE, OSGi, Spring Framework, SuperExtra Framework 5.9...tu wstaw kolejne cacko...kiedy ta znajomość nie przekłada się na...przysłowiowy spokój ducha. Z własnych obserwacji siebie: znając więcej nie pozwoliło mi na posiadanie więcej czasu realizując problemy szybciej (!) Wręcz przeciwnie, miałem wciąż nieodparte poczucie utraty czegoś wartościowego, bo nie udało mi się jeszcze poznać Scali, języków funkcyjnych w ogólności, itp. Warto od czasu do czasu zadać sobie pytanie: "Po co?!"
Trzeba mi było prawie 5 lat publicznych dywagacji w postaci bloga, wystąpień technologicznych, artykułów, rozmów, aby w końcu dojrzeć i dojrzec sens tego pytania. Przywołany do tablicy Maciej Moczkowski natchnął mnie i wskazał właściwą drogę rozwoju. Nie kolejna, nowa technologia, ale kolejna, nowa...aplikacja. Dopiero jej stworzenie może być oznaką przejścia do grona znawców tematu i stanowić cenny nabytek w zespole realizującym zadanie dla klienta za właściwe benefity we właściwym czasie bez zbędnego stresu.
Maciej jest tylko przykładem. Kolejnym mógłby być Adam Warski, którego obserwowałem przez ostatnie tygodnie, jak tworzył aplikację w Scali na potrzeby konferencji Javarsovia 2010. Przyglądałem się, jak my, użytkownicy, kapituła konferencji, prowadzimy go przez chaszcze funkcjonalne, w których on odnajdował drogę tnąc je wykorzystanymi technologiami. Nie ma znaczenia, czy technologia była najwłaściwsza i czy znał się na Scali i Lift przed podjęciem zadania. Nie jest też ważne, czy właściwie wykorzystał dane mu narzędzia, czy stosował TDD, BDD, czy XYZ. Najważniejsze, że dobrnął do końca i ukończył ją na czas. Pewnie, że znajomość dodatkowych narzędzi mogło sprawić, że to zadanie będzie jeszcze bardziej wartościowe, ale zbyt często dążenie do celu przesłaniają nam kwestie drugiego rzędu, właściwie bez znaczenia. Najważniejsze jest umiejętne zbalansowanie potrzeb i przyjemności. Dzisiaj, w święto, ma to niebagatelne (wagowo) znaczenie :-)
Prawda, w programowaniu chodzi o to żeby pisać programy :) i najważniejszą cnotą aplikacji jest jej poprawne działanie. Brzydki kod można zrefraktorować.
OdpowiedzUsuńZ drugiej strony jednak wypada mieć, takie ogólne pojęcie OCB w różnych frameworkach. Choćby po to żeby wybrać odpowiedni framework, albo --- nie wybrać masakrycznie złego. Bo jakiś często trzeba wybrać --- czy piszesz aplikacje okienkową w Swingu, czy SWT. Czy piszesz frontent aplikacji webowej w JSF, wickecie, GWT, czt nawet jsp. Coś jednak wypada wybrać, po pisać czystych gołych servletów jednak chyba nie warto.
Przykład z życia: aplikacja pisana pod Java WebStart z założeniem że musi być ona używana przez ludzi z różnymi systemami --- używająca SWT (przez co do tej pory nie działa z 64bit Linuxem) --- no i sama aplikacja 'napuchła' o kilka mega!
Choć w pełni zgadzam się z postulatem --- ucz się nowych technologii przy pisaniu aplikacji, może nie aplikacji produkcyjnych w które kilka milion osób, ale nie warto uczyć sie na sucho.
Inną sprawą jest natomiast poszerzanie horyzontów. Każda nowo poznana technologia daje inne spojrzenie na te "stare". Coś jednak jest w tym powiedzeniu, że "z niejednego pieca chleb jadał" :)
OdpowiedzUsuńWitaj Jacku,
OdpowiedzUsuńPiszac moj post nie zdawalem sobie sprawy, iz spowoduje on tak powazne przemyslenia. Milo, im ze uznales go za wartosciowy. Faktycznie praca programisty to przede wszystkim rozwiazywanie problemow a technologia to po prostu narzedziem. Ja takze w tym momencie stawiam na ten pierwszy aspekt... ale byc moze dlatego iz ja juz nasycilem troche swoja ciekawosc technologiczna. Nie bylo tak jednak zawsze i byc moze po prostu zalezy to od tego jakie kazdy z nas ma potrzeby w danym momencie czy bagaz doswiadczen zawodowych.
Prawdopodobnie najlepiej zachowac zloty srodek;) Pozdrawiam