Konsultacje indywidualne i code review z perspektywy Senior Frontend Engineera. Pomoc dopasowana do tego, gdzie aktualnie jesteś: czy dopiero zaczynasz, czy pracujesz już komercyjnie.
Pracuję komercyjnie jako Senior Frontend Engineer. Tematy konsultacji to rzeczy, które pojawiają się w prawdziwych projektach: asynchroniczność w JavaScript, wzorce komponentowe, architektura w Next.js.
Nie ma uniwersalnej ścieżki. Jest Twój konkretny projekt, Twój kod i pytania, na które szukasz odpowiedzi. Sesję układamy wokół tego, na czym akurat utknąłeś.
Utknąłeś? Przejdziemy razem przez Twój kod. Wskażę problem, wyjaśnię, skąd się bierze, i pokażę, jak podchodzę do takich rzeczy w projektach komercyjnych.
Uczysz się programowania samodzielnie i nie masz pewności, czy idziesz w dobrą stronę? Przejdziemy razem przez fundamenty HTML, CSS i JavaScript, pokazując, jak te technologie wyglądają w komercyjnych projektach.
Pracujesz już komercyjnie i chcesz pójść dalej? Pokażę Ci wzorce, które poznaje się dopiero w zespole: patterny w React, architekturę w Next.js i decyzje, które generują najmniej długu technicznego.
Wyślij mi swój projekt lub pull request. Przejrzę kod tak samo, jak robię to w projektach komercyjnych, i przygotuję dokument z konkretnymi uwagami.
Koszt: ustalany indywidualnie, w zależności od zakresu projektu
Twój kod przejrzy osoba, która na co dzień prowadzi review w projektach produkcyjnych. Ocenię strukturę, czytelność, wydajność i to, jak kod wytrzyma utrzymanie przez kolejne miesiące.
Otrzymasz dokument z uwagami spisanymi punkt po punkcie. Przy każdej propozycji wyjaśniam, dlaczego ją proponuję i jakie to ma konsekwencje.
Dowiesz się, jakich błędów unikać, jakie wzorce stosować i jak myśleć o kodzie z perspektywy zespołu, który utrzyma go przez kolejne miesiące.
Code review to codzienność każdego developera w zespole. Zobaczysz, jak wygląda dobry feedback i jak przygotować własny kod, żeby łatwiej było go przejrzeć.
Pracuję komercyjnie jako Senior Frontend Engineer. Buduję aplikacje webowe w React, Next.js i TypeScript, a w razie potrzeby pracuję także po stronie API, bazy danych oraz konfiguracji CMS-ów.
Na co dzień odpowiadam za architekturę frontendu w zespołach pracujących w Scrumie, projektuję Design Systemy i optymalizuję wydajność aplikacji o dużej ilości danych (mapy, dashboardy, złożone tabele). W ramach konsultacji i code review dzielę się tym samym warsztatem, który stosuję w projektach komercyjnych.
Prowadzę indywidualny mentoring frontend developerów oraz publikuję treści techniczne na blogu i Instagramie. Sposób tłumaczenia dopasowuję do konkretnej osoby — to, co dla seniora jest oczywiste, juniorowi trzeba przedstawić inaczej.
Branża IT rozwija się niesamowicie szybko, co kiedyś stało się nawet memem żartującym z codziennych pojawień się nowych frameworków do JavaScript. W natłoku codziennych spraw i obowiązków ciężko jest być na bieżąco ze wszystkim. Również mi jest trudno, dlatego wypracowałem u siebie pewien proces, który pozwala być mniej więcej na bieżąco z tym, co jest na czasie
Używanie TypeScript chroni nas przed błędami już na etapie kompilacji. Są jednak przypadki, gdy programiści wyłączają tę ochronę, używając any lub unknown. Dzisiaj wyjaśnię, jak te opcje się różnią oraz czy warto je w ogóle używać.
Projekty poboczne są genialnym sposobem na naukę, rozwijanie umiejętności programowania i eksperymentowanie z różnymi technologiami. Co więcej, nie musisz się ścigać z terminami, więc masz więcej swobody w podejmowaniu decyzji i testowaniu swoich pomysłów.
Niedawno miałem przyjemność zapoznać się z najnowszą pozycją na rynku wydawniczym – książką "Marka osobista w branży IT" autorstwa Krzysztofa Kempińskiego . Jako ktoś, kto stoi u progu budowania własnej marki osobistej, ta książka natychmiast przykuła moją uwagę.