Smutny programista "ekspert" i jego świetna praca

0

Cześć.

Piszę do was, gdyż chciałbym prosić was o radę. Zwłaszcza osoby, które programowaniem zajmują się zawodowo.

Teoretycznie programistą mogę się nazwać, mam to przecież napisane na umowie. Lecz tak naprawdę w ostatnim czasie przeżywam mały programistyczny kryzys.

Od roku pracuje w pewnej dużej, szybko rozwijającej się, znanej, innowacyjnej firmie. Pracuje tam jako programista C++ w kilkunastoosobowym zespole. Oprócz tego, że pracuję, to kończę jeszcze studia. Moja nauka powoduje, że niestety nie jestem w stanie pracować na cały etat. Pracuję więc na 1/2 etatu.

Moja praca, z której powinienem być bardzo zadowolony jest dla mnie pierwszą pracą w zawodzie (niemniej jednak pracowałem dużo już wcześniej, dorywczo i terminowo, więc wiem co to praca i ciężka praca).

W czym problem...

Generalnie nie jestem zadowolony ze swoich wyników. Prawda jest taka, że po roku pracy w firmie nie czuję się specjalistą w tym co robię. Produkt nad którym pracujemy jest rozwijany od bardzo dawna i ma kilkaset tysięcy linii. Moją główną bolączką jest to, że nie potrafię go w swoim umyśle w całości objąć, a jednocześnie mieć go przedstawionego w szczegółach.

Na studiach każdy program, który pisałem pisałem od podstaw. Znałem jego architekturę, gdyż sam go projektowałem. Czasami była przesrana, ale wiedziałem o niej wszystko, bo była stworzona przeze mnie.

Przyszedłem do pierwszej pracy zawodowej i rzucono mnie na głęboką wodę. Ogrom wszystkiego był i niestety nadal jest dla mnie przytłaczający. Stwierdziłem, że o ile pisać kod potrafię, to czytać go w większej ilości już nie bardzo. Dokumentacja w mojej firmie pamięta czasy prezydenta Wałęsy, więc na nic się nie przydaje. Dopiero tutaj w pracy zacząłem uczyć się korzystać np. z callstacka. Nigdy wcześniej moje programy nie wymagały używania go podczas debugowania. Ja po prostu doskonale wiedziałem dlaczego jestem w tej a nie innej funkcji. Teraz jest inaczej.

Na początku tak bardzo się nie martwiłem, bo przecież byłem nowy...no i się dopiero uczyłem. Jednak za wszelką cenę chciałem pokazać, że decyzja osoby, która przeprowadzała ze mną rozmowę kwalifikacyjną była słuszna. Więc gdy napotykałem jakiś problem to koniecznie chciałem go rozwiązać sam. Po pierwsze: nie mogę pokazać, że tego nie umiem...to na pewno jest łatwę, posiedzę jeszcze chwilę to to rozczaję. Nie potrafiłem korzystać z pomocy mojego teamu. Zadawałem zdecydowanie za mało pytań(przecież ja miałem prawo tego nie wiedzieć!!!). Duma mnie zjadła i teraz cierpię.

W tym wszystkim dobija mnie jeden fakt. Do naszego zespołu 4 miesiące po mnie dołączyła kolejna osoba. Ona pytała o wszystko...nie tylko o architekturę...ale i czasami o podstawy z języka...(co na początku wydawało mi się śmieszne..To przecież powinien umieć!). Ta osoba jednak pytała, pytała, pytała...a teraz jest specjalistą w tym co robi.

Problemy rozwiązuje kilka razy szybciej ode mnie. Jak czasami ta osoba rozmawia z innymi z mojego zespołu, to słyszę jej tok myślenia...co może być tego powodem. Padają wówczas nazwy funkcji, klas o których w życiu nie słyszałem. A na dodatek ta osoba potrafi ograrnąć to wszystko w całości...ale w razie potrzeby zejść na najniższy poziom.

Ja tak nie potrafię i coraz bardziej zastanawiam się, czy po prostu tego się jeszcze nie nauczyłem, czy po prostu tego nie potrafię się nauczyć?

Niestety nie mam w firmie żadnej takiej osoby, której bym się mógł zwierzyć z tego, ża tak naprawdę czuję się bardzo słaby ze znajomości całego systemu i żeby ta osoba mnie poprowadziła jako mój osobisty mentor.

