#Pierwsza praca w IT. Jak przeżyć pierwszy miesiąc

By 24 August 2015Pierwsza Praca

Ostat­ni odcinek z serii Pier­wsza pra­ca w IT poświę­cony będzie temu jak przeżyć pier­wszy miesiąc w nowej pra­cy. Zapy­tal­iśmy naszych zna­jomych o wskazów­ki — zaprasza­my do zapoz­na­nia się z ich rada­mi!

Fil­ip ma kil­ka rad na tem­at tego, jak dbać o sposób, w jaki jesteśmy postrze­gani i oce­ni­ani

Początek pra­cy jest bard­zo ważny. Opinia, jaką wyro­bi sobie pra­cown­ik u przełożonych na początku pra­cy ciąg­nie się bard­zo dłu­go. Na początku pra­cy nie warto prosić częs­to o wcześniejsze wyjś­cie czy inne, nie­s­tandar­d­owe trak­towanie. Trze­ba wykazać sum­i­en­ność i odd­anie. Nowy pra­cown­ik jest obser­wowany — jeżeli przez prób­ny okres zbudu­je sobie pozy­ty­wny wiz­erunek, później będzie mu dużo łatwiej w dal­szej pra­cy.

Nie staraj się być naj­madrze­jszy. Jeżeli Twój pomysł nie zostanie zre­al­i­zowany, nie próbuj udowod­nić, że miałeś rac­je, nawet jeżeli tak było.

Nie bój się pytać. Każdą funkcjon­al­noś­ci moż­na zapro­gramować w różny sposób. Jeżeli nie jesteś czegoś pewny — pytaj. Oszczędzi to Two­jej pra­cy i stre­su.

Kodowanie to nie wyś­ci­gi. Lep­iej prze­myśl kod dwa razy, niż odd­aj szy­b­ciej, ale z błę­da­mi lub bez komen­tarzy.

Pisząc kod pami­etaj, że piszesz go dla innych. Pamię­taj o dodawa­niu komen­tarzy do kodu oraz nazy­wa­niu zmi­en­nych i funkcji zgod­nie z ich przez­nacze­niem. Twój przełożony, jeżeli nie będzie wiedzi­ał co robi kod bez dogłęb­nej anal­izy, będzie się na Ciebie wkurzał ;)

Fil­ip Szam­bors­ki, CEO Order Group, Sp. z.o.o.

Agniesz­ka z kolei podzieliła się z nami zło­ty­mi rada­mi — zde­cy­dowanie zachę­camy, aby wydrukować i powiesić nad biurkiem!

Nie bój się pytać – kto pyta nie błądzi
To nie wstyd jeśli czegoś nie wiesz – szczegól­nie jak jesteś nowy w fir­mie / orga­ni­za­cji / pro­gramowa­niu.

Dowiedz się …
Dowiedz się, jak zor­ga­ni­zowana jest pra­ca w Two­jej fir­mie oraz jakie są Two­je obow­iąz­ki (także te niezwiązane z pro­gramowaniem).
Dowiedz się, jakie narzędzia i dlaczego są wyko­rzysty­wane (jeśli nie rozu­miesz ich funkcjonowania/działania – dopy­taj / doczy­taj), oraz jak należy z nich poprawnie korzys­tać.
Dowiedz się jakie są wyty­czne pisa­nia kodu, komen­towa­nia, nazewnict­wa, wer­sjonowa­nia i archi­wiz­owa­nia.

Zapisuj, co masz zro­bić
Szczegól­nie na początku istotne jest byś zapisy­wawał otrzymy­wane zada­nia i ich skład­owe. Po zapisa­niu poproś swego przełożonego/osobę, która zle­ciła Ci to zadanie, o potwierdze­nie, czy dobrze zrozu­mi­ałeś cel nowej funkcjon­al­noś­ci i wszys­tkie ele­men­ty, które masz zre­al­i­zować.

Staraj się zrozu­mieć cel danej funkcjon­al­noś­ci, a nie tylko sposób dzi­ała­nia
Staraj się zrozu​mieć jaką korzyść użytkown​ikowi ma przynieść nowa funkcjon​al​ność. Zas­tanów się dlaczego chce dodać nowy przy­cisk czy też okno. Jeśli znasz  lep​sze rozwiązanie jego prob​lemu (mniej prob​lematy​czne) przed­staw mu swo­ją kon­cepcję, ale uszanuj jego decyzję, jeśli będzie odmow­na.

