Hogyan kérj segítséget?

Pl. a laborvezetődtől

Vagy legalábbis tőlem úgy általánosságban :)

Jól kérdezni nem mindig könnyű. Összeszedtem pár gondolatot a gördülékenyebb segítségnyújtás (és problémamegoldás) érdekében.

• Ezek közül semmi sincs kőbe vésve.
• Örülök bármilyen visszajelzésnek, gondolatnak a lentiekkel kapcsolatban.

Három alapvető szabály:

1. Kérdezz bármit
   • Nincs rossz kérdés. Nem kérdezni rossz.
2. Kérdezz bármikor
3. Ha valami nem egyértelmű, kérj egyértelműsítést.

Amit NE csinálj: Nem tudod, hogy hogyan oldj meg egy problémát, de nem kérsz segítséget senkitől.

Ehelyett csináld inkább ezt:

• Nem vagy biztos abban, hogy hogyan tovább, ezért elmagyarázod valakinek, és meghallgatod, hogy mit gondolnak. (Ez lehet akár egy laborvezető is, vagy egy hallgató társad.)

Checklist

Mivel a tárgyon sokszor ütközhetsz bele alapvetően kódolásos problémákba, ezért összeszedtem ehhez pár gondolatot.

Mindenekelőtt:

• rákerestél Google-ön,

  • vagy legalább DuckDuckGo-n?

• Találtál hasonló kérdést StackOverflow-n?

• Írd le a problémádat. Hol akadtál el? Mit próbáltál? Fordul a kód?

  • Programozóként ne küldj el egy darab kódrészletet önmagában, magyarázat nélkül. Futtasd le, nézd meg mi történik.
    • Olvasd el a dokumentációt. (De legalább a releváns részét.)
    • Kiír valamit a konzol?
    • Lefordult a kód?
    • Próbálj meg debuggert használni...
      • ... vagy legalább rakd tele a kódodat print-ekkel.
      • Azt írja ki, amit vártál?
    • Ha ezek közül egyik sem segít, írd le a tapasztalataidat amikor kérdezel.
  • Minél jobban konkretizálod a kérdésedet, annál könnyebb (értsd: kevesebb idő és energia) válaszolni, és annál jobban átjön az is, hogy foglalkoztál vele, és hogy melyik az a konkrét mozzanat, ami nem világos. Tehát a segítség is hasznosabb lesz.
    • Még ha csak a saját érdekét is nézi az ember, valószínűleg annál korábban kap választ, minél konkrétabb (tehát gyorsabban megválaszolhatóbb) a kérdés.

• Mellékelj egy önmagában értelmezhető kódbázist.

  • Ha pl. a kamera osztály matekjával van bajod, akkor küldd el a számításaid (akár LaTeX-el összedobva / papírról befotózva), és az implementációdat.
  • Ha "mindent próbáltál", de "nem fordul a kódod", vagy "fekete a kép", akkor miután végigmentél az előző pontokon, és leírtad hogy miket próbáltál, küldj el egy MVP-t a problémádról (és ha nem egyértelmű, fordítási utasításokat), amivel ki tudom próbálni.
  • Küldhetsz zip-et emailen, de még jobb, ha hozzáadsz egy privát git repohoz. (@bobarna vagyok GitHub-on, git.sch-n, GitLab-en)

Akadémiai környezetben az email a default. Ne aggódj azon, hogy a címzett ne olvasná az emailjeit. Sőt, nem kizárt, hogy annyi emailt kap minden nap, hogy ha nem kezelné őket hatékonyan és precízen, bele is őrülne. Főleg akadémiában.

Broadcast üzenetek

Minél többen látják, annál több embernek van esélye rá válaszolni. Sokszor akár hallgatótársaid, más laborvezető, vagy akár a tárgy előadója is lehet, hogy válaszol a kérdésedre, ha publikus csatornába dobod be. Erre jó lehet pl. a tárgy Teams csoportja, de van ahol pl. Moodle-t, Piazza-t vagy Slack-et használnak tantermi Q&A-hez csoport szinten.

Ne feledd: ami neked nehézség volt, nem kizárt, hogy másnál is felmerült. Akár megoldotta, akár nem, neki is hasznos lesz a válasz.

Plusz gondolat: legyél igényes a munkádra

Code is read more often than it is written. Code should always be written in a way that promotes readability.

-- Guido Van Rossum

Bármennyire is furcsán hangzik, de még egy egyetemi beadás keretei között is általában egy másik ember fogja elolvasni azt, amit írtál. (Főleg ha csak részben van kész a beadásod, és részpontszámokat kell keresgélni. És persze elvonatkoztatva az automatikus javítástól. Bár még ezutóbbi esetben is hálás leszel magadnak később, ha nem értelmezhetetlen a kódod: meglepő, mennyiszer tér vissza egy-egy megoldásához az ember.)

Valószínűleg nem a 3D Grafikus Rendszerek laborbeadásodat fogod belerakni a virtuális CV-dbe. (Bár egy szépen megcsinált önálló házi feladatnál még ez sem kizárt...) Ennek ellenére most tudod a legjobban begyakorolni azokat a skilleket, amikkel később akár akadémiában, akár a munkaerőpiacon vagy éppen a start-upodban, egy csapat részeként kell hasznosítanod. Minimális plusz idő-és energiaráfordítással hatalmas versenyelőnyre és gyakorlatra tudsz ebben szert tenni.

Ha már a laborvezetőd is ráncolja a homlokát, ahogy a beadásodat bogarássza, képzeld el, mit fog gondolni egy kollégád, amikor meglátja a pull requestedet. Ne feltételezd, hogy ez automatikusan menni fog "amikor majd szükséged lesz rá". Ezt is gyakorlod akkor, amikor sok órát beleraksz egy-egy feladat elkészítésébe. Ne szalaszd el ezt a lehetőséget valós, piacképes, és végtelenül hasznos tapasztalat szerzésére: gondold végig, hogy hogyan lesz kedve bárkinek elolvasni azt, amit írtál.

• Ehhez már akár csak 1-2 komment beszúrása, vagy adekvát változónevek választása is segít. (Egy szépen formázott, követhező README.md-ről már nem is beszélve.)

Források, további olvasásra

• Hasznos tippek email íráshoz (akadémiában és azon túl)
• Pár gondolatot Toshiya Hachisuka Graduate Study Survival Guide írásából vettem át. A fentieken túlmutatóan minden (főleg kutatás iránt érdeklődő) hallgatónak ajánlom végig olvasni, nagyon hasznos és praktikus gondolatok vannak benne.
• StackOverflow: How do I ask a good question?
• gitezéshez bootstrap:
  • röviden
  • kicsit hosszabban és részletesebben