✨️ Jak ADHD wpływa na moją karierę programisty?Ⓘ Zajmuję się zawodowo programowaniem (backendowym) i mam duże doświadczenie, ale cierpię na ADHD, przez co nie odniosłem w branży sukcesu.
Co myślicie o tym, co niżej opisałem i co (kieruję to zwłaszcza do ludzi z #programowanie i #pracait) byście poradzili, żebym robił inaczej?
Jeszcze takie pytanie: czy gdybym sobie przez jakieś dwa lata popracował w czymś dla mnie luźniejszym (ale słabo płatnym) np. w marketingu w małej firmie mojego znajomego, bardzo by to w przyszłości rekruterom w firmach IT przeszkadzało? Bo na np. 4programmers polecają, żeby prac spoza IT w ogóle w CV nie wymieniać. Oczywiście już teraz w CV robię sporo optymalizacji.
Moje style pracy
Zadania wykonuję na jeden z trzech sposobów, przeważnie wybieram nr 2. Z każdym jest coś nie tak.
Dotyczy każdego tworzonego przeze mnie kodu, dokumentacji, wysyłanych e-maili, itd. Opiszę na przykładzie kodu, ale problem nie jest ograniczony do samego kodu.
Sposób nr 1: pisanie wszystkiego "normalnie", jak inni ludzie. Ale wtedy jest pełno błędów w przypadkowych miejscach spowodowanych tym, jaki ja "roztrzepany" jestem. Znacznie więcej niż ludzie są w stanie zaakceptować.
Sposób nr 2, mój główny: (1) robię coś jeden raz, np. piszę kod jakiegoś endpointa API, ale nie uznaję jeszcze tego za zrobione, po czym przechodzę do innych, niezwiązanych spraw, żeby zapomnieć co dokładnie napisałem (2) jakiś czas później robię to samo drugi raz np. piszę kod tego samego endpointa API jeszcze raz, tak jakbym to robił po raz pierwszy, bez kopiowania ani nawet zaglądania do rozwiązania z punktu (1) (3) w efekcie mam dwa rozwiązania tego samego problemu, gdzie każde ma wiele dziwnych błędów spowodowanych nieuwagą, ale w jednym te błędy są inne niż w drugim - następnie używam tych dwóch rozwiązań do stworzenia ostatecznego - to, co w tych dwóch jest identyczne po prostu przekopiowuję, a tam gdzie w tych dwóch jest jakaś istotna różnica, zastanawiam się dlaczego i wybieram jedną z dwóch wersji jako dobrą, zazwyczaj doskonale widać którą trzeba wziąć, bo są to problemy typu np. pisząc ten endpoint raz z roztrzepania napisałem $fieldValue = $row['price'], a innym razem poprawnie $fieldValue = Utils::formatPriceAsJsonFragment($row['price'], $row['currency'])
Końcowa jakość jest wtedy podobna jak u innych ludzi. Błąd może powstać tylko na dwa sposoby: jeżeli dwa razy pomyliłem się identycznie robiąc to samo (mało prawdopodobne, bo te błędy spowodowane moim ADHD są losowo porozrzucane) lub gdy podczas tworzenia ostatecznego rozwiązania z dwóch niezależnych wstępnych rozwiązań pomyliłem się przy wybieraniu, w którym z tych dwóch wstępnych rozwiązań dany fragment jest dobry, a w którym jest zły, co się prawie nigdy nie zdarza.
Problem: ludzie narzekają na tempo pracy. Chociaż jakość jest dobra.
Sposób nr 3: (1) robię coś normalnie, jest w tym pełno przypadkowych błędów
i teraz w pętli, do czasu aż podczas n-tej analizy wyjdzie, że jest ZERO znalezionych problemów, albo gdy się boję, bo to jakiś hotfix itp. to gdy dwa razy z rzędu tak wyjdzie: ----- (2) analizuję od góry do dołu napisany kod, czy dla każdego wejścia da właściwy wynik itd., czy zachowa się dobrze przy niedostępnościach zewnętrznych usług sieciowych itd., wypisując co jest źle (oczywiście zdaję sobie sprawę z tego, że prawie na pewno czegoś nie zauważę podczas sprawdzania) ----- (3) naprawiam to co wypisałem że wymaga naprawienia (niestety powstają tutaj kolejne błędy, ale przypominam że powtarzam te analizy w pętli na coraz bardziej naprawionym kodzie aż zejdę z problemami do zera)
(4) gdy skończę w powyższej pętli przerabiać kod, mam kod o sensownej jakości
Problem: ludzie narzekają na tempo pracy. To zajmuje jeszcze więcej czasu niż sposób nr 2, bo punkty (2) i (3) muszę powtarzać np. 7 razy, aż liczba znalezionych problemów z moim rozwiązaniem spadnie do zera (wychodzi np. 15 rzeczy do naprawienia, przy drugim sprawdzeniu 10 - trochę niezauważonych krok wcześniej, trochę nowych spowodowanych naprawami krok wcześniej, 7 rzeczy, 4 rzeczy, 2 rzeczy, 1 rzecz, 0 rzeczy - koniec). Jakość wychodzi znacznie wyższa niż przy sposobie nr 1, trochę niższa niż przy sposobie nr 2. Ale, w przeciwieństwie do sposobu nr 2, nie ma tu kroku "przechodzę do innych, niezwiązanych spraw, żeby zapomnieć co dokładnie napisałem", wymagającego żeby mieć możliwość przejścia dalej do czegoś innego na trochę czasu.
Moja historia zatrudnienia firma 1 - nie przedłużyła umowy po okresie próbnym - za mała dokładność w pracy (wtedy jeszcze pracowałem głównie według sposobu nr 1 z powyżej opisanych, nie nr 2) firma 2 - nie przedłużyła umowy po okresie próbnym - za niskie tempo firma 3 - 2 lata było im ze mną dobrze, później wprowadzili rejestrację czasu pracy, gdzie miałem cały czas problemy typu: za dużo godzin "non-billable", za dużo przekroczeń "budżetu" (liczonego w godzinach), a gdy nie wpisywałem wszystkiego (przekroczeń dozwolonego według budżetu czasu) to były pretensje o godziny niesumujące się do 8 dziennie, po 4 latach od zatrudnienia wyleciałem za wydajność firma 4 - nie przedłużyła umowy po okresie próbnym - za niskie tempo firma 5 - zatrudniła, przez 2,5 roku było dobrze, następnie nałożyła na mnie (tylko mnie) zakaz pracy zdalnej (chociaż później i tak uznałem, że praca zdalna jest chyba nie dla mnie, przy zdalnej jest znacznie więcej oskarżeń w moim kierunku o podejrzewane zajmowanie się nie tym co trzeba itd. niż przy stacjonarnej), a po 4,5 roku od zatrudnienia dokonała fikcyjnej likwidacji mojego stanowiska (tylko mojego) firma 6 - nie przedłużyła umowy po okresie próbnym - za niskie tempo gdy dbałem o jakość + zbyt mocne obniżenie jakości przy próbie zwiększenia tempa poprzez pracę "bardziej normalnym" niż mój standardowy sposobem (problemy typu white screen of death, zera zamiast cen co chwilę, przypadkowe wklejenia do plików z kodem rzeczy niebędących kodem, przypadkowe pomijanie kawałków zadań i uznawanie części zrobionej za całość zrobioną itd.) firma 7 - na razie jedną wypłatę dostałem, chociaż standardowe pretensje do mnie są, tylko nie wiadomo czy firmie to aż tak przeszkadza, że się mnie jak inne pozbędzie, czy nie aż tak
Leki? Mam ADHD ale zdecydowanie nie mam takich problemów związanych z pracą. Co najwyżej problem z robieniem rzeczy, które mój wewnętrzny algo uzna za zbyt mało interesujące ale LLMy pomogły z tym.
@greedy_critic znasz może jakieś fajne materiały/sposoby gdzie moznaby nabyć wiedzy na ten temat. Też mi zdiagnozowali adhd ale nadal uważam że to Przykrywka i da się nad tym pracować.
@mirko_anonim: W sumie mam podobny problem, ale obecnie stosuję weryfikacje swoich wypocin copilotem i on takie bzdury spowodowane nieuwagą wyłapuje. (typu literówki, odwrócona kolejność działań, etc.) A w sumie to brzmi, jakbyś był skrojony pod TDD, jak napiszesz sobie sensowne przypadku użycia, to edge case Ci nie uciekną i nie będziesz musiał ich analizować.
1. Task switching który stosujesz w sposobie drugim to najgorsze co możesz zrobić. Nie ma czegoś takiego jak efektywne robienie kilku rzeczy na raz. Były na ten temat badania, wyszło że ludzie którzy mieli robić kilka rzeczy na raz pracowali tak, jakby mieli o kilkanaście - kilkadziesiąt punktów IQ mniej.
punktualny-sojusznik-84: A jak z twoją fizjologią organizmu? Wydalasz normalne satysfakcjonujące wielkości wydzielin z ciała? Przyjmujesz normalne sycące porcje substancji odżywczych albo innych rzeczy które potrzebuje ciało? Tyczy się wszystkiego łącznie z umysłowymi rzeczami. Dasz radę codziennie godzinę czasu w normalnej pozie bez żadnych problemów np. zrobić marsz?
Zauważyłeś jakieś nieprawidłowości albo dziwne rzeczy w działaniu czy wyglądzie twoje ciała? Czy twoja sylwetka jest prawidłowa? wpisz sobie prawidłowa sylwetka gooogle.
@mirko_anonim: Jakieś dziwne firmy Ci się trafiały, a raczej nie znające się na rzeczy. Kodu się nigdy nie klepie na wyścigi. Może musisz zmienić zupełnie firmy które wybierasz i dopasować je do siebie, poszerzyć umiejętności? Klepanie jakiś requestów na czas wydaje się głupie.
Zajmuję się zawodowo programowaniem (backendowym) i mam duże doświadczenie, ale cierpię na ADHD, przez co nie odniosłem w branży sukcesu.
Co myślicie o tym, co niżej opisałem i co (kieruję to zwłaszcza do ludzi z #programowanie i #pracait) byście poradzili, żebym robił inaczej?
Jeszcze takie pytanie: czy gdybym sobie przez jakieś dwa lata popracował w czymś dla mnie luźniejszym (ale słabo płatnym) np. w marketingu w małej firmie mojego znajomego, bardzo by to w przyszłości rekruterom w firmach IT przeszkadzało? Bo na np. 4programmers polecają, żeby prac spoza IT w ogóle w CV nie wymieniać. Oczywiście już teraz w CV robię sporo optymalizacji.
Moje style pracy
Zadania wykonuję na jeden z trzech sposobów, przeważnie wybieram nr 2. Z każdym jest coś nie tak.
Dotyczy każdego tworzonego przeze mnie kodu, dokumentacji, wysyłanych e-maili, itd. Opiszę na przykładzie kodu, ale problem nie jest ograniczony do samego kodu.
Sposób nr 1: pisanie wszystkiego "normalnie", jak inni ludzie. Ale wtedy jest pełno błędów w przypadkowych miejscach spowodowanych tym, jaki ja "roztrzepany" jestem. Znacznie więcej niż ludzie są w stanie zaakceptować.
Sposób nr 2, mój główny:
(1) robię coś jeden raz, np. piszę kod jakiegoś endpointa API, ale nie uznaję jeszcze tego za zrobione, po czym przechodzę do innych, niezwiązanych spraw, żeby zapomnieć co dokładnie napisałem
(2) jakiś czas później robię to samo drugi raz np. piszę kod tego samego endpointa API jeszcze raz, tak jakbym to robił po raz pierwszy, bez kopiowania ani nawet zaglądania do rozwiązania z punktu (1)
(3) w efekcie mam dwa rozwiązania tego samego problemu, gdzie każde ma wiele dziwnych błędów spowodowanych nieuwagą, ale w jednym te błędy są inne niż w drugim - następnie używam tych dwóch rozwiązań do stworzenia ostatecznego - to, co w tych dwóch jest identyczne po prostu przekopiowuję, a tam gdzie w tych dwóch jest jakaś istotna różnica, zastanawiam się dlaczego i wybieram jedną z dwóch wersji jako dobrą, zazwyczaj doskonale widać którą trzeba wziąć, bo są to problemy typu np. pisząc ten endpoint raz z roztrzepania napisałem $fieldValue = $row['price'], a innym razem poprawnie $fieldValue = Utils::formatPriceAsJsonFragment($row['price'], $row['currency'])
Końcowa jakość jest wtedy podobna jak u innych ludzi. Błąd może powstać tylko na dwa sposoby: jeżeli dwa razy pomyliłem się identycznie robiąc to samo (mało prawdopodobne, bo te błędy spowodowane moim ADHD są losowo porozrzucane) lub gdy podczas tworzenia ostatecznego rozwiązania z dwóch niezależnych wstępnych rozwiązań pomyliłem się przy wybieraniu, w którym z tych dwóch wstępnych rozwiązań dany fragment jest dobry, a w którym jest zły, co się prawie nigdy nie zdarza.
Problem: ludzie narzekają na tempo pracy. Chociaż jakość jest dobra.
Sposób nr 3:
(1) robię coś normalnie, jest w tym pełno przypadkowych błędów
i teraz w pętli, do czasu aż podczas n-tej analizy wyjdzie, że jest ZERO znalezionych problemów, albo gdy się boję, bo to jakiś hotfix itp. to gdy dwa razy z rzędu tak wyjdzie:
----- (2) analizuję od góry do dołu napisany kod, czy dla każdego wejścia da właściwy wynik itd., czy zachowa się dobrze przy niedostępnościach zewnętrznych usług sieciowych itd., wypisując co jest źle (oczywiście zdaję sobie sprawę z tego, że prawie na pewno czegoś nie zauważę podczas sprawdzania)
----- (3) naprawiam to co wypisałem że wymaga naprawienia (niestety powstają tutaj kolejne błędy, ale przypominam że powtarzam te analizy w pętli na coraz bardziej naprawionym kodzie aż zejdę z problemami do zera)
(4) gdy skończę w powyższej pętli przerabiać kod, mam kod o sensownej jakości
Problem: ludzie narzekają na tempo pracy. To zajmuje jeszcze więcej czasu niż sposób nr 2, bo punkty (2) i (3) muszę powtarzać np. 7 razy, aż liczba znalezionych problemów z moim rozwiązaniem spadnie do zera (wychodzi np. 15 rzeczy do naprawienia, przy drugim sprawdzeniu 10 - trochę niezauważonych krok wcześniej, trochę nowych spowodowanych naprawami krok wcześniej, 7 rzeczy, 4 rzeczy, 2 rzeczy, 1 rzecz, 0 rzeczy - koniec). Jakość wychodzi znacznie wyższa niż przy sposobie nr 1, trochę niższa niż przy sposobie nr 2. Ale, w przeciwieństwie do sposobu nr 2, nie ma tu kroku "przechodzę do innych, niezwiązanych spraw, żeby zapomnieć co dokładnie napisałem", wymagającego żeby mieć możliwość przejścia dalej do czegoś innego na trochę czasu.
Moja historia zatrudnienia
firma 1 - nie przedłużyła umowy po okresie próbnym - za mała dokładność w pracy (wtedy jeszcze pracowałem głównie według sposobu nr 1 z powyżej opisanych, nie nr 2)
firma 2 - nie przedłużyła umowy po okresie próbnym - za niskie tempo
firma 3 - 2 lata było im ze mną dobrze, później wprowadzili rejestrację czasu pracy, gdzie miałem cały czas problemy typu: za dużo godzin "non-billable", za dużo przekroczeń "budżetu" (liczonego w godzinach), a gdy nie wpisywałem wszystkiego (przekroczeń dozwolonego według budżetu czasu) to były pretensje o godziny niesumujące się do 8 dziennie, po 4 latach od zatrudnienia wyleciałem za wydajność
firma 4 - nie przedłużyła umowy po okresie próbnym - za niskie tempo
firma 5 - zatrudniła, przez 2,5 roku było dobrze, następnie nałożyła na mnie (tylko mnie) zakaz pracy zdalnej (chociaż później i tak uznałem, że praca zdalna jest chyba nie dla mnie, przy zdalnej jest znacznie więcej oskarżeń w moim kierunku o podejrzewane zajmowanie się nie tym co trzeba itd. niż przy stacjonarnej), a po 4,5 roku od zatrudnienia dokonała fikcyjnej likwidacji mojego stanowiska (tylko mojego)
firma 6 - nie przedłużyła umowy po okresie próbnym - za niskie tempo gdy dbałem o jakość + zbyt mocne obniżenie jakości przy próbie zwiększenia tempa poprzez pracę "bardziej normalnym" niż mój standardowy sposobem (problemy typu white screen of death, zera zamiast cen co chwilę, przypadkowe wklejenia do plików z kodem rzeczy niebędących kodem, przypadkowe pomijanie kawałków zadań i uznawanie części zrobionej za całość zrobioną itd.)
firma 7 - na razie jedną wypłatę dostałem, chociaż standardowe pretensje do mnie są, tylko nie wiadomo czy firmie to aż tak przeszkadza, że się mnie jak inne pozbędzie, czy nie aż tak
#programowanie #pracait #adhd
〰〰〰〰〰〰〰〰〰〰〰〰〰〰〰
▶︎ Obserwuj nasz tag #mirkoanonim
〰〰〰〰〰〰〰〰〰〰〰〰〰〰〰
· Akcje: Odpowiedz anonimowo · Więcej szczegółów
· Opublikuj swój własny wpis: Mirko Anonim
· Zaakceptował: mkarweta
👉 Z Twoją pomocą możemy działać dalej! Wspomóż projekt
Przykrywka i da się nad tym pracować.
A w sumie to brzmi, jakbyś był skrojony pod TDD, jak napiszesz sobie sensowne przypadku użycia, to edge case Ci nie uciekną i nie będziesz musiał ich analizować.
1. Task switching który stosujesz w sposobie drugim to najgorsze co możesz zrobić. Nie ma czegoś takiego jak efektywne robienie kilku rzeczy na raz. Były na ten temat badania, wyszło że ludzie którzy mieli robić kilka rzeczy na raz pracowali tak, jakby mieli o kilkanaście - kilkadziesiąt punktów IQ mniej.
Wydalasz normalne satysfakcjonujące wielkości wydzielin z ciała?
Przyjmujesz normalne sycące porcje substancji odżywczych albo innych rzeczy które potrzebuje ciało? Tyczy się wszystkiego łącznie z umysłowymi rzeczami. Dasz radę codziennie godzinę czasu w normalnej pozie bez żadnych problemów np. zrobić marsz?
Zauważyłeś jakieś nieprawidłowości albo dziwne rzeczy w działaniu czy wyglądzie twoje ciała? Czy twoja sylwetka jest prawidłowa? wpisz sobie prawidłowa sylwetka gooogle.
No na pewno( ͡° ͜ʖ ͡°)
Jesteś ignorantem kolego.