Zwolnienie a kariera

Witam wszystkich,
Zostałem zwolniony za bycie zbyt wolny. Mimo wiedzy, taski realizowałem za wolno i na standupach coraz częściej zbierałem za to opieprz. Nie z powodu obijania się, po prostu mam wrażenie że wszyscy w firmie są dużo szybsi ode mnie (pracuje ok rok). Potem zacząłem starać się robić szybciej ale pojawiały się błędy w oprogramowaniu za które znowu dostawałem opieprz 2x większy więc wróciłem do robienia wolniej z mniejszą ilością błędów a w końcu zostałem zwolniony. Przez pewien moment też pracowalem po 10h zamiast 8h (+ czasem weekendy) i wtedy było dobrze, nie zbierałem nawet specjalnie opieprzu ale nie dawałem rady tak dłużej i przestałem. Może to był błąd.

Dodatkowo kilka uniwersalnych pytań, już bez związku z moją konkretną sytuacją:
Jak to że zostało zwolnionym wpływa na dalszą karierę jako programista.
Czy z zawodem można się pożegnać, jeśli powód takiego zwolnienia leżał po stronie programisty?
Czy w CV wpisać firmę, z której się zostało zwolnionym? A jeśli to była jedyna firma w życiorysie danego programisty?

Jedno zwilnienie to nie koniec swiata. Zrob jakis fajny projekt OS aby to zrownowazyc i pomysl jak ubrac to zwolnienie ladnie w slowa.

Wszystko w na tym świecie ma dwie strony. Ciemną i jasną (coś jak strony mocy). Jeżeli zostałeś zwolniony, to masz szansę teraz znaleźć taką pracę, w której:
a) będziesz otrzymywał zadania adekwatne do Twoich umiejętności
b) nie będziesz musiał robić nadgodzin
c) nikt nie będzie na Ciebie krzyczał i Cie za coś opieprzał (powinieneś od razu się zwolnić)

Jak to że zostało zwolnionym wpływa na dalszą karierę jako programista.

A pozwolisz żeby wpłyneło?

Czy z zawodem można się pożegnać, jeśli powód takiego zwolnienia leżał po stronie programisty?

Jeżeli się nie wyrabiałeś to widocznie nie miałeś jeszcze wystarczających umiejętności, albo robili z Ciebie robota. Jeżeli każesz miesięcznemu dziecku biegać a to się przewróci to czy to oznacza, że już może sobie dać spokój i do końca życia będzie pełzać bo się raz przewróciło? Tak się składa, że jakoś wszyscy na ziemi chodzą, a nie raz lądowali na ziemi, tylko dorośli zapominają o tym podejściu.

Wyciągnij wnioski, otrzep kolana i idź dalej.

Czy w CV wpisać firmę, z której się zostało zwolnionym? A jeśli to była jedyna firma w życiorysie danego programisty?
pewnie a czemu nie. w końcu pracowałeś tam przez rok

Czy z zawodem można się pożegnać, jeśli powód takiego zwolnienia leżał po stronie programisty?
Nie. to tak może być po roku ,że może dawali Ci nieadekwatne zadania. też tak czasem mam, niby myślę logicznie ale wolniej niż inni -lepiej się nie załamywać.
są ważniejsze rzeczy w życiu niż jakieś tam taski a na rynku jest dużo ofert i pewno coś znajdziesz ;].

. Potem zacząłem starać się robić szybciej ale pojawiały się błędy w oprogramowaniu za które znowu dostawałem opieprz 2x większy więc wróciłem do robienia wolniej z mniejszą ilością błędów

• a czy pisałeś testy jednostkowe? W tym: czy próbowałeś pisać TDD?
• czy miałeś code review w firmie?
• czy znasz skuteczne techniki debugowania? (skuteczne - takie, które pozwolą ci zlokalizować błąd szybko. Wymaga to nieco doświadczenia, ale również znajomości odpowiednich tooli).

Błędy zawsze będą, ale sztuka to sobie z nimi radzić jakoś oraz zapobiegać w miarę możliwości.

