Pamiętaj abyś wiedzę swą święcił

8

“Ciągły rozwój” jest, zdawałoby się, charakterystyczną cechą dla naszego zawodu. Nie tylko naszego oczywiście, ale my, programiści, szczególnie lubimy myśleć o sobie jako o tych, którzy nigdy nie stoją w miejscu i ciągle poznają nowe/lepsze techniki, rozwiązania, praktyki.

Warto jednak zatrzymać się czasem na chwilę i zastanowić: czy ja sam nie odstaję od tego autopromowanego pozytywnego stereotypu? Kiedy ostatni raz nauczyłem się czegoś nowego? Czy mój dzisiejszy kod jest lepszy niż ten napisany na przykład rok temu?

Dobrą wymówką może być codzienna praca. Niejeden z nas spędza 8 lub więcej godzin dziennie na nudnym klepaniu ciągle tego samego. Wiadomo – większość programistów pracuje utrzymując wieloletnie, kobylaste systemy, które zwykle nie świecą przykładem jeśli chodzi o optymalne podejście do rozwiązywania problemów czy jakość kodu. Wielu programistów odbębnia te osiem godzin, idzie do domu, i szluss. I po prostu nie chce się robić nic więcej.

Czy tak być powinno? Nikt nikogo do niczego nie zmusi, ale ulepszenie swoich umiejętności, nawet jeśli nie przydadzą się w codziennych obowiązkach, może po prostu dać satysfakcję, być inwestycją w przyszłość. Dostaję sporo maili z pytaniami typu “jak stać się dobrym programistą?“. Odpowiedź jest zawsze jedna i ta sama: przez robienie czegoś.

W necie można spotkać wiele teorii na temat “jak powinien wyglądać rozwój programisty”. A to każą uczyć się przynajmniej jednego nowego języka rocznie. A to każą czytać jedną książkę techniczną miesięcznie. A to każą chodzić na spotkania lokalnych grup pasjonackich…

Ale tak naprawdę nie ma większego znaczenia CO robisz. Ważne żeby robić COKOLWIEK. Niech to będzie faktycznie lektura książki. Niech to będzie hobbystyczny projekt open source, który nigdy nie zostanie skończony. Niech to będzie czytanie blogów. Niech to będzie oglądanie sesji z wypasionych konferencji. Niech to będzie zapoznanie się z cudzym działającym kodem. Niech to będzie posłuchanie podcasta.

Po prostu: inwestuj w siebie. To nie musi być dużo. Efekt poznasz bardzo łatwo: jeśli za kilka miesięcy spojrzysz na swój kod i pomyślisz “dzisiaj napisałbym to lepiej” – wygrałeś. I nic nie powstrzymuje cię przed wygrywaniem dalej. Jak cytowałem w “Słowie na niedzielę, o lenistwie” – wystarczy zacząć. Potem pójdzie z górki.

Będąc programistami otrzymaliśmy pewnego rodzaju dar. Dar wychodzący poza łatwość znalezienia pracy oraz absurdalnie wysokie zarobki (w porównaniu do innych zawodów, szczególnie na początku kariery). Otrzymaliśmy dar możliwości nieustannej walki z nudą i codzienną rutyną. Jako jedni z niewielu mamy możliwość łyknięcia nowej wiedzy i natychmiastowego wypróbowania jej w praktyce. Nie pozwólmy takiej szansie się marnować – jako programista jesteś warty tyle, ile twoja wiedza. Stąd już tylko krok do praktycznego doświadczenia, najbardziej cennego zasobu w kieszeni każdego deva.

Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET i współorganizator konferencji Programistok. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook, YouTube.

8 Comments

  1. Pingback: dotnetomaniak.pl

  2. Od roku zyje za pan brat z TDD i mimo iz czesto zdarza mi sie grzebac w starszych systemach, wlasnie z ta metodologia grzebie mi sie latwiej, bo lokalnie.
    Dwa miesiace temu kupilem sobie pozycje “Refaktoryzacja. Ulepszanie struktury istniejącego kodu” Autorzy: Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts.
    W obliczu tutejszej dyskusji z R# w tle, brzmi jak banal. Jednak po analizie materialu i wytrwalym przegryzieniu tematu, zdarzylo mi sie niedawno wziac kod spaghetii i rozkminic go jak nigdy dotad. Sztuka polegala na “agresywnej” refaktoryzacji kodu PoC, ktory dawniej pozostawil bym takim jaki zastalem, tylko go rozszerzajac.
    Satysfakcja dla mnie jest to, ze nie robil tego za mnie automat R#, ale ja sam, rozumiejac dokladnie co i po co zroblem.

  3. Technikalia tak szybko pedza ze juz nie wystarczy po prostu sie uczyc. Trzeba priorytetyzowac i planowac,co warto czego nie warto. Umiec selekcjonowac informacje nie istotne, od istotnych. Do tego z czasem (i wiekiem ;) ) troszke maleje zapal i checi, zaczyna brakowac czasu, to juz nie czasy studenckiej mlodosci i blogiego wciagania litrow kawy :)

    Warto pamietac ze gdy ktos nie daje rady nadazac za technologia to zawsze moze lekko zmienic kariere. W Software Developerce mozna zajac sie innymi ciekawymi rzeczami :) Mozna polaczyc wiedze techniczna z wiedza menadzerska ktora ma mniejsza “inflacje” wiedzy i w ktorej znacznie bardziej liczy sie doswiadczenie.

    Wg mnie w naszej sciezce kariery trzeba “dywersyfikowac” inwestycje w wiedze. Byc jack of all trades. Uczyc sie nie tylko technologi ale przede wszystkim podstawowych koncepcji ktore sa niezalezne od frameworkow, jezykow itd. Do tego dorzucic sporo wiedzy interpersonalnej, menadzerskiej.

  4. Filip Zawada on

    Odnośnie nadążania za technologią, Scott Hanselman miał bardzo ciekawą prezentację podczas DevDay 2012 – “It’s not what you read, it’s what you ignore”. Zdecydowanie warto poświęcić na nią godzinę swojego czasu: http://www.youtube.com/watch?v=IWPgUn8tL8s

  5. Jak to w tym roku powiedział jeden z prowadzących na studiach z Technologi Analogowej ( przedmiot legenda, czasam może i gorsza od analizy), cyt. “Jeszcze nikt nie wygrał turnieju tenisowego, poprzez oglądanie go w telewizji”.

  6. Można powiedzieć, że kariera programisty jest jak dobra rga RPG :) Wiele taktyk, trzeba inwestować w swój rozwój. Jedni wybierają szybką, ale ryzykowną ścieżkę, inni dłuższą, ale stabilniejszą :D

Newsletter: devstyle weekly!
Dołącz do 1000 programistów!
  Zero spamu. Tylko ciekawe treści.
Dzięki za zaufanie!
Do przeczytania w najbliższy piątek!
Niech DEV będzie z Tobą!