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.

0

Programowanie ekstremalne nie polega przecież na pisaniu na akord, lecz na odejściu od ociężałego modelu kaskadowego, w którym najpierw się projektuje całość, potem implementuje, a po 10 latach pisania jedzie do klienta, który w ogóle już nawet nie pamięta, że coś zamawiał. ;)
A programowanie w parach, to zmniejszenie liczby wpisanych znaków. :)

0

Gdzieś czytałem, że ilość napisanych linii kodu dziennie słabo zależy od języka w którym się ten kod pisze. Tak więc jak pisze się w języku, który wymaga mniej kodu do stworzenia funkcjonalności, to dodawanie funkcjonalności idzie szybciej. Podobnie: jeżeli ktoś nie zna sposobu działania jakichś bibliotek, zwłaszcza biblioteki standardowej, w przypadku Javy może to być np nieznajomość klas java.util.Arrays, java.util.Collections itp w ogóle mechaniki kolekcji to będzie pisał w kółko kod który już przecież jest w standardzie, tym samym oddalając termin zakończenia implementacji docelowych funkcjonalności.

A więc jeśli we dwójkę napisze się mniej kodu, ale tyle samo funkcjonalności, to to jest plus jak dla mnie. Mniej kodu = mniej błędów i mniejsze koszty utrzymania.

0

Mniej kodu = mniej błędów i mniejsze koszty utrzymania

Zawsze zastanawiało mnie to stwierdzenie. Niby jak jest więcej kodu to masz więcej okazji do popełnienia.
Z drugiej strony w językach wysokiego poziomu jak się zrobi błąd to jest on znacznie bardziej subtelny i ciężki do znalezienia (np. trudno rozbić wysokopoziomowe operacje na mniejsze kroki, żeby zobaczyć co jest nie tak). Bazuje tutaj na doświadczeniach z Matlaba, w którym można bardzo zwięźle zapisywać algorytmy w stosunku np. do C++.

0

np. trudno rozbić wysokopoziomowe operacje na mniejsze kroki, żeby zobaczyć co jest nie tak

Na przykład?

0

Załóżmy, że chcesz znormalizować macierz (tablicę 2D) przez sumę poszczególnych rzędów.
Co jest łatwiej zrozumieć:
for(int i = 0; i < m; i++)
{
double sum = 0;
for(int j = 0; j < n; j++)
sum += a[i][j];
for(int j = 0; j < n; j++)
a[i][j] /= sum;
}
czy coś takiego
A = A / repmat(sum(A, 2), 1, size(A, 2))
W wersji Matlaba jest drobny błąd, ciekawe czy potrafisz go zobaczyć.

0
0x200x20 napisał(a)

Załóżmy, że chcesz znormalizować macierz (tablicę 2D) przez sumę poszczególnych rzędów.
Co jest łatwiej zrozumieć:
for(int i = 0; i < m; i++)
{
double sum = 0;
for(int j = 0; j < n; j++)
sum += a[i][j];
for(int j = 0; j < n; j++)
a[i][j] /= sum;
}
czy coś takiego
A = A / repmat(sum(A, 2), 1, size(A, 2))
W wersji Matlaba jest drobny błąd, ciekawe czy potrafisz go zobaczyć.

Pytanie dla bardziej doświadczonych programistów:
Czy przy pisaniu takiej normalizacji nie lepiej jest użyć gotowych funkcji typu repmat, sum, size itd niż rzeźbić własnoręcznie?
Chodzi mi o różnicę pomiędzy czytelnością a duplikowaniem czegoś co istnieje oraz ewentualne debugowanie?

0

Jezeli takowe istnieja, to zdecydowanie lepiej wykorzystac gotowe funkcje jakie oferuje jezyk programowanie. Po to one sa :)

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