Mimo wiedzy, taski realizowałem za wolno i na standupach coraz częściej zbierałem za to opieprz. Nie z powodu obijania się, po prostu mam wrażenie że wszyscy w firmie są dużo szybsi ode mnie (pracuje ok rok)

Czemu byli szybsi? Skąd to wynikało? Czemu ty byłeś wolny? Co ci najwolniej szło? Co mógłbyś usprawnić? W jakiego rodzaju zadaniach czujesz się lepiej, a w jakich gorzej? (możliwe, że np. dostawałeś taski, do których miałeś wybitny antytalent, a jeśli byś dostawał inne, poradziłbyś sobie lepiej).

Może powinieneś teraz wykonać jakąś retrospekcję i pomyśleć nad jakimś improvementem. Bo inaczej w kolejnej firmie może być to samo... ;)

Czy z zawodem można się pożegnać, jeśli powód takiego zwolnienia leżał po stronie programisty?

Wujek Bob jakoś dalej programuje, mimo że jak pisał w Clean Coder (z tego co pamiętam) to zwolnili go kiedyś.
Jedna porażka to nie koniec świata.

Dzięki za słowa otuchy @karolinaa i @Desu

LukeJL napisał(a):

. Potem zacząłem starać się robić szybciej ale pojawiały się błędy w oprogramowaniu za które znowu dostawałem opieprz 2x większy więc wróciłem do robienia wolniej z mniejszą ilością błędów

• a czy pisałeś testy jednostkowe? W tym: czy próbowałeś pisać TDD?
• czy miałeś code review w firmie?
• czy znasz skuteczne techniki debugowania? (skuteczne - takie, które pozwolą ci zlokalizować błąd szybko. Wymaga to nieco doświadczenia, ale również znajomości odpowiednich tooli).

Na testy nie zawsze był czas, tzn pewnie pisałbym więcej ale musiałem już oddać taska bo poganiali. Code review było.
Skuteczną techniką sprawdzenia czy wszystko działa poprawnie było odpalenie apki samemu, tyle że trwało to dość długo.

LukeJL napisał(a):

Błędy zawsze będą, ale sztuka to sobie z nimi radzić jakoś oraz zapobiegać w miarę możliwości.

Mimo wiedzy, taski realizowałem za wolno i na standupach coraz częściej zbierałem za to opieprz. Nie z powodu obijania się, po prostu mam wrażenie że wszyscy w firmie są dużo szybsi ode mnie (pracuje ok rok)

Czemu byli szybsi? Skąd to wynikało? Czemu ty byłeś wolny? Co ci najwolniej szło? Co mógłbyś usprawnić? W jakiego rodzaju zadaniach czujesz się lepiej, a w jakich gorzej? (możliwe, że np. dostawałeś taski, do których miałeś wybitny antytalent, a jeśli byś dostawał inne, poradziłbyś sobie lepiej).

Nie wiem czemu byłem wolniejszy. Na pewno nie z powodu znajomości narzędzi. Ogarniałem dość zaawansowane elementy technologii, a miałem problemy w rzeczach dotyczących zwykłej logiki biznesowej. Tzn coś trzeba było pozmieniać w całej aplikacji (coś starego wywalić, coś nowego wprowadzić), no i robiłem, task prawie gotowy, ale okazuje się, że przez to inne rzeczy będą się sypać i że trzeba inne rzeczy wziąć pod uwagę.
A co do innych, czemu byli szybsi: miałem wrażenie, że siadają i robią taska, jakby od samego dostania go wiedzieli co i jak trzeba zrobić. Na standupie mówili "to mi zajmie gdzieś godzine" "pół dnia" choć taski wydawały mi się trudne. Może trafiłem po prostu do świetnej firmy (w sensie programistów)?.
Mnie połowe czasu zajmowała analiza wymagań, przejrzenie obecnego kodu, ogarnięcie jak to zrobić i dopiero potem robienie.
Nie wiem też czy nie było tak że za słabo tłumaczyłem co mi zajmuje tyle czasu. Może po prostu uznali mnie na początku za słabego a potem jak coś robiłem długo to już nie myśleli, że tyle task zajmuje, tylko że ja jestem wolny...

