Dlaczego tak wielu świetnych developerów odchodzi szybko na emeryturę?

Przejrzeliśmy serwis Quora.com w poszukiwaniu niebanalnych pytań. Developerzy z tego portalu chętnie udzielają wyczerpujących odpowiedzi, które postanowiliśmy przetłumaczyć i zamieścić w poniższym artykule. Jesteśmy ciekawi, jak Wy odpowiedzielibyście na zadane pytania.

Pytanie #1. Co charakteryzuje dobrego developera?

Odpowiada: Dave Aronson, Software Development Consultant

Chciałbym powiedzieć o tylu rzeczach, ale ograniczę się do trzech cech. Oto one:

• zawsze się uczy. Nieważne, czy odkrywa nowy język, framework, poznaje interesującą technikę, którą polecił znajomy, zawsze rozwija swoje umiejętności. Dobry developer uczy się nawet, kiedy pod opieką ma początkującego programistę, bo jak pewien mądry facet powiedział: mądrzy uczą się więcej od początkujących niż oni od niego.
• interesuje się nie tylko tym, czy program działa. Dobrego deva interesuje to, czy wykonał prawidłową pracę (aniżeli wykonał pracę dobrze), czyli czy zajmował się tym, czego klient oczekiwał. Dba o solidność, testowalność, bezpieczeństwo i wiele innych aspektów tego, co zrobił.
• jest przynajmniej przyzwoity w kontaktach z innymi. Developer, który świetnie radzi sobie z kodem, ale jest niemiły i trudno się z nim dogadać, to obciążenie dla zespołu. Może i robi 10 razy więcej niż inni — ale jego zachowanie obniża produktywność reszty. Prawdopodobnie lepiej zatrudnić dwóch devów, którzy mogliby wykonać jego pracę, ale takich, z którymi da się porozmawiać.

Odpowiada: John David

• nienasycona ciekawość — dobry dev widzi coś, czym jest zainteresowany, ale nie chce usłyszeć, jak to działa. Musi rozebrać dany sprzęt na części, zrozumieć model działania, a potem złożyć go spowrotem.
• samodyscyplina — traktuje priorytetowo swój czas i wysiłek. Gdy pracuje dla firmy potrzebuje więcej czasu na realizację zadania, bo zawsze może być czymś zaskoczony, poproszony o coś więcej. Gdy pracuje dla siebie, wylicza każdą minutę dnia, by jak najlepiej wykorzystać swój czas.
• nieustępliwość — Albert Einstein powiedział kiedyś, że swoje osiągnięcia zawdzięcza temu, że poświęcił na rozwiązanie problemu więcej czasu niż inni.
• pasjonat w swojej dziedzinie — pracuje, kiedy inni śpią, rozwija się, gdy inni oglądają TV. Chodzi na wykłady, pisze wypracowania, tworzy prototypy, przedstawia swoje prace znajomym i daje ją do oceny. Uczy i chce być nauczany.
• duma z projektu — jest zadowolony, że zakończył pracę nad projektem i chce pozyskać feedback na jego temat.
• team player — lider albo członek zespołu, który w pełni akceptuje nadaną mu rolę. Dużo poświęca czasu na to, by jeszcze lepiej wykonywać swoją pracę, nie tylko w kontekście programowania. Spędza dodatkowy czas na czytanie dokumentacji, pomaga innym, angażuje się w dyskusje z innymi pracownikami. Czuje się częścią zespołu i świętuje sukces innych.
• brak wstydu za swoje błędy — błędy, o których nie mówi się przełożonym, bardzo trudno znaleźć. To kosztowny i pracochłonny proces. Dobry developer weźmie odpowiedzialność za popełnione błędy, nie zwali ich na innych, tylko naprawi je, wykorzystując tę sytuację jako szansę na zbudowanie reputacji osoby, na którą można zawsze liczyć.

Pytanie #2. Dlaczego tak wielu świetnych developerów odchodzi szybko na emeryturę?

Odpowiada: Ha Phan, Software Engineer

