Jak być zayebistym juniorkiem

Tak jak w tytule.

Jak być rockstar junior developer w nodejs?

znac dobrze nodejs, sql, aws, kafke, kubernetes, docker, html, js/ts, git, jakis framework fe najlepiej ktorys z react/angular/vue, graphql, dobrze jakbys umial ogarnac CI/CD np na github actions, dobre skille miękkie, angielski perfect, umiesz pisac testy?, jakies portfolio/github z projektami innymi niz 1k innych wannabe juniorow

No i podstawa to z 5 lat doświadczenia.

• nie wymądrzać się (przez pouczanie innych), nie używać terminologi, której się nie rozumie.
• uczyć się, czytać dokumentację
• znać perfekcyjnie podstawy, żeby na rozmowie nie popłynąc na zadaniu typu: usuń duplikaty znaków z napisu (widzę coś takiego często na Interview).
• umieć pisać testy

Co do pierwszego punktu: rockstar developer :P.

Możesz mieć skille regulara i sprzedać je w cenie juniora, ale biznesowo to jest słabe, choćby pod względem motywacji do dalszego rozwoju czy samej płacy.

Junior nie musi znać wszystkiego, on na tym nadal etapie się uczy i popełnia błędy, zdobywa swoje pierwsze komercyjne doświadczenie. Warto podejść do tego trochę spokojniej, bo to nie jest to samo co kolejne miesiące przy własnym projekcie.

Jak chcesz lepiej to rozegrać, to spójrz raczej na swoją pracę trochę od końca. W ramach tej samej firmy po pierwsze nie opłaca Ci się z pozycji juniora stawać regularem. Podkreślam, że to jest najbardziej lukreatywne rozwiązanie, lecz dla pracodawcy, nie dla Ciebie. Tu w Polsce, pracodawcy, zapominają, że wraz z awansem należy dawać normalną podwyżkę, czego potwierdzeniem jest to, że oni podbiją wynagrodzenie o parę procent dopiero, gdy zdecydujesz się rzucić papierami. Co i tak jest bez sensu, bo jak przyjmiesz ofertę z innej firmy to stawkę masz zupełnie na innym poziomie.

Co w tym czasie powinien robić junior?

1. Jak masz ambicje to w pierwszej kolejności opanuj swoje ego i emocje, to właśnie ono w pierwszej kolejności może stanąć Ci na drodze. Pamiętaj kod firmowy nie jest wyznacznikiem Twojego życia, kod firmowy to nie Twój kod. Kod jest jaki jest, ale jeśli ten kod powoduje kasę, to w pierwszej kolejności powinieneś ten fakt docenić i uszanować. Nie jedna baza kodu w github jest 100 kroć piękniejsza, ale co z tego jeśli to nie ma wpływu na Twój rachunek bankowy? Sztuka to jednak tak pisać, aby na tym zarabiać i tego ucz się w firmie.

2. Nie oceniaj na podstawie kodu czy produktu firmy ani ludz,i z którymi przyjdzie Ci wspólnie pracować. W firmie będą leszcze, debile, popaprańcy, zarozumialcy, ale z jakiegoś względu firma ich zatrudnia, uszanuj to, bo nie Ty jesteś szefem. Zamiast tego bądź profesjonalistą, rób to za co Ci płacą, ale nie - uwaga - nie przeholuj! Nie próbuj być mądrzejszy, nie próbuj pokazywać jak to powinno się kodować, a przeglądu kodu pod żadnym względem nie odbieraj osobiście. Bez sensu jest się złościć, gdy ktoś niekompetentny zrobił Ci słaby przegląd? Co mu zrobisz? Wyjaśnisz, jak bardzo się myli? Uważaj, bo zrozumie, uważaj bo da Ci spokój, oni mają swoje ograniczenia i musisz to zrozumieć, nim zrobisz coś głupiego. W firmie, chociaż nikt o tym tak wprost nie mówi, chodzi o zachowanie pozytywnego wrażenia, budowanie zaufania i jak to z zaufaniem byw,a możesz zrobić coś 10 razy dobrze, co dzień mieć rację, ale na samem koniec jej kosztem racji popsuć niejedną relację. Nie warto.

