Długo robię pewne zadanie w pracy

Czy to normalne, że długo robię jedno zadanie w pracy? Dodam, że to moja pierwsza praca. Zadanie polegało na stworzeniu od zera całej logiki, widoku i w sumie wszystkiego. Już 3 tydzień będzie jak będę robić. Ale ciągle do przodu.

Zależy. Z Twojego opisu nie wynika w zasadzie nic. Równie dobrze mógł być to task na dzień jak i na miesiąc. Skoro zadajesz takie pytanie to domyślam się, że nikt nie zrobił estymacji taska, a to byłby najlepszy punkt odniesienia.

Ogólnie, na szybkość programowania ma wpływ wiele czynników.

Może warto poćwiczyć szybkie pisanie?
Ucząc się nieświadomie pisać, czasem nie wykorzystuje się wszystkich 10-ciu palcy na klawiaturze, przez co pisze się trochę wolniej.

Jak pierwszy raz wykonujesz danego typu projekt to wiadomo, że będziesz wymyślał koło na nowo, a mając już pewne pojęcie można tylko upraszczać daną metodę wytwarzania projektu.
Jak biegle będziesz robił ciągle to samo, to w końcu twój mózg będzie wydajniej pracował gdyż odkryje optymalniejsze drogi rozwiązania problemu.

Może warto poćwiczyć szybkie pisanie?
Ucząc się nieświadomie pisać, czasem nie wykorzystuje się wszystkich 10-ciu palcy na klawiaturze, przez co pisze się trochę wolniej.

Myślę, że szybkość pisania to akurat najmniejszy problem w tym przypadku. Pisanie stanowi raczej niewielki ułamek pracy programisty, większość czasu to rozkminianie jak rozwiązać dany problem i jak później zakodować to rozwiązanie. Zwłaszcza, jeżeli kolega jest początkujący to pewnie większość czasu spędza, szukając "czemu coś nie działa, choć powinno, bo przecież wszystko jest na pewno dobrze" ;)

Progress napisał(a):

Myślę, że szybkość pisania to akurat najmniejszy problem w tym przypadku.

Masz rację, ale z logicznego punktu widzenia i tak jakiś progress to daje...

A co to za projekt ?

A ja widzę to tak - to Twoja pierwsza praca, możliwe że nie znasz jeszcze wystarczająco projektu. 3 tygodnie - czyli oko 100 godzin (zakładam że realnie pracujesz po 6,57h dziennie). Dodatkowo jeśli tworzysz coś od zera - a ma to być solidne - to nie jest to wg mnie jakiś wyjątkowo długi czas. Dodatkowo - staraj się też nie porównywać do kolegów, którzy mają większy staż pracy - bo czasami nawet 23 miesiące różnicy mogą sprawiać wrażenie "omg, oni tacy mądrzy, a ja taki głupi`. Zawsze możesz pogadać z przełożonym o postępach.

Reasumując - spokojnie, dopóki masz progress, dopóki komuś raportujesz że problem jest większy niż się wydaje lub masz przestoje jakieś - będzie ok :)

Odpowiedź zależy m.in od takich czynników jak:

1. Co to zaprojekt, jaka jest jego złożoność
2. Jakie jest twoje doświadczenie w pisaniu takich rzeczy (ogólnie, nie w sensie "czysto komercyjnym")
3. Czy wymagania są jasno postawione
4. Czy język i technologię masz oblatane, czy się ich ciągle uczysz.
5. Co do technologii/frameworkó/itp. czy korzxystasz z dokumentacji i jaka jest jej jakość, czy szukasz odpowiedzi na każdy problem w google.
6. Czy w ogóle masz wenę twórczą i ochotę nad tym pracować.

Jak im to nie przeszkadza to możesz i rok robić. Chociaż tu powinny dojść jakieś sprinty i w danym sprincie w +/- powinieneś się wyrobić.

@Pietass: ja bym po prostu nie olewał tematu i nie zakładał, że komuś może to nie przeszkadzać. Czasem w teamach takie informacje nie są transparentne (mimo iż być powinny) i może okazać się po miesiącu czy dwóch, że dostanie negatywny feedback, co może wpłynąć na jego przyszłość w firmie.

Do autora: ja w pierwszej pracy dostałem dość skomplikowane zadanie jak na moje umiejętności do zrobienia za pomocą kilku libek, których dokumentacje miały po kilkaset stron każda (nie pamiętam już dokładnie co to było, ale coś z machine learning kilka lat temu, więc jak na studenta to było dla mnie rocket science). Też szło to powoli, ale codziennie prawie rozmawiałem z innym developerem odnośnie tego jak posunąć się dalej, czy po prostu żeby pokazać, do czego doszedłem. Trwało to miesiąc, zadanie ostatecznie skończyłem i wszyscy byli zadowoleni, ale był to chyba najdłuższy task w mojej karierze do tej pory. ;) Także to co mogę poradzić to rozmawiać i prezentować swoje obawy innym bardziej doświadczonym developerom. I prosić o feedback, jak i samemu go udzielać. Takim sposobem jak nawet zawalisz, to nie będziesz robił sobie wyrzutów, że nie próbowałeś tego zrozumieć i sięgnąć po pomoc.

Nie przesadzaj, GNU Hurd robią od 1990 i dalej nie działa.