Z kim porównywałeś ten czas robienia zadań? Z osobami o podobnym doświadczeniu jak Ty? Wiadomo, że jeśli były tam osoby pracujące parę lat to znały projekt, siadały i klepały taska bo był np. powtarzalny i rozwiązywali już coś podobnego.

Na testy nie zawsze był czas,
(...)
Tzn coś trzeba było pozmieniać w całej aplikacji (coś starego wywalić, coś nowego wprowadzić), no i robiłem, task prawie gotowy, ale okazuje się, że przez to inne rzeczy będą się sypać i że trzeba inne rzeczy wziąć pod uwagę.

No tak się kończy podejście "na testy nie zawsze jest czas". Jeśli w twoim zespole panowało takie przeświadczenie, że na testy nie ma czasu, to normalne, że jak projekt się rozrastał, to brak testów musiał skończyć się bugami i wielką entropią, bo tak jak piszesz - piszesz rzecz X i nagle rzecz Y się psuje. Właśnie do tego są testy, żeby zapewnić poprawność działania całego programu.

Może jakbyś pisał małą apkę w jedną osobę, to można było sobie poradzić bez testów, ale przy dużej aplikacji pisanej w ileś osób raczej zawsze powinien być czas na testy. Bo to się będzie potem mścić (jak widać).

Jak następnym razem trafisz na firmę, która uważa, że "na testy nie zawsze jest czas", to zawsze możesz powiedzieć im, że niepisanie testów (tudzież niestosowanie innych dobrych praktyk, np. brak czasu na refaktoring i na pomyślenie o architekturze) to dług technologiczny(technical debt), który będzie trzeba kiedyś spłacić w postaci np. fiksowania bugów, które się pojawią znikąd.

Może trafiłem po prostu do świetnej firmy (w sensie programistów)?.

z tego co piszesz to właśnie do słabego zespołu trafiłeś.

Znam parę podobnych przypadków.

W jednym też był problem w kodzie, dobrze się w nim orientowali głównie starzy wyjadacze, a po młodych kierownicy potrafili jechać, że się nie nadają do pracy, bo nie ogarniają tego syfu. Wśród tych doświadczonych byli jednak młodzi wiekiem, którzy na tym kodzie się wychowali i nie znali innego, stąd pewnie potrafili się w nim poruszać. Dlatego, jak już wyżej powiedziano, nie bierz sprawy tak bardzo do siebie i nie żegnaj się z karierą. :)

W drugim też pracownik został zwolniony, ale firma nie trzymała go aż rok. Problem był od początku, bo ta osoba nie znała technologii tak dobrze jak inni i jak było to potrzebne w projekcie, ponadto był duży nacisk na czas. Pracownik niedomagał (ale nie robił w weekendy, szanujmy się) i skończyło się na twardym dywaniku u prezesa.

W oparciu o to drugie odpowiedzi na Twoje pytania:

1. Fakt zwolnienia ma znaczenie raczej tylko przy szukaniu pracy zaraz po nim, bo na rozmowie kwalifikacyjnej trzeba uzasadnić szukanie pracy, a ściemniać nie ma jak, bo już jesteś na wypowiedzeniu i jesteś szybciej dostępny. W kolejnej, jeśli w ogóle zapytają o powody wszystkich odejść, można już ten fakt pominąć i powiedzieć bardziej elegancko, że nie pasowała Ci kiepska jakość kodu czy zadania nieadekwatne do umiejętności.
2. Nie ma co się żegnać, o ile nie wrzuciłeś do internetów danych osobowych z banku. :)
3. Wpisać, zwłaszcza jeśli to była jedyna praca, bo pokazuje doświadczenie. Później też wpisywać, bo nie ma sensu sobie robić dziury w ciągłości zatrudnienia (skoro mówimy o zwolnieniu, to zapewne nie chodzi o pracę w czasie studiów na umowie śmieciowej, a akurat taką można pominąć całkowicie bezpiecznie).
   Happy end: osoba z drugiego przypadku dostała kolejną pracę dużo bardziej w swojej technologii, w firmie z bardziej ludzką organizacją i bardziej ludzkimi ludźmi, została uznana za coś wartą i nawet przekazywała wiedzę innym.

