Hallo!
De laatste paar jaar werk ik veel met mensen die net beginnen aan hun carrière in de IT. Omdat zowel de vragen als de manier waarop ze gesteld worden bij veel mensen vergelijkbaar zijn, heb ik besloten mijn ervaring en aanbevelingen op één plek te verzamelen.
Lang geleden las ik het boek van Eric Raymond uit 2004, en heb ik het in mijn carrière altijd strikt gevolgd. Het is behoorlijk omvangrijk en meer gericht op systeembeheerders. Ik help mensen die vaak helemaal geen ervaring hebben in de ontwikkeling om junioren te worden en hun carrière te beginnen.
Voor degenen die al zijn geworden of nog steeds dromen van het worden van een beginnende ontwikkelaar, kan ik de volgende aanbevelingen geven:
- Bestudeer het probleem zelfstandig
- Communiceer eerst het doel, en breng daarna het probleem ter sprake
- Schrijf correct en to the point
- Stel gerichte vragen en deel de oplossingen
- Respecteer de tijd van anderen
- Kijk breder
Laten we nu dieper ingaan op de details.
Bestudeer het probleem zelfstandig
Je studeert een programmeertaal via een boek of cursus. Je hebt een stuk code gepakt, uitgevoerd, maar het faalt met een fout die voor jou onbegrijpelijk is. Als je de boek gelooft, zou het moeten werken. Maar je vertrouwt je ogen - het werkt niet. Wat zijn de opties?
- Beslissen dat je nooit een ontwikkelaar zult worden omdat de hele wereld tegen je is, en zelfs werkende voorbeelden niet werken. Stoppen met leren;
- Beslissen dat je nooit een ontwikkelaar zult worden omdat je te dom bent of dat het je niet gegeven is. Stoppen met leren;
- Begin te vragen aan iedereen die op de een of andere manier met IT te maken heeft, en eis dat ze uitzoeken waarom het voor jou niet werkt. Veel over jezelf leren, beledigd zijn. Stoppen met leren;
Welke optie is juist? Hier is die:
Begrijp dat je niet uniek bent (wat je moeder of grootmoeder ook zegt), en de wereld van IT is niet zo eenvoudig als ze beweren wanneer ze je naar cursussen en webinars roepen.
Het besef dat je niet uniek bent, leidt tot de realisatie dat jouw probleem waarschijnlijk al tientallen, honderden, duizenden mensen is overkomen. Als je een beginnende ontwikkelaar bent, heb je gemakkelijk iets kunnen missen, niet geïnstalleerd of niet juist ingesteld. Hier is een checklist die ik voorstel om te doorlopen voordat je beseft dat je het probleem zelf niet kunt oplossen en hulp nodig hebt:
- Zorg ervoor dat de vraag uniek is en dat er geen antwoord op te vinden is op internet
- Bestudeer de oorzaak van het probleem grondig, en niet het gevolg
- Evalueer de mogelijke oplossingsvarianten, hun voor- en nadelen
- Denk na over alternatieve manieren om het doel te bereiken
- Denk na over mogelijke vragen die je kunnen worden gesteld en bereid antwoorden voor
met de eerste Het punt is eenvoudig: als de foutmelding je totaal niet duidelijk is, kopieer je deze in Google en lees je aandachtig de tekst op de links.
De tweedeBijvoorbeeld, als je code crasht met de fout "Kan externe bibliotheek niet verbinden", dan ligt het probleem niet in je code. Het probleem is dat je een bepaalde bibliotheek die je wilt gebruiken niet hebt geïnstalleerd. Je moet dus zoeken hoe je deze kunt installeren, niet hoe je je code kunt repareren.
Derde en vierde zijn vrij vergelijkbaar: Wat als het probleem juist in deze bibliotheek ligt, en ik gewoon naar een andere moet zoeken? Wat als ik helemaal geen externe bibliotheek gebruik, maar mijn eigen code schrijf met standaard middelen?
Vijfde Dit punt leidt ons naar het volgende: denk na over wat de persoon aan wie je je richt je kan vragen, en houd de antwoorden klaar.
Communiceer eerst het doel, en breng daarna het probleem ter sprake
Een doel is wat je wilde bereiken. Bijvoorbeeld, code schrijven die online gaat en 10 foto's van grappige katten opslaat. Een probleem is waarom je een foutmelding in de console ziet, maar geen 10 grappige katten ziet. Begin je vraag niet met het probleem. Begin met je doel, eindig met het probleem. Als de persoon aan wie je om hulp vraagt een ervaren ontwikkelaar is en veel weet, kan hij je ongetwijfeld een eenvoudiger en eleganter oplossing voor het probleem bieden. Als je al de eenvoudigste en elegantste hebt gekozen, zal hij duidelijk begrijpen wat en waarom je wilt doen, en dat versnelt de beantwoording.
Goede vraag:
Ik wil elke dag 10 grappige katten opslaan om te lachen en mijn leven te verlengen. Daarom heb ik deze code geschreven: […]. Ik verwacht dat hij verbinding maakt met FTP server en nieuwe afbeeldingen van daar uploadt. Maar toen ik het uitvoerde, zag ik de volgende foutmelding: […] Hoewel ik via de browser toegang heb tot deze server.
Snelle reactie:
Je hebt deze bibliotheek ten onrechte gekozen, niemand ondersteunt of ontwikkelt deze al lang. Neem maar beter deze — ik download zelf afbeeldingen met katten hiermee!
Slechte vraag:
Hallo, mijn code gaf deze foutmelding […], weet je misschien wat het probleem kan zijn?
Evidente reactie:
Hallo. Nee, dat weet ik niet.
Schrijf correct en to the point
Vermijd het overladen van iemand met een stortvloed aan gedachten. De persoon naar wie je om hulp vraagt, is bezig met zijn eigen zaken. Zorg ervoor dat hij snel begrijpt wat je probleem is en wat je van hem wilt. Als je problemen hebt met de taal, gebruik dan online spelling- en grammaticacontrole. Je kunt ook rommel uit je boodschap verwijderen zonder online diensten. Vermijd overbodige details en ga niet te ver terug. Schrijf kort, bondig en to the point. Geef voorbeelden.
Slecht:
— Hey, hoe was je weekend?))) Ik probeer kort een project samen te stellen, maar het werkt niet, het crasht om de een of andere reden O_ó, hoewel ik alles heb gedaan zoals het moet. Kun je alsjeblieft komen kijken?))))) In de console gebeurt iets onduidelijks((( ik heb alles al geprobeerd, maar niets werkt, aaah(
Goed:
— Hallo, ik probeer een project te starten, maar er is een probleem. Het crasht direct na de opdracht docker-compose up, hier is het opstartlog en de fout: […] Kun je me helpen het op te lossen?
Stel gerichte vragen en deel de oplossingen
Schrijf geen vraag als privébericht aan een specifieke persoon, tenzij je specifiek is verteld dat je het aan hem moet vragen. Het is beter om een groep mensen te benaderen, omdat:
- Iedereen bezig is met zijn eigen problemen. De kans dat iemand in de algemene chat of op het forum je tijd kan geven, is groter.
- De kans dat iemand in de algemene chat weet hoe hij je kan helpen, is groter.
- Je geeft anderen de kans om dezelfde vraag en het antwoord later te vinden.
Kijk naar het laatste punt. Je hebt al geleerd dat je problemen zelf moet proberen op te lossen? Heb je al gezocht in de chat/forum/groep, maar geen vermelding van je probleem gevonden? Oké, dan kun je vragen.
Aan de andere kant, stoor mensen niet onnodig. Probeer iedereen uit de lijst te verwijderen die je niet kan helpen. Hoe meer berichten iemand ontvangt, hoe minder kans dat hij ze allemaal leest. Laat de mensen niet de gewoonte ontwikkelen om meldingen uit te schakelen of je berichten gewoon te negeren.
Zeker, jouw ervaring kan nuttig zijn voor iemand anders. Bespaar tijd voor jezelf en anderen door je antwoord of oplossing te delen. De volgende nieuwkomer, als hij al weet waar we het hier over hebben, zal niemand lastig vallen — hij vindt jouw oplossing via de zoekfunctie. Waarom zeg ik dat je tijd voor jezelf kunt besparen? Omdat je misschien volgend jaar met hetzelfde probleem geconfronteerd wordt en niet meer weet hoe je het op moest lossen. Zoeken zal je opnieuw helpen.
Respecteer de tijd van anderen
Maak het leven van mensen, van wie je om hulp vraagt, zo eenvoudig mogelijk.
Zorg ervoor dat de links die je stuurt, werken. Probeer ze in de incognito-modus te openen. Als de link autorisatie vereist, krijg je een toegangsfout te zien. Bijvoorbeeld, als je de code in een privé repository hebt geüpload, of een link naar een Google Drive hebt gestuurd, waar alleen jij toegang toe hebt — de persoon zal een fout zien en moet tijd besteden om dit aan jou te melden, en dan wachten tot jij de toegang hebt ingesteld. Zorg ervoor dat de persoon meteen ziet waar je het over hebt.
Verwacht niet dat iemand zal willen herinneren wat je twee dagen geleden vroeg. Stuur de informatie nogmaals, herinner de context. Niemand wil door de correspondentie zoeken naar iets wat jij direct bij de hand hebt. Als je te lui bent om de informatie opnieuw te sturen, zodat mensen niet hun tijd aan het zoeken hoeven te besteden, heb je geen hulp nodig.
Trek niet uit de context. Als je een log met een fout stuurt, is het duidelijk dat je niet alleen de fout zelf moet opnemen, maar ook de code die deze heeft veroorzaakt, met een voorbeeld van waar hij is misgelopen.
Als er een vastgesteld proces is voor het oplossen van jouw probleem, volg dit dan. Het is niet nodig om het wiel opnieuw uit te vinden, als er al een artikel met een stap-voor-stap HowTo bestaat.
Probeer niet tegelijkertijd via verschillende kanalen (Slack, Skype, Telegram) dezelfde persoon om een reactie te vragen — dit is vervelend voor de persoon.
Het is niet nodig om hetzelfde bericht tegelijkertijd naar meerdere mensen te sturen, in de hoop dat iemand je zal antwoorden. Al deze mensen kunnen je een antwoord geven (waarschijnlijk zal het hetzelfde zijn), maar ze zullen allemaal een tijdje van hun eigen werk worden afgeleid. Gebruik groepschats.
Kijk breder
Alles wat we hier besproken hebben, is van toepassing buiten de IT-sfeer. Volg deze regels in de supermarkt, de garage, op vakantie in het buitenland, en tijdens gesprekken met vrienden en familie. Laat mensen zien dat je hun tijd waardeert en hen niet wilt storen met onbenulligheden. Toon aan dat je moeite en tijd hebt besteed aan het zelf oplossen van een probleem, maar dat het je niet is gelukt, en dat je echt hulp nodig hebt. In ruil daarvoor zullen mensen begripvol zijn voor je problemen en je helpen bij het vinden van een oplossing.
Bron: habr.com