Rozwiązu­jąc prob­lem tech­niczny najpierw szukaj infor­ma­cji, a dopiero później pytaj
Prob­le­my tech­niczne, na jakie się z pewnoś­cią natkniesz, zacznij rozwiązy­wać poprzez szukanie infor­ma­cji w Internecie. Z pewnoś­cią nie jesteś pier­wszym ani ostat­nim pro­gramistą, który ma taki prob­lem. Sprawdź w Internecie, być może ktoś już go rozwiązał. Jeśli nie zna­jdziesz niczego pomoc­nego zapy­taj kolegów którzy są obok, a jeśli oni nie są Ci w stanie pomóc, zapy­taj architek­ta / pro­gramisty który zle­cił Ci to zadanie. Jeśli on nie zna rozwiąza­nia z pewnoś­cią wie, jaki był cel biz­ne­sowy tej funkcjon­al­noś­ci i może zapro­ponować nowe pode­jś­cie do zagad­nienia.

Komu­nikuj…
Komu​nikuj oso​bie, która Ci zle​ciła zadanie, postępy w jego real​iza​cji. Przekazuj ew. prob​lemy które udało Ci się rozwiązać i prob​lemy, których nie możesz rozwiązać, oraz przy​bliżony czas zakończenia prac (oczy​wiś​cie częs​totli​wość i zakres zależny jest od zadania/osób zaan​gażowanych i ustaleń). Oso­by zle­ca­jące zada​nia, co jak­iś czas same muszą komu​nikować postępy z ich real​iza​cji, a zatem komu​nikowanie poz​woli im być na bieżą­co. Dzię­ki waszym infor­ma­cjom będą wiedzi​ały, czy ist­nieje zagroże­nie real­iza­cji zada­nia w wyz­nac­zonym ter­minie oraz z czym radzisz sobie najlepiej.
Komu​nikuj oso​bie, która zle​ciła Ci zadanie fakt, iż zbliżasz się do wyz​nac​zonego cza­su / pra​cochłon​ności, ale nie kończysz jeszcze prac. Komu​nikuj, jeśli klient zmienia wyma​gania w trak​cie real​iza​cji zada​nia (zależne od mod​elu pra­cy z klientem/przełożonym). Infor​muj pra​co​dawcę, jeśli czegoś nie wiesz i chci​ałbyś posz​erzyć swą wiedzę w tym zakre​sie. Także w sytu​acji, kiedy jeden z przewidzianych tren​ingów był niepełen. Pro​ponuj pra​co​dawcy ścieżkę kari​ery, którą chci​ałabyś podążać (on, jeśli tylko będzie miał taką możli​wość, z pewnoś​cią Ci w niej pomoże).

Tes­tuj
Poza sprawdze­niem ścież­ki poprawnej, sprawdź i przek­likaj każdą niepoprawną ścieżkę, każdy przy­cisk, niepoprawną daną.

Automatyzuj
Prace wyko­naną na środowisku devel­op­er­skim „zapakuj” w skryp­ty i przy ich uży­ciu odtwórz funkcjon­al­ność na środowisku testowym wewnętrznym i klien­ta. Nie zapom­i­naj dodać do skryp­tów danych słown­ikowych, mody­fikacji col­la­tion czy innych mody­fikacji związanych z dany­mi. Jeśli testerzy wykryją błąd popraw go w skryptach i ponown­ie prze­buduj środowisko z ich wyko­rzys­taniem. Czyn­noś­ci te spraw­ią, iż wdroże­nie będzie łatwe, przy­jemne i przede wszys­tkim bezprob­le­mowe dla użytkown­ików. Dzi­ałanie oparte na skryptach pozwala uniknąć „zgu­bi­enia się” niezbęd­nych danych np. słown­ikowych, lub efek­tów z tak zwanych „szy­b­kich poprawek” na środowisku testowym.

Nie ekspery­men­tuj na pro­dukcji!
Tego tłu­maczyć mam nadzieję nie trze­ba ;)

Agniesz­ka Sad­ows­ka, Kierown­ik Pro­jek­tów BAKK Sp. z o.o.

Maria ma jeszcze kil­ka rad — szczegól­nie dla Kobi­et w branży IT

I’m not sure this is IT relat­ed, but it’s maybe non-obvi­ous giv­en the lone hack­er sav­ing the world stereo­types. Just talk to peo­ple. Though peo­ple are gen­er­al­ly nice, and it’s good to have friends, this is also self-preser­va­tion advice. When you screw up (as just *will* hap­pen when you’re new to any­thing) you want to be able to go to coworkers/local geeks/people from your user group and ask for help. And you want them to think you’re a rel­a­tive­ly nice per­son who is pret­ty smart when you ask, so that they feel like help­ing. They will think this is you’re a rel­a­tive­ly nice per­son who is pret­ty smart to their face. Imple­men­ta­tion details left to read­er. Options include chats, pints, and oth­er social events.