Wybitny Lew napisał(a):

Nie wiem czemu byłem wolniejszy. Na pewno nie z powodu znajomości narzędzi. Ogarniałem dość zaawansowane elementy technologii, a miałem problemy w rzeczach dotyczących zwykłej logiki biznesowej. Tzn coś trzeba było pozmieniać w całej aplikacji (coś starego wywalić, coś nowego wprowadzić), no i robiłem, task prawie gotowy, ale okazuje się, że przez to inne rzeczy będą się sypać i że trzeba inne rzeczy wziąć pod uwagę.

A zostałeś w ogóle wprowadzony w biznes i architekturę aplikacji, czy tak Cię po prostu wrzucono do projektu?

Może trafiłem po prostu do świetnej firmy (w sensie programistów)?.

Którzy nie mieli czasu na testy? Wątpliwe.

Mnie połowe czasu zajmowała analiza wymagań, przejrzenie obecnego kodu, ogarnięcie jak to zrobić i dopiero potem robienie.

I to jest całkowicie normalne. Ba, nawet 80% czasu na analizę i wczytanie się w kod jest normalne.

Generalnie, jeśli nie masz wpisanej jakiejś nagany do świadectwa pracy, to nic się nie stało. Na rozmowie kwalifikacyjnej w następnej firmie powiesz, że odszedłeś, bo nie było testów, kod był zagmatwany, i nie mogłeś liczyć na niczyje wyjaśnienia, a wymagano od Ciebie dotrzymania terminów, i o ile to nie będzie druga taka sama firma, to uznają Cię za rozsądnego człowieka.

W momencie w którym zacząłes dostawać opieprz na standupach powinieneś sam zacząć myslec o zmianie. Od opieprzania jest co najwyżej szef a nie ludzie z własnego teamu. W ogole wtf - rok to sporo czasu więc powinniscie juz się całkiem dobrze znać i raczej pomagać/wspolpracowac a nie jakieś opieprzanie...

@dbCooper no nie wiem. Wyobraź sobie że masz gościa w teamie który klepie jedną formatkę html na 5 pól tekstowych przez tydzień czasu, a potem jeszcze musisz po nim poprawiać bo źle ją zrobił. A "capacity" twojego zespołu jest liczone z tym gościem jako pełnoetatowym koderem. W efekcie reszta teamu musi pracować ciężej żeby nadrobić za takiego agenta. Chętnie zobaczyłbym co ty byś zrobił w takiej sytuacji i jak byś wspierał i pomagał takiemu gościowi. Szczególnie że z twojej perspektywy pracujesz za dwóch a on prawie wcale a zarabiacie pewnie tyle samo...

@Wybitny Lew może po prostu technologia ci nie podchodzi? Może dziedzina? W ogóle to jest dziwna sytuacja bo zwykle przecież estymowanie zadań na sprint robi sie całym zespołem, więc z góry wiadomo na ile wszyscy wyceniają dane zadanie. A potem zadania bierzesz z backlogu w sposób losowy. Więc jeśli przypadkiem to akurat tobie zawsze brakowało czasu, to może jednak problem leży gdzieś po twojej stronie?

Wyobraź sobie że masz gościa w teamie który klepie jedną formatkę html na 5 pól tekstowych przez tydzień czasu, a potem jeszcze musisz po nim poprawiać bo źle ją zrobił. A "capacity" twojego zespołu jest liczone z tym gościem jako pełnoetatowym koderem. W efekcie reszta teamu musi pracować ciężej żeby nadrobić za takiego agenta. Chętnie zobaczyłbym co ty byś zrobił w takiej sytuacji i jak byś wspierał i pomagał takiemu gościowi. Szczególnie że z twojej perspektywy pracujesz za dwóch a on prawie wcale a zarabiacie pewnie tyle samo...

