Zdałem sobie sprawę że napisanie dobrego kodu który działa to jest może 10% sukcesu. Ile rzeczy jest na około to głowa mała. Pisze tego posta żeby ktoś kto chciałby wejść do branży na stanowisko 15k zastanowił się nad innymi ścieżkami rozwoju. Oczywiście możesz robić każdą z tych ról w niektórych firmach. Dzisiaj zdałem sobie sprawę czemu w IT są tak wysokie zarobki.
Management Wymagania często przychodzą mało precyzyjne i trzeba wszystko dogadać z biznesem żeby być pewnym co się chce osiągnąć. Powiedzmy sobie szczerze; rzadko klient wie czego chce. Jego myśl "chcę przycisk który usuwa urządzenie" trzeba przekuć w odpowiedni projekt architektury czyli wymyślenie całości w głowie żeby powiedzieć czy się da ile to zajmie.
Bardzo dobrze jeśli Product Owner / Project Manager ma doświadczenie techniczne i też był kiedyś programistą.
Design Często przychodzą designy opisujące sunny day scenario. Czyli nie pokrywają edge casów, nie pokrywają przypadku kiedy user nie ma uprawnień albo chociażby nie ma neta. Kolejne odbijanie piłeczki.
UX/UI designer powinien rozumieć produkt, problem i być w stanie przewidzieć wszystkie przypadki z perspektywy usera.
Testy Testy są tak samo ważne jak kod który piszecie. Pomijając unit testy które po prostu są must have w każdej cywilizowanej firmie, są jeszcze testy integracyjne i end to endowe, które muszą wykonać się dla nowej każdej zmiany i przejść żeby zgodzić się merge codu do developa. Gruby temat. Testowanie aplikacji w różnych wersjach, na różnym hardware, na różnych urządzeniach, setup danych testowych. Można od tego wyłysieć. Sam setup CI/CD jest problematyczny tak jak i jego utrzymanie.
Testerem (QA Engineer) w sumie powinien być developer kodu. Mam mieszanie uczucia co do osobnego stanowiska testera. Jeśli robicie projekt od zera to programista powinien odpowiadać za jakość kodu. Jeśli przejmujecie nowy projekt i nie ma testów to uważam że zatrudnienie dedykowanych ludzi ma sens żeby załatać dziury.
Synchronizacja pracy z innymi teamami To jest kolejna bolączka, żeby nikomu nic nie popsuć, albo jak zaplanować robotę żeby osiągnąć wspólne cele nie wchodząc sobie w drogę.
Tutaj muszą być ogarnięci Produkt Ownerzy którzy mają między sobą dobrego Project Managera.
Kompatybilność wsteczna Jeśli nie macie wersjonowania API to jesteście w czarnej dziurze. Utrzymanie kompatybilności jest problematyczne. Wprowadzanie usprawnień może sprawić że wersja apki sprzed miesiąca może przestać działać userowi. Zawsze trzeba o tym myśleć i jest to hamulcem bardzo szybkiego rozwoju produktu.
Architekt / Developer o to musi dbać
Chmura Orkiestracja serwisów nie należy do prostych zadań. Zwłaszcza kiedy koszty generowane przez chmurę idą w dziesiątki tys $. Sam Amazon oferuje 200 różnych dedykowanych serwisów (stan na dzisiaj). Do tego dochodzą tematy cybersecurity. Są standardy w tej branży ale nie jest to prosta rzecz do zaimplementowania.
Devops to chłop który się tym zajmuje, jednak uważam że developer też może pełnić jego obowiązki.
Scrum ... Oprócz twoich ubowiązków musisz uczestniczyć w Scrumie. Generalnie dobra rzecz, jeśli osoba która jest Scrum Masterem chce ci pomóc, a nie wdrażać swoich wizji "bo tak jest w guidelinie". Scrum jest spoko dla zespołów > 5 osób. W mniejszych wg mnie można się obyć bez. Im bardziej płaska struktura tym lepiej. Sam narzut w scrum ceremoniach jest duży: retro, refinement, planning, daily i tak dalej. Generalnie większość programistów by tego nie chciała.
Najgorsze jest to że jak zaprojektujesz wszystko idealnie od pierwszej linijki kodu to i tak raczej nie przetrwa to próby czasu. Różni ludzi przychodzą, wiedza ochodzi a utrzymanie standardów w grupie 10-20 osób jest często trudne. Zapraszam do dyskusji.
@its_over_for_chlop: że ci się chciało to pisać i brać udział w tych baitowych dyskusjach. No fajnie, że sobie to uświadomiłeś - jest jeszcze kilka elementów, których nie wymieniłeś... Exp++
Testerem (QA Engineer) w sumie powinien być developer kodu. Mam mieszanie uczucia co do osobnego stanowiska testera. Jeśli robicie projekt od zera to programista powinien odpowiadać za jakość kodu.
To stwierdzenie dowodzi albo ze nigdy nie byłeś w poważnym projekcie gdzie byli prawdziwi testerzy albo nie znasz realiów. Nie znam chyba żadnego developera który umiałby przetestować wszystkie edge case’y swojego feature’a włączając testy integracyjne, e2e. To wymaga znajomości zarówno
@bb89: pracowałem w formie gdzie testerzy byli osobna kompetencja i w sumie nie widzę żadnej wartości dodanej. Jaki problem developerowi ustawic analizę statyczna na branch coverage 80% i wtedy qa jest zbędny tak jak jego wszystkie przypadki. Jeśli jest dobry proces to developerzy sami sobie mogą znaleźć błędy w obrębie zespołu. Uważam że developer sam sobie napisze testy najlepiej. Przecież mowisz o testach white box. Dodatkowo jakie klikanie? Przecież całe
Testerem (QA Engineer) w sumie powinien być developer kodu
@its_over_for_chlop: tak mi co dzień mówią paniusie pozatrudniane u nas jako testerki. Jeszcze nie raz się skarżą że słabo testuję. One są od picia kawki i ploteczek.
@its_over_for_chlop: Jest pełno rzeczy naokoło, ale to przecież wcale nie oznacza, że jedna osoba ma to wszystko ogarniać. Dużo zależy też od specyfiki firmy/branży. Generalnie startupy, kontraktornie, agencje i inne softłer hausy są najgorsze pod względem presji i ilości obowiązków. W dobrze zarządzanej firmie taki przeciętny klepacz ma zazwyczaj naprawdę wąskie poletko do zaorania. Wysokie zarobki wynikają raczej z gargantuicznego zapotrzebowania na informatyzację wszystkiego co się da niż z tego,
@bb89: Byłbym w stanie się z Tobą zgodzić że tylko korpo ma takie podejście, jednak w firmach w kktórych pracują znajomi jest tak samo. Są to firmy top 5 w swojej branży i tam również nie ma testerów dedykowanych. Może robicie jakiś krytyczny system od którego zależy ludzie życie, ale uważam że ogarnięci developerzy w dobrym procesie są sami testować kod produkowany przez własny zespół. Są wolniejsi przez to ale
Disclaimer: IT nie jest jednorodne, tak naprawde IT jako jedna branza to mit. Nie ma jednego przepisu na sukces. Kazdy z nas zyje w swojej bance kontaktow i organizacji i moze mocno inaczej widziec praktyki, podejscie do pracy etc.
Najgorsze jest to że jak zaprojektujesz wszystko idealnie
@its_over_for_chlop: Nie projektujesz idealnie :) tylko wystarczajaco dobrze i to jest kolejny skill ktory warto dopisac do twojej listy. Rynek jest tak konkurencyjny ze firmy
Całkowicie się zgadzam. Programista obecnie to taki zwykły inżynier który wie jak poskładać klocki do kupy. Duże zapotrzebowanie na automatyzacje == eldorado dla IT.
@its_over_for_chlop: Ano, tylko trochę to smutne, że o predyspozycjach do pracy bardziej decyduje dziś znajomość tych klocków, czyli konkretnych frameworków i technologii, które się bardzo szybko dezaktualizują, niż ogólne obycie i taka bardziej ponadczasowa, uniwersalna wiedza (algorytmy, dobre wzorce, itp).
Management
Wymagania często przychodzą mało precyzyjne i trzeba wszystko dogadać z biznesem żeby być pewnym co się chce osiągnąć. Powiedzmy sobie szczerze; rzadko klient wie czego chce. Jego myśl "chcę przycisk który usuwa urządzenie" trzeba przekuć w odpowiedni projekt architektury czyli wymyślenie całości w głowie żeby powiedzieć czy się da ile to zajmie.
Bardzo dobrze jeśli Product Owner / Project Manager ma doświadczenie techniczne i też był kiedyś programistą.
Design
Często przychodzą designy opisujące sunny day scenario. Czyli nie pokrywają edge casów, nie pokrywają przypadku kiedy user nie ma uprawnień albo chociażby nie ma neta. Kolejne odbijanie piłeczki.
UX/UI designer powinien rozumieć produkt, problem i być w stanie przewidzieć wszystkie przypadki z perspektywy usera.
Testy
Testy są tak samo ważne jak kod który piszecie. Pomijając unit testy które po prostu są must have w każdej cywilizowanej firmie, są jeszcze testy integracyjne i end to endowe, które muszą wykonać się dla nowej każdej zmiany i przejść żeby zgodzić się merge codu do developa. Gruby temat. Testowanie aplikacji w różnych wersjach, na różnym hardware, na różnych urządzeniach, setup danych testowych. Można od tego wyłysieć.
Sam setup CI/CD jest problematyczny tak jak i jego utrzymanie.
Testerem (QA Engineer) w sumie powinien być developer kodu. Mam mieszanie uczucia co do osobnego stanowiska testera. Jeśli robicie projekt od zera to programista powinien odpowiadać za jakość kodu. Jeśli przejmujecie nowy projekt i nie ma testów to uważam że zatrudnienie dedykowanych ludzi ma sens żeby załatać dziury.
Synchronizacja pracy z innymi teamami
To jest kolejna bolączka, żeby nikomu nic nie popsuć, albo jak zaplanować robotę żeby osiągnąć wspólne cele nie wchodząc sobie w drogę.
Tutaj muszą być ogarnięci Produkt Ownerzy którzy mają między sobą dobrego Project Managera.
Kompatybilność wsteczna
Jeśli nie macie wersjonowania API to jesteście w czarnej dziurze. Utrzymanie kompatybilności jest problematyczne. Wprowadzanie usprawnień może sprawić że wersja apki sprzed miesiąca może przestać działać userowi. Zawsze trzeba o tym myśleć i jest to hamulcem bardzo szybkiego rozwoju produktu.
Architekt / Developer o to musi dbać
Chmura
Orkiestracja serwisów nie należy do prostych zadań. Zwłaszcza kiedy koszty generowane przez chmurę idą w dziesiątki tys $. Sam Amazon oferuje 200 różnych dedykowanych serwisów (stan na dzisiaj). Do tego dochodzą tematy cybersecurity. Są standardy w tej branży ale nie jest to prosta rzecz do zaimplementowania.
Devops to chłop który się tym zajmuje, jednak uważam że developer też może pełnić jego obowiązki.
Scrum ...
Oprócz twoich ubowiązków musisz uczestniczyć w Scrumie. Generalnie dobra rzecz, jeśli osoba która jest Scrum Masterem chce ci pomóc, a nie wdrażać swoich wizji "bo tak jest w guidelinie". Scrum jest spoko dla zespołów > 5 osób. W mniejszych wg mnie można się obyć bez. Im bardziej płaska struktura tym lepiej. Sam narzut w scrum ceremoniach jest duży: retro, refinement, planning, daily i tak dalej. Generalnie większość programistów by tego nie chciała.
#programista15k #programowanie
Hmm?
To stwierdzenie dowodzi albo ze nigdy nie byłeś w poważnym projekcie gdzie byli prawdziwi testerzy albo nie znasz realiów. Nie znam chyba żadnego developera który umiałby przetestować wszystkie edge case’y swojego feature’a włączając testy integracyjne, e2e. To wymaga znajomości zarówno
Komentarz usunięty przez autora
@its_over_for_chlop: tak mi co dzień mówią paniusie pozatrudniane u nas jako testerki. Jeszcze nie raz się skarżą że słabo testuję. One są od picia kawki i ploteczek.
IT nie jest jednorodne, tak naprawde IT jako jedna branza to mit. Nie ma jednego przepisu na sukces. Kazdy z nas zyje w swojej bance kontaktow i organizacji i moze mocno inaczej widziec praktyki, podejscie do pracy etc.
@its_over_for_chlop: Nie projektujesz idealnie :) tylko
wystarczajacodobrze i to jest kolejny skill ktory warto dopisac do twojej listy. Rynek jest tak konkurencyjny ze firmy@its_over_for_chlop: Ano, tylko trochę to smutne, że o predyspozycjach do pracy bardziej decyduje dziś znajomość tych klocków, czyli konkretnych frameworków i technologii, które się bardzo szybko dezaktualizują, niż ogólne obycie i taka bardziej ponadczasowa, uniwersalna wiedza (algorytmy, dobre wzorce, itp).
A propo QA w starej robocie
@its_over_for_chlop: kto je tam wie? Jeszcze nie widziałem żeby coś zrobiły a trochę materiału do badań już mam.