fbpx
devstyle.pl - Blog dla każdego programisty
devstyle.pl - Blog dla każdego programisty
3 minut

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


11.02.2013

“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.

0 0 votes
Article Rating
8 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
trackback
11 years ago

Pamiętaj abyś wiedzę swą święcił | Maciej Aniserowicz o programowaniu…

Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl…

tekkno
tekkno
11 years ago

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.

Michal Franc (@francmichal)

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.

Filip Zawada
11 years ago

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

Pawel Sawicz
11 years ago

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”.

Kamg
11 years ago

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

Kurs Gita

Zaawansowany frontend

Szkolenie z Testów

Szkolenie z baz danych

Książka

Zobacz również