Byłam hardware engineerem przez 4 lata i software engineerem przez ponad 15 lat. Planuję odejść na emeryturę w ciągu najbliższych lat. Oto dlaczego:

1. Branża oprogramowania bardzo starzeje się w Bay Area. Im jestem starsza, tym trudniej znaleźć kolejną pracę, chyba, że jest się super koderem. Jednak stres w pracy codziennej i odrzucenie podczas rozmowy kwalifikacyjnej to brutalny cios.

2. Trudno utrzymać work-life balance. Wiele software house’ów zatrudnia programistów z innej strefy czasowej, które mogą pracować w przedziałach od 7 rano do 23 wieczorem. To powoduje wiele problemów natury rodzinnej.

3. Bay Area to centrum rynku pracy w IT, dlatego muszę mieszkać właśnie w tym miejscu. A koszty życia są bardzo wysokie.

4. Z wiekiem nabyłam inne pasje i zainteresowania. Technologia nie jest już na pierwszym miejscu w moim życiu.

5. Życie jest zbyt krótkie na to, by kłaść pracę ponad moje zainteresowania.

To świetne, że pracując jako software engineer dużo zarabiam. Dlatego mogę odłożyć tyle, żeby było mnie stać na emeryturę.

Oferty pracy z

Odpowiada: Pradeep B, Software Engineer at DXC Technology

Życie software engineera i większości pracowników tej branży nie należy do łatwych. Nie mówię, że w innych branżach jest łatwiej, ale na pewno potwierdzicie, że praca w IT jest trudna. Całodniowe spotkania, telefony, dedlajny itp. obniżają motywację wielu pracownikom.

Inny aspekt, o którym chciałbym powiedzieć: W Bengaluru, widzimy i czytamy historie o wielu ludziach, którzy wzbogacili się tworząc ciekawe usługi dla software engineerów. Oni są niezależni, nie dotyczą ich nasze problemy, np. związane z utrzymaniem równowagi między pracą a życiem prywatnym. Sprzedawca kawy i papierosów, którego widzę pod biurem, też nie przejmuje się tymi problemami. Dobrze zarabia, bo otworzył kolejne siedziby, a u nas wygląda to całkiem inaczej. Każde pieniądze, które dostajemy z rzadkich podwyżek czy premii, zostają rozbite i zmniejszone o podatek.

Nie dziwię się, że developerzy chcą szybko odejść na emeryturę. Wymieniam kilka powodów poniżej:

1. W Indiach presja społeczeństwa powoduje, że w wieku 30-35 lat powinieneś dochrapać się co najmniej stanowiska managerskiego. Ale przecież życie managera jest jeszcze trudniejsze niż życie software engineera. Spotkania, dyskusje i siedzenie do późnych godzin, by obmyślić strategię na kolejne dni — z tym liczyć musi się każdy manager. Większe zarobki nie zawsze muszą oznaczać większego poziomu zadowolenia z pracy. Właśnie ten niski poziom zadowolenia, może zachęcać do przejścia na wcześniejszą emeryturę.

2. Choćbyś pracował na ergonomicznym fotelu, nadal spędzasz 6-7 godzin siedząc. To zdecydowanie niezdrowe dla Twojego zdrowia, a efekty pracy w tej pozycji odczujesz dopiero kilkanaście lat później. I tutaj pojawia się kolejny powód odejścia na wcześniejszą emeryturę: zdrowie.

3. Wielu software developerów zarabia na tyle dobrze, że jest w stanie co miesiąc odłożyć całkiem sporą kwotę, nim dojdzie do wieku 40 lat, i zainwestować ją w mały biznes. Może coś w stylu franczyzy McDonalda, Domino, czy otwarcia małego hotelu.

4. Przez lata pracy, developerzy obserwują jak powstaje i jak rozwija się biznes. Może to zachęcić ich do otwarcia własnej firmy w branży IT. To jednak niełatwe zadanie, ale na pewno ułatwi zarządzanie swoim czasem i życiem.