3. Nieproszony, szkodzisz. Firma nie zatrudnia Cię, abyś wymyślał zadania i tworzył priorytety, tym bardziej na stanowisku juniorskim. Jeśli możesz, oducz się tego czym prędzej. Programiści nie są w firmach widziani jako osoby decyzyjne, lecz jako wykonawcy. Masz wpasować się w proces biznesowy i tyle. Jak masz energię to wspieraj wszystkie osoby dookoła, ale za Chiny nie rób za szefa. Od tego w firmie jest kierownictwo, team leaderzy, product ownerzy/managerzy, ale nie Ty. Powtarzam, celem jest robić to co istotne dla firmy (nie dla Ciebie!), a nie poprawki w kodzie (ogranicz do poprawek zgodnie z zasadą skauta: https://michalkulinski.blogspot.com/2018/11/zasada-skautow.html), dopóki w istocie refaktoryzacja nie stanie się one priorytetem biznesu.

4. W firmie buduj dobre relacje z ludźmi, bądź tą osobą z którą wygodnie się pracuje. Wtedy to każdego roku procentuje, nie tylko jako plus do referencji, ale tak w ogóle na przyszłe oferty. Jako znajomy masz tę przewagę, że dowiesz się o niejednej ofercie, nim ta stanie się dostępna publicznie.

5. Nim staniesz się seniorem, a stanie się to szybciej niż myślisz, spróbuj uchwycić na dłużej jak to jest być juniorem. Może to pomoże Ci podejść w pracy do juniorów z większym zrozumieniem i poczuciem humoru :)

znowutosamo napisał(a):

