Ostatni odcinek z serii Pierwsza praca w IT poświęcony będzie temu jak przeżyć pierwszy miesiąc w nowej pracy. Zapytaliśmy naszych znajomych o wskazówki — zapraszamy do zapoznania się z ich radami!
Filip ma kilka rad na temat tego, jak dbać o sposób, w jaki jesteśmy postrzegani i oceniani
Początek pracy jest bardzo ważny. Opinia, jaką wyrobi sobie pracownik u przełożonych na początku pracy ciągnie się bardzo długo. Na początku pracy nie warto prosić często o wcześniejsze wyjście czy inne, niestandardowe traktowanie. Trzeba wykazać sumienność i oddanie. Nowy pracownik jest obserwowany — jeżeli przez próbny okres zbuduje sobie pozytywny wizerunek, później będzie mu dużo łatwiej w dalszej pracy.
Nie staraj się być najmadrzejszy. Jeżeli Twój pomysł nie zostanie zrealizowany, nie próbuj udowodnić, że miałeś racje, nawet jeżeli tak było.
Nie bój się pytać. Każdą funkcjonalności można zaprogramować w różny sposób. Jeżeli nie jesteś czegoś pewny — pytaj. Oszczędzi to Twojej pracy i stresu.
Kodowanie to nie wyścigi. Lepiej przemyśl kod dwa razy, niż oddaj szybciej, ale z błędami lub bez komentarzy.
Pisząc kod pamietaj, że piszesz go dla innych. Pamiętaj o dodawaniu komentarzy do kodu oraz nazywaniu zmiennych i funkcji zgodnie z ich przeznaczeniem. Twój przełożony, jeżeli nie będzie wiedział co robi kod bez dogłębnej analizy, będzie się na Ciebie wkurzał ;)
Filip Szamborski, CEO Order Group, Sp. z.o.o.
Agnieszka z kolei podzieliła się z nami złotymi radami — zdecydowanie 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ólnie jak jesteś nowy w firmie / organizacji / programowaniu.
Dowiedz się …
Dowiedz się, jak zorganizowana jest praca w Twojej firmie oraz jakie są Twoje obowiązki (także te niezwiązane z programowaniem).
Dowiedz się, jakie narzędzia i dlaczego są wykorzystywane (jeśli nie rozumiesz ich funkcjonowania/działania – dopytaj / doczytaj), oraz jak należy z nich poprawnie korzystać.
Dowiedz się jakie są wytyczne pisania kodu, komentowania, nazewnictwa, wersjonowania i archiwizowania.
Zapisuj, co masz zrobić
Szczególnie na początku istotne jest byś zapisywawał otrzymywane zadania i ich składowe. Po zapisaniu poproś swego przełożonego/osobę, która zleciła Ci to zadanie, o potwierdzenie, czy dobrze zrozumiałeś cel nowej funkcjonalności i wszystkie elementy, które masz zrealizować.
Staraj się zrozumieć cel danej funkcjonalności, a nie tylko sposób działania
Staraj się zrozumieć jaką korzyść użytkownikowi ma przynieść nowa funkcjonalność. Zastanów się dlaczego chce dodać nowy przycisk czy też okno. Jeśli znasz lepsze rozwiązanie jego problemu (mniej problematyczne) przedstaw mu swoją koncepcję, ale uszanuj jego decyzję, jeśli będzie odmowna.
Rozwiązując problem techniczny najpierw szukaj informacji, a dopiero później pytaj
Problemy techniczne, na jakie się z pewnością natkniesz, zacznij rozwiązywać poprzez szukanie informacji w Internecie. Z pewnością nie jesteś pierwszym ani ostatnim programistą, który ma taki problem. Sprawdź w Internecie, być może ktoś już go rozwiązał. Jeśli nie znajdziesz niczego pomocnego zapytaj kolegów którzy są obok, a jeśli oni nie są Ci w stanie pomóc, zapytaj architekta / programisty który zlecił Ci to zadanie. Jeśli on nie zna rozwiązania z pewnością wie, jaki był cel biznesowy tej funkcjonalności i może zaproponować nowe podejście do zagadnienia.
Komunikuj…
Komunikuj osobie, która Ci zleciła zadanie, postępy w jego realizacji. Przekazuj ew. problemy które udało Ci się rozwiązać i problemy, których nie możesz rozwiązać, oraz przybliżony czas zakończenia prac (oczywiście częstotliwość i zakres zależny jest od zadania/osób zaangażowanych i ustaleń). Osoby zlecające zadania, co jakiś czas same muszą komunikować postępy z ich realizacji, a zatem komunikowanie pozwoli im być na bieżąco. Dzięki waszym informacjom będą wiedziały, czy istnieje zagrożenie realizacji zadania w wyznaczonym terminie oraz z czym radzisz sobie najlepiej.
Komunikuj osobie, która zleciła Ci zadanie fakt, iż zbliżasz się do wyznaczonego czasu / pracochłonności, ale nie kończysz jeszcze prac. Komunikuj, jeśli klient zmienia wymagania w trakcie realizacji zadania (zależne od modelu pracy z klientem/przełożonym). Informuj pracodawcę, jeśli czegoś nie wiesz i chciałbyś poszerzyć swą wiedzę w tym zakresie. Także w sytuacji, kiedy jeden z przewidzianych treningów był niepełen. Proponuj pracodawcy ścieżkę kariery, którą chciałabyś podążać (on, jeśli tylko będzie miał taką możliwość, z pewnością Ci w niej pomoże).
Testuj
Poza sprawdzeniem ścieżki poprawnej, sprawdź i przeklikaj każdą niepoprawną ścieżkę, każdy przycisk, niepoprawną daną.
Automatyzuj
Prace wykonaną na środowisku developerskim „zapakuj” w skrypty i przy ich użyciu odtwórz funkcjonalność na środowisku testowym wewnętrznym i klienta. Nie zapominaj dodać do skryptów danych słownikowych, modyfikacji collation czy innych modyfikacji związanych z danymi. Jeśli testerzy wykryją błąd popraw go w skryptach i ponownie przebuduj środowisko z ich wykorzystaniem. Czynności te sprawią, iż wdrożenie będzie łatwe, przyjemne i przede wszystkim bezproblemowe dla użytkowników. Działanie oparte na skryptach pozwala uniknąć „zgubienia się” niezbędnych danych np. słownikowych, lub efektów z tak zwanych „szybkich poprawek” na środowisku testowym.
Nie eksperymentuj na produkcji!
Tego tłumaczyć mam nadzieję nie trzeba ;)
Agnieszka Sadowska, Kierownik Projektów BAKK Sp. z o.o.
Maria ma jeszcze kilka rad — szczególnie dla Kobiet w branży IT
I’m not sure this is IT related, but it’s maybe non-obvious given the lone hacker saving the world stereotypes. Just talk to people. Though people are generally nice, and it’s good to have friends, this is also self-preservation advice. When you screw up (as just *will* happen when you’re new to anything) 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 relatively nice person who is pretty smart when you ask, so that they feel like helping. They will think this is you’re a relatively nice person who is pretty smart to their face. Implementation details left to reader. Options include chats, pints, and other social events.
Tech-wise, if you’re moving to programming from something else, you’re probably not a naturally talented programming genius already. Additionally, there are lots of things to learn on the journey toward tiny godhood (see: http://powazek.com/posts/1655). Work out what is the most confusing thing you’re meant to do. Learn about it, Do it, Repeat. Since you’re already being a super nice person to other programmers, see if they have time to help with the learning bit. In order to be a super nice person to other programmers, let them know about any awesome stuff you do so they can learn.
Culture-wise… you don’t have to be an uber-nerd, but it does help. At minimum, listen to Johnathan Coulton’s Code Monkey (www.youtube.com/watch?v=qYodWEKCuGg). It will help you identify your people. If you’re a systems person you probably always want to peruse the dictionary: http://www.catb.org/jargon/
And specifically for women who are putting on the programming hat… mostly just do the other things. But fair warning: most people are lovely, but in an industry with so few women, the few non-lovely people don’t get told to shut up as often as is necessary for them to learn that being non-lovely is unacceptable. They may insist that you’re HR, that you “just wouldn’t understand”, or just that you’re very pretty but not as smart as they are. When you’re new it might be tempting to think they’re right. They’re not. Get better people. There are women in tech groups everywhere there’s tech, and if that’s not your thing, there are the lovely coworkers/nerds/communities that you should be chatting with anyway. Focus on acquiring new skills and meeting great people. Don’t accept poor working conditions, and let people know if there’s something wrong.
Maria Francesca O’Connor, Programista
I na koniec parę słów od Kuby
Początek pracy to niepowtarzalna okazja — od tego, jak ją wykorzystasz zależy jak potoczy się Twoja dalsza kariera. Przede wszystkim słuchaj — wiele osób będzie chciało Ci pomóc, naprawdę warto ich wysłuchać, nawet jeśli nie zawsze trzeba zastosować się do ich rad. Nie bój się pytać, ale pytaj o rzeczy, których nie znajdziesz w powszechnie dostępnych źródłach (oczywiście lepiej zapytac niż spędzić cały dzień próbując bez powodzenia zastosować się do wskazówek znalezionych w jakimś miejscu). Bądź szczery i otwarty — jeśli nie rozumiesz, dlaczego coś działa tak, a nie inaczej, do czego coś służy, nie bój się o tym powiedzieć. Dla innych może być to oczywiste, ale gdzies trzeba się tego nauczyć po raz pierwszy. I przede wszystkim trochę się odstresuj — oczywiście można trafić na idiotów, ale w większości ludzie są życzliwi i pomocni. Nie będą krzyczeć, jeśli się pomylisz, nie obrażą jeśli poprosisz o uzasadnienie decyzji i nie spojrzą z góry kiedy zapytasz o coś. A jeśli niestety trafiłaś na osoby z tej pierwszej grupy — pamiętaj, że zawsze możesz zmienić pracodawcę i spróbować jeszcze raz, jeśli atmosfera okaże się nie do zniesienia.
Choć z różnych perspektyw, wszystkie te wypowiedzi można sprowadzić do tego, aby być otwartym na wiedzę i naukę, współpracować z zespołem i skupić się na jakości, a nie szybkości. Podpisujemy się pod tym wszystkimi rękami (oraz łapami, a także ogonem) i gorąco zachęcamy do wdrożenia ich od dzisiaj — i to nie tylko w pierwszej pracy ;)
