Początki pracy programisty

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.

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

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ą).

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:
2. 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.
3. 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.
4. 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ć.
5. 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.

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.

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ę.
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 :)

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

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.

0

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

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 ;-)

0
AdamPL napisał(a)

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

No to bardzo ciekawi ludzie. Ja na szczęście aż takich heretyków jeszcze nie spotkałem. Jesteś pewien, że to od wielkości firmy zależy? Może w dużych też tacy siedzą, tylko nikt ich na zewnątrz nie wypuszcza?

troche_zestresowany napisał(a)

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

Nie wyobrażam sobie douczania się po godzinach pracy. To jest po pierwsze okradanie samego siebie, a po drugie przemęczanie swojego organizmu. A organizm przemęczony jest mniej efektywny następnego dnia.

Jeśli w pracy dostaję jakieś zadanie, to robię je w pracy. Jeśli wymaga to doczytania dokumentacji, książki czy znalezienia rozwiązania na forum, to robię to w pracy. Jeśli z nudów poczytam coś potrzebnego do pracy w domu, to następnego dnia posiedzę w pracy krócej. Jeśli coś mnie zmęczyło, to to zostawiam i biorę się za coś innego, wrócę do zadania później. Problemy rozwiązuje się pod wpływem natchnienia, a nie siedząc przy nich n godzin.

Różne problemy na początku pracy to normalna sprawa, ale po to jest okres próbny, żeby się douczyć i po to są koledzy z pracy, żeby w razie czego pomogli. Słaba musi być firma, w której dają świeżakom krytyczne zadania, i w której pracownicy sobie wzajemnie nie pomagają. Nie chciałbym w takiej pracować.

0

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

Śmiem się nie zgodzić.
Może zależy to od firmy, ale raczej od tego, jaki masz stosunek do samego siebie. Mi płacą od godziny, dlatego nie spędzam nad zadaniami z pracy godzin, za które mi nie zapłacą. Dokształcanie się jest w cenie tych godzin. Nie biorę pracy do domu (mam tam drugą pracę, i współpracownicy by się obrazili).

To nie jest zawód, w którym odbębniasz 8 godzin. To jest zawód, w którym jak masz dobry dzień, wenę i nastrój, to siedzisz i kodzisz do upadłego, do nocy, do rozwiązania problemu i jest ci z tym dobrze, a jak ci się nie chce, jak ci nie idzie albo lenia masz, to wpadasz do biura na 3 godzinki po czym mówisz, że dzisiaj chciałbyś wyjść wcześniej.

0

Hmmm to tak na prawdę zależy od samego programisty. Niektórzy, zwłaszcza na początku boją się, że stracą pracę, że się nie sprawdzą. Czują, że mają braki i starają się je uzupełniać. Inni po prostu mają inne podejście. Zdrowsze mi się wydaje podejście aurel'a. Ja to co musze zrobić robię w pracy. Nikt mnie nie goni. Czasem jak nie mam weny to nie moge wpaść na rozwiązanie przez 2-3 dni. Staram się nie myśleć o tym. Wena przychodzi w najmniej oczekiwanym momencie. Jak wpadne na pomysł w domu to nie rzucam wszystkiego i nie koduje tylko robie to następnego dnia w pracy. Jak widzisz na siłę, że nie przychodzi rozwiązanie to odpocznij, zajmij sie czymś innym, przewietrz się. Odpoczynek umysłowy wpływa pozytywnie na logiczne myślenie. W domu staram się nie robić tego co muszę zrobić w pracy. Oczywiście czasem się zdarzają sytuacje nieprzewidziane no trzeba się z nimi uporać. Ale oczywiście można się rozwijać w domu. Ja to robię na zasadzie tego co lubię. Piszę sobie jakąś gierkę czy coś innego. Coś co sprawia mi przyjemność. Dodatkowo piszę tutoriale - to też dobra metoda by pogłębić swoją wiedzę a przy okazji zrobić coś co pomoże innym.

0

Nie wyobrażam sobie douczania się po godzinach pracy. To jest po pierwsze okradanie samego siebie, a po drugie przemęczanie swojego organizmu. A organizm przemęczony jest mniej efektywny następnego dnia.

Ja się tam często douczam po pracy w ramach hobby. Tak się "jakoś" złożyło, że to co robię w pracy i moje hobby mają sporo punktów wspólnych :]

0

Hej

Dzięki za odpowiedzi ;) Nie ukrywam, że trochę zazdroszczę podejścia zgodnie z którym staracie się wszystko robić w pracy i nie przynosić pracy do domu :P Mnie się to jak na razie nie udaje. Może jestem zbyt ambitny i jeśli się za coś biorę to najchętniej przeczytałbym całą dokumentację z tym związaną. A może po prostu za bardzo się stresuję jeśli coś nie idzie mi w pracy i dopiero w domu na spokojnie jestem w stanie rozkminić co i jak (chyba to też jest spory problem w tej branży, nie?). Generalnie lubię się uczyć nowych rzeczy i robienie czegoś jeśli dobrze to rozumiem i w miarę mi to wychodzi przynosi mi satysfakcję. Nie jestem jednak chyba aż takim pasjonatem, który siedziałby po 13 godzin dziennie przy kompie, kładł się spać i szedł znów do biura. A to może w tej branży nie wróży zbyt dobrze. O właśnie... Powiedzcie mi proszę, czy w branży programistycznej da się według Was nie być pasjonatem tylko po prostu ... hmmm... dobrym rzemieślnikiem, który lubi to co robi? :)

0

