Co to znaczy samodzielność?

Czytam oferty pracy i w kilku pojawia się "samodzielność" a co lepsze chyba każda z nich miała też w wymaganiach odnajdywanie się w grupie. Tak więc co znaczy ta samodzielność? Jak czegoś nie wiem to nie mogę spytać kolegi z firmy, żeby mu nie przeszkadzać? Seniorzy nie pomagają sobie nawzajem?

samodzielność? pewnie tak, nie trujesz d**y tylko szukasz samemu rozwiązania, ew. potem tylko dajesz kod do przejrzenia w komentach piszesz czego nie rozumiesz/ masz wątpliwości
ludzie sobie pomagają, ale jak będziesz co pól godziny podchodził do mid/seniora z zapytaniem to będą ofiary w ludziach

Samodzielność to znaczy że jak dostajesz taska to siadasz i potrafisz go zaklepać / wyszukać rozwiązanie napotkanych problemów / wiesz jak to sensownie zaprojektować. Jasne że nie wszystko musisz wiedzieć i nie ma sensu marnować całego dnia na googlowanie zamiast kogoś spytać, ale to ma być wyjątek a nie reguła. Zresztą jeśli masz problemy z "zaklepaniem" rozwiązania to bardzo możliwe że nie jesteś samodzielny. Mam wrażenie że na pewnym etapie ma sie wątpliwości już tylko co do designu, jak ten kod sensownie zaprojektować żeby był rozszerzalny, testowalny i pasował do przyjętej architektury.
Nie ma to nic wspólnego z pracą w grupie. Umiejętność pracy w grupie oznacza że potrafisz sie odnaleźć w nie-swoim kodzie i nie wpadasz w szał jak ktoś majstruje przy "twoim" kodzie.

czysteskarpety napisał(a):

samodzielność? pewnie tak, nie trujesz d**y tylko szukasz samemu rozwiązania

Tak rozumiana „samodzielność” zbyt daleko posunięta negatywnie odbija się na wydajności zespołu.
Bo będzie szukał taki przez dwa dni rozwiązania, a wystarczyłoby gdyby zapytał, może siedzący obok akurat wie i pomoże rozwiązać problem w 15 minut.

Wybitny Rycerz napisał(a):

Czytam oferty pracy i w kilku pojawia się "samodzielność" a co lepsze chyba każda z nich miała też w wymaganiach odnajdywanie się w grupie. Tak więc co znaczy ta samodzielność? Jak czegoś nie wiem to nie mogę spytać kolegi z firmy, żeby mu nie przeszkadzać? Seniorzy nie pomagają sobie nawzajem?

Ładnych parę lat temu w robocie odebrałem telefon od współpracownika, tj. świeżego pana 'inżyniera' po giertychowskiej maturze wpuszczonego na studia. Prosił mnie o pomoc, ponieważ właśnie skończył posiedzenie w WC, nie ma papieru do d---- a z ob----ą nie może po niego wyjść. Udzieliłem instruktażu, żeby zachował spokój, a następnie skręcił górną część swojego ciała zwieńczonego tzw. głową o 180 stopni, wtedy powinien dostrzec leżący na zbiorniku kompaktu ww. papier do d----.

Wiem, że wydaje się nieprawdopodobne, ale historia jest autentyczna. Z tego co mi donoszą ludzie pracujący na etatach od tego czasu samodzielność absolwentów zdążyła jeszcze spaść.

Samodzielnosc jest wpisana w IT, jezeli jakas firma to podkresla w ogloszeniu to bardzo zly znak. Moze sie okazac ze pracuja tam same mruki, ktore nie pomoga nawet raz na pol roku, a pierwszego taska dostaniesz zanim zainstalujesz IDE. Ja bym sie zastanowil dwa razy.

Mam wrażenie, że bardziej jest ceniona w firmach raczej praca w grupie niż samodzielność (za którą możesz tylko zjebki dostać). Szczególnie, że pewne praktyki grupowe, np. pair programming albo planowanie sprintu, znoszą w zasadzie samodzielność, przynajmniej na czas ich wykonywania.

Mam wrażenie że na pewnym etapie ma sie wątpliwości już tylko co do designu, jak ten kod
sensownie zaprojektować żeby był rozszerzalny, testowalny i pasował do przyjętej architektury.
Nie ma to nic wspólnego z pracą w grupie.