Tech-wise, if you’re mov­ing to pro­gram­ming from some­thing else, you’re prob­a­bly not a nat­u­ral­ly tal­ent­ed pro­gram­ming genius already. Addi­tion­al­ly, there are lots of things to learn on the jour­ney toward tiny god­hood (see: http://powazek.com/posts/1655). Work out what is the most con­fus­ing thing you’re meant to do. Learn about it, Do it, Repeat. Since you’re already being a super nice per­son to oth­er pro­gram­mers, see if they have time to help with the learn­ing bit. In order to be a super nice per­son to oth­er pro­gram­mers, let them know about any awe­some stuff you do so they can learn.

Cul­ture-wise… you don’t have to be an uber-nerd, but it does help. At min­i­mum, lis­ten to Johnathan Coulton’s Code Mon­key (www.youtube.com/watch?v=qYodWEKCuGg). It will help you iden­ti­fy your peo­ple. If you’re a sys­tems per­son you prob­a­bly always want to peruse the dic­tio­nary: http://www.catb.org/jargon/

And specif­i­cal­ly for women who are putting on the pro­gram­ming hat… most­ly just do the oth­er things. But fair warn­ing: most peo­ple are love­ly, but in an indus­try with so few women, the few non-love­ly peo­ple don’t get told to shut up as often as is nec­es­sary for them to learn that being non-love­ly is unac­cept­able. They may insist that you’re HR, that you “just wouldn’t under­stand”, or just that you’re very pret­ty but not as smart as they are. When you’re new it might be tempt­ing to think they’re right. They’re not. Get bet­ter peo­ple. There are women in tech groups every­where there’s tech, and if that’s not your thing, there are the love­ly coworkers/nerds/communities that you should be chat­ting with any­way. Focus on acquir­ing new skills and meet­ing great peo­ple. Don’t accept poor work­ing con­di­tions, and let peo­ple know if there’s some­thing wrong.

Maria Francesca O’Connor, Pro­gramista

I na koniec parę słów od Kuby

Początek pra­cy to niepow­tarzal­na okaz­ja — od tego, jak ją wyko­rzys­tasz zależy jak potoczy się Two­ja dal­sza kari­era. Przede wszys­tkim słuchaj — wiele osób będzie chci­ało Ci pomóc, naprawdę warto ich wysłuchać, nawet jeśli nie zawsze trze­ba zas­tosować się do ich rad. Nie bój się pytać, ale pytaj o rzeczy, których nie zna­jdziesz w powszech­nie dostęp­nych źródłach (oczy­wiś­cie lep­iej zapy­tac niż spędz­ić cały dzień próbu­jąc bez powodzenia zas­tosować się do wskazówek znalezionych w jakimś miejs­cu). Bądź szcz­ery i otwarty — jeśli nie rozu­miesz, dlaczego coś dzi­ała tak, a nie inaczej, do czego coś służy, nie bój się o tym powiedzieć. Dla innych może być to oczy­wiste, ale gdzies trze­ba się tego nauczyć po raz pier­wszy. I przede wszys­tkim trochę się odstre­suj — oczy­wiś­cie moż­na trafić na idiotów, ale w więk­szoś­ci ludzie są życ­zli­wi i pomoc­ni. Nie będą krzy­czeć, jeśli się pomylisz, nie obrażą jeśli popro­sisz o uza­sad­nie­nie decyzji i nie spo­jrzą z góry kiedy zapy­tasz o coś. A jeśli nieste­ty trafiłaś na oso­by z tej pier­wszej grupy — pamię­taj, że zawsze możesz zmienić pra­co­daw­cę i spróbować jeszcze raz, jeśli atmos­fera okaże się nie do zniesienia.

Choć z różnych per­spek­tyw, wszys­tkie te wypowiedzi moż­na sprowadz­ić do tego, aby być otwartym na wiedzę i naukę, współpra­cow­ać z zespołem i skupić się na jakoś­ci, a nie szy­bkoś­ci. Pod­pisu­je­my się pod tym wszys­tki­mi ręka­mi (oraz łapa­mi, a także ogonem) i gorą­co zachę­camy do wdroże­nia ich od dzisi­aj — i to nie tylko w pier­wszej pra­cy ;)

  • 20
  •  
  •  
  •  
  •