Hej

Dzięki za odpowiedzi ;) Nie ukrywam, że trochę zazdroszczę podejścia zgodnie z którym staracie się wszystko robić w pracy i nie przynosić pracy do domu :P Mnie się to jak na razie nie udaje. Może jestem zbyt ambitny i jeśli się za coś biorę to najchętniej przeczytałbym całą dokumentację z tym związaną. A może po prostu za bardzo się stresuję jeśli coś nie idzie mi w pracy i dopiero w domu na spokojnie jestem w stanie rozkminić co i jak (chyba to też jest spory problem w tej branży, nie?). Generalnie lubię się uczyć nowych rzeczy i robienie czegoś jeśli dobrze to rozumiem i w miarę mi to wychodzi przynosi mi satysfakcję. Nie jestem jednak chyba aż takim pasjonatem, który siedziałby po 13 godzin dziennie przy kompie, kładł się spać i szedł znów do biura. A to może w tej branży nie wróży zbyt dobrze. O właśnie... Powiedzcie mi proszę, czy w branży programistycznej da się według Was nie być pasjonatem tylko po prostu ... hmmm... dobrym rzemieślnikiem, który lubi to co robi? :)

0
troche_zestresowany napisał(a)

O właśnie... Powiedzcie mi proszę, czy w branży programistycznej da się według Was nie być pasjonatem tylko po prostu ... hmmm... dobrym rzemieślnikiem, który lubi to co robi? :)

W sensie odbębnić swoje i iść do domu? Pewnie, że można. Jednak nie lubię tego określenia. Dla mnie rzemieślnik w tym sensie, to ktoś kto jest programistą tylko dlatego, że usłyszał, że można dobrze zarobić. Jednak nie jest pasjonatem w swojej branży. W każdym zawodzie potrzebne jest jakieś "pojebanie" na punkcie tego, co się robi (nie ważne czy jesteś programistą czy hodowcą bydła) - wtedy dużo rzeczy przychodzi łatwiej i przyjemniej. Jednym słowem - dobry pracownik, to taki który przykłada się solidnie do swojej pracy, ponieważ chce być coraz lepszym w tym co robi (szczególnie w tej branży, gdzie każdy dzień przynosi coś całkiem nowego).
Jednak wychodzę z założenia, patrząc na ludzi, których spotkałem i spotykam w życiu, że Ci którzy widzą w tej branży tylko jeden cel - kasę - szybko odpadają, ponieważ wymagania ich przewyższają. Pewnie, są tacy, co robią wszystko do końca bo "muszą", ale, co to za praca, która nie daje żadnej wewnętrznej satysfakcji?:) Osoba bez pasji w tym, co robi nigdy nie będzie ideałem w swojej dziedzinie.
Jestem jeszcze młody, myślę, że starsi koledzy, pracujący w tej branży długie lata mogą to bardziej precyzyjnie przedstawić. :)

0

Może jestem zbyt ambitny i jeśli się za coś biorę to najchętniej przeczytałbym całą dokumentację z tym związaną. A może po prostu za bardzo się stresuję jeśli coś nie idzie mi w pracy i dopiero w domu na spokojnie jestem w stanie rozkminić co i jak (chyba to też jest spory problem w tej branży, nie?).

A czym tu się stresować...? Może masz kiepskie stanowisko pracy, skoro przy nim nie możesz rozkminiać? Mi wystarczy kubek kawy, słuchawki na uszy, roxy rewind i jechane ;)

Powiedzcie mi proszę, czy w branży programistycznej da się według Was nie być pasjonatem tylko po prostu ... hmmm... dobrym rzemieślnikiem, który lubi to co robi?

Pasjonat nie koniecznie musi oznaczać no-life'a. Żaden pracodawca nie ma prawa od ciebie wymagać, żebyś poświęcał dla niego swoje prywatne życie. Przecież ktoś musi obiadek ugotować, koty nakarmić, mężczyźnie odrobinę uwagi poświęcić...
Można być pasjonatem i wciąż nie przynosić pracy do domu. W domu to ja mogę dla siebie coś na kompie porobić. Hobbystycznie. Albo za dodatkową kasę.

0

Można być pasjonatem i wciąż nie przynosić pracy do domu. W domu to ja mogę dla siebie coś na kompie porobić. Hobbystycznie. Albo za dodatkową kasę.

I to jest zdrowe podejście. Zmuszanie się do pracy po godzinach może doprowadzić do tego, że się ją znienawidzi...

0

No tak, niby macie rację, ale ja tak nieśmiało zgaduję, że jednak programowanie jest Waszą pasją, którą traktujecie jako coś więcej niż tylko pracę którą po prostu lubicie. Ja natomiast lubię programowanie, generalnie podoba mi się to co robimy na stażu (no może prócz presji czasu - to mnie wykańcza), ale nie ukrywam, że gdybym wygrał w totka, zająłbym się czymś innym (nawet wiem czym konkretnie :) ). Wy natomiast - tak sądzę - nie rzucilibyście programowania i pracowalibyście dalej w tej branży (może z mniejszym zaangażowaniem, ale jednak). Prawda? :) Jestem bardziej rzemieślnikiem niż pasjonatem... i boję się, że to może bardzo przeszkadzać. Co Wy na to?

0

Ja jestem bardziej fizykiem niż programistą ale robie to co robie bo większa kasa. Najlepszym rozwiązaniem było by dla mnie pisanie aplikacji pod zastowania naukowe. No ale nie ma lekko i teraz pisze benchmarki testujące w pracy...

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