No właśnie to bardzo dużo ma wspólnego z pracą w grupie. W jaki sposób się najszybciej dowiesz czy coś pasuje do przyjętej architektury, jak nie właśnie poprzez konsultacje z innym programistą, który w tym siedzi dłużej? Albo z tą rozszerzalnością... Nie wszystko musi być super rozszerzalne, wiele rzeczy powinno być bardziej pisane "na pałę". A bez konsultacji z innymi (nie tylko programistami, ale też pytając o wymagania biznesowe) też się nie dowiesz, co powinno być rozszerzalne, a czego nie warto rozszerzać. I nie będziesz umiał zastosować abstrakcji w odpowiednim miejscu, a nie robić jej tam, gdzie byłoby to stratą czasu.

Na pewno własne skille też są tu potrzebne, ale jednak raczej coś w rodzaju synergii, a nie na zasadzie "ja zrobię coś, bo wiem najlepiej, i nie będę się konsultować z innymi", bo to najlepsza droga do dostawania opieprzu...

No i transfer wiedzy. Nawet jak się jest faktycznie słabym to i tak z moich doświadczeń bardziej przychylnie będzie się patrzyć jak się ktoś pyta o coś, konsultuje z innymi, radzi mądrzejszych od siebie - bo wtedy jest szansa, że zrobi coś dobrze, nawet jak jest juniorem - niż jak męczy się z jakimś problemem samemu (co owocuje tym, że zrobi coś źle).

Czyli wymagania samodzielności są tylko na papierku, a w praktyce to i tak jest praca grupowa w większości.

Umiejętność pracy w grupie oznacza że potrafisz sie odnaleźć w nie-swoim kodzie

Za to, to nie ma akurat nic wspólnego z pracą w grupie, a bardziej z umiejętnościami czytania kodu, który nie każdy posiada (ja np. nie umiem się odnajdywać w nieswoim kodzie i jak wchodzę do dużego projektu to za nic nie potrafię być samodzielny). Masz po prostu z setkę modułów i musisz je zrozumieć od strony powiązać (chociaż okej, ma to tyle wspólnego z pracą w grupie, że musisz mieć nawyk pytania innych o rzeczy, których nie rozumiesz)

Nie ma to nic wspólnego z pracą w grupie. Umiejętność pracy w grupie oznacza że potrafisz sie odnaleźć w nie-swoim kodzie i nie wpadasz w szał jak ktoś majstruje przy "twoim" kodzie.

A to ciekawe..W firmie dostałem projekt do dokonczenia w Laravelu. Zamiast grzebac sie w tym co napisal moj kolega, ktory porzucil projekt, napisalem wszystko od poczatku w nowszej wersji frameworka, poniewaz to co zastalem w plikach uznalem za zle napisane i ustalilem z managerem, ze napisze swoja wersje kodu...Oczywiscie krytyka byla niedopuszczalna, bo ten projekt zaczal robic senior, a ja jestem junior, chociaz robie wszystko jak regular.

@Biedny Rycerz to jest bardzo częsty błąd początkujacych programistów ;) Zwykle nie ma czasu na to żeby coś przepisywać od nowa i często nawet nie powinno się tego robić. Niektórzy mają takie przeświadczenie że "to jest źle napisane, ja bym zrobił lepiej", a potem męczą się kilka dni z listą wymagań i dochodzą do takiego samego albo gorszego rozwiązania, bo nagle okazuje się że lepiej przy istniejących ograniczeniach się nie da.

Mój kolega senior też mi zostawił w spadku kod który był po prostu zwykłym spaghetti.
Ok, podzielony na moduły, ale co z tego jeżeli modele używane do orm były używane w widoku. I potem powstawały jakieś potworki w templatkach razora. Jak się zapytałem jak myślał dodawać tam różne konstrukty (takie było wymaganie) to sie dowiedziałem, że nie planował :|.

@Biedny Rycerz to jest bardzo częsty błąd początkujacych programistów ;) Zwykle nie ma czasu na to żeby coś przepisywać od nowa i często nawet nie powinno się tego robić. Niektórzy mają takie przeświadczenie że "to jest źle napisane, ja bym zrobił lepiej", a potem męczą się kilka dni z listą wymagań i dochodzą do takiego samego albo gorszego rozwiązania, bo nagle okazuje się że lepiej przy istniejących ograniczeniach się nie da.

