Początki i Edukacja
Jak wyglądały Twoje początki w zawodzie i dlaczego akurat temat stworzenia oprogramowania był dla Ciebie interesujący?
Z tworzeniem oprogramowania zetknęłam się na studiach i ten temat bardzo mi się spodobał. Czytałam dużo artykułów, książek i robiłam kursy online. Najwięcej podstaw poznałam na różnych portalach, na których można spróbować programowania bez potrzeby konfiguracji lokalnego środowiska, można porównać języki programowania, sprawdzić różne rozwiązania tego samego zadania. To chyba wciągnęło mnie najmocniej, nie tylko możliwość rozwiązywania problemów - co samo w sobie jest już bardzo satysfakcjonujące, ale też różnorodność tych rozwiązań.
Skąd najlepiej czerpać wiedzę jako Software Developer; zarówno dla tych osób, które zaczynaja swoja przygode w tej branży, jak i tych już nieco bardziej zaawansowanych?
IT jest mocno opensourcową branżą, dzięki czemu łatwo znaleźć w internecie masę dobrze przygotowanych materiałów dla początkujących i zaawansowanych. Nowości można szukać na twitterze, oficjalnych kanałach na youtube, konferencjach. Warto też uczestniczyć w meetupach, na których doświadczeni programiści i programistki dzielą się swoją wiedzą.
W jaki sposób szukałaś swojej pierwszej pracy i w jaki sposób trafiłaś do PushPushGo?
Pierwszej pracy szukałam kończąc studia, aplikowałam na różne staże i praktyki w Javie, bo tak mi polecili znajomi. W międzyczasie spotkałam osobę która szukała kogoś do pomocy w rozwijaniu aplikacji w startupie, tylko że w JavaScripcie. Umówiliśmy się, że w miesiąc douczę się JSa i podstaw Reacta, a po tym czasie zaczniemy współpracę w formie miesięcznych praktyk i zobaczymy jak to wyjdzie.
Tą osobą był Mateusz, jeden z założycieli PushPushGo - od tamtej chwili minęły 4 lata, a ja wciąż intensywnie się uczę i cieszę się że mogę uczestniczyć w przemianie startupu w dobrze prosperującą firmę.
Praca i Rozwój
Jakie Twoim zdaniem kluczowe KPI powinny być mierzone w pracy Software Developer?
Myślę że produktywność w pracy Software Developera(-rki) to umiejętność jakościowego rozwoju systemu i wdrażania funkcjonalności na produkcję. Na pewno wskaźnikiem produktywności nie będzie ilość napisanych linii kodu ani ilość przerobionych tasków, bo one nie są porównywalne. Gdybym miała wybrać wskaźniki o które powinniśmy dbać to byłyby to:
- code stability - łatwość utrzymania kodu, ilość generowanych błędów
- code coverage - pokrycie kodu testami
- lead time - czas od pomysłu do dostarczenia rozwiązania na produkcję
- code simplicity - czytelność kodu
- knowledge sharing - dzielenie się wiedzą, pair programming
Jak mierzysz efekty swojej pracy, aby uzyskać informacje, że jest ona efektywna zarówno dla Ciebie jaki i dla firmy?
Praca jest efektywna, jeżeli usprawnia działanie systemu nad którym pracujemy zarówno od strony kodu źródłowego jak i użyteczności dla klientów. Jeżeli klienci są zadowoleni i zespołowi deweloperskiemu dobrze pracuje się z moim kodem to znaczy, że dobrze wykonuję swoją pracę.
Panuje powszechne przeświadczenie, że skille techniczne są ważniejsze od umiejętności miękkich w działach IT. Które z nich uważasz, za ważniejsze w swojej pracy? Określiłabyś siebie jako osobę stricte techniczną czy może wręcz przeciwnie?
Jestem osobą techniczną, która potrafi się komunikować. Skill techniczny jest niezbędny, ale umiejętności miękkie też są bardzo ważne. Pracujemy z innymi ludźmi i ciężko byłoby skorzystać z pełni potencjału skilla technicznego, nie potrafiąc komunikować się z resztą zespołu.
Czy możesz opisać w liczbach skalę działania w jakich na co dzień się obracasz?
Codziennie poświęcam do 6 godzin na samo kodowanie, w tygodniu rozwiązuję ok 2 bugi, deploye z moimi zmianami pojawiają się przynajmniej raz w tygodniu.
Co na co dzień czytasz, aby rozwijać swoje umiejętności odnośnie pracy?
Newslettery bo kondensują najciekawsze artykuły, dokumentacje, ostatnio też portal ohmydev. Lubię też przerabiać kursy online bo pozwalają podglądnąć jak inni piszą kod.
Z jakich narzędzi korzystasz w swojej pracy?
Webstorm, Gitlab, Youtrack, Slack, Discord, Discourse
Co oceniasz jako największy sukces w dotychczasowej pracy/ jakie było największe wyzwanie i jak udało Ci się z nim poradzić?
Jednym z wyzwań z którym się zmagałam było pokonanie syndromu oszusta. Nie odczuwałam go na co dzień, ale kiedy poszłam na branżowy meetup mocno poczułam, że jestem dziewczyną w świecie IT - mimo tego, że miałam umiejętności i techniczne wykształcenie, czułam się ”nie na miejscu”.
W pokonaniu tego uczucia pomógł mi udział w wydarzeniu girls.js, udział w konferencji Women in Tech - zetknięcie z kobietami które też są techniczne, doświadczenie tego, że zainteresowanie technologiami wśród kobiet jest zupełnie normalne, uświadomienie sobie że jest nas bardzo dużo i nie ma w tym nic dziwnego. Bardzo bym chciała, żeby to było dla wszystkich naturalne.
W PushPushGo jednym z większych wyzwań było poszerzanie zespołu deweloperskiego. Nie mając doświadczenia w rekrutacji, kierowaliśmy się głównie intuicją. W ten sposób udało nam się zrekrutować naprawdę świetne osoby, dobrze podzielić zadania i stworzyć szybko rozwijający się zespół.
Jakie momenty podczas programowania sprawiają, że myślisz "Wow, kocham swoją pracę"?
Kiedy wiem jak za pomocą kodu ułatwić komuś pracę albo rozwiązać jakiś problem. I kiedy kod, który piszę jest dobrze przemyślany, dobrze przetestowany i bezproblemowo wdrożony na produkcję.
I też zawsze kiedy tylko zaczynam się nudzić i szybko znajduje się nowe trudne zadanie do rozwiązania, nowe zagadnienie do nauki, nowe wyzwanie.
Jakie są Twoje hacki produktywności?
Wydzielanie czasu na czyste kodowanie - np. przez pracę w godzinnych cyklach, w których wyciszam komunikatory i przez godzinę skupiam się tylko na kodowaniu. Po tym czasie odrywam się, sprawdzam wiadomości, robię przerwę i wyciszam na kolejną godzinę.
Jakie widzisz trendy obecne oraz na przyszłość odnośnie tematu software development?
Ze względu na dużą zmienność w środowisku software developmentu, myślę, że bardzo cenna jest teraz znajomość uniwersalnych zasad niezależnych od poszczególnych technologii, jak znajomość wzorców projektowych czy zasad czystej architektury systemów.
