Jak wygląda system pracy programisty?

0

Ile czasu poświęcacie na rzeczywiste pisanie kodu a ile na doczytywanie dokumentacji, douczanie się, biurokrację biurową inne sprawy nie związane z tworzeniem rzeczywistego kodu (np. czytanie/udzielanie się na tym forum również itp).

Najbardziej interesuje mnie to w przypadku programistów .NET ale prawdopodobnie na innych platformach te proporcje wyglądają podobnie.

Pytam bo nie mam wśród znajomych żadnych programistów którzy pracowaliby w typowej firmie produkującej oprogramowanie.

Jak to u Was wygląda w pracy?

0

Zalezy od sytuacji, czasami zapieprzam caly dzien jak jest duzo roboty i nie ma nawet czasu przeczytac wiadomosci, a czasami caly dzien nie robie nic, co mialo by zwiazek z programowaniem.

0

Dużo czasu marnuje się też na sytuacje typu „przepinamy serwer” — w wyniku czego przez trzy dni nic nie działa.

0

Najbardziej interesuje mnie stosunek pisanie kodu do douczania się, doczytywania dokumentacji.

Chodzi o to, że nie mam wyobrażenia ile taki programista faktycznie już umie zaczynając pracę a ile się jeszcze doucza w pracy, co teoretycznie wydaje się być normalnie akceptowalne przez przełożonych ponieważ to taka dziedzina (wiecznie żywa, zmieniająca się).

9
Azarien napisał(a)

Dużo czasu marnuje się też na sytuacje typu „przepinamy serwer” — w wyniku czego przez trzy dni nic nie działa.

Pracujesz na forum 4programmers?

1
Varran napisał(a)

Najbardziej interesuje mnie stosunek pisanie kodu do douczania się, doczytywania dokumentacji.

Chodzi o to, że nie mam wyobrażenia ile taki programista faktycznie już umie zaczynając pracę a ile się jeszcze doucza w pracy, co teoretycznie wydaje się być normalnie akceptowalne przez przełożonych ponieważ to taka dziedzina (wiecznie żywa, zmieniająca się).

U mnie to wszystko wpada w development. Czasem trzeba pomyśleć nad rozwiązaniem ułożyć sobie wszystko, doczytać dokumentację, przypomnieć sobie jakiś niuans. Na koniec trzeba jeszcze przetestować swój kod. Możliwe, że w ramach zadania które zajęło 4h, realnego pisania kodu było 0.5h. Jednakże nikt nie pyta ile pisałeś kod, tylko patrzy ile czasu Ci zajęło zadanie całościowo.

1
Varran napisał(a)

Najbardziej interesuje mnie stosunek pisanie kodu do douczania się, doczytywania dokumentacji.

Dam Ci genialny przykład z mojej pracy zawodowej:

  1. projekt obecny - czas robienia całości: 5 dni roboczych (+ nadgodziny). czas nauki (w tym czytanie dokumentacji, nauka na błędach, omijanie braków dokumentacji, wymiana informacji między nami a firmą dającą sdk) 4 dni robocze (+ nadgodziny). faktyczny czas pracy: 6 godzin.

  2. projekt poprzedni - 3h nauki, 6 dni kodowania

  3. "poważny projekt biznesowy" - na kazde 1h porządnej pracy przypada: 10m nauki/szukania info, 1h kompletnego opieprzania się podczas czekania na decyzje z góry, 30m oglądania seriali. ogólnie średnia: 1h pracy, 10m nauki, 1h30m nicości. i tak przez 3 lata (joke, na serio to ok 3 mies, ale ciągnie się strasznie)

a i tak przy okazji: nigdy nie wiesz na co trafisz, ale zawsze będzie trzeba się coś douczyc, przypomnieć itp, bo po prostu nie da rady z palca cały projekt zrobić. szczegóolnie jeśli masz cały zespół do współpracy i trzeba jakieś standardy ustalić.

2

Jeśli napisałem np 180 KB kodu (wliczając poprawki), a pisanie idzie mi z szybkością 100 znaków na minutę (zaniżone) to napisanie tego w sumie zabrało 1800 minut, czyli 30 godzin. Jeżeli siedziałem nad tym kodem 2 m-ce, czyli 45 dni po 8 godzin = 360 godzin, to wychodzi na to, że pisanie kodu zabiera mi 8.3 % czasu.

Oczywiście wszystkie szacunki nie mają odniesienia do rzeczywistości :P

1

Samo kodowanie zajmuje mi bardzo mało czasu, skłaniałbym się do tych Wibowitowych 8% całego czasu w pracy.
Reszta to:

  • wymyślanie "jak to napisać"
  • czytanie cudzego kodu, żeby rozczaić o co chodzi
  • czytanie blogów, wyszukiwanie rozwiązań znanych problemów w Google
  • testowanie kodu (mamy osobną ekipę od testów i QA, ale wiadomo, że dla nich dostarcza się działający kod)
  • zarządzanie ticketami / taskami
  • przeglądy cudzego kodu w celu kontroli jakości
  • gadanie na czacie z ludźmi z firmy
  • telekonferencje
  • inne (przerwy, sprawdzanie poczty, czytanie newsów itp.)
0

Czyli nie jest tak tragicznie jak mi się zaczęło to rysować po lekturze pierwszej części książki "Agile Programowanie zwinne" R.C. Martin i M. Martin. Książka ogólnie chwalona, ale część pierwsza "wytwarzanie zwinne" - gdzie mam wrażenie - autor opisuje tworzenie oprogramowania wręcz na tempo, to dla mnie trochę abstrakcja. Zawsze miałem wrażenie że praca twórcza, konstruktor, inżynier, programista itp. ma na celu przede wszystkim coś osiągnąć, coś stworzyć a czas tego tworzenia jest trochę na drugim miejscu. A tu autor opisuje praktyki programowania ekstremalnego, programowanie w parach, równe, wysokie tempo pracy, iteracyjne wytwarzanie oprogramowania (takt w linii produkcyjnej? O.o) - jakby mi ktoś w morde dał.

Niemniej dalsza część książki, gdzie opisywane są zasady i wzorce rozwiązywania problemów podczas pisania czy projektowania oprogramowania to rewelka, od części drugiej to to czego szukałem do dalszej nauki.

Dzięki za odpowiedzi w tym temacie, po nich wnoszę że to co nazywane jest programowaniem ekstremalnym może być jakimś celem do wdrożenia w firmie w korporacji ale jest szalenie mało prawdopodobne do pełnego wdrożenia. Czyli coś do czego można dążyć ale nie ma szans na pełne osiągnięcie tego typu stylu pracy.

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