W pierwszych 4 miesiacach swojej pracy wlasnie to zrobilem. Poprawialem kod seniora na nowy od 0. Fakt, ze wymagania zmienily sie o 360 stopni, ale moje przedswiadczenie, ze zrobie to lepiej strasznie mnie zgubily. Poprawilem potwory ktore byly tam, ja za to dodalem kolejne potwory, bo po prostu nie poradzilem sobie sam z wymaganiami co do tego projektu (projekt robilem sam bez zadnego CR drugiej osoby), przez co projekt powstal na dosc kiepskim poziomie i teraz po roku doswiadczenia od czasu do czasu siadam go refaktorowac po godzinach bo jest mi po prostu wstyd.

Vlogger napisał(a):

Fakt, ze wymagania zmienily sie o 360 stopni

można mieć 60 IQ i robić w IT ?
MOŻNA

Sceptyczny Dinozaur napisał(a):

Vlogger napisał(a):

Fakt, ze wymagania zmienily sie o 360 stopni

można mieć 60 IQ i robić w IT ?
MOŻNA

To nawet nie takie żadne że wymagania się zmieniają żeby wrócić do pierwotnej formy po zmarnowaniu paru miesięcy. Szczególnie jak się freelanceruje.

Samodzielność jest wtedy gdy nie ma potrzeby by ktoś stał i Cię kontrolował czy dobrze coś robisz. Samodzielność jest wtedy gdy jak masz zadanie i brakuje Ci wiedzy by je zrobyć to zidentyfikujesz to i sam wyjdziesz z inicjatywą by tę wiedzę pozyskać. Samodzielność jest wtedy gdy dodatkowo sam zidentyfikujesz dodatkowe rzeczy do zmiany/poprawy.

Mimo proszenie o pomoc nikt ci nie pomógł, a tłumacząc kaczce swój problem doszedłeś do rozwiązania, oznacza to, że masz samotność poziomu pierwszego i da się z tym żyć, nikt nie jest doskonały, a ty zrobiłeś to tak jakby to inni robili, ale bóg i tak zawsze ci pomoże.

@Shalom

@Biedny Rycerz to jest bardzo częsty błąd początkujacych programistów ;) Zwykle nie ma czasu na to żeby coś przepisywać od nowa i często nawet nie powinno
się tego robić. Niektórzy mają takie przeświadczenie że "to jest źle napisane, ja bym zrobił lepiej", a potem męczą się kilka dni z listą wymagań i dochodzą do
takiego samego albo gorszego rozwiązania, bo nagle okazuje się że lepiej przy istniejących ograniczeniach się nie da.

Nie zgodziłbym się, że przepisywanie to błąd. Myślę, że raczej, że to zależy od skali. Przepisywanie dużej aplikacji to olbrzymie koszty, ale przepisywanie od zera małej aplikacji to koszty o wiele mniejsze (często w kilka dni można przepisać to, co było pisane w kilka miesięcy), za to ma się zysk w postaci zerowego długu technologicznego. Jak kod jest brzydki a aplikacja (pod kątem ficzerów, wymagań biznesowych) jest niewielka, to nie ma co się patyczkować i trzymać kod tylko dlatego, że ktoś go napisał. Co innego jeśli istniejąca już aplikacja realizuje wiele wymagań biznesowych i zawiera w sobie wiele gotowych ficzerów. Wtedy faktycznie ciężko przepisywać od nowa, tylko lepiej refaktorować (chociaż nawet w dużej aplikacji można czasem przepisać od zera jeden konkretny moduł)

No i nie zgodziłbym się, że Zwykle nie ma czasu na to żeby coś przepisywać od nowa , bo walka z legacy kodem zajmuje często więcej czasu niż przepisanie czegoś na czysto (trochę jak z testami - ludzie też mówią, że nie ma czasu pisać testów - a przecież samo napisanie testów dużo nie zajmuje wcale, a może oszczędzić czas w przyszłości)

Lukxxx napisał(a):

Samodzielność jest wtedy gdy nie ma potrzeby by ktoś stał i Cię kontrolował czy dobrze coś robisz. Samodzielność jest wtedy gdy jak masz zadanie i brakuje Ci wiedzy by je zdobyć to zidentyfikujesz to i sam wyjdziesz z inicjatywą by tę wiedzę pozyskać. Samodzielność jest wtedy gdy dodatkowo sam zidentyfikujesz dodatkowe rzeczy do zmiany/poprawy.

