Początki pracy programisty

Odpowiedz Nowy wątek
2011-08-22 22:48
troche_zestresowany
0

Hej!!

Niedawno zacząłem moją pierwszą pracę (staż) w dziedzinie programowania. Bardzo szybko doszedłem do wniosku, że to czego uczą na studiach stanowi jakieś 10% wiedzy, która w prawdziwej robocie jest raptem wiedzą podstawową. Codziennie idąc do biura zastanawiam się, czy dam radę, bo wymagania są dość spore. Boję się, że mnie wywalą jeśli nie będę łapał wszystkiego od razu. Czasem nawet nie wiem czy wypada kolejny raz pytać o coś bardziej doświadczonych ludzi w biurze czy może lepiej nie, bo odnotują sobie gdzieś , że pytam o głupoty. Stres jest tym większy, że uświadamiam sobie, że jeśli się poddam, to będę nikim na rynku pracy :/ Poza tym 8 godzin pracy w biurze i później jakieś 5 w domu (żeby ogarnąć w miarę to co robiłem w robocie) powoduje, że powoli mam dosyć.

Wiem, że może wyolbrzymiam mój problem, ale powiedzcie, czy na początku też mieliście takie dylematy? Czy z czasem to przechodzi :D ? Mam 23 lata.

Pozostało 580 znaków

2011-08-23 00:29
0

Takie uczucie niewiedzy, nieporadności towarzyszy wielu programistom w pierwszej pracy, a czasem także w kolejnej pracy w nowej firmie jeżeli ta praca wiąże się z używaniem nieznanej, nieopanowanej wcześniej technologii lub sposobu pracy. W każdej firmie koledzy i przełożeni reagują na to inaczej.

W mniejszej firmie poprzeczka jest często postawiona bardzo wysoko. Trafiamy do małego zespołu, gdzie pytając o proste rzeczy wychodzimy na ofermę, zadawanie pytań nie jest mile widziane, przełożeni i współpracownicy, którzy pracują z kodem od początku jego powstania oceniają to jako niekompetencję. Dodatkowo projekt w małej firmie jest bardzo często prowadzony po partyzancku, bez dokumentacji, bez planu, bez project managera, z często zmieniającymi się założeniami. Przełożeni wymagają od członków zespołu szybkich postępów w opanowaniu technologii i wdrożeniu się w zespół oraz dużej własnej inicjatywy, a to dlatego, że w małej firmie sukces zależy od każdego członka zespołu. Przełożeni często nie mają doświadczenia w prowadzeniu firmy, czy kierowaniu zespołem, krytycznie oceniają nasz sposób pracy jeżeli odbiega on od sposobu pracy innych członków zespołu, który już znają. Osoby pracujące już od jakiegoś czasu w małej firmie bardzo często są nastawione do swojej pracy bezkrytycznie, pomimo pracy w niezgodzie ze standardami i dobrymi praktykami. Surowo oceniają 'świeżaka', który myśli i pracuje inaczej. Wynika to z faktu, że te osoby nie miały jeszcze okazji pracować w innych firmach gdzie stosuje się inne sposoby pracy, inne narzędzia, technologie czy kryteria oceny pracownika.

W większych firmach tolerancja na tą początkową nieporadność jest znacznie większa. Nie ma tak dużej presji na natychmiastowe postępy, ponieważ wynik pracy zespołu i firmy jest rozłożony na wiele osób. Nikt nie patrzy na nas dziwnie gdy po raz kolejny zadajemy z pozoru głupie pytanie o proste rzeczy, mamy z reguły więcej czasu na wdrożenie się w zespół niż w małej firmie. Ze względu na większą rotację pracowników nie jesteśmy jedyną osobą, która zaczyna pracę i zadaje pytania, a przełożeni i współpracownicy z większym zrozumieniem podchodzą do tego, że nowy musi się wdrożyć. Ocena naszej pracy jest znacznie bardziej obiektywna i wyważona, w końcu jesteśmy oceniani przez managera z wieloletnim doświadczeniem, który miał okazję współpracować z wieloma osobami.

Cytaty pracowników małych firm z którymi miałem okazję współpracować: "Programowanie obiektowe się do niczego nie nadaje, lepsze jest programowanie proceduralne, które jest prostsze i bardziej zrozumiałe. Współczuje programistom Javy.", "Lepiej napisać wszystko od zera, niż korzystać z gotowego kodu, ponieważ nie wiemy co znajduje się w środku, a mi się nie chce czytać dokumentacji do tego.", "Debugger jest dla osób, które nie rozumieją co dzieje się w kodzie, ja mam debugger w głowie.", "Dokumentacja wymaga dodatkowego nakładu pracy i w niczym nie pomaga, ja ogarniam cały projekt, więc po co ją pisać?", "Dobry programista używa ORM zamiast SQL, ponieważ jak się napisze złe zapytanie w SQL to działa wolno, a poza tym trzeba się uczyć nowego języka, lepiej być specjalistą w jednym."