Czuje się samotny w pracy z moją tajemnicą, że czuję że g**no umiem!

Pracuje nadal i jednocześnie wątpie żebym był tak po prostu zwolniony, gdyż jakby nie było skoro firma zatrudnia i tak cały czas nowych programistów, to i tak jakiego by nie zatrudniła, to na początku i tak będzie gorszy ode mnie! Ja juz niby jestem wyszkolony.

Co ja mam zrobić? Z braku czasu nie mogę poświęcić sobie domowego wieczoru na dodatkową analizę struktury programu. Z pewnych przyczyn studia w tym momencie są jeszcze dla mnie na tyle ważne, by dopchać je do końca.

Coraz bardziej zastanawiam się nad zmianą pracodawcy. Boję się tego, że to byłby mój ogromny błąd! Firma jest bardzo dobra i pod względem wynagrodzenia i pod względem socjalnym. Powód dla którego bym poszedł gdzieś indziej byłby taki, by zmazać z siebie status osoby, która niby powinna już coś umieć, ale jednak nie czuje się z tym najlepiej.

Co ja mam zrobić? Czy tylko ja czuję się zagubiony pośród setek tysięcy linii kodu? W szkołach nie uczą jak modyfikować ogromny program, którego nie znamy całej struktury.

Czy macie dla mnie jakieś rady? Może są jakieś książki poświęcone tym tematom? Może sami mieliście podobne problemy?

(proszę jednocześnie o wyrozumiałość... mam nadzieję, że ten przynajmniej zalicza się do kategorii off-topic. Może tutaj znajdę jakąś pomoc w tej sprawie)

0

Zadaj sobie kilka pytan:

  1. Co reszta zespolu mysli o Twoich umiejetnosciach?
  2. Czy kiedykolwiek ktokolwiek dal Ci do zrozumienia, ze 'nic nie wiesz' i jak czesto tak bylo?
  3. Czy osoba, o ktorej mowa przyszla od zera czy z doswiadczeniem?
  4. Co robisz w kierunku lepszego poznania systemu?

IMO sam sie dobijasz pesymistycznym mysleniem. Przede wszystkim jeszcze tam pracujesz, tak? Czyli pracodawca jest co najmniej zadowolony z Twojej pracy, skoro jeszcze nie dal Ci do zrozumienia, ze troche wolno Ci idzie. Po drugie - jak radzi sobie reszta zespolu? Czy system jest trudny tylko dla Ciebie, czy tez cala reszta raz na jakis czas dowiaduje sie, ze jest w systemie cos, o czym nikt nie wiedzial, ze istnieje :D (tak, tak, to sie zdarza ;) ). Skoro architektura jest duza, to nikt nie broni Ci zadawac pytan. Prawdopodobnie nie ma u was w zespole osoby, ktora by wiedziala wszystko, czyli MACIE prawo czegos nie znac.

Ja tez pracuje w systemie zamotanym jak poranne wstawanie. Ale zawsze przy okazji buszowania w poszukiwaniu jakichs szczegolow, pisania nowych funkcjonalnosci zawsze staram sie patrzec naokolo. Jak trafi sie jakas klasa, funkcja, ktorej nie widzialem to rzucam okiem do srodka. Czasem w minute mniej wiecej wiem co robi (bo nazwy mowia same za siebie), czasem notuje sobie w pamieci - jest taka klasa, moze ktos niedlugo bedzie o niej wspominal to poslucham do czego jest.

Nie ma sie co samemu dobijac. Raczej nikt nie bedzie wymagal by po roku w duzym projekcie znac go na wylot - to sie rzadko lub nigdy nie zdarza.

0

Ci, co g**no potrafią, nie wiedzą, że g**no potrafią. Więc umiesz więcej niż g**no... No, jakoś tak. IMO zbyt pesymistycznie myślisz.

0