3. Nieproszony, szkodzisz. Firma nie zatrudnia Cię, abyś wymyślał zadania i tworzył priorytety, tym bardziej na stanowisku juniorskim. Jeśli możesz oducz się tego czym prędzej. Programiści nie są w firmach widziani jako osoby decyzyjne, lecz jako wykonawcy. Masz wpasować się w proces biznesowy i tyle. Jak masz energię to wspieraj wszystkie osoby dookoła, ale za chiny nie rób za szefa. Od tego w firmie jest kierownictwo, team leaderzy, product ownerzy/managerzy, ale nie Ty. Powtarzam, celem jest robić to co istotne dla firmy (nie dla Ciebie!), a nie poprawki w kodzie (ogranicz do poprawek zgodnie z zasadą skauta: https://michalkulinski.blogspot.com/2018/11/zasada-skautow.html) dopóki w istocie refaktoryzacja nie stanie się one priorytetem biznesu.

super przepis na juniora co leci z donosem jak inny programista konstruktywnie skrytykuje jego kod

Dużo nauki czyli to, co przedmówcy pisali.

Poza tym: pytaj.

Nie tylko jak czegoś nie rozumiesz, ale jak rozumiesz, to tym bardziej, ważne jest, żeby dociekać. A często jak się już coś wie o czymś, to można lepsze pytania zadać.

I nie tylko chodzi o pytania do innych ludzi czy szukanie w necie. możesz też:

• odpytywać kod, nad którym pracujesz (np. debugowanie, logowanie czy pisanie testów i asercji to forma zadawania pytań kodowi - co robi? czy na pewno to, co myślimy, że robi?). Możesz tez spojrzeć na kod z lotu ptaka albo w szczególe, żeby wykryć pewne schematy i odkryć możliwości refaktoru choćby
• samego siebie - czemu robię to, co robię? Może powinienem coś innego zrobić albo inaczej (zadając pytania samemu siebie można zaoszczędzić sobie długich dni czy tygodni na robieniu czegoś, co jest złym rozwiązaniem, a czego można uniknąć przez dobre przemyślenie sprawy i zrobienie prototypu sprawdzające nasze założenia).

Przy czym małe zastrzeżenie - zadawanie pytań i dociekliwość jest dobre, jeśli jesteś w stanie tolerować niejasność (nie na wszystkie pytania trzeba znać odpowiedź, a na niektóre pytania najlepsza odpowiedź „to zależy”. Z dociekliwością tez można przesadzić)

Moze można by to w skrócie powiedzieć „bądź bardzo ciekawy i dociekliwy, ale umiej też być ignorantem i czuć się komfortowo robiąc coś ze świadomością, że tego nie rozumiesz”

jedz na śniadanie chlep z szynkom, cebulą, sałatą, pomidorem i wykonuj taski, ale takie wiesz zwykłe.
Może niewystarczy to ale też wystarczy pewnie dla kogoś.

Wstawaj o 5, idź pobiegać a potem na terapię. Nieważne jaką, po prostu idź.

Tak mi się skojarzyło....
https://pl.wikipedia.org/wiki/Juniorki

znowutosamo napisał(a):

W ramach tej samej firmy po pierwsze nie opłaca Ci się z pozycji juniora stawać regularem. Podkreślam, że to jest najbardziej lukreatywne rozwiązanie, lecz dla pracodawcy, nie dla Ciebie.

"Lukratywne rozwiązanie" dla pracodawcy, bo dał awans pracownikowi? Przecież wraz ze zmianą stanowiska nie rosną skokowo kompetencje, a to kompetencje są tym, na czym zarabia pracodawca. Po awansie zwykle robisz mniej więcej to samo, tylko masz większą odpowiedzialność, a dostajesz więcej kasy.

Tu w Polsce, pracodawcy, zapominają, że wraz z awansem należy dawać normalną podwyżkę, czego potwierdzeniem jest to, że oni podbiją wynagrodzenie o parę procent dopiero, gdy zdecydujesz się rzucić papierami. Co i tak jest bez sensu, bo jak przyjmiesz ofertę z innej firmy to stawkę masz zupełnie na innym poziomie.

To zależy od firmy.

Jak masz ambicje to w pierwszej kolejności opanuj swoje ego i emocje, to właśnie ono w pierwszej kolejności może stanąć Ci na drodze.

Junior z założenia jest niekompetentny. Umie napisać kod, który działa, ale nie wie, jak to zrobić wydajnie i czytelnie, jakich bibliotek użyć, jak zweryfikować to, czy kod w pełni spełnia założenia. Tu chyba nie ma miejsca na ego, bo pierwszy lepszy senior wdepcze takiego juniora w ziemię.

Nie oceniaj na podstawie kodu czy produktu firmy ani ludz,i z którymi przyjdzie Ci wspólnie pracować. W firmie będą leszcze, debile, popaprańcy, zarozumialcy, ale z jakiegoś względu firma ich zatrudnia, uszanuj to, bo nie Ty jesteś szefem.

Jeśli w firmie kod jest kiepskiej jakości, to junior małe ma szanse czegoś dobrego się nauczyć. Jeśli współpracownicy to idioci, to frustracja prędzej czy później zniechęci do pracy. Jeśli firma zatrudnia takich ludzi, to albo bardzo kiepsko płaci, albo rządzą nią również idioci, w obu tych przypadkach trzeba spieprzać.

Zamiast tego bądź profesjonalistą, rób to za co Ci płacą, ale nie - uwaga - nie przeholuj!

Z czym przeholować? Z robieniem tego, za co pracodawca płaci? Z profesjonalizmem chyba u juniora kiepsko o nadmiar.

Firma nie zatrudnia Cię, abyś wymyślał zadania i tworzył priorytety, tym bardziej na stanowisku juniorskim.

Nawet jeśli wymyśli, to kto będzie realizował jego zadania? Struktura organizacyjna zespołu uniemożliwia takie zachowania. Natomiast nikt nie zabrania zwrócić się z pomysłem do teamleada czy PMa, przecież junior też może mieć dobre pomysły.

Programiści nie są w firmach widziani jako osoby decyzyjne, lecz jako wykonawcy.

To chyba w idealnej firmie, gdzie masz bardzo dobrych analityków i precyzyjną specyfikację. W rzeczywistości nie zdarza się to często, za to często trzeba samemu zrobić research i podjąć decyzję, a nie ze wszystkim zawracać tyłek przełożonemu. Różnica między seniorem a juniorem jest tutaj taka, że senior przeważnie wie, kiedy decyzję może podjąć sam, a jego decyzja przeważnie jest trafna.

W firmie buduj dobre relacje z ludźmi, bądź tą osobą z którą wygodnie się pracuje. Wtedy to każdego roku procentuje, nie tylko jako plus do referencji, ale tak w ogóle na przyszłe oferty.

Nikogo nie obchodzą referencje. W swojej niemal dwudziestoletniej karierze, w trakcie której kilkadziesiąt razy byłem na rozmowach kwalifikacyjnych, raz jeden jedyny spotkałem się z prośbą o namiar na przełożonego z poprzedniej firmy.

Jako znajomy masz tę przewagę, że dowiesz się o niejednej ofercie, nim ta stanie się dostępna publicznie.

???

Nim staniesz się seniorem, a stanie się to szybciej niż myślisz

???

Ktoś spisał te najwazniejsze rzeczy

• Nullify the output of 10 engineers.

Change requirements as far into development as possible. To avoid blame, obfuscate requirements from the start.

• Create 400 hours of busywork.

Ask your team to perform tasks that resemble work. Common examples include presentations, diagrams, and ticket management. Create pointless rituals.

• Create 400 hours of burnout/turnover.

Be thankless. Foist blame. Sow confusion. Get angry. Cause others to work overtime.

• Hold 10 engineers hostage in a technical discussion.

Let engineers discuss ideas. Encourage them to pursue elegance over pragmatism. Ensure nobody has the authority to make any decisions.

• Add 400 hours of communication overhead.

Meetings wreck calendars. To inconspicuously waste others’ time, write lengthy messages/documents and share as widely as possible. Welcome all opinions and aim for engagement.

• Waste 10 weeks of wages on cloud costs.

Write slow programs. Avoid DB indexes. Run single-threaded programs on 16-core machines. Opt for exotic hardware with fancy RAM and GPUs. Store data on RAM/disk liberally. Don’t compress anything. Pay no attention to data layouts.

• Create useless tools.

Decide that existing solutions aren’t quite what you need. Write scripts that only one person understands. If the script does something important, avoid documentation.

• Add 400 hours of compilation/build time.

Slow builds waste time and incur compound interest. As build times increase, developers are more likely to distract themselves. To ensure developers are context-switching, recompilation should take at least 20 seconds. You can also write slow tests for similar effect.

• Write pointless tests.

Create dependencies on particular variables without testing the underlying functionality. Mock function calls until no original code runs. Introduce subtle randomness into your tests so that they succeed/fail without cause.

• Waste 400 hours of engineering on bad architecture.

Give zero consideration to how your system design will evolve over time. Alternatively, drive your team obsess over architecture decisions so that they don’t have time to test their hypotheses.

• Waste 400 hours on deployment.

Create as many environments as possible. Production and staging must differ wildly. Launch fragile code with fragile build systems. Migrate your databases frequently.

• Lose 10 weeks of wages on unhappy customers.

Repeatedly fail to detect and address severe bugs. Pay no attention to security vulnerabilities.

• Write worthless documentation.

Explain code in private messages. Write wikis that nobody uses.

• Trap 10 engineers in a futile skunkworks project.

Attract bright engineers and waste their potential. Undersell the difficulty of the project to management; oversell the project’s usefulness. Tell management it’s “almost complete” until they scrap it.

• Add dependencies that demand 400 hours of maintenance.

Engineers individually learn each library.

• Delay pivoting.

Never admit failure. Drown your team in sunk-cost. Ignore 80/20 compromises that could improve your circumstances.

• Hire 10 0x engineers.

Opportunity costs can kill. Dead-weights may not actively harm your team, but they sit in the chairs of people who could actively help.

• Hire 5 -1x engineeers.

Don’t settle for dead-weight. Actively hire engineers who cause catastrophies and resist learning.

• Prevent 10 -1x engineers from getting fired.

Don’t rock boats. Leave no paper trail of failures. Vouch for bad engineering.

• Incur 400 hours of bug triage.

Make undebuggable programs. Plaster layers of abstraction over everything. Write spaghetti code. Make everything sensitive to initial conditions. Avoid pure functions. Use dependencies liberally. Say “it works on my machine” whenever possible.

znowutosamo napisał(a):

3. Nieproszony, szkodzisz. Firma nie zatrudnia Cię, abyś wymyślał zadania i tworzył priorytety, tym bardziej na stanowisku juniorskim. Jeśli możesz, oducz się tego czym prędzej. Programiści nie są w firmach widziani jako osoby decyzyjne, lecz jako wykonawcy. Masz wpasować się w proces biznesowy i tyle. Jak masz energię to wspieraj wszystkie osoby dookoła, ale za Chiny nie rób za szefa. Od tego w firmie jest kierownictwo, team leaderzy, product ownerzy/managerzy, ale nie Ty. Powtarzam, celem jest robić to co istotne dla firmy (nie dla Ciebie!), a nie poprawki w kodzie (ogranicz do poprawek zgodnie z zasadą skauta: https://michalkulinski.blogspot.com/2018/11/zasada-skautow.html), dopóki w istocie refaktoryzacja nie stanie się one priorytetem biznesu.

Zgadzam i się nie zgadzam jednocześnie.
Niestety tak w wielu w firmach jest i z tego punktu niestety masz rację. Firmy szukają wyrobników, klepaczy, a nie inżynierów/hakerów/twórców.
I rada "mieć wyje*ane, robić co każą i mieć wszystko inne w d..." jest z tego punktu widzenia słuszna.

Problem w tym, że będąc uległym zbieramy punkty jako "posłuszny pracownik", jednak żeby iść dalej z rozwojem, to warto jednak być nieco bardziej aktywnym. Bo bez tego cały czas będzie się tym juniorem, co nic nie może i na niczym się nie zna, bo od myślenia są inni.

A później będą w kolejnej firmie na rekrutacji pytać o obowiązki i osoba, która o niczym nie decydowała, nic sama nie wnosiła, nie miała swojego zdania, co może powiedzieć? Taka osoba może zostać odebrana jako niesamodzielna.

Z perspektywy więc aktualnej firmy, gdzie ktoś pracuje, może to dobra rada (nie wychylać się, robić tylko to, co każą, quiet quitting i wyje*ongo), ale z perspektywy całej kariery, to taka stagnacja i bycie potulnym.

dużo eksperymentować/czytać i zachowywać work-life balanca. Możesz być zajebisty merytorycznie ale jak będziesz przetyrany mentalnie i ciężko będzie z tobą gadać to i tak daleko nie zajedziesz.

No i szukaj co Ci się podoba w branży i ewentualnie się przebranżowisz.
Najłatwiej się uczymy tego co nas interesuje.

Dla mnie super junior tj. z potencjałem na mida to ktoś samodzielny, odpowiedzialny i szybko uczący się nowych rzeczy. Możesz znać wszystkie najnowsze technologie, ale jeśli nie jesteś w stanie samodzielnie zrealizować powierzonego zadania, co wymaga również komunikacji i odpowiedzialności za decyzje techniczne, to daleko do mida.

Wchodzic w d... zasobom ludzkim od których zależy twój awans i podwyżki.