edytowany 3x, ostatnio: AdamPL, 2011-08-23 00:39
Tymi cytatami mnie przeraziłeś... o_O Jak się przyfarci to zweryfikuje na własnej skórze jak to wygląda ;) - byku_guzio 2011-08-23 03:02
Czytając takie rzeczy mam obawę czy ktoś mnie przyjmie do małej firmy... nie z powodu niewiedzy, ale odmiennego "spojrzenia" na świat, szczególnie inż uważam debugger za coś co dał nam Bóg ;p - lukas_gab 2011-08-23 09:55

Pozostało 580 znaków

2011-08-23 00:30
0

dobrze że pytasz - lepiej żebyś pytał nawet o głupoty niż miałbyś samemu jeszcze większe głupoty generować, przy okazji korzystając z wiedzy innych szybciej się uczysz (znaczy i tak będziesz musiał sam zrozumieć, ale przynajmniej Cie naprowadzą).

Pozostało 580 znaków

2011-08-23 00:37
1
  1. Jeśli na studiach nie wykroczyłeś poza program nauczania i sam nie opanowałeś chociaż w stopniu średnio-zaawansowanym chociaż jednej technologii, to niestety, ale będziesz musiał spędzić następne kilka lat w książkach nadrabiając swoje braki. Studia są kierowane do "ogółu" -tj. administratorów, programistów, architektów, PM'ów, grafików, więc tematy na nich poruszane to najczęściej zalążek tego co powinieneś umieć. Specjalizacje wybiera się dość późni i na ostatnich latach studiów, kiedy to masz już podejście "oby to skończyć i mieć spokój". Po to na studiach masz stosunkowo mało godzin spędzanych na uczelni aby w między czasie zacząć pracować samodzielnie (edukacja w interesującej Cię technologii, jakaś praca, staż). Nie ma nic gorszego niż studiowanie bez jakiejkolwiek analizy rynku pracy i chociaż 15minutowego przemyślenia co po zakończeniu edukacji.

To tak woli gorzkiego wstępu. Jeśli chodzi o Twoją obecną sytuacje:

  1. Staraj się jak najszybciej nadrabiać braki, tylko nie ucz się wszystkiego na raz. Lepiej być w 1 rzeczy niezłym niż w liznąć po trochu 10. Jeśli np. robisz strony www to ogarnij sobie html + css. Wtedy staniesz się w jakikolwiek sposób przydatny. Jeśli liźniesz html, css, php, asp ale efekt twojej pracy będzie we wszystkim mizerny, to żadnego pożytku firma z Ciebie nie będzie miała.
  2. Jesteś na stażu, więc masz prawo (ba - nawet obowiązek) zadawać pytania. Im więcej - tym lepiej. Nikt nie będzie notował że czegoś nie umiałeś. Zapamiętają za to fakt że się starasz i się tym interesujesz. Jeśli czegoś nie wiesz - pytaj wprost - bez kręcenia że nagle zapomniałeś, albo kiedyś w tym coś robileś. Jeśli dostajesz zadania do samodzielnej realizacji to w przypadku wątpliwości spisz sobie wszystkie pytania jakie masz. Jeśli będziesz przybiegał co 5min i przerywał komuś prace to po tygodniu będzie miał Ciebie dosyć. Jeśli natomiast 2 razy w ciągu dnia przyjdziesz do niego z 5 pytaniami to myślę że w ramach "przerwy na kawę" bardzo chętnie Ci to wytłumaczy.
  3. W żadnym wypadku nie udawaj że znasz się na czymś jeśli nie masz o tym zielonego pojęcia. Nie ma nic gorszego niż praktykant, który naopowiada bajek jak to super ogarnia, dostanie jakieś proste zadanie do zrobienia a po tygodniu okazuje się że ledwo je trącił i cały zespół musi to w piątek nadrabiać.
  4. Staraj się używać google/przynosić książki/notatki do pracy. Na dobrą sprawę na google powinieneś znaleźć większość rzeczy których potrzebujesz (kursy, ksiązki na Google Books), więc staraj z tego korzystać w pierwszej kolejności. Z całą pewnością pytanie: "Jak odczytać dane binarne z gniazda" będzie znacznie lepsze od klepnięcia: "A jak zrobić żeby tutaj wysłać obrazek". Staraj się unikać pytań, na które znalezienie odpowiedzi na google zajmuje mniej niż 3 minuty.

