Cześć
Mam pewien problem. Programowanie idzie mi dość wolno. Jak tworze jakiś kod, to dużo mi to zajmuje czasu i nie mam pojęcia czemu. Zawsze jestem pośpieszany przez szefa, i jak próbuje zrobić coś szybko to zawsze to nie działa. Długo już pracuje jako programista, ale wydaje mi się że idzie mi coraz wolniej, o podwyżkę nie poproszę bo w mojej pracy nie ma postępów. Proszę o pomoc.
0
1
Nie każdy ma te same predyspozycje/zdolności.
Opcje:
- będziesz pracował by być lepszy,
- poszukasz czegoś w czym jesteś dobry.
Słabe jest, że nie wiesz czemu, dobrze jest mieć świadomość własnych słabych stron i tych mocnych, wtedy mozna cos z tym zrobić a tka to wiesz...
2
czasami lepiej robić wolniej, a dokładnie, czysty kod, poprawne opisy, chociaż wiadomo, że janusz ma zgryz "bo piniondze z firmy uciekajo" :)
1
Weź się zastanów jakie fragmenty pracy zajmują ci najwięcej czasu. Możesz nawet mierzyć to co do minuty i zapisywać (są nawet programy do timetrackingu).
Zastanów się jak możesz przyśpieszyć daną rzecz. Albo zautomatyzować za pomocą jakiegoś skryptu.
Zawsze jestem pośpieszany przez szefa, i jak próbuje zrobić coś szybko to zawsze to nie działa. Długo już pracuje jako programista, ale wydaje mi się że idzie mi coraz wolniej, o podwyżkę nie poproszę bo w mojej pracy nie ma postępów. Proszę o pomoc.
Zastanów też się czy przyczyna twojego braku wydajności nie leży w firmie jako takiej, w rodzaju zadań jakie na ciebie są zrzucane, w organizacji, w komunikacji między tobą a współpracownikami itp.
Czasem najlepsze co można zrobić, to pożegnać się z firmą.
0
Nie rób szybko tylko dokładnie, mierzeniu czasu to dobry pomysł, np. Timble (darmowy i bardzo prosty w obsłudze). Programowanie nie polega na pisaniu jak największej ilości kodu, tylko stworzeniu czegoś "co ma ręce i nogi" :)
7
Zawsze jestem pośpieszany przez szefa
Zmień szefa. Może się okazać, że wraz z nim odejdą wszystkie twoje problemy...
2
Zastosuj radę @aurel, a jakby i to nie pomogło, to przejdź z klepania kodu ja jego utrzymanie/optymalizację czy na stanowisko architekta.
Te zadania są przynajmniej tak samo trudne, ale za to czasu na zastanowienie się i dokładne działanie jest już znacznie więcej.
0
A mi się podoba, że wszyscy tutaj obecni z automatu założyli, że to wina wszystkiego, tylko nie braku umiejętności. Naprawdę nikt nie spotkał się z ludźmi, którzy na zadania wycenione na 4h - a i to z okładem na kwejka z przodu i Youtube'a z tyłu - potrzebowali dwóch dni? I to nie tylko domena juniorów, osoba z dwuletnim doświadczeniem tak się uwijała.
Moje rady:
- Sprawdź, jak wygląda Twoja wydajność w domu. Na pewno możesz znaleźć podobne zadania.
- Jeśli wolniej - to ćwicz. I ćwicz. I ćwicz. Po prostu brakuje Ci biegłości w programowaniu i musisz się tego nauczyć, nikt się za Ciebie tego nie nauczy, co najwyżej z pracy wylecisz.
- Jeśli w pracy idzie Ci zdecydowanie wolniej niż w domu - to może rzeczywiście być coś nie tak. Rozejrzyj się po rynku.
2
Biały Jeleń napisał(a):
Zastosuj radę @aurel, a jakby i to nie pomogło, to przejdź z klepania kodu ja jego utrzymanie/optymalizację czy na stanowisko architekta.
Te zadania są przynajmniej tak samo trudne, ale za to czasu na zastanowienie się i dokładne działanie jest już znacznie więcej.
No tak, każdy pracodawca przecież marzy o tym, aby wziąć na architekta gościa, który się z zadaniami programistycznymi nie wyrabia. :D
wartek01 napisał(a):
I to nie tylko domena juniorów, osoba z dwuletnim doświadczeniem tak się uwijała.
A kim niby jest osoba z dwuletnim doświadczeniem, jak nie juniorem?
1
@somekind
Firma przede wszystkim powinna od architekta wymagać dobrej architektury, a nie szybkości pisania kodu, bo nie po to on jest.
Ja wiem, że bardzo często w firmach panuje założenie, że jak ktoś jest dobrym programistą to będzie dobrym architektem(vide https://en.wikipedia.org/wiki/Peter_principle), ale to jest zupełna bzdura.
Wymyślić jak coś dobrze zrobić, a to dobrze i szybko zaimplementować to są 2. różne kwestie.
To są oddzielne zadania, wymagające oddzielnych umiejętności.
Oczywiście bycie dobrym koderem będzie pomagać, ale zdecydowanie to nie wystarczy, ani nawet nie jest decydujące.
0
A mi się podoba, że wszyscy tutaj obecni z automatu założyli, że to wina wszystkiego, tylko nie braku umiejętności. Naprawdę nikt nie spotkał się z ludźmi, którzy na zadania wycenione na 4h - a i to z okładem na kwejka z przodu i Youtube'a z tyłu - potrzebowali dwóch dni? I to nie tylko domena juniorów, osoba z dwuletnim doświadczeniem tak się uwijała.
Oczywiście to możliwe. Jednak taka osoba raczej nie stanie się lepszym programistą od tego, że ktoś nad nią będzie stał i mówił: "szybciej, szybciej!".
0
Naprawdę nikt nie spotkał się z ludźmi, którzy na zadania wycenione na 4h - a i to z okładem na kwejka z przodu i Youtube'a z tyłu - potrzebowali dwóch dni? I to nie tylko domena juniorów, osoba z dwuletnim doświadczeniem tak się uwijała.
To może zadanie było źle wycenione?
Poza tym... co to jest "dwa dni" na skalę jednego zadania? Okej, jeśli każde zadanie będzie w ten sposób opóźniane to co innego. Ale jeśli to było pojedyncze zadanie to 2 dni jest tyle co nic.
No i, w takich przypadkach należy usiąść i pomyśleć skąd wynikają opóźnienia (żeby uniknąć podobnych rzeczy w przyszłości), a nie zakładać, że winny jest programista.
1
LukeJL napisał(a):
Naprawdę nikt nie spotkał się z ludźmi, którzy na zadania wycenione na 4h - a i to z okładem na kwejka z przodu i Youtube'a z tyłu - potrzebowali dwóch dni? I to nie tylko domena juniorów, osoba z dwuletnim doświadczeniem tak się uwijała.
To może zadanie było źle wycenione?
Poza tym... co to jest "dwa dni" na skalę jednego zadania? Okej, jeśli każde zadanie będzie w ten sposób opóźniane to co innego. Ale jeśli to było pojedyncze zadanie to 2 dni jest tyle co nic.
No i, w takich przypadkach należy usiąść i pomyśleć skąd wynikają opóźnienia (żeby uniknąć podobnych rzeczy w przyszłości), a nie zakładać, że winny jest programista.
Ludzie nie umieją estymować, ile coś zajmie, a już tym bardziej w wycenianiu czasu potrzebnego na programowanie. Po prostu ludzki mózg tego nie umie i raczej się nie nauczy. Okej, czasem można to zrobić, ale uważam, że nie powinno się. Zespoły, które pracują ze sobą dłużej IMO powinny wyceniać w abstrakcyjnych jednostkach, nie związanych z godzinami/dniami np. punktach czy żelkach.
0
wartek01 napisał(a):
A mi się podoba, że wszyscy tutaj obecni z automatu założyli, że to wina wszystkiego, tylko nie braku umiejętności. Naprawdę nikt nie spotkał się z ludźmi, którzy na zadania wycenione na 4h - a i to z okładem na kwejka z przodu i Youtube'a z tyłu - potrzebowali dwóch dni? I to nie tylko domena juniorów, osoba z dwuletnim doświadczeniem tak się uwijała.
Przykład z życia (świeży!).
Klient wymaga włączenia funkcjonalności, którą kiedyś wywaliliśmy ze względu na błędy w renderowaniu UI.
No to szybkie spojrzenie w historię i już wiadomo co było zmienione (usunięte dwie linijki + 2 relokacje metod, nic nadzwyczajnego).
Zrobiłem szybki revert... nie działa.
Po wnikliwej analizie - zmiana w pewnej bibliotece zewnętrznej. No to fallback. Nie dość, że nadal nie działa, to jeszcze x innych rzeczy się zaczyna pier...dzielić, bo doszły nowe funkcje z których korzystamy. Angażuje się kilka osób więcej, sprawa ma spory priorytet.
Wniosek - albo klient przerzuca się na nowo rozwijaną wersję, albo czeka. Przerzucić się nie chce, więc kopiemy dalej. Na razie bez skutków.
Task, który spokojnie mógłby być oszacowany wstępnie na te 3-4h (patrząc na logi z gita) zajmuje już grubo ponad miesiąc, w tym także osobom, które architekturę tego systemu znają lepiej ode mnie. I zanosi się na to, że jedyną opcją będzie upgrade.
0
Po wnikliwej analizie - zmiana w pewnej bibliotece zewnętrznej. No to fallback. Nie dość, że nadal nie działa, to jeszcze x innych rzeczy się zaczyna pier...dzielić, bo doszły nowe funkcje z których korzystamy. Angażuje się kilka osób więcej, sprawa ma spory priorytet.
Brzmi jak syndrom braku testów i złego designu aplikacji.
Ale dlatego właśnie nie należy winić z miejsca programisty, do którego przypisany jest dany task, bo możliwe, że on tylko spłaca dług techniczny zaciągnięty jeszcze przez poprzednich programistów.
3
Biały Jeleń napisał(a):
Firma przede wszystkim powinna od architekta wymagać dobrej architektury, a nie szybkości pisania kodu, bo nie po to on jest.
A czy ja gdzieś napisałem, że architekt ma pisać kod?!
Ja wiem, że bardzo często w firmach panuje założenie, że jak ktoś jest dobrym programistą to będzie dobrym architektem
Być może. Jest ono równie głupie, jak założenie, że na architekta nadaje się ktoś, kto z programowaniem sobie nie radzi.
Oczywiście bycie dobrym koderem będzie pomagać, ale zdecydowanie to nie wystarczy, ani nawet nie jest decydujące.
Ale kto twierdzi, że wystarczy? :|
Na architekta nadaje się ktoś, kto ma wieloletnie praktyczne doświadczenie w programowaniu, wziął udział w wielu projektach, zarówno udanych, jak i nie, jest proaktywny, odpowiedzialny, patrzy systemowo, potrafi przewidywać problemy zanim nastąpią, ma szeroką wiedzę technologiczną, projektową a także biznesową.
Ktoś, kto jest słabym albo niedoświadczonym programistą, na architekta się po prostu nie nadaje.
Oczywiście są firmy, w których wystarczy być szwagrem szefa albo pójść z nim do łóżka, żeby zostać architektem, ale to jakby patologia.
1
@somekind
Czy jeżeli ktoś ma wieloletnie doświadczenie, brał udział w wielu projektach i potrafi przewidzieć konsekwencje zastosowania jakiegoś podejścia/frameworku, ma dużą wiedzę i jest proaktywny, ale jednocześnie w prostych zadaniach z dużą ilością kodu do napisania jest ślimakiem, to już architektem będzie złym?
Dla mnie to trochę jak z pingpongiem i szachami.
To, że ktoś sobie nie radzi w szybkiej akcji, nic nie mówi o tym czy będzie sobie dobrze radził w kwestiach gdzie dużo ważniejsza jest strategia, a czas schodzi na dalszy plan.
Ja nigdzie nie napisałem, że autor tematu będzie dobrym atchitektem(z tym doświadczeniem pewnie nie), ale skoto "pingpongistą" nie jest to może wypadało by sprawdzić czy nie lepszym rozwiązaniem są dla niego "szachy", bo to wymaga zupełnie innych zdolności i predyspozycji.
0
@aurel
@LukeJL
@datdata
@xfin
Gwoli ścisłości - tak, wiem, że istnieje coś takiego jak "ukryte g*wno", tzn. proste z pozoru zadanie, nad którym siedzi się tygodniami. Zdarzyło mi się źle wycenić zadanie.
I ten przypadek, który miałem na myśli do nich nie należał. Sprawa była naprawdę prosta, i - jestem prawie pewien - że większości nie zabrałoby to więcej niż te 4h, zwłaszcza, gdy korzysta się z ogarniętego IDE. Tutaj nie padło żadne sensowne wytłumaczenie. Druga sprawa była taka - to nie był odosobniony przypadek.
Próbowaliśmy jako zespół coś z tym zrobić. Pytałem człowieka, czy wszystko w porządku itp. Nic poza jakimiś dziwnymi tekstami w stylu "a X przecież też się kiedyś spóźnił".
Po prostu sprawa jest taka - dzisiaj założenie "pracuje jako programista więc jest zapaleńcem" jest fałszywe. Obecnie na programistów startują ludzie, którzy chcą pracować 8-16 i potem z programowaniem nie mieć nic wspólnego. To jest jak najbardziej w porządku dopóki taki człowiek robi to, co do niego należy i robi to na dobrym poziomie. W tym konkretnym przypadku mieliśmy do czynienia z olewaczem, którego przepuściły HRy i człowiek od rozmów technicznych.
Biały Jeleń napisał(a):
Dla mnie to trochę jak z pingpongiem i szachami. To, że ktoś sobie nie radzi w szybkiej akcji, nic nie mówi o tym czy będzie sobie dobrze radził w kwestiach gdzie dużo ważniejsza jest strategia, a czas schodzi na dalszy plan.
Trochę nietrafione porównanie, bo to są dwie nieobejmujące się dziedziny sportu.
Wydaje mi się, że lepiej porównać obie profesje do szachów standardowych (programowanie) i błyskawicznych (architektura). To, że ktoś jest dobry w normalnych szachach nie znaczy jeszcze, że będzie dobry w błyskawicznych. W drugą stronę działa to tak, że wymiatacz w szachach błyskawicznych wcale nie musi być wymiataczem w standardowych. Ale jeśli ktoś sobie kompletnie nie radzi w szachach normalnych, to nie ma co liczyć, że będzie dobry w błyskawicznych.
3
Biały Jeleń napisał(a):
@somekind
Czy jeżeli ktoś ma wieloletnie doświadczenie, brał udział w wielu projektach i potrafi przewidzieć konsekwencje zastosowania jakiegoś podejścia/frameworku, ma dużą wiedzę i jest proaktywny, ale jednocześnie w prostych zadaniach z dużą ilością kodu do napisania jest ślimakiem, to już architektem będzie złym?Dla mnie to trochę jak z pingpongiem i szachami.
To, że ktoś sobie nie radzi w szybkiej akcji, nic nie mówi o tym czy będzie sobie dobrze radził w kwestiach gdzie dużo ważniejsza jest strategia, a czas schodzi na dalszy plan.
A od kiedy pisanie kodu jest pracą na czas? Piszesz tak, jakby szybkość napieprzania w klawiaturę miała jakiekolwiek znaczenie. Jeśli wynika to z Twojego doświadczenia zawodowego, to Ci szczerze współczuję.
Zarówno pisanie kodu jak i architektura to zajęcia wymagające wyłącznie myślenia. Architektura jednak wymaga go więcej, bo jest na wyższym poziomie abstrakcji, i o ile schrzaniony kod zawsze można poprawić, to schrzanionej architektury już nie. (No chyba, że w następnym projekcie.)
Trzeba być najpierw dobrym programistą, żeby móc zostać dobrym architektem. Architekt to najwyższe stanowisko techniczne w naszej branży. A Ty je proponujesz koledze, który ma problemy w pracy kilka poziomów niżej. To tak, jakbyś gimnazjaliście, który ma problemy z biologią, zaproponował stanowisko ordynatora chirurgii.