@Shalom, daj spokój - dorośli ludzie powinni ze sobą rozmawiać, a nie się opieprzać. W ostateczności po prostu rozwiązać umowę, ale przed tym rozwiązaniem umowy nie ma absolutnie żadnego uzasadnienia do upokarzania tej osoby. Wytknąć błędy i skrytykować zawsze można kulturalnie.

a ktoś jeszcze na to patrzy, czy śledzi czy był zwolniony, czy sam zrezygnował ?
trochę z innej beki znam gościa co miał prawko zatrzymane za alko, patola konkretna, a teraz widziałem nadal na tirach jeździ i ma się dobrze, inny był zwolniony za kradzież i też pracuje, akurat w naszym kraju to uczciwi mają najgorzej :D

@dbCooper
@aurel
Macie rację, nikogo nie powinno się publicznie upokarzać, ale też kiedy zespół po raz N-ty się nie wyrabia w sprincie przez jedną osobę - to wkurza. Jestem w stanie uwierzyć, że komuś mogły puścić nerwy i powiedział coś głośno coś, co wszyscy myślą.
Druga sprawa: "zebrać opieprz" to wyrażenie dosyć subiektywne. Dla jednych uwaga w stylu "wiemy, że nie wszystko poszło idealnie" jest już zebraniem opieprzu.

Jeśli projekt może się położyć przez jedną osobę, to znaczy, że albo jest jednoosobowy, albo źle prowadzony. W normalnej sytuacji nie ma możliwości, że projekt leży, bo jeden programista nawalił ze swoim taskiem.
Współczuję pracy w JanuszSoftach ludziom, którzy uważają, że opieprzanie i zrzucanie winy jest prawidłową metodą prowadzenia projektów.

ale też kiedy zespół po raz N-ty się nie wyrabia w sprincie przez jedną osobę - to wkurza

Jest taki show w telewizji, który nazywa się "Warto rozmawiać". Prowadzi go Pospieszalski. Nie mam pojęcia o czym jest ten program, ale jego nazwa mi utknęła w pamięci ;)

W sytuacjach, kiedy coś nie trybi w zespole zawsze warto spróbować naprawić ten problem razem. Warto rozmawiać ;) Może przedyskutować pewne rzeczy (tj. potraktować czyjąś słabą wydajność jako problem całego zespołu, a nie jako "winę" konkretnego pracownika). Może zrobić pair programming. Może wreszcie spróbować przemówić komuś do rozsądku (jeśli faktycznie ktoś ma słabe podejście do pracy, czasem feedback/konstruktywna krytyka może dużo zdziałać). Ale generalnie wydaje mi się, że w dalszym ciągu - zespół to zespół. Najwyżej ktoś może do danego zespołu po prostu nie pasować, wtedy mu się dziękuje za współpracę i tyle (co niekoniecznie musi znaczyć, że zespół jest dobry, a ten, kto nie pasował jest gorszy -- w przypadku o którym pisze OP mam wrażenie, że trafił on do jakiegoś dziwnego zespołu).

Nie pracuje w metodologii scrum. Ale z tego co tu czytam to chyba jest trochę stresujące? Żeby nie odstawać żeby szybko pracować i do tego dobrze programować co nie zawsze idzie parze i wtedy łatwiej o błędy w kodzie.
Ja mam tak, że są przydzielane zadania każdy robi swoje a PM dopytuje jak idzie, jakie problemy napotkane ewentualnie itp. Ale akurat team jest taki, że raczej nie ma mowy o tym, żeby ktoś się obijał tylko robi jak najsprawniej może.
Chcę zaznaczyć, że jestem laikiem w pracy z metodologiami agile także spoko jakby ktoś mi wyjaśnił jak to dokładniej wygląda bo póki co widzę to w stylu "masz zadanie masz na nie 4 godz nie wyrobisz się wylatujesz".

Swoją drogą przypomniał mi się fajny cytat w temacie:

I've missed more than 9000 shots in my career. I've lost almost 300 games. 26 times, I've been trusted to take the game winning shot and missed. I've failed over and over and over again in my life. And that is why I succeed.

Autorem tych słów jest Michael Jordan

Hepek napisał(a):