Oczywiście rady te mają jakiekolwiek zastosowanie tylko w przypadku gdy chociaż trochę ogarniasz temat. Jeśli całkowicie nie czujesz się na siłach to radziłbym CI zrezygnować z IT, papierek ładnie oprawić i szukać innego zawodu.

Pozostało 580 znaków

2011-08-23 09:15
0

To jest wszystko kwestia firmy jak to już @AdamPL napisał. Miałem okazję pracować w bardzo dużej firmie z sektora IT i tam od samego początku wszystkim nowym pracownikom powtarzali że "Masz prawo czegoś nie wiedzieć albo nie umieć, ale nie masz prawa się do tego nie przyznać". Jeśli czegoś nie wiedziałeś to należało iść i spytać kogoś kto wie. Rozkminiając to samemu zmarnowałbyś X godzin, a kolega mógłby ci to samo wyjaśnić w 10 minut, więc z punktu widzenia firmy znacznie bardziej opłacało się zachęcać pracowników do pytania :)
Poza tym to inaczej wygląda w przypadku projektów które ciągną się od kilku lat i są gigantycznych rozmiarów. W takich projektach nawet ludzie pracujący długo mogą nie wszystko wiedzieć i pytanie o coś jest na porządku dziennym.

Pozostało 580 znaków

2011-08-23 09:49
1
  1. "Programowanie obiektowe się do niczego nie nadaje, lepsze jest programowanie proceduralne, które jest prostsze i bardziej zrozumiałe. Współczuje programistom Javy.",
  2. "Lepiej napisać wszystko od zera, niż korzystać z gotowego kodu, ponieważ nie wiemy co znajduje się w środku, a mi się nie chce czytać dokumentacji do tego.",
  3. "Debugger jest dla osób, które nie rozumieją co dzieje się w kodzie, ja mam debugger w głowie."
  4. Dokumentacja wymaga dodatkowego nakładu pracy i w niczym nie pomaga, ja ogarniam cały projekt, więc po co ją pisać

Akurat te cytaty nie są aż takie głupie, chociażby być może niezbyt zgodne ze współczesnymi trendami.

  1. Jeżeli chodzi o programowanie obiektowe to w przypadku niskiego poziomu średnio tam obiektowość pasuje i właśnie low levelowcy często mają takie opinie.
  2. Jeżeli masz odpowiednią ilość czasu to pisanie od zera jest całkiem dobrym podejściem. Jak piszesz od podstaw to możesz dostosować kod do konkretnych wymagań, do tego biblioteki zewnętrzne bardzo często mają bugi. Jak wyjdzie taki bug to tak na prawdę zostajesz sam, ewentualnie możesz liczyć, że twórca bibliteki go poprawi (co najprędzej się stanie pewnie za kilka miesięcy o ile w ogóle).
  3. Generalnie w Javie debugger jest średnio potrzebny, znam ludzi którzy sobie spokojnie radzą bez debuggera. W C++ to raczej konieczność. Chociaż Stallman twierdzi, że nawet w kernelu nie potrzebuje debuggera ;)
  4. Jak kod często się zmienia (co w przypadku startupów jest normą) to faktycznie nie ma sensu ciągle pisać dokumentacji, zwłaszcza że dobrą dokumentacje trudniej napisać niż dobry kod. A szef najczęściej ocenia z funkcjonalności jakie dodałeś, a nie czy napisałeś ładną dokumentację.
edytowany 2x, ostatnio: 0x200x20, 2011-08-23 09:56
Dlatego go jeszcze nie wydali ;p - lukas_gab 2011-08-23 09:56
Nie wiem co twoja mówić - 0x200x20 2011-08-23 10:31
Mówić o tym jak wyglądać obecny hurd ;p - lukas_gab 2011-08-23 13:48

Pozostało 580 znaków

2011-08-23 11:06
0

W mojej firmie była pełna wyrozumiałość, "nie śpiesz się", "nie ma co się denerwować" itp. Fakt, że lepiej, żebym pytała członków mojego zespołu (który akurat jest niewielki i rozproszony po oddziałach w różnych miastach) niż z innej ekipy. Po prostu każdy jest zajęty swoim zadaniem i nie ma czasu dla świeżaka. Ale każdy nowo przychodzący do pracy dostaje swojego "opiekuna", do którego powinien zgłaszać się z problemami. Zostało mi wręcz powiedziane, że dokształcanie się to część mojej pracy, w związku z czym np. na ogarnięcie hibernate'a dostałam normalnie zadanie w project managerze.