Chyba, że to jest januszsoft i szef ze swojego gabineciku co jakiś czas łypie oczkiem na openspace pracownicze i lecą hasła pokroju (jak nie wprost to półsłówkami) "jak to nie jest Pan w stanie tego wygooglać olaboga za co ja płacę" - z własnego doświadczenia. Nawiasem firma robiące zlecenia dla czołowych graczy pewnej działki IT z USA. Dodatkowo później jak przerywaliśmy współpracę "za obopulną zgodą" okazało się, że samodzielność dodatkowo miała obejmować realizację projektu (pierdułka na potrzeby wewnętrzne) w sposób wymarzony przez rzeczonego szefa, który nie wtrącał się w czasie realizacji ze swoimi wymaganiami co do projektu bo zostawił pole do popisu "dla samodzielności". No ale cóż, od tamtego czasu znalazłem pracę w IT, która wymaga nieco innych umiejętności niż telepatia, jasnowidzenie i dupowlaztwo.

@Biedny Rycerz to jest bardzo częsty błąd początkujacych programistów ;) Zwykle nie ma czasu na to żeby coś przepisywać od nowa i często nawet nie powinno się tego robić. Niektórzy mają takie przeświadczenie że "to jest źle napisane, ja bym zrobił lepiej", a potem męczą się kilka dni z listą wymagań i dochodzą do takiego samego albo gorszego rozwiązania, bo nagle okazuje się że lepiej przy istniejących ograniczeniach się nie da.

Oczywiscie nic nie zrozumiałes. Jesli chodzi o czas, to dostalem projekt do dokonczenia z informacja, ze senior b.dlugo go pisal...Po wstepnej analizie zawartosci i poznaniu domeny szybko sie zorientowalem, ze senior tak naprawde niewiele napisal ( mimo, ze b.dlugo pisal i zmarnwal naprawde duzo czasu). ...Nie wdajac sie w dalsze szczegoly moge stwierdzic, ze senior listy wymagan nie uwzglednl w ogole, a to co napisal przypominalo bardziaj jakas artystyczna, hermetyczna, poetycka impresje nie majaca nic wspolnego z domena problemu i dlugą listy wymagan. Ponadto nie umial ze mna rozmawiac na temat tego co napisal, bo napisal gowno kod. Pracuje dla tej firmy tylko dlatego, ze mi placa. Gdyby przestali placic, to z przyjemnoscia przeniose sie do innej, gdzie projekty wykonuje sie bardziej swiadomie z zachowaniem wszelkich procedur inzynierii oprogramowania.

Biedny Rycerz napisał(a):

Gdyby przestali placic, to z przyjemnoscia przeniose sie do innej, gdzie projekty wykonuje sie bardziej swiadomie z zachowaniem wszelkich procedur inzynierii oprogramowania.

Tylko nie zapomnij nam na forum podać nazwy takiej firmy. ;)

No właśnie, w IT nie ma prawdziwej hierarchii i senior może być w rzeczywistości juniorem, bo ktoś go zrobił seniorem przez pomyłkę. IT to nie polityka, że im wyższe stanowisko, tym osoba bardziej kompeten... Oh, wait XD

Samodzielność - umiejętność wykonania zadania bez nadzoru i opieki innych. Pracownik samodzielny nie prosi o wyjaśnienia jak coś zrobić, bo albo wie to sam od razu (bazując na wiedzy i doświadczeniu), albo jest w stanie znaleźć efektywne rozwiązanie (co też wymaga wiedzy i doświadczenia, żeby w ogóle móc szukać sensownych informacji na dany temat). W efekcie, samodzielny programista gdy ma problem, to nie mówi kolegom, że "nie umiem tego zrobić", a raczej: "Ten problem da się rozwiązać na sposoby A, B i C. Mam dylemat, który wybrać, bo A można wykonać najszybciej, w B będzie łatwiej wprowadzać zmiany w przyszłości, zaś C jest najbardziej wydajny.".

A praca zespołowa to pojęcie z zupełnie innej kategorii i całkowicie z samodzielnością niesprzeczne. W pracy zespołowej chodzi o to, żeby:

• Rozumieć, że wiele osób pracuje nad wspólnym celem, że nie jest to np. konkurencja między programistami a testerami, w której jedna ze stron ma dowieść swojej racji, tylko wszyscy razem mają wytworzyć produkt dobrej jakości.
• Umieć współpracować z ludźmi, umieć z nimi rozmawiać, nie obrażać się na krytykę, nie uznawać kogoś za głupca, tylko dlatego, że ma inne zdanie albo mniejszą wiedzę.
• Nie realizować swoich osobistych celów kosztem projektu. Np. nie bawić się tygodniami w refaktoryzację kawałka kodu, o którym wiadomo, że wypadnie z aplikacji za 2 miesiące.