5. Wielu developerów zmienia pracę na spokojniejszą i np. zostaje wykładowcą akademickim. Dzięki temu może dzielić się swoimi doświadczeniami, nie przejmując się już terminami, czy wieczornymi rozmowami z szefostwem.

6. Cześć programistów interesuje się giełdą. Kupują i sprzedają akcje, zarabiając pierwsze pieniądze na giełdzie. To ciekawe rozwiązanie, które pozwala zarabiać środki na życie nie wychodząc z domu.

7. Jeśli mają różne źródła dochodu (wynajmują np. swoje mieszkania), prawdopodobnie rzucą pracę programisty, by poświęcić się swoim pasjom i zainteresowaniom.Przejrzeliśmy serwis Quora.com w poszukiwaniu niebanalnych pytań. Developerzy z tego portalu chętnie udzielają wyczerpujących odpowiedzi, które postanowiliśmy przetłumaczyć i zamieścić w poniższym artykule. Jesteśmy ciekawi, jak Wy odpowiedzielibyście na zadane pytania.

Pytanie #3. Jak programista-samouk, któremu brakuje komercyjnego doświadczenia, może znaleźć pierwszą pracę?

Odpowiada: Adam Goodkind, Computational Linguist

W sieci dostępnych jest wiele kursów programowania, takich jak codecademy.com, czy MIT OpenCourseWare. Zanim zacząłem programować, też szukałem magicznej ścieżki, która szybko doprowadzi mnie do znalezienia pierwszej pracy.

Niestety (albo stety) odkryłem jedyny prawidłowy sposób na to, by zostać najlepszym developerem: pasja i praktyka. Różnica między najlepszym, a najgorszym developerem jest taka, że ten pierwszy rozwiąże problem, rozwiąże go jeszcze raz i doda do niego dodatkowe funkcje. Przeciętny programista rozwiąże problem i pójdzie dalej. Moim zdaniem tylko pasja i szukanie wielu odpowiedzi na jedno rozwiązanie, świadczy o tym, czy jesteś dobrym materiałem na programistę.

Co zatem musisz zrobić, żeby znaleźć pracę? Opisuję krok po kroku ścieżkę rozwoju początkującego deva:

1. Naucz się podstaw. Nieważne, że poznałeś je na zajęciach w szkole, na uczelni. Notka: tyle samo o programowaniu dowiedziałem się z zajęć na studiach, które kosztowały mnie tysiące dolarów, co z darmowych kursów dostępnych w sieci.

2. Zacznij kodować. Stwórz stronę, dla zabawy.

3. Zastanów się nad zabawnymi sposobami na rozbudowanie tej strony.
– jeśli nie masz pomysłu, co zrobić, zapytaj znajomego “co chciałby zobaczyć jeszcze na takiej stronie”,
– jeśli nie wiesz, jak to zaprogramować, poszukaj podobnego rozwiązania w Google, na Stackoverflow, zapytaj innego deva,
– wprowadź w życie pomysły na usprawnienie strony.

4. Powtórz krok numer 3, wiele razy. Dzięki temu dowiesz się, jakim solidnym programistą potrafisz być.

5. Pokaż portfolio firmie, do której aplikujesz.

6. Zacznij zarabiać na programowaniu.

Odpowiada: Tyler Tak Kuhn, Decentralizing traditional web paradigms

Byłem Flash Devem przez 6 lat. Później pracowałem przez 4 miesiące na stanowisku Front-End Deva, używając w pracy głównie CSS & Javascriptu. Jestem aspirującym Rails Devem i odbyłem wiele rozmów o pracę na stanowiska Rails Deva. Rozmawiałem też z wieloma moimi znajomymi, doświadczonymi Rails Devami, pytając ich o to, czego się uczyć, co stworzyć i czego oczekiwać rozglądając się za pracą.

Pierwsza rada jaką otrzymałem brzmiała: zrób Railsową aplikację, później następną i następną. Poznaj bliżej Rails, używając go. Opublikuj kod na Githubie, żeby inni mogli zobaczyć, co udało Ci się zrobić. Jeśli to możliwe, spraw, by ludzie korzystali ze stworzonej przez Ciebie aplikacji.