Chcę zaznaczyć, że jestem laikiem w pracy z metodologiami agile także spoko jakby ktoś mi wyjaśnił jak to dokładniej wygląda bo póki co widzę to w stylu "masz zadanie masz na nie 4 godz nie wyrobisz się wylatujesz".

To nie jest agile. W agile programista/zespół szacuje czas wykonania zadania, nikt tego odgórnie nie narzuca.

Jestem w podobnej sytuacji jak autor tematu. Pierwszą pracę straciłem po trzech miesiącach, drugą po miesiącu.

Przez cały okres liceum i studiów ludzie mi wmawiali, że w programowaniu najważniejsza jest komunikacja z zespołem. Bzdura, w obydwóch firmach wyglądało to tak, że rozmawialiśmy może po pół godziny na osiem godzin, a proszenie innych o pomoc oznaczało konieczność wysłuchiwania komentarzy o "przeszkadzaniu" i "niesamodzielności".

Moim problemem było to, że wykonywanie "tasków" (nienawidzę tego dzielenia projektu, wyobrażałem sobie przez całe życie że wszyscy pracują razem, dyskutują ze sobą) zajmowało mi średnio 4 razy więcej czasu niż pozostałym osobom. Oni znali na pamięć nazwy wszystkich tabel i kolumn, ja zapytania SQL pisałem z prędkością bliską 0, bo musiałem wszystkiego szukać jak się nazywa, a to były zapytania na 30 i więcej linii kodu SQL. Druga przyczyna takiego a nie innego tempa: przeważnie pisałem szybko kod prawie działający prawidłowo, ale nie do końca i naprawianie tego zajmowało mi kilka razy dłużej niż początkowe napisanie, a okazywało się że problemem była jakaś bzdura w kodzie, np. użycie < zamiast <= do porównania wartości. Z przyzwyczajenia pisałem co chwilę "string" zamiast t("string"), bo nigdy wcześniej nie widziałem programu z tekstem w wielu językach, zdarzało mi się przez przypadek otwierać ten sam plik w dwóch oknach edytora i robić połowę w jednym, połowę w drugim, przez co jakaś zmiana niszczyła wcześniejszą. Do tego doszły trudności z obsługą Windows 8 i wielu monitorów, bo takiej konfiguracji nigdy wcześniej w życiu nie widziałem.

Testy, o których piszecie to dobry żart. W pierwszym zakładzie pracy każdy "task" po zrobieniu bez żadnych testów trafiał na publicznie dostępną stronę WWW, klienci dzwonili że strona działa źle, a ja nie dawałem sobie rady z szybkim rozwiązywaniem tych problemów. W drugim testy było tylko ręczne, ale musiał je wykonywać autor kodu. Przeważnie końcowe pełne testowanie pomijałem, bo widziałem że "czterogodzinne" zadanie robię już 15 godzin. Nie wyrzucili mnie za bugi, tylko za czas wykonywania zadań.

Prawdopodobnie nigdy się nie dowiem, co jest ze mną dokładnie źle, na pewno nie brak wiedzy w zakresie języków i frameworków tylko coś innego. Teraz szukam pracy w IT, ale nie programowaniu, oczywiście gorzej płatnej. Programowanie dla siebie uwielbiam, a programowania dla innych nie, bo nic nie mogę zdążyć.

jacek.tr napisał(a):

Jestem w podobnej sytuacji jak autor tematu. Pierwszą pracę straciłem po trzech miesiącach, drugą po miesiącu.

Przez cały okres liceum i studiów ludzie mi wmawiali, że w programowaniu najważniejsza jest komunikacja z zespołem. Bzdura, w obydwóch firmach wyglądało to tak, że rozmawialiśmy może po pół godziny na osiem godzin, a proszenie innych o pomoc oznaczało konieczność wysłuchiwania komentarzy o "przeszkadzaniu" i "niesamodzielności".

