Hva er vel bedre enn å skrive på Habr om utvikling? Mens noen forbereder den store habraposten sin i anfall og start om kveldene, her, rett i arbeidstiden, deler du interessante ting med samfunnet og får utbytte av det.
Hvilken jobb kan være verre enn å skrive om utvikling på Habr? Mens noen skriver kode hele dagen, ser du på disse menneskene og slikker leppene dine, og du jobber med kjæledyrprosjektet ditt i anfall og starter om kveldene.
Vi () hvert år holder vi flere og flere forskjellige konferanser for utviklere, så vi søker nå etter en annen medarbeider (i tillegg til meg og ) for tekster i habrabloggen vår. For å gjøre det klart hvem vi trenger og hva som venter denne personen, beskrev jeg hvordan det er generelt når jobben din er å skrive tekster for utviklere på en bedriftsblogg på Habré.
Hva er kult?
Hva liker jeg med denne jobben? Selv om målet med enhver bedriftsblogg er å hjelpe selskapet, betyr det ikke her "å skrive en glødende salgstekst om hvor fantastisk det er." Dette fungerer rett og slett ikke på Habré. En annen ting fungerer her: skriv innlegg som er interessante og nyttige for fellesskapet, der omtale av aktivitetene dine virker passende.
Du kan skrive "konferansene våre er fantastiske og utrolige" minst ti ganger uten argumenter, og rett og slett ingen vil lese det. Eller du kan publisere en tekstutskrift av en rapport fra en tidligere konferanse, folk vil strekke seg etter informasjon som er nyttig for dem - og samtidig, ved å bruke et ekte eksempel, vil de forstå hva som kan sees på arrangementet og om de ønsker å gå til dette neste gang.
Hvis jeg ble pålagt å kontinuerlig skrive tekster bestående av reklame-tull, ville jeg veldig fort ønsket å henge meg. Heldigvis skriver jeg i stedet tekster om temaene for konferansene våre, der det på slutten bare er en liten merknad "siden du ble tiltrukket av denne teksten om mobilutvikling, vær oppmerksom, her er en konferanse om det."
En annen fordel med denne jobben er at du får samhandle med mange kule mennesker. Når en del av jobben din er å intervjue noen av kaliber Jonah Skeete, du lytter til svarene hans med tilbakeholdt pust, og på slutten sier han "takk for spørsmålene, det var interessant", du tar deg selv i å tenke "vent, jeg betaler for dette de betaler også"?
Vel, en bonus for elskere av mage: når du skriver habraposter er jobben din, og du publiserer dem ofte, kan du nå førsteplassen i rangeringen av habra-brukere. Og da vil du begynne å motta rare personlige meldinger!
Hva er vanskeligheten?
Men alle disse godsakene betyr ikke at alt er perfekt. Hovedutfordringen er dette.
På den ene siden er det klart at jo mer du vet om utvikling, desto bedre er det for slikt arbeid, og hvis du er veldig oppslukt av et spesielt tema, så kan du skrive noe kult i forbindelse med det.
Men samtidig har vi en rekke konferanser innen ulike områder (fra Java til testing), så for hver forfatter er det flere arrangementer som må dekkes, og nye kan legges til når som helst. Dette betyr at du ikke vil være i stand til å begrense deg til favorittemnet ditt, og du må fordype deg i noe helt annet, mye mindre kjent. Og samtidig er konferansene våre ganske hardcore, deres besøkende er ikke nye i bransjen, så innholdet bør være av interesse for erfarne utviklere.
Å være senior i flere retninger samtidig er generelt urealistisk. Legg nå til dette at du heller ikke jobber som utvikler: en del av arbeidstiden din kan vies til kode for ikke å bryte ut av fagområdet, men dette er ikke hovedaktiviteten. Og legg til dette regelmessigheten til innlegg: hvis folk som skriver til Habr på sjelens kall kan bruke måneder på å tegne opp ett emne før de komponerer teksten, så vil ikke dette fungere her.
Hvordan er det under slike forhold mulig å skrive noe som kan interessere erfarne utviklere?
Det kan virke som om alt er helt dystert, men det er ganske brukbare alternativer.
Hvordan leve?
For det første, selv om du ikke kan skrive om mange emner uten omfattende personlig arbeidserfaring, er det også mange som ikke krever dette.
En ny versjon av Java har dukket opp, og utviklere lurer på "hva har endret seg der"? For et normalt innlegg om dette må du kunne skrive i Java, men du trenger ikke "måneders erfaring" spesifikt med den nye versjonen; det er nok å forstå engelskspråklige kilder (det er også nyttig å prøve ut) innovasjoner personlig, men dette kan gjøres raskt). Kommer denne nye versjonen av Java med et JShell-verktøy? Siden det er nytt, vil selv erfarne utviklere finne opplæringen nyttig, og før du skriver den, er det nok å leke med JShell i en time eller to ("måneder" i en REPL er rett og slett ingenting å bruke på). GitHub gjort private depoter gratis? Selvfølgelig vil jeg umiddelbart informere hubbrowserne om slike nyheter, og det vil ta litt tid for research (slik at innlegget ikke bare er en linje), men også beskjedent.
For det andre, hvis du brenner for et bestemt emne og forstår det dypt, så er dette også fantastisk. Ja, du vil ikke kunne skrive om det hver dag; oftere må du forholde deg til noe annet - men når blant annet favorittemnet ditt kommer opp, vil kunnskapen komme godt med. Her tullet Oleg med Graal-prosjektet allerede før det ble mote, så han spurte villig Chris Thalinger, som jobber med Graal, om ting som inlining-parametere - vel, flott: til slutt var både Oleg og andre interesserte i emnet interessert.
Og for det tredje kan du ikke begrense deg til din egen kompetanse, koble andres. For eksempel i et intervjuformat, hvor du ikke trenger å vite alle svarene i verden, men kunne stille spørsmål. De mest interessante menneskene fra hele verden kommer for å tale på konferansen vår, fra .NET-legenden Jeffrey Richter til hodet til Kotlin Andrew Breslav, det er synd å ikke stille slike spørsmål. Det viser seg å være en fullstendig vinn/vinn: både intervjueren er interessert og leserne av Habr er interessert (rekorden vår var med det samme Jon Skeet, som har samlet mer enn 60 000 visninger), og foredragsholderne selv er vanligvis glade for å gi intervjuer på kvelden før konferansen, og dette er en åpenbar fordel for konferansen.
For å stille spørsmål til slike mennesker kreves det selvfølgelig også viss kunnskap – men omfanget av kravene er helt annerledes.
En annen måte å dele andres kompetanse på er de allerede nevnte tekstutskriftene av rapporter. Det hender også at en av våre foredragsholdere publiserer et blogginnlegg på engelsk, og vi, etter avtale med ham, oversetter det til russisk. I slike tilfeller må du forstå teksten, men du trenger ikke være en ekspert som kan skrive den.
Hva fører dette til?
Fra min egen erfaring vil jeg si at med denne typen arbeid ser man på IT fra et ganske interessant perspektiv.
Generelt kan dette være støtende: det foregår en slags bevegelse overalt, folk skaper interessante ting, og du ser på alt dette "fra utsiden", stiller spørsmål, og til slutt forstår du noe om hver av disse ting overfladisk, men i detaljene i implementeringen forstår du det ikke allerede - for å finne ut av det, må du hele tiden jobbe med det. Det er sannsynligvis også mye interessant i dypet; å se alt dette med et blikk frister deg bare!
Men samtidig, mens du taper i dybden, får du bredde i dekningen – og dette er også verdifullt. Hvis du jobber i en spesifikk rolle i et spesifikt prosjekt, så ser du alt gjennom dette prismet: noe faller ikke inn i synsfeltet i det hele tatt, noe du ser fra siden ("testere er de dårlige menneskene som bryter den vakre koden min ”). Og når du skriver om forskjellige ting, ser du veldig forskjellige ting, og ikke "fra siden", men fra et fugleperspektiv: du kan ikke se detaljene, men du får helhetsbildet i hodet. Jeg snakket (både i intervjuer og bare på konferansene våre) med mange helt forskjellige mennesker: fra kompilatorer til testere, fra Googlere til startupere, fra de som skriver i Kotlin til de som skriver Kotlin selv.
En JS-utvikler kan være nysgjerrig på å lese habraposter fra C++-verdenen ("hva har de der?"), men han vil bli overveldet av materialer i hovedfeltet og vil ikke komme til disse ikke-kjernematerialene. For meg er nesten alle områder spesialiserte; all tekst jeg leser om utvikling og testing kan være nyttig i arbeidet mitt.
Jeg føler at jeg på en måte er veldig heldig: i motsetning til folk flest kan jeg i arbeidstiden med interesse følge med på hvordan utviklingen generelt lever og utvikler seg.
Hvem trenger vi?
Av alt dette følger det at slikt arbeid krever en ganske unik person.
Han (eller hun) må ha god forståelse for utvikling, men samtidig være villig til å gjøre noe annet enn selve utviklingen.
Å forstå utvikling krever ikke bare fra et kodeperspektiv, men også fra et fellesskapsperspektiv. Du må snakke samme språk med utviklere og vite hva som bekymrer dem.
Du trenger en kombinasjon av initiativ og flid. På den ene siden er det standardoppgaver som må fullføres (for eksempel har vi de tradisjonelle "topp 10 rapportene fra siste konferanse"-innlegg). På den annen side ønsker vi at du selv kommer med ideer til interessante tekster, og ikke bare venter på instruksjoner.
Selvfølgelig må du kunne skrive: både fra et leseferdighetssynspunkt og fra synspunktet om å "gjøre det interessant." Vi verdsetter tekster som ikke bare ser ut som en tørr teknisk opplæring, men som virkelig er fengslende. Hvis du for eksempel har en personlig historie fra livet ditt som på en eller annen måte krysser temaet for materialet, kan det være en utmerket introduksjon.
Fleksibilitet kreves også: akkurat nå er vi først og fremst opptatt av tekster på .NET og testing, så vi er spesielt interessert i personer med relevant kompetanse, men prioriteringer kan endre seg. I tillegg til Habr publiserer vi noen ganger på andre nettsteder, og vi må også kunne tilpasse oss dette (essensen forblir den samme, "tekster for utviklere", men formatet kan variere).
Og selv om ingen krever at vi jobber utenom arbeidstiden, vil IT-nerder som på fritiden jobber med et kjæledyrprosjekt for moro skyld eller leser om IT, føle seg på sin plass her: dette løser ikke direkte arbeidsproblemer, men til slutt bidrar til å løse de er mer effektive.
Hvis alt som er skrevet ovenfor ikke skremte deg vekk, men interesserte deg, og du vil vite flere detaljer eller svare, kan begge gjøres på .
Kilde: www.habr.com