Wat is een betere baan dan op Habr schrijven over ontwikkeling? Terwijl iemand 's avonds met horten en stoten zijn grote habrapost klaarmaakt, deel jij hier, precies tijdens werktijd, interessante dingen met de gemeenschap en profiteer je ervan.
Welke baan is erger dan schrijven over ontwikkeling op Habr? Terwijl iemand de hele dag code schrijft, kijk jij naar deze mensen en lik je je lippen, en werk je 's avonds met horten en stoten aan je lievelingsproject.
Wij () elk jaar houden we steeds meer verschillende conferenties voor ontwikkelaars, daarom zijn we nu op zoek naar een andere medewerker (naast mij en ) voor teksten in onze habrablog. Om duidelijk te maken wie we nodig hebben en wat deze persoon te wachten staat, heb ik beschreven hoe het in het algemeen is als het jouw taak is om teksten te schrijven voor ontwikkelaars op een bedrijfsblog op Habré.
Wat is cool?
Wat ik zo leuk vind aan deze baan? Hoewel het doel van elke bedrijfsblog is om het bedrijf te helpen, betekent dat hier niet 'goede verkoopteksten schrijven over hoe geweldig het is'. Dit werkt simpelweg niet op Habré. Hier werkt nog iets: schrijf berichten die interessant en nuttig zijn voor de gemeenschap, waarin vermelding van uw activiteiten passend lijkt.
Je kunt minstens tien keer zonder argumenten schrijven: “Onze conferenties zijn geweldig en ongelooflijk”, en niemand zal het lezen. Of u kunt een teksttranscriptie publiceren van een rapport van een afgelopen conferentie, mensen zullen op zoek gaan naar informatie die voor hen nuttig is - en tegelijkertijd zullen ze, aan de hand van een echt voorbeeld, begrijpen wat er op het evenement te zien is en of ze willen hier de volgende keer naartoe.
Als ik voortdurend teksten zou moeten schrijven die uit reclame-onzin bestaan, zou ik mezelf heel snel willen ophangen. Gelukkig schrijf ik in plaats daarvan teksten over de onderwerpen van onze conferenties, waar aan het einde gewoon een kleine opmerking staat “aangezien je werd aangetrokken door deze tekst over mobiele ontwikkeling, let op, hier is een conferentie erover.”
Een ander voordeel van deze baan is dat je met veel leuke mensen in contact komt. Als een deel van uw werk het interviewen van iemand van kaliber is Jonas Skeete, je luistert met ingehouden adem naar zijn antwoorden, en aan het eind zegt hij “bedankt voor de vragen, het was interessant”, betrap je jezelf erop dat je denkt “wacht, ik betaal hiervoor zij betalen ook"?
Welnu, een bonus voor buikliefhebbers: als het schrijven van habraposts jouw taak is, en je publiceert ze vaak, kun je de eerste plaats bereiken in de ranglijst van habra-gebruikers. En dan zul je vreemde persoonlijke berichten gaan ontvangen!
Wat is de moeilijkheid?
Maar al dit lekkers betekent niet dat alles perfect is. De belangrijkste uitdaging is deze.
Aan de ene kant is het duidelijk dat hoe meer je weet over ontwikkeling, hoe beter dergelijk werk is, en als je erg verdiept bent in een bepaald onderwerp, dan kun je er iets leuks over schrijven.
Maar tegelijkertijd hebben we een aantal conferenties op verschillende gebieden (van Java tot testen), dus voor elke auteur zijn er verschillende evenementen die moeten worden besproken, en er kunnen op elk moment nieuwe worden toegevoegd. Dit betekent dat je je niet kunt beperken tot je favoriete onderwerp en je zult moeten verdiepen in iets heel anders, veel minder bekend. En tegelijkertijd zijn onze conferenties behoorlijk hardcore, hun bezoekers zijn niet nieuw in de branche, dus de inhoud moet interessant zijn voor ervaren ontwikkelaars.
Senior zijn in meerdere richtingen tegelijk is over het algemeen onrealistisch. Voeg daar nu aan toe dat je ook niet als ontwikkelaar werkt: een deel van je werktijd kan aan code worden besteed om niet af te wijken van het vakgebied, maar dit is niet de hoofdactiviteit. En voeg daarbij de regelmaat van de berichten: als mensen die op verzoek van hun ziel naar Habr schrijven, maanden kunnen besteden aan het opstellen van één onderwerp voordat ze de tekst opstellen, dan zal dit hier niet werken.
Hoe is het onder dergelijke omstandigheden überhaupt mogelijk om iets te schrijven dat ervaren ontwikkelaars zou kunnen interesseren?
Het lijkt misschien dat alles volkomen somber is, maar er zijn redelijk werkbare opties.
Hoe te leven?
Ten eerste: hoewel je niet over veel onderwerpen kunt schrijven zonder uitgebreide persoonlijke werkervaring, zijn er ook genoeg waarvoor dit niet nodig is.
Er is een nieuwe versie van Java verschenen en ontwikkelaars vragen zich af "wat is daar veranderd"? Voor een normaal bericht hierover moet je in Java kunnen schrijven, maar specifiek met de nieuwe versie heb je geen “maanden ervaring” nodig; het is voldoende om Engelstalige bronnen goed te begrijpen (het is ook handig om het uit te proberen innovaties persoonlijk, maar dit kan snel). Wordt deze nieuwe versie van Java geleverd met een JShell-tool? Omdat het nieuw is, zullen zelfs ervaren ontwikkelaars de tutorial nuttig vinden, en voordat je hem schrijft, is het voldoende om een uur of twee met JShell te spelen (“maanden” in een REPL zijn simpelweg niets om aan uit te geven). GitHub heeft privérepository's gratis gemaakt? Natuurlijk zou ik de hubbrowsers onmiddellijk over dergelijk nieuws willen informeren, en het zal enige tijd duren voor onderzoek (zodat het bericht niet slechts één regel is), maar ook bescheiden.
Ten tweede, als je gepassioneerd bent over een bepaald onderwerp en het diep begrijpt, dan is dit ook geweldig. Ja, je zult er niet elke dag over kunnen schrijven; vaker zul je met iets anders te maken krijgen - maar als onder andere je favoriete onderwerp ter sprake komt, dan komt de kennis wel van pas. Hier was Oleg al aan het sleutelen aan het Graal-project voordat het in de mode kwam, dus vroeg hij Chris Thalinger, die bij Graal werkt, graag naar zaken als het inlinen van parameters - nou ja, geweldig: uiteindelijk waren zowel Oleg als anderen die in het onderwerp geïnteresseerd waren geïnteresseerd.
En ten derde kun je jezelf niet beperken tot je eigen competentie en die van iemand anders verbinden. Bijvoorbeeld in een interviewformat, waarbij je niet alle antwoorden van de wereld hoeft te weten, maar wel vragen kunt stellen. Op onze conferentie komen de meest interessante mensen van over de hele wereld spreken, van de .NET-legende Jeffrey Richter naar het hoofd van Kotlin Andrew Breslav, het is een zonde om zulke vragen niet te stellen. Het blijkt een complete win/win te zijn: zowel de interviewer als de lezers van Habr zijn geïnteresseerd (ons record was met hetzelfde Jon Skeet, die meer dan 60 keer bekeken is), en de sprekers zelf geven doorgaans graag interviews aan de vooravond van de conferentie, en dit is een duidelijk voordeel voor de conferentie.
Om zulke mensen te ondervragen is natuurlijk ook bepaalde kennis vereist, maar de omvang van de vereisten is compleet anders.
Een andere manier om de competentie van iemand anders te delen zijn de reeds genoemde teksttranscripties van rapporten. Het komt ook voor dat een van onze sprekers een blogpost in het Engels publiceert, en wij, in overleg met hem, deze naar het Russisch vertalen. In dergelijke gevallen moet u de tekst begrijpen, maar hoeft u geen expert te zijn die de tekst kan schrijven.
Waar leidt dit toe?
Uit eigen ervaring wil ik zeggen dat je met dit soort werk vanuit een nogal interessant perspectief naar IT kijkt.
Over het algemeen kan dit aanstootgevend zijn: er is overal een soort beweging gaande, mensen werken aan interessante dingen, en je bekijkt dit allemaal “van buitenaf”, stelt vragen en uiteindelijk begrijp je iets van elk van de dingen. deze dingen oppervlakkig, maar in de details van de implementatie begrijp je het al niet - om het uit te zoeken, zou je er constant mee moeten werken. Er zijn waarschijnlijk ook veel interessante dingen in de diepte; als je dit allemaal in één oogopslag ziet, kom je alleen maar in de verleiding!
Maar tegelijkertijd, terwijl u aan diepte verliest, wint u aan dekking in de breedte - en dit is ook waardevol. Als je in een specifieke rol in een specifiek project werkt, dan zie je alles door dit prisma: iets valt helemaal niet in het gezichtsveld, iets dat je vanaf de zijkant ziet (“testers zijn die slechte mensen die mijn mooie code breken ”). En als je over verschillende dingen schrijft, zie je heel verschillende dingen, en niet ‘van de zijkant’, maar vanuit vogelperspectief: je ziet de details niet, maar je krijgt het totaalbeeld in je hoofd. Ik heb met heel veel verschillende mensen gesproken (zowel in interviews als alleen op onze conferenties): van compilers tot testers, van Googlers tot startups, van degenen die in Kotlin schrijven tot degenen die Kotlin zelf schrijven.
Een JS-ontwikkelaar is misschien nieuwsgierig naar habraposts uit de C++-wereld (“wat hebben ze daar?”), maar hij zal overweldigd worden door materialen op het hoofdgebied en zal niet toekomen aan deze niet-kernmaterialen. Voor mij zijn bijna alle vakgebieden gespecialiseerd; elke tekst die ik lees over ontwikkelen en testen kan nuttig zijn in mijn werk.
Ik heb het gevoel dat ik in zekere zin veel geluk heb: in tegenstelling tot de meeste mensen kan ik tijdens werkuren met belangstelling kijken hoe de ontwikkeling in het algemeen leeft en zich ontwikkelt.
Wie hebben we nodig?
Uit dit alles volgt dat dergelijk werk een vrij uniek persoon vereist.
Hij (of zij) moet een goed inzicht hebben in ontwikkeling, maar tegelijkertijd bereid zijn iets anders te doen dan de ontwikkeling zelf.
Het begrijpen van ontwikkeling vereist niet alleen vanuit een codeperspectief, maar ook vanuit een gemeenschapsperspectief. Je moet dezelfde taal spreken met ontwikkelaars en weten wat hen zorgen baart.
Je hebt een combinatie van initiatief en toewijding nodig. Aan de ene kant zijn er standaardtaken die moeten worden voltooid (we hebben bijvoorbeeld de traditionele “top 10-rapporten van de laatste conferentie” -berichten). Aan de andere kant willen we dat je zelf ideeën aandraagt voor interessante teksten, en niet alleen maar wacht op instructies.
Natuurlijk moet je kunnen schrijven: zowel vanuit het oogpunt van geletterdheid als vanuit het oogpunt van ‘het interessant maken’. Wij waarderen teksten die er niet alleen uitzien als een droge technische tutorial, maar echt boeiend zijn. Als je bijvoorbeeld een persoonlijk verhaal uit je leven hebt dat op de een of andere manier aansluit bij het onderwerp van het materiaal, kan dit een uitstekende introductie zijn.
Flexibiliteit is ook vereist: op dit moment houden we ons vooral bezig met teksten over .NET en testen, dus we zijn vooral geïnteresseerd in mensen met relevante competenties, maar prioriteiten kunnen veranderen. Naast Habr publiceren we soms op andere sites en moeten we ons daar ook op kunnen aanpassen (de essentie blijft hetzelfde, “teksten voor ontwikkelaars”, maar het formaat kan verschillen).
En hoewel niemand van ons verlangt dat we buiten werktijd werken, zullen IT-geeks die in hun vrije tijd voor de lol aan een lievelingsproject werken of over IT lezen, zich hier op hun plaats voelen: dit lost werkproblemen niet direct op, maar uiteindelijk helpt oplossen, zijn ze effectiever.
Als alles wat hierboven is geschreven u niet heeft afgeschrikt, maar u heeft geïnteresseerd, en u meer details wilt weten of wilt reageren, kunt u beide doen op .
Bron: www.habr.com