Druga rada dotyczyła udziału w open source’owym projekcie. Znajomi mówili mi, żebym znalazł projekt, który mnie zainteresuje i żebym zaczął go używać, szukając bugów i potencjalnych usprawnień. Github to świetne miejsce na zgłaszanie poprawek, ponieważ możesz zaproponować rozwiązanie, a autorzy mogą je szybko wdrożyć.

Kilku moich znajomych, którzy zajmują się rekrutacją developerów Railsa, mówią, że szukają kandydatów myślących pragmatycznie. Zadają im takie pytania jak “Jak dużo samochodów jest obecnie w San Francisco?”, albo “Napisz program, który powie mi, o czym dzisiaj piszą najczęściej użytkownicy Twittera”. Jeśli nie znasz dokładnej liczby wskazującej, ile samochodów jest w SF, możesz powiedzieć, że dowiesz się tego poznając liczbę mieszkańców, ale też domów i bloków w SF. W pytaniu dotyczącym Twittera, rekruterzy chcą sprawdzić, czy wiesz, w jaki sposób zarządzać dużymi zbiorami danych. Pewnie nie będziesz w stanie odpowiedzieć na wszystkie tego typu pytania, które usłyszysz na rozmowie o pracę, ale to nic złego.

Z mojego doświadczenia powiem, że na rozmowach naprawdę słyszy się pytania, które opisałem powyżej. Zazwyczaj na początku byłem pytany o znajomość Railsa, czyli o to czy znam konkretne terminy i metodologie. Rekruterzy zadają pytania w taki sposób: jaka jest różnica między “x” a “y” (w miejsce “x” i “y” wstawiając różne metodologie). Poniżej zamieszczam też kilka innych pytań, które usłyszałem na rozmowach o pracę:

Jaka jest różnica między prywatnym, chronionym i publicznym?
Co oznacza słowo REGEX i czym jest?
Zdefiniuj kilka terminów, klas, obiektów i metod?
Co oznacza skrót MVC?
Co oznacza skrót DRY?
Czym jest iterator?

Pytanie #4. Co software engineer ma zrobić, kiedy CEO poprosi go o napisanie kodu, który jest bardzo trudny do implementacji, a dev nie ma pojęcia, jakich algorytmów do niego użyć?

Odpowiada: Kurt Guntheroth, 35+ years wrangling bits; 20+ doing C++ development. Windows, Linux, embedded

To dzieje się od zawsze. Większość nowego kodu powstaje właśnie dlatego, że nie wiesz, jak coś zrobić. Jeśli jesteś szczęściarzem, do zadania o którym mowa dostaniesz dokumentację, którą wystarczy przeczytać. Jeśli nie, musisz poszukać rozwiązania gdzieś indziej. Jeśli ono nie zadziała, musisz — jak mówi przysłowie — zjeść słonia. Czyli zacząć od prostej rzeczy i powoli przechodząc do tej trudniejszej.

Praca z dobrym zespołem bywa w takich sytuacjach bezcenna: możesz przecież porozmawiać z nim o swoich pomysłach i rozwiązaniach. Dzięki takiemu wyzwaniu możesz też podwyższyć swoją poprzeczkę umiejętności.

Musisz też wiedzieć, że Twoja praca może nie ujrzeć światła dziennego. Wielu developerów mówi o tym, że po wykonaniu trudnego zadania, użytkownicy końcowi nie mają możliwości zobaczenia efektu, na który poświęciliśmy mnóstwo godzin. Niektórzy mówią, że bywa tak w 75% przypadków. Ale zgadnij co… mimo to, zawsze dostajesz kasę za wykonaną pracę. Czy to nie wspaniałe?

Odpowiada: Håkon Hapnes Strand, Data Scientist

Kiedy ktoś pyta mnie, czy mogą coś zrobić, czego wcześniej nie robiłem, moja odpowiedź jest zawsze twierdząca. Nawet jeśli kompletnie nie mam pojęcia, jak zrealizować to zadanie.

