Jak wyglądały wasze początki w branży IT?

2

Cześć, od stycznia zaczynam swoją przygodę z IT na stanowisku Junior Developer. Mam wrażenie, że jestem już solidnie przygotowany do pracy ale wyjdzie pewnie tak, że przez pierwsze kilka tygodni będę sobie rwał włosy z głowy próbując zrozumieć co się tam wyprawia.

Jak wyglądały wasze początki w branży IT? Gdybyście musieli wrócić do początków, to do czego (jeszcze przed pracą) byście się bardziej przyłożyli, żeby na początku było wam lżej? Co najbardziej utkwiło wam w pamięci lub co dla was wydawało się najtrudniejsze?,
Abstrachując od technologii z jaką pracowaliście. :)

Pozdrawiam

13

Moja rada jest taka: nie obiecuj sobie dużo po pracy w IT że np. będziesz rakiety budować albo Marsa kolonizować. Co więcej: HRy itp. kreują wokół bycia developerem jakiś mityczny obraz jak to fajnie jest, jakie super jest korpo - to wszystko bullshit. Wyzbądź się oczekiwań i nie kreuj w głowie obrazu tego jak twoja praca będzie super wyglądać. Unikniesz rozczarowań.

Co bym zmienił zaczynając od początku? Właśnie pozbył się z głowy tych iluzji o profesjonalizmie w IT (np. jeżeli chodzi o jasność organizacji/procedur) oraz popracował bardziej nad charakterem, tj. poćwiczyłbym cierpliwość i zaakceptował stan ch*jni jako domyślny, oszczędziłbym sobie frustracji oraz dużo wcześniej wyzbył się inicjatyw i snucia planów, bardzo szybko spotkasz się ze ścianą "niby można to zrobić tak i tak ale po co jak do tej pory jakoś idzie". Jak chcesz robić w programowaniu coś fajnego to rób to po godzinach prywatnie. ;)

2

Ja się zgodzę z @MrMadMatt, największy błąd jaki można popełnić na samym początku to dać się ponieść entuzjazmowi i szczerze rajcować się programowaniem.

Niepotrzebnie rajcowałem się klepiąc sobie jakieś tam swoje bieda-projekty na studia, ładując tam wszystko co mi tylko przychodziło do głowy, niepotrzebnie robiłem sobie od górkę zrównoleglając (to mnie chyba najbardziej zawsze jarało) i kombinując i wymyślając jaki ficzur możnaby jeszcze dorobić. Teraz zamiast równoległości mam co najwyżej bezstanową aplikację, wielowątkowy serwer HTTP i autoscaler k8s, zamiast ficzerów i bajerów jest żonglowanie encjami, DTOsami, obiektami domenowymi czy co się tam akurat trafi. Dosłownie raz mi się zdarzyło coś faktycznie zrównoleglać, a i tak dało się sprowadzić problem do tzw. 'embarassingly parallel' więc zwykła pula i do przodu.

Także największym błędem młodości jest entuzjazm.

2

Entuzjazm nie jest zły. na 3 roku studiów w 2001r. zacząłem pracę i pierwsza rzecz jaką dostałem to oprogramować jakiś przepływomierz nie mając dokumentacji ( celem było napisane sterownika dla aplikacji w pascalu ). Musiałem zhackować komunikację po rs232. I udało się ;-) Kilka lat później zaczęło się jak to kolega wyżej napisał żonglowanie encjami i tak jest do dzisiaj. Tylko, że encje coraz bardziej poje.... skomplikowane :-) W sumie na nudę nie narzekam. Hobbystycznie i pół/zawodowo grzebię w elektronice i algorytmach genetycznych co jest fajną odskocznią od baz danych, raportów i nudnych "encji".

3

Cześć, bardzo ciekawe pytanie.