O jaką pomoc prosiłeś? Coś ci się np. nie kompilowało, czy nie rozumiałeś np. jak działa aplikacja, albo nie wiedziałeś, jak zabrać się za taska?
Bo jak latałeś z głupotami do kolegów które w 5 minut można znaleźć na SO lub dokumentacji to nic dziwnego że się wkurzali.
Oczywiście możliwe też jest, że zwyczajnie byli niemili, ale wtedy o czymś takim należało powiadomić szefa. Obowiązkiem pracowników jest wprowadzić nowego do projektu. W niektórych firmach wyznaczani są opiekunowie.

jacek.tr napisał(a):

Moim problemem było to, że wykonywanie "tasków" (nienawidzę tego dzielenia projektu, wyobrażałem sobie przez całe życie że wszyscy pracują razem, dyskutują ze sobą)

A jak sobie to wyobrażasz, że siadają przy jednym komputerze i podpinają 10 klawiatur? Czy że w 10 dyskutują o przesunięciu w prawo inputa w CSS?

jacek.tr napisał(a):

otwierać ten sam plik w dwóch oknach edytora i robić połowę w jednym, połowę w drugim, przez co jakaś zmiana niszczyła wcześniejszą.

No chłopie, też bym cię zwolnił. Korzysta się z IDE, które samo zapisuje plik jak np IntelliJ Idea (czy tam inne wersje edytora). Ja sam w Intellij pisze nawet skrypty w bashu bo uwielbiam skroty takie jak Ctrl-W do zaznaczania słów czy multiline edit.

jacek.tr napisał(a):

Do tego doszły trudności z obsługą Windows 8 i wielu monitorów, bo takiej konfiguracji nigdy wcześniej w życiu nie widziałem.

Przecież drugi monitor mogłeś wyłączyć. Sam wole pracować na jednym, na środku ustawionym a nie zerkać w prawo i lewo.

Prosiłem o pomoc dotyczącą struktury aplikacji i bazy, a nie języka i frameworka, np. w jakiej kolumnie jakiej tabeli jest jakaś wartość albo w którym z 600 plików znajdę komunikat który muszę zmienić.

Normalnie sobie wyobrażam współpracę - jeżeli umiem zrobić 95% zadania, chciałbym żeby pozostałe 5% inni zrobili za mnie, tak samo żebym ja pomagał innym gdy mają problem. Tak dziwne to jest?

jacek.tr napisał(a):

albo w którym z 600 plików znajdę komunikat który muszę zmienić.

No tutaj się kłania znajomość narzędzi programistycznych. W moim przypadku będzie to Search in path w IntelliJ, lub grepowanie w bashu - ty na Windowsie powinieneś znać odpowiednie narzędzia wyszukiwania.
Jeżeli z każdą pierdołą leciałeś "a gdzieś coś jest" to faktycznie mogło być to męczące.
Nie mówię tego by sprawić Ci przykrość, ale byś odpowiedział sobie na pytanie, czy na wina nie leży po twojej stronie. Bo jeśli leży, to lepiej, bo możesz ją naprawić. Gdyby natomiast zwalniali cię mimo, że nie masz sobie nic do zarzucenia, to mogło by znaczyć, że masz pecha. A zaufaj mi, lepiej być słaby niż mieć pecha :]

jacek.tr napisał(a):

Normalnie sobie wyobrażam współpracę - jeżeli umiem zrobić 95% zadania, chciałbym żeby pozostałe 5% inni zrobili za mnie

A ja bym chciał aby inni 100% zrobili za mnie.

@jacek.tr

1. Komunikacja w zespole nie ma nic wspólnego z tym że chodzisz i zawracasz ludziom głowę ;)
2. To że pisałeś kod niechlujnie i z bugami to tylko i wyłącznie twoja wina.
3. To ze dev testuje to co commituje sam to jest chyba oczywiste. Co ty sobie myslisz, że commitujesz coś co może działa, moze nie, a potem jakis tester to sprawdza? o_O Jak coś commitujesz to znaczy że sprawdziłeś że działa poprawnie a tester tam jest na wszelki wypadek.

w jakiej kolumnie jakiej tabeli jest jakaś wartość

Co zapewne jest w dokumentacji którą powinieneś był przyswoić ;) Ale to jest jeszcze ok, o ile nie latasz tak co 5 minut przez 2 miesiące....

