robienie tylko tego, czego się od nas wymaga - nie więcej, nie mniej (czasem robienie więcej może zostać źle odebrane, bo robimy nie to, co powinniśmy i ktoś może pomyśleć, że nie rozumiemy wymagań i część takiej pracy może pójść do kosza)
To, to. Nie ma co być zbyt ambitnym, bo praca to nie jest jakieś laboratorium, w którym można testować sobie kolejne rozwiązania. Nie jesteśmy też żadnymi inżynierami, żeby tworzyć najlepsze rozwiązanie. Trzeba robić to, co każą, ani grama więcej. W przeciętnej firmie i tak ważniejsze jest zachowanie terminów niż rozwiązanie lepsze, ale dostarczone później i będzie zwykle ceniona bardziej szybkość od jakości (niestety).
Ja podchodziłem od drugiej strony, a potem rzeczy mi wolno szły, bo próbowałem zrobić jak najlepsze, albo jak najmocniej zrozumieć projekt (mimo, że w praktyce to nikt nie rozumie do końca dużych projektów i po prostu trzeba klepać w dużej mierze na ślepo, bardziej opierając się na intuicji i poradach kolegów z zespołu).
Jak ktoś jest idealistą, to lepiej żeby to robił po pracy, we własnym projekcie, bo w pracy trzeba zamykać taski.
kwestionowanie rozwiązań (np. jak czegoś nie rozumiesz, albo wydaje Ci się dziwne lub głupie, to zapytaj kogoś z zespołu dlaczego tak jest)
Dokładnie. Nie ma co się bawić w podejście "zatrudnili mnie hurra, muszę im udowodnić, że naprawdę się nadaję, bo spytanie o pomoc to wstyd, bo wyda się, że nic nie umiem" (tak miałem). Syndrom oszusta to samospełniająca się przepowiednia. Bo wtedy ukrywasz własną niewiedzę albo niekumatość. Więc nie rozumiesz poleceń ani projektu, a nie masz odwagi się przyznać. Więc lepiej już, żeby ktoś cię uznał za głupka i ignoranta, niż żeby się męczyć samodzielnie i dostawać zjebki, że "czemu jeszcze nie zrobione?".
Druga rzecz związana z syndromem oszusta, to podejście "muszę pracować bez przerwy, żeby było widać, że pracuję i że się nie opieprzam. A jak zrobię przerwę, to tylko przy komputerze i będę czytał jakieś artykuły na HackerNews czy ciekawostki o technologiach, żeby było widać, że dalej robię coś związanego z pracą, nawet jeśli to przerwa"
Niestety takie podejscie sprawiało, że czułem się wyczerpany po iluś godzinach (z przerwami tylko na kawę czy toaletę) i głodny (nie zawsze jadłem obiad). Więc moja wydajność się zmniejszała przez to i nie mogłem już patrzeć na kod. Szczególnie, że ogólnie łatwiej mi myśleć nad rozwiązaniem z dala od kompa. Jak siedziałem cały czas przy kompie "na pokaz", to ciężko mi było się skupić nad rozwiązaniem.