U mnie był entuzjazm, zostałem szybko sprowadzony na ziemię ale z drugiej strony to było najlepsze co mi się mogło przytrafić. Jak w 2013 roku trafiłem do nudnych projektów związanych z regulatorami UE i księgowością tak do dziś w tym siedzę.
Po drodze nauczyłem się jednak dość dobrze co to znaczy Spółka i mam już za sobą dwie biznesowe przygody. Jedna z moich spółek ma rozmiar obecnie +10 osób i zajmuje się marketingiem i programowaniem. Po nowym roku ruszam z trzecią firmą a to wszystko przed 27 rokiem życia.

Morał z tego taki, że nie skupiaj się za mocno na samym programowaniu. Patrz jak działa firma, poznawaj ciekawe osoby i rób swoje. :) ja cały czas mimo wielu rzeczy na głowie aktywnie programuje, aktualnie dla jednego z dużych banków w centrum Wawy, więc dobrze poukładany biznes, wspólnicy i kilka projektów z różnych źródeł to coś co śmiało można ciągnąć jednocześnie.
Z tego też kolejny morał. Praca zespołowa i zaufanie. Tego też trzeba się uczyć.

I na koniec. Tak jak kolega wyżej wspomniał, rakiet raczej nigdy budował nie będziesz, więc czeka Cię trochę zderzenie z rzeczywistością programistyczną. Trzymam kciuki!

5
kiowa72 napisał(a):

? Gdybyście musieli wrócić do początków, to do czego (jeszcze przed pracą) byście się bardziej przyłożyli, żeby na początku było wam lżej? Co najbardziej utkwiło wam w pamięci lub co dla was wydawało się najtrudniejsze?

Myślę, że podjąłbym takie kroki na starcie:

  • wyzbycie się ego, przeszkadza to w pracy i poza pracą w sumie też
  • uważne słuchanie feedbacku innych (np. jak na code review ktoś Ci zgłasza 100 uwag, to zazwyczaj nie dlatego, że chce Cię dojechać tylko dlatego, żeby wypracować jak najlepsze rozwiązanie)
  • zadawanie wielu pytań (wtedy szybciej rozwiążesz problem, niż jak będziesz siedział sam w kącie i móżdżył nad czymś w nieskończoność - ostatecznie chodzi o rozwiązywanie problemów - nieważne jak)
  • 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)
  • jasne precyzowanie zadań i oczekiwań
  • 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)
  • praca nad jasną i klarowną komunikacją (najlepiej werbalną, a w drugiej kolejności maile i komunikatory)
  • branie odpowiedzialności za to, co się robi i nie zwalanie niczego na innych (nawet jeśli byśmy teoretycznie mogli)
  • pomoc innym, jeśli potrafimy (jeśli nie potrafimy, to też można spróbować, bo a nuż się uda)
  • staranie się być jak najlepszym w tym, co robimy (projekt, domena, język programowania, narzędzia, itd.)
4

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.

2

Od pierwszych dni starałem się nauczyć jak najwięcej i robić taski tak jak pozostali, żeby dorównać osobom, które już kilka lat pracowały z projektem. Po pracy w domu analizowałem projekt, rozrysowywałem sobie różne schematy itp. To nie miało sensu, bo potem zobaczyłem, że kolejni, którzy zatrudnili się po mnie, prawie nic nie robili i się tym nie przejmowali.

3

Im szybciej uświadomisz sobie, że praca to praca a nie start w igrzyskach olimpijskich tym lepiej dla ciebie - pracownika.

0

Nie odgadniesz na co Cię rzucą. Proponuję dobrze wypocząć, wyspać się, pozałatwiać sprawy przed rozpoczęciem, po to by jak zaczniesz mieć siłę nadrobić braki.

0

Ooo fajny temat, jestem w dość podobnej sytuacji,i mam jedno pytanie, jakie taski na początku dostawaliście?, chodzi mi o juniorów/stażystów, warto powtarzać sobie tematy dot. bezpieczeństwa serwisu czy rest api czy bardziej podstawy?

1 użytkowników online, w tym zalogowanych: 0, gości: 1