albo w którym z 600 plików znajdę komunikat który muszę zmienić.

Też bym cię zwolnił skoro nie umiesz korzystać z narzędzi typu grep.

chciałbym żeby pozostałe 5% inni zrobili za mnie

:D :D

Ja trochę tego nie rozumiem wszystkiego. Każdy mówi czy to tu na forum, czy jak chodzę na jakieś prelekcje, albo oglądam jakiś film na yt, żeby iść do pracy i tam zdobywać doświadczenie jak się ma już jakieś swoje projekty,a co za tym idzie ma się już jakąś wiedzę. Wielokrotnie też zawsze każdy powtarza żeby się o wszystko pytać jak się jest nowym, że to normalne.
Przechodzisz proces rekrutacji, czyli oni wiedzą o Tobie że zaczynasz, że to Twoja pierwsza praca, że będziesz robił coś nowego, że będziesz mało wnosił do projektu, bo wielu rzeczy nie znasz a jak znasz to nie na pamięć i musisz korzystać z internetu lub pytać innych.
Mimo tego wymagają od Ciebie że będziesz pracował jak ktoś kto robi w tym projekcie od dwóch lat, a sam pracuje od czterech?
Nie potrafię tego zrozumieć jak w NORMALNEJ firmie takie zachowania są dopuszczalne. Jeszcze po miesiącu kogoś wywalić bo za długo robi taski. Sory ale mnie się wydaje że jak na nasz piękny kraj przystało tu się szuka w dużej mierze jeleni. Szukają taniej siły roboczej czyli studentów którzy "kodzą od przedszkola" i na studiach idą do pracy bo są już tacy pro, a za dwa tysiące będą w pracy 8h i w domu kolejne 10h siedzieć żeby tylko ich nie zwolnili.
Gdzie w takim poszanowaniu i atmosferze widzieć sens tego co się robi i jeszcze czerpać z tego jakąś przyjemność?
Wydaje mi się, że programista to zawód który bardzo ciężko jest wykonywać jeżeli to nie jest czyjaś pasja. Czyli analogicznie przeważnie początkujący programista, który zacznie pracować będzie się pewnie w każdej wolnej chwili szkolił w domu, w dodatku jak będzie widział że w pracy nie daje do końca rady, a będzie mu zależeć na tym żeby pracować.

W takim razie czym jest "komunikacja", jeżeli inni oczekują ciszy, której ja nienawidzę? W innych branżach np. dziennikarstwie z tego co wiem komunikacja oznacza ciągłe rozmawianie z innymi, robienie wszystkiego razem.

Dokumentacja do projektu z informacjami dla programisty, a nie końcowego użytkownika? Chyba sobie żartujesz, nikt w Polsce poza megakorporacjami nie ma na to czasu.

"Taski" to dla mnie największa głupota i nie zmienię zdania. Optymalnie byłoby: nieskończenie wiele nieskończenie małych "tasków", wtedy problem który opisałem nie istnieje, można znaleźć optymalny przydział do osób.

jacek.tr napisał(a):

"Taski" to dla mnie największa głupota i nie zmienię zdania.

Jesteś moim mistrzem. Perełka.

Krzywy Kot napisał(a):

Jesteś moim mistrzem. Perełka.

Jesteś prawdopodobnie jednym z tych mistrzów łączących niezwiązane ze sobą rzeczy w jeden "task", żeby pokazać komuś że jest zerem, bo nie wykonał na czas ani jednego w całości. "Task" zatytułowany datą/numerem, bo zawiera tyle różnych zagadnień, że nie wiadomo jaki wymyślić tytuł.

A ty jesteś prawdopodobnie trollem.

1. Zarejestrowałeś się żeby napisać w tym wątku
2. jacek.tr - czyżby jacek.troll?
3. No takie głupoty pisać to ja nawet nie...
   Task to po prostu zadanie. Chcesz nie dostawać zadań, czy o co ci chodzi? Jak wyobrażasz sobie tą pracę bez tasków? Że siadacie przy jednym kompie i cały projekt tak robicie? W 10 osób?