Nie zmieniaj pracy z tego powodu, że projekt jest skomplikowany i że nie ma do niego dokumentacji. Ja też pracuje przy systemie, który piszą ponad 21 lat (fajnie wiedzieć, że system ma tyle lat co ja :)) i w którym dokumentacja jest tak roz****** że równie dobrze mogło by jej nie byc. Jak zmienisz pracę to masz spore szanse, że trafisz na podobny projekt. Kiedyś słyszałem ciekawy cytat, jednego profesora z MIT "Computer Engineering is about controling the complexity". Przy takim dużym projekcie masz okazje się nauczyć właśnie takiej kontroli. Tak naprawde każdy potrafi pisać działający kod, dopiero prawdziwym wyzwaniem jest ten kod utrzymać tak żeby cały projekt się nie rozjechał w pizdu.
Duży błąd, że nie zadawałeś pytań. Teraz już masz nauczkę na przyszłość, żeby męczyć ludzi swoimi pytaniami ile wleźe.

Czy system jest trudny tylko dla Ciebie, czy tez cala reszta raz na jakis czas dowiaduje sie, ze jest w systemie cos, o czym nikt nie wiedzial, ze istnieje

U mnie gość który pracuje ponad 5 lat ciągle dowiaduje się nowych rzeczy :D

0

Hehe, moj system z ktorym pracuje jest niestety starszy ode mnie, w tym roku 30stke obchodzi i nawet nie mam zamiaru go analizowac, bo to miliony linii kodu sa :)

sadprogrammer, sie nie stresuj tak, bo to do niczego nie prowadzi. Sam w pierwszej pracy po studiach mialem takie odczucia "ze nic nie wiem, jestem kiepski, blablabla", a finalnie to calkiem ok to wychodzilo. I nie boj sie zadawac pytan, bo na nie nigdy nie jest zapozno... jesli faktycznie okaze sie, ze za malo wiesz i pracodawca ma o to pretensje to wtedy zmienisz prace. A poki co to wszystko jest ok :)

0

To ja Ci podam swój przykład, może się przełamiesz i przestaniesz bać się zadawać pytań. Jestem liderem zespołu (małego, 3-4 osoby) i na początku projektu też projektantem. Jak zaczynamy pracę to zespół przychodzi do mnie pytać o prawie wszystko. Jednak po 2-3, albo więcej miesiącach developerki jak muszę coś w tym systemie zaimplementować to niemal zawsze muszę podejść do kogoś i zapytać o szczegóły. A zgodnie z Twoim tokiem rozumowania powinienem wiedzieć o nim wszystko - w końcu sam to g*** ;) projektowałem.

Musisz wiedzieć że zespół projektowy ma wiedzę rozproszoną po poszczególnych członkach. Dobry zespół to nie taki, gdzie każdy wie wszystko, ale taki który sprawnie wymienia się tymi informacjami. Więc za każdym razem kiedy zamiast grzebać w czymś 5h i dalej nie wiedzieć, pójdziesz i zorientowaną osobę zapytasz - cały team zyskuje.

Poza tym spróbuj tak dla zdrowia zrzucić z siebie trochę winy. Ktoś kto cię wdrażał (albo przynajmniej przywitał w zespole) powinien dać Ci sygnał, że wolno pytać jeśli się nie wie. Ludzie mają różne fiksacje po studiach, np że każde zadanie trzeba wykonać w 100% samodzielnie, bo inaczej to oszustwo. A co było dobre na studiach, niekoniecznie sprawdza się w rzeczywistości.

No i jeszcze uważam, że możesz przekuć swoje doświadczenia na dobre działania. Dobrze wiesz jakie męki przechodzą "nowi" w firmie. Jeśli ci "nowi" nie są objęci odpowiednią opieką - zrób to samodzielnie, jeśli jesteś z natury people-person ;) Zrobisz coś pożytecznego oraz zyskasz ich sympatię i szacunek.

Powodzenia i dawaj znać jak Ci idzie, trzymamy kciuki.

0

A tak w ogóle to chyba mamy jakieś przesilenie. Drugi temat w przeciągu 2 dni, w którym autorzy martwią się o swoje słabe umiejętności programistyczne, które w rzeczywistości pewnie nie są takie słave :)

0

Z wykształcenia NIE jestem informatykiem, ale okoliczności sprawiły, że pracuję dla bardzo dużej firmy międzynarodowej jako developer.
Jak się tam pojawiłem, to też się zamartwiałem, że nie mam doświadczania, że jestem samoukiem, że zaraz się mnie pozbędą.
Minął rok i teraz już wiem, że w takich molochach brak jest przyzwoitych informatyków.
Jednym z moich obowiązków jest Code Review i to jak ludzie czasami kodują to przechodzi ludzkie pojecie. I to nie tacy ludzi "z ulicy" jak ja, ale ludzie z wykształceniem informatycznym. Po tym jak zobaczyłem jak to działa i jaki jest poziom profesjonalizmu doszedłem do wniosku, że sprzedałem duszę za zbyt małą kasę.

