Hej!
I de seneste par år har jeg arbejdet meget med folk, der lige er begyndt deres karriere inden for IT. Da både spørgsmålene og måden, de bliver stillet på, ofte er ens, besluttede jeg at samle mine erfaringer og anbefalinger et sted.
For længe siden læste jeg en bog fra 2004 af Eric Raymond, og jeg har ufravigeligt fulgt den i min karriere. Den er ret omfattende og er mere rettet mod systemadministratorer. Jeg skal dog ofte hjælpe folk, der slet ikke har erfaring i udvikling, med at blive juniorer og starte deres karriere.
Til dem, der allerede er blevet eller drømmer om at blive nye udviklere, kan jeg give følgende anbefalinger:
- Studer problemet selvstændigt
- Først angiv målet, derefter problemstillingen
- Skriv klart og præcist
- Stil relevante spørgsmål og del løsninger
- Respekter andres tid
- Tænk bredere
Og nu lidt mere detaljeret.
Studer problemet selvstændigt
Du studerer et programmeringssprog gennem en bog eller et kursus. Du har taget et kodeeksempel, kørt det, men det gik ned med en fejl, som du ikke forstår. Hvis man skal tro bogen, skulle det virke. Men du kan se med egne øjne, at det ikke fungerer. Hvilke muligheder har du?
- At beslutte, at du aldrig vil blive udvikler, fordi verden er imod dig, og selv fungerende eksempler ikke virker. At opgive din lære;
- At beslutte, at du aldrig vil blive udvikler, fordi du er for dum eller ikke har talent. At opgive din lære;
- At begynde at spørge alle bekendte, der har en eller anden forbindelse til IT, og insistere på, at de finder ud af, hvorfor det ikke virker for dig. At lære meget om dig selv og blive fornærmet. At opgive din lære;
Hvilket valg er det rigtige? Her er det:
At forstå, at du ikke er unik (uanset hvad mor og bedstemor siger), og IT-verdenen ikke er så simpel, som det bliver præsenteret, når de inviterer dig til kurser og webinars.
At forstå, at du ikke er unik, fører til en bevidsthed om, at dit problem helt sikkert allerede har været mødt af dusinvis, hundreder eller tusinder af mennesker. Hvis du er en ny udvikler, kan du nemt have overset, ikke installeret eller ikke konfigureret noget. Her er en tjekliste, som jeg foreslår, at du gennemgår, før du indser, at du ikke kan løse problemet selv, og at du har brug for hjælp:
- At sikre, at spørgsmålet er unikt, og at der ikke er svar på internettet
- At undersøge årsagen til problemet nøje, ikke bare følgerne
- Vurdere mulige løsninger på problemet, deres fordele og ulemper
- Overveje alternative måder at nå målet på
- Tænke over, hvad man kan blive spurgt om, og forberede svarene på forhånd
Med anges først det er ganske enkelt: hvis fejlmeddelelsen er helt uforståelig, så kopier den ind i Google og læs grundigt teksten på linksene.
Anden: for eksempel, hvis din kode fejler med fejlen "Kan ikke tilslutte eksternt bibliotek", så er det ikke din kode, der er problemet. Problemet er, at du ikke har installeret et bibliotek, som du ønsker at bruge. Så skal du finde ud af, hvordan du installerer det, ikke hvordan du reparerer din kode.
Tredje og fjerde meget ligesom: Hvad hvis problemet faktisk ligger i dette bibliotek, og jeg bare skal finde et andet? Hvad hvis jeg slet ikke bruger et eksternt bibliotek, men skriver min egen kode ved hjælp af standardværktøjer?
Femte punktet fører os til den næste del: tænk på, hvad personen, du henvender dig til, kan spørge dig om, og hav svarene klar.
Først angiv målet, derefter problemstillingen
Målet er det, du ønskede at gøre. For eksempel, at skrive kode, der går online og gemmer 10 billeder af sjove katte. Problemet er den fejl, du ser i konsollen, men ikke ser 10 sjove katte. Start ikke dit spørgsmål med problemet. Start med målet, afslut med problemet. Hvis personen, du beder om hjælp, er en erfaren udvikler med meget viden, kan han helt sikkert foreslå en enklere og mere elegant løsning på problemet. Hvis du allerede har valgt den enkleste og mest elegante løsning - vil han forstå klart, hvad og hvorfor du ønsker at gøre det, og det vil fremskynde modtagelsen af svar.
Godt spørgsmål:
Jeg vil gemme 10 sjove katte hver dag, så jeg kan grine og forlænge mit liv. For dette har jeg skrevet sådan en kode: […]. Jeg forventer, at den vil oprette forbindelse til FTP server og hente nye billeder derfra. Men når jeg kørte det, så jeg denne fejl: […] Selvom jeg kan tilgå denne server via browseren.
Hurtigt svar:
Du har forkert valgt dette bibliotek, det har ikke været understøttet eller udviklet i lang tid. Tag hellere dette — jeg downloader billeder med det!
Dårligt spørgsmål:
Hej, min kode gav mig denne fejl […], ved du måske, hvad problemet kan være?
Åbenbart svar:
Hej. Nej, det ved jeg ikke.
Skriv klart og præcist
Undgå at overøse personen med tankestrømme. Den person, du henvender dig til for at få løst et problem, er optaget af sine egne opgaver. Gør det klart for vedkommende, hvad dit problem er, og hvad du ønsker fra dem. Hvis du har problemer med din skriftlighed, kan du benytte online tjenester til at tjekke stavning og tegnsætning. Du kan også rense din besked for overflødige ord uden online værktøjer. Vær kortfattet, kom til sagen, og vær seriøs. Giv eksempler.
Dårligt:
— hej, hvordan gik weekenden))) Jeg forsøger kort at samle et projekt, men det virker ikke, det falder på en eller anden måde O_0 selvom jeg har gjort alt som det skal, kom lige forbi))))) der er noget uforståeligt i konsollen((( jeg har allerede prøvet alt, men intet fungerer, aaah(
Godt:
— Hej, jeg prøver at starte et projekt, men jeg har stødt på et problem. Det falder straks efter kommandoen docker-compose up, her er loggen og fejlen: […] Kan du hjælpe mig med at løse det?
Stil relevante spørgsmål og del løsninger
Det er ikke en god idé at stille spørgsmålet som en personlig besked til en bestemt person, medmindre du har fået at vide, at du skal spørge netop dem. Det er bedre at skrive til en gruppe mennesker, fordi:
- Alle er optaget af at løse deres egne problemer. Chancerne for, at nogen i den generelle chat eller på forummet kan tage sig tid til at hjælpe dig, er højere.
- Chancerne for, at nogen i den generelle chat ved, hvordan de kan hjælpe dig, er større.
- Du giver andre mulighed for senere at finde samme spørgsmål og svar.
Tag et kig på det sidste punkt. Har du allerede lært, at man skal forsøge at løse problemer selv? Har du allerede brugt søgefunktionen i chatten/forummet/gruppen, men ikke fundet omtale af dit problem? Okay, så spørg.
På den anden side bør du undgå at forstyrre folk unødigt. Så vidt muligt, udelad dem, der ikke kan hjælpe dig, fra modtagerlisten. Jo flere beskeder en person modtager, jo mindre sandsynligt er det, at de læser dem alle. Skab ikke en vane hos folk om at slukke for notifikationer eller ignorere beskeder.
Din erfaring kan helt sikkert være nyttig for andre. Spar tid for dig selv og andre ved at offentliggøre dit svar eller din løsning. Den næste nybegynder vil, hvis han allerede kender til det, vi taler om her, slet ikke besværliggøre situationen - han vil finde din løsning via søgning. Hvorfor siger jeg, at du kan spare tid for dig selv? Fordi du måske støder på dette problem om et år, og ikke kan huske, hvordan du løste det. Søgning vil redde dig igen.
Respekter andres tid
Gør livet så nemt som muligt for dem, du beder om hjælp.
Sørg for, at de links, du sender, fungerer. Prøv at åbne dem i inkognito-tilstand. Hvis linket kræver login, vil du se en adgangsfejl. For eksempel, hvis du har uploadet kode til et privat repository, eller sendt et link til Google Drive, som kun du har adgang til - vil personen se en fejl, og de vil skulle bruge tid på at informere dig om dette, og derefter vente på, at du konfigurerer adgangen. Sørg for, at personen straks kan se det, du taler om.
Forvent ikke, at nogen ønsker at huske, hvad du spurgte om for to dage siden. Send oplysningerne igen, mind dem om konteksten. Ingen ønsker at lede gennem korrespondancen for det, du har lige ved hånden. Hvis du er for doven til at duplikere oplysningerne, så folk ikke bruger tid på at lede, har du ikke brug for hjælp.
Skil ikke tingene ad fra deres kontekst. Hvis du sender en log med en fejl, er det åbenlyst nødvendigt at inkludere ikke kun selve fejlen, men også koden, der forårsagede den, med et eksempel på, hvad den gik i stå på.
Hvis der er en etableret proces til løsning af dit problem - følg den. Det giver ikke mening at genopfinde hjulet, hvis der allerede findes en artikel med en trin-for-trin HowTo.
Det er ikke en god idé at bede om svar fra én person på forskellige kanaler (skrive i Slack, Skype, Telegram) på én gang - det vil være ubehageligt for personen.
Det er ikke nødvendigt at sende den samme besked til flere personer på én gang, i håbet om at nogen vil svare. Alle disse personer kan give dig et svar (sandsynligvis vil det være det samme), men de vil alle for en tid blive distraheret fra deres arbejde. Brug gruppechats.
Tænk bredere
Alt, hvad vi har talt om her, gælder også uden for IT-verdenen. Følg disse regler i supermarkedet, bilværkstedet, på ferie i et andet land, når du interagerer med venner og familie. Vis folk, at du værdsætter deres tid, og at du ikke ønsker at belaste dem med småting. Vis, at du har brugt kræfter og tid på at løse problemet selv, men at det ikke lykkedes, og at du virkelig har brug for hjælp. Som tak vil folk forstå dine problemer og hjælpe med at løse dem.
Kilde: habr.com