W ponad 90% projektach, nad którymi pracowałem, zajmowałem się tematami, nad którymi wcześniej nie pracowałem. To bardzo typowe, jeśli zawodowo zajmujesz się programowaniem.

Częścią pracy dobrego programisty jest przezwyciężanie początkowej paniki, która powstaje, gdy zabieramy za nowe wyzwanie. Mimo wszystko warto ufać swoim umiejętnościom i doświadczeniu, które zdobyło się przez lata pracy jako developer.

Pytanie #5. Czego dotyczyła najważniejsza dla Ciebie lekcja w zawodowym życiu software engineera?

Odpowiada: Sunil Kumar, Mobile & Web App Development Expert

W ciągu wielu lat pracy w branży IT jako software engineer i architekt aplikacji, nauczyłem się wielu ważnych rzeczy. Oto kilka z nich:

1. Nigdy nie oceniaj projektu/zadania bez analizy wymagań. Nawet jeśli klient albo Project Manager prosi o przybliżoną wycenę.

2. Naucz się odmawiać, jeśli masz ręce pełne roboty. Odmawiaj, gdy chcą żebyś zrobił jeszcze więcej rzeczy, dzięki temu lepiej wykonasz powierzone wcześniej zadania.

3. Zawsze rób research, zanim zabierzesz się za wykonywanie zadań — może i będziesz potrzebował więcej czasu na rozpoczęcie realizacji zlecenia, ale dzięki researchowi szybciej je wykonasz.

4. Doceniaj testowanie i debugowanie — po prostu testuj, zanim powiesz, że wykonałeś zadanie.

5. Nie dotykaj kodu z produkcji bez backupu, nawet jeśli chcesz usunąć tylko jeden znak z kodu.

6. Nie wahaj się prosić o pomoc.

7. Zawsze ucz się nowych rzeczy, podnoś swoje kwalifikacje… myśl o technologiach przyszłości.

8. Dziel się i wspieraj open source’owe technologie.

Teraz najważniejsza rzecz, której nauczyłem się przez lata pracy:

Skup się na jakości — to zadowoli wszystkich, od PMa po klienta aż po Ciebie. Na pewno spotkasz ludzi, którzy będą prosić Cię o zrobienie szybkiej poprawki za małe pieniądze — wiedz, że tacy ludzie nie znają się na programowaniu, ale też nie będą szanować ani Ciebie, ani Twojej pracy. Nie akceptuj takich zleceń, tacy ludzie sprawiają, że życie deweloperów staje się nędzne. Wiele razy stawiałem czoła takim osobom i to jest lekcja, której nigdy nie zapomnę.

Odpowiada: Eric Klamer, Software Engineer

Jestem senior software engineerem w małym software housie, który zajmuje się utrzymaniem międzynarodowego systemu ERP. Jest to bardzo duże oprogramowanie, pracujemy dla dużych klientów, dla których tworzymy niestandardowe usprawnienia. Zazwyczaj jestem bardzo zaangażowany w proces projektowania, opracowywania i dostarczania zleconych nam rozwiązań.

Najważniejszą lekcją, jaką się nauczyłem było: nie pozwól klientowi wymyślać rozwiązania.

Najgorszy w projekcie jest klient, który ma swoją wizję rozwiązania problemu. Odmawia wdrożenia naszego pomysłu, ponieważ uważa, że zna lepiej swój biznes. Takie projekty zazwyczaj otrzymują nieefektywne rozwiązanie problemu, a usprawnianie go to koszmar.

Najlepszy w projekcie jest klient, który opisuje problem i czeka na nasze propozycje rozwiązania go. Wtedy, przygotowując się do pracy, możemy porozmawiać z wieloma osobami z firmy, od CEO, pracowników na niższych stanowiskach aż po użytkowników końcowych, by zrozumieć do czego będą wykorzystywać dane usprawnienie. To wszystko pozwoli na stworzenie najlepiej dopasowanego rozwiązania. Takie projekty zazwyczaj spotykają się z największą satysfakcją klienta.

Zdjęcie główne artykułu pochodzi z redbubble.com