Wniosek jest prosty. NIE PRZEJMUJ SIĘ.
Pytaj jak czegoś nie rozumiesz/nie wiesz. W takich wielkich projektach nikt nie ma pojęcia o całości panuje powszechny burdel. Nie przejmuj się, że inni rozmawiają o jakiś klasach, o których nie masz pojęcia. Oni czują dokładnie to samo, gdy ty rozmawiasz z kimś o swojej części kodu lub o kodzie z nim związanym.
pÓÓÓÓki robisz swoje nikt się ciebie czepiał nie będzie.
Znam gościa zatrudnionego jako developer, który nie napisał linijki kodu od ponad roku (udaje scrum mustera) i nawet nie planują go wywalić (tylko czasami jak wymyśla jakieś głupoty, które mają sprawić wrażenie jaki jest ważny i cenny, to się z niego po cichu śmiejemy).
Jak będziesz tak rozpaczał to tylko się nabawisz choroby serca albo depresji.

Pamiętaj informatyków brakuje i brakować będzie, więc jeśli postanowią się z tobą rozstać to nową lepszą pracę znajdziesz w dwa/trzy tygodnie.
Jeśli chcesz ogarnąć cały projekt to może zacznij programować: paliki, lodówki, zmywarki, samochody. Kumpel mówi, że w tych dziedzinach poznasz dokładnie system, prawie co do ostatniej linijki kodu, w ciągu maks 6 miesięcy.

0

To, że nie rozumiesz całości projektu nie musi być tylko Twoją winą. Słusznie sam zauważyłeś, że błędem był Twój brak odwagi do zadawania mnóstwa pytań na początku. W większości firm pracownicy przechodzą szkolenie albo są traktowani ulgowo i ze zrozumieniem przez początkowy okres, który wymaga masy nauki.

To dziwne, że tak się prześliznąłeś przez ten rok czasu... Wg mnie to nie najlepiej świadczy o Twojej firmie. Ktoś powinien Tobą pokierować i po roku powinieneś już ogarniać ten moduł, którym się zajmujesz.

Przede wszystkim odpowiedz sobie na pytanie czy możesz się jeszcze czegoś nauczyć i rozwinąć w tej firmie. Twoje złe samopoczucie, brak pewności siebie i uczucie, że projekt Ciebie przerasta to nie najlepsze podstawy do satysfakcjonującej pracy.

0

Pomysl, co Ty mozesz zaproponowac firmie? Moze w koncu czas zmienic ten balagan w cos bardziej zrozumialego wlasnymi rekami...

0
id02009 napisał(a)

Musisz wiedzieć że zespół projektowy ma wiedzę rozproszoną po poszczególnych członkach. Dobry zespół to nie taki, gdzie każdy wie wszystko, ale taki który sprawnie wymienia się tymi informacjami. Więc za każdym razem kiedy zamiast grzebać w czymś 5h i dalej nie wiedzieć, pójdziesz i zorientowaną osobę zapytasz - cały team zyskuje.

zainteresowanym polecam zapoznac sie z terminem "bus number"

a co do tematu - ja rowniez pare razy juz mialem okazje stwierdzic ze poziom oryginalnych tworcow byl zatrwazajaco niski..

nie tylko w kodzie np. w jednym projekcie ktos nie lubil... tablic. tak wiec, np. analizujac pesel: char znak1=pesel[0]; char znak2=pesel[1]; .. char znak11=pesel[10]..)

ale i w ogolnej organizacji: projekt budowalo sie np tak:

  • kompilujesz xxx.sln - dostajesz dwie dllki
  • kompilujesz yyy.sln - dostajesz nastepne dllki
  • kopiujesz dllki do blah/libs, kompilujesz blah.sln - dostajesz .exe
  • kopiujesz dllki oraz exe do /export
  • odpalasz /export/fix.bat - poprawialo wersje,sciezki.. lepiej nie pytajcie
  • odpalasz /export/compress.bat - dostajesz zipa, aby...
  • kompilujesz /export/installer.sln - instalator mogl sobie go wrzucic do Resources..
    [btw: to wszystko dalo sie spokojnie zrobic w 1 solution, inteligentnie piszac pre/post/buildscripty..]

