Pisanie kodu: jak wygląda dzień pracy programisty

1. Zwykły dzień z życia programisty

Bycie programistą jest łatwe i przyjemne ☀️. Za organizację pracy odpowiada Project Manager, za listę funkcji produktu — Product Owner. Spotkania organizuje Scrum Master. Wszystkie procesy organizacyjne są maksymalnie sformalizowane i znormalizowane ✅.

Przychodzisz rano do pracy, robisz sobie herbatę albo kawę ☕️, siadasz do komputera 🖥️. Otwierasz wspólny czat 💬, sprawdzasz, czy nie ma pilnych wiadomości, czy ktoś nie zachorował 🤒, i jeśli wszystko jest w porządku, zabierasz się do pracy.

Otwierasz serwis JIRA, w którym znajduje się lista wszystkich zadań twojego zespołu: backlog projektu i backlog bieżącego sprintu. Zadania są już posortowane według priorytetu przez twojego Scrum Master/TeamLead lub ProductOwner.

Bierzesz zadanie z samej góry — to o najwyższym priorytecie 🔝 i zaczynasz nad nim pracować. Aby to zrobić, trzeba przenieść je do statusu In Progress. To kwestia kilku kliknięć 🖱️. No to start, czas leci ⏳.

Do opisu zadania zazwyczaj dołączane są dodatkowe informacje lub link do dokumentacji 📄. Zadanie powinno zawierać wszystkie niezbędne informacje, abyś mógł je wykonać. Zapewnienie takich informacji — to obowiązek twojego menedżera 👨‍💼.

Jeśli coś jest nie tak, możesz przekierować zadanie („task” w żargonie programistów) na swojego menedżera i w komentarzach napisać, jakie pytania się pojawiły i/lub jakich informacji brakuje.

2. Piszemy kod

Przeanalizowałeś opis zadania i wiesz, co trzeba zrobić. Świetnie — zabieraj się do pracy 🏁. Pomoże ci w tym twoje doświadczenie z nauki na CodeGym oraz praca zespołowa 🤝.

Gdy kolejna funkcjonalność jest gotowa i upewniłeś się, że działa, musisz wrzucić kod do Git. Da się to zrobić kilkoma kliknięciami prosto z IDE. W twoim przypadku — z IntelliJ IDEA 🚀. Najpierw commitujesz swój kod do lokalnego repozytorium, a następnie wypychasz (push) go do centralnego repozytorium Git.

Najczęściej ostatnia operacja odbywa się poprzez Pull Request, gdy za pomocą Git wysyłasz do swojego team leada prośbę o review twojego kodu. Jeśli z kodem wszystko jest w porządku i nie ma uwag, twój team lead zaakceptuje (accept) ✅ twój pull request i trafi on do głównej roboczej gałęzi Gita.

Ważne! Pod żadnym pozorem nie siedź cicho, jeśli nie wiesz, jak wykonać zadanie. Taka sytuacja zdarza się często, a wielu początkujących (i nie tylko) rozwiązuje ją niewłaściwie. Zapamiętaj: jeśli w ciągu 2 godzin wciąż nie wiesz, jak podejść do zadania, musisz o tym poinformować swojego menedżera 🚩.

Nie warto też iść do team leada ze stwierdzeniem „tego nie da się zrobić”. Taka fraza bardzo irytuje, zwłaszcza gdy team lead doskonale wie, że „da się to zrobić” i sam robił coś podobnego wielokrotnie.

Nie wiesz, jak to zrobić — powiedz: „spędziłem dwie godziny/dwa dni, próbując zrozumieć, jak to zrobić, ale mi się nie udaje”. Team lead podpowie ci, w jakim kierunku szukać w Google 🔍.

I to tyle, jeśli chodzi o obraz współczesnego procesu wytwarzania produktu. Pisanie kodu — to tylko mała część całej pracy, ale wszystko jest zorganizowane tak, aby nic nie odciągało cię od pracy. Dlatego śmiało przechodź do nauki Java 25 — praca programisty ci się spodoba 😉.