Aby uniknąć pytania zbyt często - google, google i jeszcze raz google. Podstawowe narzędzie pracy. Możesz też zapytać na forum :)

Pozostało 580 znaków

2011-08-24 16:43
0

Firma w której ja pracuje jest małą firmą. Problemem jest fakt, że pisze różne rzeczy w różnych językach. Często jest tak, że współpracownicy zajmują się czymś innym i nie wiedzą jak mi pomóc a często też nie mają czasu. Dla tego wiele rzeczy muszę robić sam. Jak czegoś nie wiem, a nikt nie wie wszystkiego, to szukam po forach, kombinuje innymi sposobami. Grunt by się nie stresować i zachować zimną krew. Wiem z doświadczenia, że jak coś nie wychodzi można się zestresować i próbować coś zrobić na siłę. To nie jest dobre rozwiązanie. Jak jest możliwość lepiej sie przewietrzyć, odpocząć.

Jako, że jesteś starzystą masz prawo nie wiedzieć wielu rzeczy. Staż powinien pozwolić Ci rozwinąć swoje umiejętności. Jednakże tak na prawde wiele zależy od pracodawcy i ludzi z którymi pracujesz. Nastawienie innych pracowników czasem może zniechęcić do zadawania pytań. Ale lepiej czasem tak niż siedzieć tydzień nad prostą rzeczą.

Pozostało 580 znaków

2011-08-24 19:49
wpisałem nick
0

Miałem dokładnie tak samo jak opisałeś w pierwszym poście (pierwsza praca w wieku 23 lat, sporo pytań, stres, doczytywanie w domu często do 3 rano - pobudka o 7). Najpierw zawsze google'aj, przeglądaj jak najwięcej kodu w projekcie, nawet ten poboczny. Rozkminiaj jak to wszystko działa. Dopiero, gdy nie znajdziesz odpowiedzi na swoje pytanie w google'u i nie potrafisz czegoś rozkminić albo po prostu uważasz, że potrafisz, tylko nie w sensownym czasie, to dopiero pytaj. Z czasem pytań będzie mniej - u mnie najgorsze były pierwsze 3 miesiące. Po takim czasie zacząłem stopniowo przerzucać odpowiedzialność za kod na siebie (wcześniej mówiłem koledze z projektu jak coś rozwiązałem i przed commitem pytałem, czy nic się nie zjebie żeby mieć psychiczną podpórkę, że zaakceptował :-) ). Oczywiście rób sobie ze wszystkiego notatki - dopiero w pracy doceniłem moc kartki i długopisu. Zapisywałem sobie wszystko: jak co działa, jakieś schematy, komendy systemowe, skróty klawiszowe w IDE (bardzo ważna rzecz, która mocno przyspiesza pracę, na początku ciężko się ich używa, bo ciężko zapamiętać, ale później się nakurwia jak szatan), instrukcje jak coś skonfigurować, itp. Dzięki notatkom nie będziesz pytał dwa razy o to samo.

Najgorsze co możesz zrobić, to rezygnacja. Ja sobie postanowiłem, że jak mnie nie wywalą, to nie zrezygnuję, choćbym czuł się jak ostatni kretyn i nie potrafił robić prostych rzeczy. Często czułem się jak debil, ale dostałem bardzo dobrą opinię na swój temat na końcu okresu próbnego. Wniosek taki, że człowiek często wkręca sobie do głowy, że jest za słaby, gdy nie jest to prawdą.

Powodzenia.

Pozostało 580 znaków

2011-08-24 20:15
0

Dokładnie. To, że czegoś nie wiesz nie znaczy też, że Cie zwolnią...

Pozostało 580 znaków

2011-08-24 22:45
0

Bardzo szybko doszedłem do wniosku, że to czego uczą na studiach stanowi jakieś 10% wiedzy, która w prawdziwej robocie jest raptem wiedzą podstawową.
Niestety, w tej dziedzinie przewagę mają nerdy, haxx0ry i inne nołlajfy, które po szkole czy pracy idą do domu, siadają do kompa i ślęczą do trzeciej w nocy.

To NIE JEST zawód, w którym odbębniasz 8 godzin po czym czym zapominasz o robocie i cieszysz się normalnym, spolecznym życiem. Przynajmniej nie na początku ;-)

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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