nie ma co sie zalamywac.. dopoki widzisz ze mozna cos zdzialac, wiosna idzie, naucz sie waznej rzeczy: smiej sie z "kodu" :) i jak masz wolna chwile, przerabiaj na lepszy - tak, zeby na zewnatrz nikt tego nie widzial - albo wybadaj komu z Twojego otoczenia mozna wjechac na ambicje i powiedz wyraznie i kategorycznie ze to-a-to jest tragiczne/niebezpieczne/zue/smierdzi/robi sie to inaczej/standardymowiazecostam.. po paru razach moze nastepnym razem ktos inny sie zastanowi, albo moze zaczna zwracac sobie sami na krzyz uwage na podobne wpadki..

tam, gdzie ja bylem - teamy zachowywaly sie w dwoch modelach:

  • wiekszosc byla pojetna i miala ambicje (jeszcze). tak wiec po (N tlumaczeniach) lapali o co chodzi i zaczynali stosowac i sami sie kontrolowac na wzajem. jednostki (t)oporne albo sie przelamywaly, albo je team "spolecznie" wypychal z siebie, bo mial wrazenie ze smieca w kodzie/dokumentach/etc
  • albo... caly team byl oporny (np. szef nie lubil jak ktos sie madrzy, albo w ogole metodyka pracy brzmiala: "to ma dzialac za 2 godziny. jakkolwiek. to Twoja sprawa.") -- wtedy zwykle ja "wylatywalem" (przypadek 'a':) ) albo pisalem takie jakkolwiek, ze malo kto by to potem zrozumial - i zmienialem za jakis czas projekt/prace (przypadek 'b')..

nie stresuj sie. postaw sobie jakis cel. przypomnij sobie stare swoje 'idee' i co Ciebie wciagalo. naucz sie znow 'bawic' kodem. sprobuj naprawic swiat. nie uda sie? no coz.. Babel tez nie wyszlo, sila wyzsza:) postawi sie nowa..

0

user image

0

Eeee...a ja od zawsze sądziłem że po to ktoś "wymyślił sobie" programowanie obiektowe żeby członek zespołu nie musiał znać całego wieeelkiego projektu żeby coś zaimplementować. Sądziłem że to miało usprawnić pracę a nie dołować pracowników.

Co do kwestii umiejętności i wiedzy. Cała branża techniczna, nie tylko inżynieria oprogramowania, ma taką wredną cechę że się szybko rozwija skubana, przez co zawsze znajdzie się coś czego nie wiemy. Taki przykład: jest sobie dwóch nieszczęsnych programistów którzy codziennie ciężko stukają w klawiatury żeby zarobić na kawałek chleba. Jeden w swojej firmie przez rok pisał załóżmy gierki na telefon, drugi powiedzmy jakieś edytory graficzne(przykłady nie mają większego znaczenia). Obydwaj pracują w jednym języku. I jak sądzisz, czy po roku ukierunkowanego pisania jeden może wytknąć drugiemu coś w stylu: "Hahaha jesteś słaby bo nawet painta nie napisaleś!!" ?? Jasne że nie. Jeżeli koleś od gierek usiadłby do zadania zrobienia cieniowania grafik (przykład bez większego znaczenia) to pewnie by sobie poradził. A to że musiał poszperać tu i ówdzie lub podpytać kogoś o coś to chyba najmniej istotne, ważne że masz ogólne pojęcie i wiesz pod co się podpiąć i jak się do czegoś zabrać. W sumie od człowieka zależy czy o szczegółach dowie się z google, od kolegi z zespołu z większym doświadczeniem czy od teściowej. Ja tam sądzę że kto pyta nie błądzi.

Podsumowując, więcej dystansu man...wyjdź na miasto z ludźmi i przypomnij sobie że radość życia nie bierze się tylko z programowania :P

0

@several: ten topic to stary kotlet, ale jeszcze nie śmierdzi bo ma tylko 3 mc (prawie 4).

0

Wiem, spojrzałem na datę. Ale jakaś wewnętrzna potrzeba zmusiła mnie do wrzucenia posta. Poza tym...kotlet jeszcze nie śmierdział więc stwierdziłem że nie zgrzeszę :P

1 użytkowników online, w tym zalogowanych: 0, gości: 1