Co się dzieje jeśli macie problem z rozwiązaniem jakiegoś problemu i nic nie przychodzi wam do głowy a pracodawca naciska?
Czy ktoś kto stara się o pracę powinien bigle znać daną technologię, tak aby nie mieć żadnych problemów? W przeciwnym razie grozi to wyrzuceniem z pracy?
0
0
2 i 3 pytanie już było zadane na tym forum.
2
"Biegle" -- na pewno nie, na pewno nie na każde stanowisko. Przecież firmy zatrudniają też i junior developerów, którzy miewają spore luki w wiedzy.
Ja problemy typu "nie mam pomysłu jak to rozwiązać" miałem może na początku studiów, ale potem jakoś to zaczęło stopniowo mijać. Inna sprawa, że nie robię nie wiadomo jak trudnych/odkrywczych rzeczy. Ale wiem, że i z tym, co ja robię, i z czymś łatwiejszym całkiem sporo osób miewa problemy typu "nie wiem jak to ugryźć".
Myślę, że te problemy mijają wraz z doświadczeniem. Takim dobrym doświadczeniem: nie że "pracuję od X lat", tylko "pracuję od X lat, cały czas się ucząc". Rozwiązałem już sporo problemów, dobrze znam języki, w których piszę. Biblioteki też. A jak używam technologii, której jeszcze nie znam, to używam doświadczenia w przeszukiwaniu dokumentacji.
To wszystko brzmi banalnie, ale po forum widać, ilu ludzi pyta się o podstawy w necie i zawraca innych głowę rzeczami, które spokojnie można znaleźć w dokumentacji lub rozwiązać, używając logiki.
Dla mnie, rozwiązywanie problemów jest teraz dość mechaniczne. Dotyczy to zarówno projektowania aplikacji, jak i pisania kodu czy debugowania. Dzielenie problemu nad podproblemy. Identyfikacja niezmienników, wejścia i wyjścia dla wszelkie maści "black boxów" (procedur, obiektów). Gdy trzeba, zaczynanie od napisania kodu wysokopoziomowego i schodzenie coraz niżej, pisząc banalnie wyglądające, parolinijkowe funkcje.
Jest błąd? Nie należy się denerwować. Mówienie "to niemożliwe" nic nie da, bo to się właśnie stało. Błąd nie leży w bibliotece ani w systemie operacyjnym, tylko najpewniej w moim kodzie. Błąd można namierzyć metodą połowienia: występuje gdzieś w obrębie tych 200 linii? To sprawdźmy, czy występuje już w setnej. Nie? To 150. Tak? To 125. Nadal? To 113. Szybko ograniczamy się do kilku linijek i błąd się sam pojawia. Dzieje się coś przypadkowego? To może być sytuacja tzw. wyścigu lub inny problem związany ze współbieżnością.
A najlepiej używać testów. Ostatni raz w trybie TDD programowałem... dzisiaj (w zasadzie to BDD, ale to tutaj mniej więcej jeden czort). Kod testów był oczywiście dłuższy niż sam moduł, ale wykryły z miejsca dwa czy trzy zupełnie durne błędy, których usunięcie w późniejszej fazie byłoby znacznie trudniejsze i droższe.
Trochę algorytmiki też się przydaje. Przynajmniej podstawy. Nawet dla złożonych problemów powinniśmy być w stanie wymyślić choćby niewydajne rozwiązanie brute force.
Po nabraniu pewnego doświadczenia ma się we łbie pewien zestaw narzędzi i procedur. Taki przybornik programisty. Te narzędzia i procedury są w większości proste, lub nawet wydają się banalne. Stosowane konsekwentnie rozwiązują jednak większość typowych problemów. Czytałeś książkę "Sztuka wojenna" mistrza Sun Tzu? (lub Sun Zi -- pisownia różna) Jeśli nie, to polecam. Nie bez powodu tę prastarą książkę czytają współcześni managerowie i... programiści. Tam też opisany jest zbiór prostych reguł. Żadna nie wydaje się górnolotna. Zastosowanie wszystkich jednak czyni ze strategii i taktyki prawdziwą sztukę.
Takie inżynierskie, nieco mechaniczne podejście do problemów brzmi jak coś mało kreatywnego, ale nie jest w ten sposób odczuwalne. Zdarzają się oczywiście przebłyski -- czasami wpadają do głowy oryginalne i fajne rozwiązania. Fajne jest jednak to, że nie musimy polegać na przebłyskach. Praktycznie zawsze mózgownica podsunie nam standardowe rozwiązanie, do którego będziemy mogli się uciec. A jak coś fajnego wymyślimy, to super.
Mi czasami zdarzają się problemy, przy których mówię "o szlag, to mnie zmusi do użycia X". Z jakiś powodów, nie chce mi się użyć tu X-a -- szukam wtedy prostszego rozwiązania. Czasem znajdę, czasem nie.
W pracy stresu żadnego nie odczuwam. Za młodu ;) chyba miałem lekkiego cykora, że czegoś nie będę wiedział. Potem jednak nabrałem pewności siebie. Nie to, że umiem zrobić wszystko (choć nie pracuję przy budowie rakiet kosmicznych, więc na co dzień niemal wszystko mi w miarę wychodzi). Po prostu wiem, że inni programiści też nie są nieomylni, nie są supergeniuszami i też mogą mieć gorszy dzień. Ja mogę mieć jakiś problem z jakimś zadaniem, ale równie dobrze może mieć z tym problem inny programista.
Aha: ja pracuję jako senior developer. W sumie, aktualnie bodaj jedyny w teamie. Więc niby nacisk jest większy. Zawsze starałem się jednak realizować taktykę, by "nie być słabeuszem". Byłem kiedyś newbie, ale nie byłem supersłabym newbie. Po roku nauki programowania nie byłem dużo słabszy niż inni ludzie z moim stażem. Po dwóch i pięciu latach to samo. Uczę się na tyle sporo, że wiem, że nie byłem i nie jestem znacznie poniżej przeciętnej.
Dlatego nawet teraz, jako niby ten doświadczony, nie boję się przyznać, że coś spieprzyłem (a to się nieraz zdarza!), czy że czegoś nie wiem. To drugie zdarza się jeszcze częściej. Ale tutaj już funkcja mnie zobowiązuje: mam niezłe rozeznanie w wielu różnych dokumentacjach i specyfikacjach, więc jak mnie się ktoś pyta o coś, czego nie jestem pewien, to po prostu tam to sprawdzam.
Nie słyszałem, by u nas manager kogokolwiek ochrzanił za brak wiedzy. Gdy któryś zauważy problem u jakiejś osoby w jakimś obszarze, to raczej kombinuje, jak tu tę osobę doszkolić. Najprościej: niech ktoś bardziej doświadczony mu pomoże/wytłumaczy.
Warto zauważyć, że jeśli zostałeś przyjęty do pracy, a potem okazałeś się dużo za słaby, to jest to spora porażka rekrutujących. W zasadzie nie powinieneś się za bardzo przejmować swoim poziomem (oprócz tego pozytywnego stresiku, mobilizującego do nauki) tak długo, jak długo nigdy co do niego nie kłamałeś. Tzn. jeśli nie ściemniałeś w CV czy na rozmowie rekrutacyjnej, że coś robiłeś/coś wiesz, a nie wiesz.
Tak czy siak, dobrzy pracodawcy dążą do tego, by programista miał jak najmniej stresu w robocie. U mnie jest go baaaaaaardzo mało, o ile w ogóle można to nazwać "stresem". W moim teamie (i chyba w ogóle w całej korporacji) kultywujemy to podejście począwszy od samej rozmowy kwalifikacyjnej. Nawet na niej nie chodzi o to, by się stresować -- ma być możliwie luźnie, bo i w pracy stresu nie ma, więc nie ma sensu sprawdzać, jak kto na niego reaguje.
0
osobiscie czesto mam tak, że po jakimś dłuższym czasie siedzenia nad czymś mózg się wyłącza... wtedy pomaga albo odłożenie problemu na drugi dzień, albo to po co stworzono pracę zespołową - pytam kolegów czy mają jakiś pomysł/ewentualnie przekazuje zadanie. W zgranym zespole w którym jest koleżeńska atmosfera nikt Ci nie wytknie, że był 'lepszy' bo zrobił zadanie z którym miałeś problem. Bo za parę dni to Ty podpowiedz / przejmiesz coś od kogoś. Ja mam niesamowitą satysfakcję jak mogę komuś pomóc. Wtedy czuję, że douczanie się ma jakiś sens :)
Zarabiam programując dopiero 3 lata. Myślę, że z czasem coraz mniej zadań stwarza problem... nie w sensie, że z góry wiesz jak wszystko zrobić, ale orientujesz się jak coś ugryźć w miarę sprawnie.
Stres? Przecież robimy to co lubimy :)
0
roymoss napisał(a)
Co się dzieje jeśli macie problem z rozwiązaniem jakiegoś problemu i nic nie przychodzi wam do głowy a pracodawca naciska?
Czy ktoś kto stara się o pracę powinien bigle znać daną technologię, tak aby nie mieć żadnych problemów? W przeciwnym razie grozi to wyrzuceniem z pracy?
Nie miałem nigdy takiej sytuacji, może dlatego, że nigdy nie skłamałem w CV, albo dlatego, że jestem pasjonatem, który odnajduje się w rozwiązywaniu problemów, a nie w bezradnym rozkładaniu rąk.
0
roymoss napisał(a)
Co się dzieje jeśli macie problem z rozwiązaniem jakiegoś problemu i nic nie przychodzi wam do głowy a pracodawca naciska?
Mowie mu zeby sie odpierdolil na jakis czas bo mysle nad rozwiazaniem problemu i zawracanie mi d**y na pewno nie pomoze.
roymoss napisał(a)
Czy ktoś kto stara się o pracę powinien bigle znać daną technologię, tak aby nie mieć żadnych problemów?
Nie.
roymoss napisał(a)
W przeciwnym razie grozi to wyrzuceniem z pracy?
No jak jestes kretyn i nic nie umiesz i nie jestes w stanie niczego sie nauczyc to tak.