Off-topic, mały flejm, a mało konkretnych odpowiedzi... standard :).
Część flejmową niniejszego posta mamy za sobą, teraz postaram się odpowiedzieć na te pytania. Nie jestem może dziadem, choć dla kogoś w szkole średniej mogę się nim wydawać. W każdym razie, obecnie jestem senior developerem w dużej korporacji, a we wcześniejszych pracach też byłem "seniorem", więc może i coś w tym jest.
mto9 napisał(a)
- Jak wygląda dzień programisty to znaczy czy robi coś więcej niż pisanie programów?;]
To się zmienia w zależności od firmy i aktualnego klimatu/projektu.
Np.
- Przychodzisz do roboty na 12:00, bo pracowałeś przez pół nocy z domu żeby wyrobić się z ukończeniem softu na poranną premierę.
- Pijesz energy-drinka.
- Gorączkowo kodujesz poprawiając bugi, przy czym ty jeden odpowiadasz za development tego (niewielkiego) projektu, więc nikt ci nie wchodzi w grę i wydajność jest spora.
- Robisz trochę kodu na pałę, który potem będziesz musiał ukradkiem zrefaktoryzować. Ukradkiem, bo nikt ci na to czasu nie przeznaczy.
- Zamawiasz pizzę.
- Spadasz z firmy jak tylko skończysz.
- Doliczasz sobie nadgodziny z dwukrotną stawką za tę pracę w nocy.
- Mówisz "nigdy więcej".
Nie polecam tego trybu, ale zdarza się -- szczególnie na początku.
Albo (tu już normalny czas pracy):
- Od rana kodujesz, dodając nową funkcjonalność na podstawie specyfikacji projektu.
- Mailujesz z Project Managerem (kolesiem, a często kobietą, która odpowiada za cały projekt i pośredniczy pomiędzy tobą a klientem; czasem jeszcze są Account Managerowie, czasem ich nie ma). Prosisz o uściślenie wymagań. Mówisz, że jeden z bugów, który zgłosił klient, to nie twoja działka, tylko programistów odpowiedzialnych za X.
- Poprawiasz jakieś bugi.
- Ukradkiem refaktoryzujesz trochę kodu, tj. poprawiasz jego jakość/czytelność bez zmiany jego działania -- dzięki temu w projekcie nie robi się totalny gnój.
- PM zaprasza Ciebie i jeszcze jakiegoś programistę od innego modułu na półgodzinną rozmowę, na której na podstawie mętnej specyfikacji szacujesz czasochłonność jakiegoś projektu. Coś ściemniasz, tłumaczysz, że ciężko to estymować, na wszelki wypadek mnożysz to co ci wyszło razy dwa. PM mówi, że "a czy nie dałoby się krócej?". Mówisz, że nie. PM nalega. Mówisz: OK, ale jaką funkcjonalność obcinamy? PM mówi, że żadną. Jak jesteś dobry, to nie ustąpisz. Jak nie masz siły lub jesteś słabszy, to pozwolisz im mieć złudzenia i totalnie bezsensownie podasz krótszy termin -- a potem się okaże, że ten pierwszy był mniej-więcej dobry.
- Kodujesz. Przyszedł mail od PM-a: nowe poprawki/zmiany. Część totalnie niespodziewanych, więc musisz przebudować to i owo.
- Tłumaczysz coś mniej doświadczonemu programiście.
Albo tak, trochę normalniej:
- Przychodzisz na 9, mniej-więcej.
- Na 13 Twój szef ma rozmowę kwalifikacyjną z kandydatem o pracę. Dzień wcześniej doszliście do wniosku, że te testy kwalifikacyjne, które dajecie kandydatom mają już 1.5 roku i są trochę przestarzałe. Parę technologii odeszło, parę doszło. Trzeba to update'ować. Zgadnij kto to będzie robił, starszy specjalisto?
- Wywalasz niepotrzebne zadania z testu.
- Myślisz nad paroma nowymi zadaniami. Dać trudniejsze, czy łatwiejsze?
- Uznajesz, że dasz łatwiejsze do zrobienia jako takiego, ale z możliwością wykazania się. Jeśli dla kilku kandydatów okażą się prościzną, to potem je podkręcisz.
- Sklecasz zadanie, prosisz kumpla żeby je rozwiązał.
- Widzisz, że poszedł w zupełnie inną stronę niż oczekiwałeś.
- Konsultujesz z kumplem jego tok rozumowania, myślisz na chybcika jak poprawić nieścisłości, pytasz go o radę.
- Poprawiasz zadanie.
- W międzyczasie czytasz zadanie chyba stukrotnie i piszesz jedno lub kilka możliwych rozwiązań: nie chcesz żeby w zadaniu był babol.
- Jeśli wciąż niewystarczająca liczba zadań, skocz do punktu 6.
- Masz wystarczającą liczbę zadań, już przez kogoś przetestowanych. Dajesz je wszystkie do rozwiązania drugiemu kumplowi.
- Wprowadzasz ewentualne poprawki.
- Idziesz z szefem na rozmowę kwalifikacyjną jako konsultant. Starasz się zminimalizować czynnik stresu u kandydata. Razem analizujecie test rozwiązany przez kandydata. Jeśli widzisz błąd, starasz się go naprowadzić na rozwiązania. Próbujesz wyciągnąć z kandydata jak najwięcej z tego, co potrafi -- to nie takie proste, bo test jest jednak trudny, a stres każdemu jakoś daje się we znaki.
- Po rozmowie przedstawiasz szefowi swoją rekomendację.
- O, już 17.
Zauważ, że w ten dzień nie zrobiłeś ani jednego "normalnego", koderskiego projektu ;). No, ew. skubnąłeś coś tu czy tam.
Inna możliwość:
- Spotkanie SCRUM-owe wraz z video-konferencją z innym miastem/krajem. Każdy mówi, co będzie robił w najbliższym czasie, omawiane są też bieżące sprawy.
- Pomagasz kumplowi z jakimś bugiem. Z miejsca strzelasz poprawne rozwiązanie problemu. To się zdarza: czasem opłaca się kogoś zapytać, gdy zbyt długo się nad czymś głowimy.
- Kodujesz trochę nowej funkcjonalności na podstawie nienajlepszej specyfikacji.
- Gadasz z kumplami, a potem z przełożonym o konieczności otrzymywania lepszych specyfikacji. Tym samym "zgłaszasz się na ochotnika" do napisania ankiety, którą musi wypełnić każdy właściciel projektu.
- Trochę kodujesz.
- Lunch. Spadacie do jakiejś restauracji.
- Siadasz z kumplem, z którym robisz projekt. Szukacie luk w specyfikacji, wszelkich nieścisłości. Przeglądacie projekt. Nie wiesz jak to działa albo jaki to ma sens? Zapisujesz pytanie do PM-a. Lista robi się ździebko długa, zajmuje to wszystko kilka godzin.
- Na podstawie rozmowy z kumplem i waszych "best guessów", tworzysz mockup (makietę) nowej wersji aplikacji dla PM-a i dla klienta żeby pokazać jak to Waszym zdaniem ma wyglądać.
- Robisz pół-formalną inspekcję kodu innemu programiście, używając odpowiedniego oprogramowania.
- Tłumaczysz innemu kumplowi przez telefon konwencje w nowym frameworku, bo Ty w nim robiłeś już jakiś projekt, a kumpel nie.
- Implementujesz "na poważnie" trochę funkcjonalności z makiety -- wybierasz te, które praktycznie na pewno znajdą się w projekcie.
- "Papierkowa robota", przy czym papier jest elektroniczny: w odpowiednim programie zapisujesz ile nad czym przepracowałeś godzin.
To są DNI PRACY. Odnośnie (nie)posiadania życia i integracji...
W poprzednim tygodniu byłem na browarze 3x, za czwartym zlamiłem i poszedłem, ale nie piłem, bo uznałem że chcę mieć jednak więcej dni niepijących niż pijących. Byłem też w kinie na jednym filmie, a także 2x na siłce (ciężko mi się ogarnąć z normalnym rytmem treningów, ale dobre i to). Wiadomo: są tylko dwie okazje żeby spotkać się z kumplami. Alkohol i sport.
W tym tygodniu na browarze byłem raz, z ziomami z pracy. Sztywno na pewno nie było, ani informatycznie. W piątek większa impreza ze znajomymi, a jutro może jakaś sesja w Starcrafta...
mto9 napisał(a)
- Ile ok. zarabia programista?
W umowach niestety często piszą, że nie wolno podawać nikomu swoich zarobków.
Bywa różnie.
Na studiach możesz spokojnie mieć 3k netto jeśli jesteś dobry (jak nie -- 1.500). Parę lat potem możesz dołożyć do tego 30%, a możesz i 100%. Mówię tu o mojej -- niezbyt dochodowej -- branży webowej. Pracując na kontrakcie w takim SAP-ie to się już dostaje przelewy w dziesiątkach tysięcy zł, ale nie wiem czy kodowanie w SAP-ie jest tego warte ;).
Tu naprawdę dużo zależy od umiejętności. Rozstrzał jest bardzo duży.
mto9 napisał(a)
- Co zrobić, aby nie wylądować jako nauczyciel w szkole średniej ucząc psio tylko pracować w jakieś dobrej firmie?
Skoncentrować się na tym, żeby być coraz lepszym. Nie "sumiennym". Nie chodzi też o to, by narzekać, że "w szkole niczego praktycznego nie uczą". NIKOGO to nie obchodzi. Zdobycie umiejętności to TWOJA odpowiedzialność. Dobra uczelnia daje zwykle dobre impulsy i okazje, ale szkolić się trzeba samemu. A jak uczelnia nie daje nawet tego, to... zróbże coś, żebyś sam sobie dał radę.
Ja lubię czytać dobre książki branżowe (beletrystykę też, ale mniejsza o to). Kupiłem sobie i przeczytałem już kilkadziesiąt.
Trzeba dbać o swój poziom i rozumieć wagę samopolepszania się. Jeśli zrozumiesz, że musisz praktycznie CIĄGLE się doszkalać i polepszać i że to TWOJA odpowiedzialność, a nie czyjaś inna, to sobie poradzisz. I znajdziesz sposoby.
Praca w dobrej firmie może pomóc. W "dniu z życia programisty" wspomniałem o inspekcjach kodu. To mega dobry sposób na doszkolenie się -- gdy ktoś ocenia Twój kod i daje swoje sugestie. Raz, że nikt nie zna wszystkich sztuczek i na inspekcji ktoś może ci jakąś fajną podsunąć. Dwa: wiedząc, że ktoś zrobi ci inspekcję, po prostu bardziej się starasz.
Praca w złej firmie może niestety przeszkodzić. Możesz stracić wiarę w to, że może być się złych praktyk itp.