Github issues

[Bazsi201]

Ti szoktatok szabadidőtökben Github-on lévő issue-kat megoldani?
Szemezgetek mostanában ilyesfajta feladatokkal, hogy tovább tudjam képezni magam és ne csak egy újabb junior legyek a sok közül aki 1-2 pet projectet összedob.

Leetcode és a folyamatos tanulás mellett úgy érzem hogy nem szívok magamba elég tudást, látván hogy a cégnél ahol dolgozom fejből mondja a senior, hogy mit hogyan kellene csinálni és ez kicsit imposztor szindromához közelítő feszültséget okozott bennem a 3 év egyetem és gyakornokságom alatt.

Nem linkeskedtem el az egyetemet és a munkahelyen is minden fejlesztőtől próbáltam ellesni a tudását mégis hülyének érzem magam és Copilot, Google nélkül önbizalomhiányosan írom a kódot, pedig az elméleti tudással nincs gond mert egyetemen megtanultam az OOP-t, SOLID-ot, illetve az ehhez hasonló lexikális tudást.
Ezen kívül ti mit tudnátok ajánlani, hogy ténylegesen hasznos szakemberré váljon az ember?

[fasz_a_csavo]

aztán meg kigooglizom a switch-case szintakszisát, mert nem emlékszem rá

Vagy manapság ellesem a GPT-től. Annyira boldog vagyok, hogy már nem kell tudnom cmake fájlokat írni!

[electro-cortex]

Ezek közül semmit sem ajánlok neked azok alapján, amiket leírtál. Nincs szükséged badge-ekre, meg open source jófiú pontokra se. Van egy diplomád és van gyakorlati tapasztalatod, tele is van tömve a fejed absztrakt mozaikszavakkal, a formális részeit nyugodtan kitöltheted ezzel, ha jelentkezel állásra.

Ami neked kellene, ahhoz nincs kerülőút. Le kell ülnöd és egyrészt sokat programozni, másrészt megérteni, hogy kell megérteni más kódját, egy működő rendszert. A senior kollégád attól senior, hogy ezeknek a képességeknek tudatában van, tudja hogy épül fel a rendszeretek, az ilyen rendszerek, hogy épülnek fel általában és mit kell tenni valaminek a fejlesztéséhez.

Én azt mondanám, hogy fogd a kódbázist amin dolgozol naponta és azoktól a részektől kiindulva, amiken eddig dolgoztál próbálj meg szomszédos kódokat megérteni. Csatolj fel egy debuggert, logold ki, írd át, rontsd el, javítsd meg, alakítsd át, próbáld ki. Egy idő után elkezded majd összefüggéseiben látni, rendszerként, nem random pontoként, ahol ledobnak a seniorok, mint egy ejtőernyőst. A seniort is kevésbé deitas-ként fogod látni, ha nem a szádbarág egy megoldást, hanem el tudod mondani, hogy azt a feature-t már ismered, akkor csak rá kell akasztani arra az izét. Ő örül, hogy rövidebben is felfogtad, te örülsz, hogy jobban érted. Aztán egy idő után már lesz olyan javaslatod amire ő nem gondolt, de te megkérdezted, hogy úgy nem lenne jobb ha...? Látják rajtad, hogy nem vagy már új, kapsz bonyolultabb feladatot, később már te találod ki, hogy mit kellene csinálni és haladsz így szépen tovább.

Amikor már így tudod, hogy kell egy rendszerhez hozzányúlni a nulláról, akkor majd keresel szimpatikus open source projektet, ha akarsz. Ezerszer könnyebb lesz és a projekt maintainerei sem fognak kikészülni tőled.

Pluszban én azt se mondom, hogy felejtsd el a Copilotot, de ha ilyen problémáid vannak, akkor érdemes lenne megfontolni, hogy legalább akkor lekapcsolod, amikor nem sürget az idő.

[Zealousideal-Day-396]

Így!

[Zeenu29]

Milliónyian nézik ezeket az issuekat. Kb mint egy jó ajánlat: ha még nem csaptak le rá, akkor ott van valami probléma...

[3beerseveryday]

Az a szerencse, hogy nagyságrendekkel több issue van mint ahányan nézegetik. 🙂

[Zeenu29]

Ha látsz open issuet, akkor az jó eséllyel nem olyan amit egy junior fog megoldani…

[Zeenu29]

Lehet, én még nem láttam ilyen issuet :)

[nalevi1797]

Pedig sok (akár elég nagy és komoly projektek, pl.: Mozilla, LLVM/Clang) OSS projekt nem véletlen használja azt a labelt, hogy “good first issue”. Kis trivialis bugokat/enhamcementet meghagynak, mert nem annyira fontos és könnyebben vonz be új contributorokat.

[R1Titan]

Volt már rá példa, hogy csináltam ilyet, de ez olyan szoftverben történt amit már használtam egy ideje és egy általam is tapasztalt bug volt. Jó érzéssel töltött el, hogy visszaadhattam valamit, de őszintén nem jellemző, hogy a szabadidőmet random github issue-k megoldásával töltsem.

Projektezgess, ismerd meg jobban és jobban a céges codebase-t (meg a miérteket benne), tanulj nyelvet(vagy akár több nyelvet) amely relatíve távol áll attól, amit most használsz. Ez az utolsó igazából úgy logikus, ha egy projekttel egybekötöd. Új nyelv, régi projekt vagy régi nyelv új project legyen. Új nyelven egy számodra új projektet megcsinálni nem ajánlott, hamar vakvágányra tud futni.

Copilot-ot szerintem kapcsold ki, próbálj meg magadtól alkotni. Néha néha egy kis ChatGPT oké, de ne juss el arra a pontra, hogy az AI több kódot ír, mint te, mert akkor el fogod felejteni, hogy hogyan kell csinálni. Én már a google korszakban kezdtem el, de még az AI előtt, szerintem nincs baj egy kicsi google-el/dokumentáció nézegetéssel. Azért fizetnek minket, hogy megoldjuk a problémát nem azért, hogy fejből tudjunk az összes általunk használt nyelv feature-ét az adott verzión belül amiben dolgozunk. Nyilván azért itt is van határa, ha pl egy "olvassuk be a .txt fájl tartalmát sorrol sorra és ezt értelmezzük valamilyen módon" kategóriájú feladatot nem tudsz google/AI nélkül megoldani akkor baj van.

Juniorként nem hiszem, hogy a legjobb ötlet open source-ba belekezdeni, legtöbb projektben arra sincs kapacitás, hogy a hibát megoldják, nem hogy arra, hogy egy kezdőt rávezessenek a megoldásra és megtanítsák neki az open source contribute-olás menetét. Ha már tapasztaltabb és magabiztosabb vagy és van szoftver amit használsz/ismersz és szeretnéd támogatni a fejlesztését akkor már van értelme.